| |
|
Alert Type: | Updated * |
Bug Id: | CSCux20846 | Title: | Nexus 6k: IGMP HAP Reset during "install all" upgrades with IGMPv3 |
|
Status: | Open |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
During an install upgrade of NX-OS in a VPC Nexus 5K/6k vPC, the peer switch may crash due to the IGMP process during pre-upgrade checks.
VDC-1 %$ %SYSMGR-2-SERVICE_CRASHED: Service "igmp" (PID XXXX) hasn't caught signal 11 (core will be saved).
Conditions:
Seen on systems with IGMPv3 configurations and if switch has received IGMP v3 membership reports. This issue is only seen during upgrades or during IGMP process restarts and not during steady state.
Workaround:
Disable IGMP snooping globally on the vPC pair of switches prior to upgrade
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)N1(0.220), 7.3(0)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: | 03-NOV-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)ZD(0.25), 7.3(0)D1(0.143), 7.3(0)IB(0.17), 7.3(0)IB(0.80) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw84708 | Title: * | Evaluation of n9k, n3k, mds, n7k and n5k infra for NTP_October_2015 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 7000 Series Switches 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:
Exposure is not configuration dependent.
Workaround:
Not available.
More-Info:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are: 6.4/5.3
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:L/Au:N/C:N/I:P/A:P/E:F/RL:OF/RC:C/CDP:N/TD:N/CR:L/IR:L/AR:L
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: | 19-NOV-2015 |
|
Known Affected Releases: | 7.3(1)XX(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv42308 | Title: | MST Disputes VPC peer-switch secondary peer sending cost of 250 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
STP/MST disputes downstream from vPC domain with peer-switch
Conditions:
vpc peer-switch configured, this was noticed with MST, unaware if it also affects PVST
Workaround:
Flap the peer-link
Further Problem Description:
If this is encountered, please gather the following from both N7K's and engage TAC:
# show tech detail
# show tech vpc
# show tech stp
# show tech l2fm detail
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(14a)S2, 6.2(14a)S3, 7.2(1)D1(0.104), 7.2(1)D1(1), 7.2(1)ZD(0.95), 7.3(0)D1(0.126), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.69) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux30640 | Title: | After ISSU and "delete of pvlan configured vlans" would crash pvlan |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
After ISSU and "delete of pvlan configured vlans" would crash pvlan feature
Conditions:
After ISSU and "delete of pvlan configured vlans" would crash pvlan feature
Workaround:
After ISSU and "delete of pvlan configured vlans" would crash pvlan feature
Further Problem Description:
After ISSU and "delete of pvlan configured vlans" would crash pvlan feature
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.162) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw16506 | Title: | L2BFD: on F2E the command show system int aclqos info l2bfd no working |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
L2BFD is not up after issu from 6210 to 721
ACL programming didn't happen for l2bfd
Conditions:
It's limited only to F2e card.
ISSU from 6.2.10 to 7.2.1 ( not sure for other release, Shahnaaz can confirm)
Aclqos is accessing vdc-mgr sdb before its downloaded in lc.
Workaround:
After ISSU , restart the aclqos process in F2e module and configure acl/l2bfd.
or reload f2e module after ISSU.
Further Problem Description:
|
|
Last Modified: | 27-NOV-2015 |
|
Known Affected Releases: | 7.2(1)D1(0.68) |
|
Known Fixed Releases: * | 7.3(0)D1(0.167) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv02037 | Title: | L2 SVI to L3 Port to be driven by DSCP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In some cases, egress queuing behavior for F2E/F3 modules (both on Nexus 7000 & Nexus 7700) is incorrect - either the traffic selects the wrong egress queue, or the final COS of the traffic is not remarked, or both.
Conditions:
Workaround:
You can apply a 'type qos' policy on the ingress port(s) or VLAN(s) that explicitly copies dscp to dscp using a table-map.
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 6.2(10)S102, 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 6.2(12)E1, 6.2(13.7)S0, 6.2(14), 7.2(1)D1(0.40), 7.2(1)D1(1), 7.2(1)ZD(0.35), 7.3(0)D1(0.126), 7.3(0)OTT(0.73), 7.3(0)PDB(0.64) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus96878 | Title: | Nexus7700 FEX interface link flap with FET-10G |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Nexus7700 FEX interface may link flap with FET-10G
Conditions:
Nexus7706
N77-F348XP-23
Nexus2232TM
FET-10G
NXOS 6.2.10
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-NOV-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14), 7.2(0)D1(1), 7.3(0)D1(0.45) |
|
Known Fixed Releases: * | 7.0(2)FIP(0.126), 7.2(2)D1(0.11), 7.2(2)D1(0.12), 7.2(2)D1(0.14), 7.2(2)D1(0.15), 7.2(2)D1(0.16), 7.2(2)D1(0.17), 7.2(2)ZD(0.16), 7.2(2)ZD(0.17), 7.2(2)ZD(0.19) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.70) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu35152 | Title: | URIB service crash on N7K running 5.2(9) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
URIB service crash
Conditions:
This has been seen on N7K switch running 5.2(9) code while reloading on of the peer switch.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 5.2(9) |
|
Known Fixed Releases: * | 6.2(13.6)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.52), 7.2(1)D1(1) |
|
|
| |
| |
|
Alert Type: | New |
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: | 24-NOV-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) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw95510 | Title: | MVPN flag missing after ospf,bgp,pim restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic loss due to PIM process not sending join towards upstream neighbor.
Show ip pim route internal detail vrf
command shows the RPF interface and RPF neighbor as null and 0.0.0.0 respectively.
But "show ip mroute" output shows the correct RPF interface and RPF neighbor.
Conditions:
When the command, "restart pim" is done, PIM process enables the protocol on the configured interfaces and
requests MRIB process to send all the routes also. In addition, it asks for all the RPF change notification also.
It is possible that when MRIB lets PIM of all the existing routes, PIM is yet to enable the protocol on certain interfaces and hence the RPF information is not set correctly due to which joins will not be propagated upstream causing data loss.
Workaround:
The workaround is to just "disable and enable " PIM protocol on the RPF interface.
Further Problem Description:
This problem usually occurs if there are large number of multicast routes present in the system and the user does a "restart pim". It is highly unlikely that the bug is seen under any other circumstances.
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.131) |
|
Known Fixed Releases: | 7.3(0)N1(0.216), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut99084 | Title: | Expecting egress queue mismatched on F2E card of Crossbow(6.2.10) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When sending traffic with COS3 ( port trust COS , and no DSCP rewrite) or sending traffic with ip precedence 3
( have DSCP rewrite) , then issue show policy-map interface "F2E port" command.
Checking egress queue match , streams hit incorrect queue "8e-4q8q-out-q2". The correct queue for COS3 should be "8e-4q8q-out-q5".
Hardware and OS version: Crossbow N77XX (6.2.10) , F2E linecard.
Conditions:
When apply the following service-policy on F2E card of N77XX , and send traffic with COS 3 and IP precedence 3.
Class-map:
class-map type queuing match-any 8e-4q8q-in-q1
match cos 5-7
match dscp 40-63
class-map type queuing match-any 8e-4q8q-in-q-default
match cos 0-1
match dscp 0-8
class-map type queuing match-any 8e-4q8q-in-q3
match cos 3-4
match dscp 24-39
class-map type queuing match-any 8e-4q8q-in-q4
match cos 2
match dscp 9-23
class-map type queuing match-any 8e-4q8q-out-q1
match cos 5
class-map type queuing match-any 8e-4q8q-out-q2
match cos 7
class-map type queuing match-any 8e-4q8q-out-q3
match cos 6
class-map type queuing match-any 8e-4q8q-out-q4
match cos 4
class-map type queuing match-any 8e-4q8q-out-q5
match cos 3
class-map type queuing match-any 8e-4q8q-out-q6
match cos 2
class-map type queuing match-any 8e-4q8q-out-q7
match cos 1
class-map type queuing match-any 8e-4q8q-out-q-default
match cos 0
Policy-map:
policy-map type queuing NAC_TEST_IN8e-4q8q-in
class type queuing 8e-4q8q-in-q1
queue-limit percent 10
bandwidth percent 80
class type queuing 8e-4q8q-in-q-default
queue-limit percent 40
bandwidth remaining percent 35
class type queuing 8e-4q8q-in-q3
queue-limit percent 30
bandwidth remaining percent 45
class type queuing 8e-4q8q-in-q4
queue-limit percent 20
bandwidth remaining percent 20
policy-map type queuing NAC_Eg8e-4q8q-out
class type queuing 8e-4q8q-out-q1
priority level 1
shape average percent 50
class type queuing 8e-4q8q-out-q2
bandwidth remaining percent 1
class type queuing 8e-4q8q-out-q3
bandwidth remaining percent 25
class type queuing 8e-4q8q-out-q4
bandwidth remaining percent 15
class type queuing 8e-4q8q-out-q5
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q6
bandwidth remaining percent 10
class type queuing 8e-4q8q-out-q7
bandwidth remaining percent 4
class type queuing 8e-4q8q-out-q-default
bandwidth remaining percent 35
Workaround:
no workarounds
Further Problem Description:
|
|
Last Modified: | 27-NOV-2015 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.2(1)D1(0.44), 7.2(1)D1(1), 7.2(1)ZD(0.38) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCun28154 | Title: | Portloopback test fails on all LCs as vlan init has failed |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
M-series modules may report all loopback tests (Port and Rewrite engine) as untested due to 'Vlan init has failed'.
Conditions:
This has been seen in M-series modules on N7K switches running 6.2(10), 6.2(12) and 6.2(14)
Workaround:
Reload the affected module.
Further Problem Description:
This issue is completely cosmetic and has no impact on switch operations.
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(14), 7.0(1)FVL(0.76) |
|
Known Fixed Releases: | 7.1(0)D1(0.60), 7.2(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw62003 | Title: | doing takeover in sequence for both instance old primary is not updated |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:Doing takeover in sequence for both instance old primary is not updated for MST instance.
Conditions:Apply takeover for both the instance one after another immediately.
apply two cli's ("vtp primary vlan" and "vtp primary mst") one after another.
Workaround:Separately they are working fine. No issues.
apply two cli's ("vtp primary vlan" and "vtp primary mst") one after another with some delay.
OR apply the cli "vtp primary mst" once again to make the instance consistent across two switches.
More Info:
|
|
Last Modified: | 07-NOV-2015 |
|
Known Affected Releases: | 7.2(1)D1(0.68), 7.3(0)D1(0.118) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur17440 | Title: | 945snmpwalk on cpmCPUTotalTable(1.3.6.1.4.1.9.9.109.1.1.1) failing |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On nexus 5500/6000 series switches, snmpwalk on 1.3.6.1.4.1.9.9.109.1.1.1( cpmCPUTotalTable) does not return the expected objects.
Conditions:
This is seen with 7.1 train, the issue does not exist with previous trains such as 7.0
Workaround:
An snmpget to the object will work, for instance to 1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 for cpmCPUTotal5minRev
Further Problem Description:
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.1(0)N1(1), 7.1(1)N1(0.8) |
|
Known Fixed Releases: * | 7.0(0)FHS(0.23), 7.1(0)ES(0.24), 7.1(3)N1(0.613), 7.1(3)N1(1), 7.1(3)ZD(0.10), 7.1(3)ZN(0.19), 7.2(1)D1(0.64), 7.2(1)D1(1), 7.2(1)N1(0.293), 7.2(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
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: | 10-NOV-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)ZD(0.167) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur18519 | Title: | SVI GW mac not programmed on one of the LC with vlan bulk add/del |
|
Status: * | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
On FEX setups or setups with ports in port fast mode, quick range vlan delete/adds can cause missing GWMACs in Linecard.
Conditions:
The Linecard could be under stress due to previous command like VDC reload, PL flap. Under these conditions, issue is more likely.
Workaround:
When a range of vlans are deleted and added, user must have a reasonable delay of a few minutes between the delete and add. Test command < test l2fm dump smac > can be used in case if error happens. Please contact l2fm before you run the test command.
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 6.2(10)S94 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw86978 | Title: | F2E 6.2.(14) upgrade fail %VMM-2-VMM_SERVICE_ERR: VDC1: Service SAP |
|
Status: | Open |
|
Severity: | 2 Severe |
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:
Nexus 7004 chasis ( not happen on 7010)
F2E module
6.2.(14)
Workaround:
reload the module or reduce the number of SVI
Further Problem Description:
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 6.2(8.13) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh33729 | Title: | Memory leak on snmp get: libport_m |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Memory leak is seen on CISCO-ENTITY-SENSOR-MIB.
snmpd is crashed finally by memory leak.
show system internal snmp mem-stats detail will show output similar to
Private Mem stats for UUID : Non mtrack users(0) Max types: 255
--------------------------------------------------------------------------------
TYPE NAME ALLOCS BYTES
CURR MAX CURR MAX
83 [r-xp]/isan/plugin/0/isan/lib/libport_m 151542 151544 72437076 72438371
Conditions:
SNMP client try get-request to OID of CISCO-ENTITY-SENSOR-MIB.
Workaround:
Example configuration for blocking all of CISCO-ENTITY-SENSOR-MIB:
snmp-server community communityString group name
role name name
rule 1 permit read
rule 2 deny read oid 1.3.6.1.4.1.9.9.91
Further Problem Description:
The core file (when unzipped) will contain info similar to
Service: snmpd
Description: SNMP Agent
Executable: /isan/bin/snmpd
Started at Tue Aug 19 23:25:50 2014 (188528 us)
Stopped at Wed Aug 20 03:29:25 2014 (961615 us)
Uptime: 4 hours 3 minutes 35 seconds
Start type: SRV_OPTION_RESTART_STATEFUL (24)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 0.59 secs ago
RLIMIT_AS: 479921612
System image name: n7000-s1-dk9.5.2.9.bin
System image version: 5.2(9) S71
PID: 31658
Exit code: signal 6 (core dumped)
Threads: 31671
CWD: /var/sysmgr/work
RLIMIT_AS: -1
Virtual Memory:
CODE 08048000 - 080C7DDC
DATA 080C8000 - 08123928
BRK 08139000 - 14CE0000
STACK BFF5C110
TOTAL 468556 KB
|
|
Last Modified: | 11-NOV-2015 |
|
Known Affected Releases: | 5.2(9), 6.1(3)S32, 6.1(4), 6.2(2)S19 |
|
Known Fixed Releases: | 5.2(9.206)S0, 5.2(9a)E1, 6.1(4.97)S0, 6.1(4a), 6.1(4a)S7, 6.1(5.32)S0, 6.2(2), 6.2(2)S23, 6.2(5.2)S0, 7.0(0)ZD(0.84) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw01105 | Title: | DFA: multicast duplicate packets or loop on border leafs |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate multicast packets seen in multicast receiver in fabric for outside fabric source.
Multicast loop packets seen for multicast receiver in fabric for inside fabric source.
Conditions:
Connection between fabric and external devices happend to 2 border leafs that see each other on a shared L2 segment, i.e. each border leaf sees the external router as well as the other border leaf as PIM neighbor.
Workaround:
Under investigation.
Further Problem Description:
N/A
|
|
Last Modified: | 20-NOV-2015 |
|
Known Affected Releases: | 7.1(2)N1(1) |
|
Known Fixed Releases: * | 7.1(3)N1(0.639), 7.1(3)N1(1), 7.1(3)ZD(0.24), 7.1(3)ZN(0.47), 7.2(1)D1(0.88), 7.2(1)D1(1), 7.2(1)N1(0.315), 7.2(1)N1(1), 7.2(1)ZD(0.79), 7.2(1)ZN(0.77) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw02224 | Title: | PVLAN missing programming for host-association on vpc port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PVLAN missing programming for host-association on vpc port
Conditions:
PVLAN missing programming for host-association on vpc port
Workaround:
PVLAN missing programming for host-association on vpc port
Further Problem Description:
PVLAN missing programming for host-association on vpc port
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 7.2(1)D1(0.60) |
|
Known Fixed Releases: * | 7.3(0)D1(0.141), 7.3(0)ZD(0.159) |
|
|
| |
| |
|
Alert Type: | New |
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: | 12-NOV-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.111) |
|
Known Fixed Releases: | 7.3(0)D1(0.145), 7.3(0)ZD(0.162) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw73400 | Title: | EIGRP session flap after switchover with "Peer also NSF restarted" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EIGRP session flap after switchover with "Peer also NSF restarted"
Conditions:
Rtr A ---- Rtr B
Rtr B undergoes switchover and then Rtr A tries to do GR with Rtr B due to process restart or switchover.
It only happens when Rtr B does not have any EIGRP routes to be installed into RIB.
Workaround:
Disable GR and restart EIGRP process. GR can be enabled after restart.
Further Problem Description:
|
|
Last Modified: | 17-NOV-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.120) |
|
Known Fixed Releases: * | 7.0(3)I3(0.131), 7.0(3)I3(1), 7.3(0)D1(0.155), 7.3(0)IB(0.102), 7.3(0)N1(0.205), 7.3(0)N1(1), 7.3(0)ZD(0.171), 7.3(0)ZN(0.186) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur34065 | Title: | u6rib cored @u6rib_process_clt_stale while deleting vdc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
the crash seems to occur because of a client clean up issue
Conditions:
Crash is seen when vdc is reloaded
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 18-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I3(0.96), 7.1(0)D1(0.303), 7.1(0)D1(0.308), 7.1(0)ZD(0.348), 7.1(0)ZD(0.355), 7.1(2)ZD(0.11), 7.2(0)ZD(0.5), 8.3(0)CV(0.162) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(3)I3(0.111), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.1(0)AV(0.38), 7.1(0)D1(0.315), 7.1(0)OTT(0.45), 7.1(0)PDB(0.269) |
|
|
| |
| |
|
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: | 14-NOV-2015 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: | 7.0(3)I2(1.15), 7.0(3)I2(2) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux15037 | Title: | Static IPv6 route with Link Local next hop stuck in RIB after reload |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
A static IPv6 route configured with a link-local next-hop address may become stuck in the routing table after a reload. The route will be present in the routing table but will not show the link-local next-hop address. The routing table will only show the next-hop interface associated with the route.
Conditions:
-IPv6 static route with link-local address as next-hop
-Triggered after a reload of the device
Workaround:
To remove the stuck route from the routing table:
1) Remove the route from the configuration
2) Issue the 'clear ipv6 route' command for the stuck route.
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96698 | Title: | Traffic can't go through M3 vPC legs on vPC+. Can't check the FTAG CBL. |
|
Status: | Fixed |
|
Severity: * | 3 Moderate |
Description: | Symptom:
Can not ping through vPC legs on a vPC+ setup on M3 card. Need a table to show the FTAG CBL of vPC legs to verify.
Conditions:
The vPC+ is configured on M3
Workaround:
Check the hardware register.
Further Problem Description:
|
|
Last Modified: | 30-NOV-2015 |
|
Known Affected Releases: | 7.0(0)HEL(0.13) |
|
Known Fixed Releases: | 7.0(0)HEL(0.16) |
|
|
| |
| |
|
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: | 12-NOV-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)PDB(0.80) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCud41930 | Title: | VDC separation weaknesses |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptoms:
This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of the product.
Conditions:
Device configured with default configuration.
Workaround:
Not applicable or available.
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 06-NOV-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)PDB(0.80) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu32143 | Title: | [VxLAN EVPN] N7k sup standby is allowing to execute critical restart CLI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
restart bgp <> on sup-standby causes the sup console to hang for around 10+ minutes.
Moreover, this is not just for BGP but also for other options like restart ospf /eigrp.
Conditions:
in sup-standby we have restart cli's.
PE11(standby)# restart ?
amt Restart the AMT multicast routing protocol
bgp Border Gateway Protocol (BGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igmp Restart the IGMP multicast routing protocol
ospf Open Shortest Path First (OSPF)
PE11(standby)#
B_Spine1(standby)# sh clock
Time source is NTP
23:53:32.203 UTC Thu May 07 2015
B_Spine1(standby)# restart bgp 65001
<<<<< hangs here
B_Spine1(standby)# sh clock
Time source is NTP
00:04:14.116 UTC Fri May 08 2015
B_Spine1(standby)#
Workaround:
This CLI should not be used in stand-by as it could lead system to unknown state.
Further Problem Description:
restart cli shouldn't be allowed to execute in the stand-by SUP and the CLI will be blocked.
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.493) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.11) |
|
|
| |
| |
|
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: | 03-NOV-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)ZD(0.45), 7.3(0)D1(0.143), 7.3(0)IB(0.33) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur09129 | Title: | Snmp walk on syslogMessageSeverity returns raw enum 3112 for vmm. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP query for syslogMessageSeverity returns raw enum 3112 for VMM facility.
Conditions:
SNMP query for syslogMessageSeverity.
Workaround:
It is just display issue.
Further Problem Description:
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(10)S87 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.29) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw90721 | Title: | LISP: RNH notifies for db RLOCs gone when coincide with map-cache RLOCs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On a LISP site with multiple eTRs, one of the eTRs shows an incorrect status of the locators of the rest of eTRs. As an example it may mark the locator as "down" but have a route to the locator.
Conditions:
In order to reach this state the eTR (that is also working as iTR) must receive a map-reply in which one of the locators is part of the database-mapping locator-set. The problem is that this map-cache will be rapidly removed, as it is considered local, which also removes RNH tracking for the affected locators.
An easy way to reproduce this problem is to issue a "lig self"
Workaround:
The only possible workaround now is to reapply the configuration of the affected database-mapping, so that RNH tracking is reinstated
Further Problem Description:
|
|
Last Modified: | 14-NOV-2015 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.6), 7.2(2)ZD(0.11), 7.2(2)ZN(0.10) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw47708 | Title: | N7K - sub-int populated in ciscoCdpMIB even after CLI removal of sub-int |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N7K/N77 - sub-interface(s) populated in ciscoCdpMIB even after CLI removal of sub-interface
Conditions:
Port config includes sub-interface configuration(s).
Only relates to sub-interfaces. If no sub-interfaces are configured, then this problem does not exist.
Workaround:
WORKAROUNDS:
1.) Stop and restart cdp process
2.) Reload the module.
3.) Reload the switch
Further Problem Description:
Extra cdp entries can exist in SNMP that does not exist in CLI.
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 7.3(0)PDB(0.122) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux19294 | Title: | MPLS TE - RSVP BW incorrect for 40G and 100G interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
For 40G and 100G BW reported for RSVP does not match interfaces speed:
switch# sh run int e6/6,e9/6 | i mpls
mpls traffic-eng tunnels
mpls traffic-eng bandwidth percent 100
mpls traffic-eng tunnels
mpls traffic-eng bandwidth percent 100
switch#
switch# sh int e6/6,e9/6 | i BW
MTU 1500 bytes, BW 40000000 Kbit, DLY 10 usec
MTU 1500 bytes, BW 40000000 Kbit, DLY 10 usec
switch#
switch# sh mpls traffic-eng link-management interfaces e6/6 | i kbits/sec
Physical Bandwidth: 5640261 kbits/sec
Max Res Global BW: 5640261 kbits/sec (reserved: 0% in, 0% out)
switch# sh mpls traffic-eng link-management interfaces e9/6 | i kbits/sec
Physical Bandwidth: 5640261 kbits/sec
Max Res Global BW: 5640261 kbits/sec (reserved: 0% in, 0% out)
switch#
Conditions:
This happens with 40G M2 and F3 modules running 6.2 and 7.2
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 26-NOV-2015 |
|
Known Affected Releases: | 6.2(12), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.165), 7.3(0)OTT(0.73) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux27309 | Title: | inability of polling bandwidth data via snmp from tunnel interfaces |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Tunnel information via snmp regarding the ifHCInOctets and ifHCOutOctets
IF-MIB::ifName.402916228 = STRING: Tunnel900
IF-MIB::ifName.402916238 = STRING: Tunnel910
IF-MIB::ifHCInOctets.402916228 = Counter64: 0
IF-MIB::ifHCInOctets.402916238 = Counter64: 0
IF-MIB::ifHCOutOctets.402916228 = Counter64: 502818631159
IF-MIB::ifHCOutOctets.402916238 = Counter64: 3702838219
Conditions:
tunnel interfaces
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-NOV-2015 |
|
Known Affected Releases: | 6.2(8b) |
|
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: | 24-NOV-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)IB(0.113) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv14400 | Title: | FEX-fabric sfp invalid on N77-F324FQ-25 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N7700 + N77-F324FQ-25 + QSFP-40G-SR-BD
When configure Port-channel as "switchport mode fex-fabric", member port of the port-channel down with "FEX-fabric sfp invalid"
Conditions:
Configure Port-channel as "switchport mode fex-fabric"
Workaround:
Configure service unsupported-transceiver.
Further Problem Description:
Problem exists in NX-OS Software Release 7.2(0)D1(1) only.
Fixes had been integrated into 7.2(1)D1(1) and later releases.
|
|
Last Modified: | 19-NOV-2015 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(0.22), 7.2(1)D1(1), 7.2(1)ZD(0.17) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv80855 | Title: | BGP Nexthop is not correct in the case of Multiaccess Networks |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
eBGP nexthop is not the third party address for the route that is learned via IGP on a multi-access network(eg. Ethernet).
Conditions:
eBGP peering on multi-access network, and routes are learned internally.
Basically, it's the "BGP Next Hop (Multiaccess Networks)" case in
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#bgpnexthop
Workaround:
Set an outbound policy map on the neighbor with "set ip next-hop unchanged".
Further Problem Description:
|
|
Last Modified: | 10-NOV-2015 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I3(0.123), 7.0(3)I3(1), 7.3(0)RTG(0.102) |
|
|
| |
| |
|
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: | 17-NOV-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) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum09975 | Title: | SSTE: show tech bfd throws error if size greater than 500M |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When collecting a showtech from the Command Line Interface (CLI) on a N7K chassis with many Line Cards (LCs) which are of type "F3" the user can error message saying "No space left on device" in the volatile: disk.
Conditions:
Incomplete show tech ouput.
Workaround:
Need to collect the show tech output from the particular LC's for which error message is displayed.
Further Problem Description:
Whenever there is too many LC's plugged in, and the show tech output greater than 500M, the error message will be displayed "No space left on device".
Since only 500M is allocated.
|
|
Last Modified: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(6)S12 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.85) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(8)S3 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.48) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.2(10)S98 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.46) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.17) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut22444 | Title: | Nexus7k: Config lines missing in running-con after w-erase, reload, copy |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
On performing write erase, reload and copy boot-flash running.
1)The configuration which are depended on-the-config-lines in the lower-section of the entire config does not get loaded.
For example "ip route 12.12.12.0/24 41.41.41.2 track 2" where track object is defined in the lower part and hence config is missed out.
2)The configurations which are depended on previous config-lines (which is yet to finish applying in the backend) does not get loaded.
For example "FEX", VDC - allocate interface, breakout etc.." which is still getting applied in the backend due to which related config in the lower lines does not complete.
Conditions:
ISSUE-1
a)Write Erase
b)Copy tftp bootflash
c)Copy bootflash startup
d)Followed by reload
ISSUE-3
a)Write erase
b)Reload
c)Copy usb1: running-config
ISSUE-4
a) Write erase
b) Reload
c) Save VDC, FEX and BREAKOUT related configurations into the running configuration of the NEXUS-SWITCH.
d) Copy the remaining configuration into USB or Bootflash to be used in step "6" below.
e) Ensure all modules are up and VDC & FEX configurations are applied and related features working.
f) COPY USB TO RUNNING
Workaround:
Workaround
1)Prepare the Initial-Config From the current running-config in your device --- i) VDC, ii) POWER Redundancy, iii) FEX, iv) Interface-Breakout and v)Object-Track etc into bootflash.
2)Next load the Initial-Config either via TFTP (This can be instead done manually by pasting configuration after reload into the running-config)
- copy tftp: Initial-Config bootflash
- write erase
- copy bootflash: Initial-Config startup-config
- reload
3)Next copy Remaining-config bootflash or USB and do nothing as of now
- write erase
- copy tftp:Remaining-config bootflash
4)Once device is up
- Verify if all modules are up and in "oK" state.
- Verify if all fex using "show fex" and check if the fex is in "Online" state.
- Verify the required fex-breakout interfaces "Ethernet101/1/.." are available.
5) If all is fine above then
Copy bootflash:Remaining-config running-config
Further Problem Description:
Route-Cause-from-the-observations
1)The configuration which are depended on config-lines in the lower section does not get loaded.
For example "ip route 12.12.12.0/24 41.41.41.2 track 2" where track object is defined in the lower part and hence config is missed out.
2)The configurations which are depended on previous config-lines (which is yet to finish applying) does not get loaded.
For example "FEX", VDC - allocate interface, breakout etc.." which is still getting applied in the backend due to which related config in the lower lines does not complete.
|
|
Last Modified: | 04-NOV-2015 |
|
Known Affected Releases: | 6.2(12), 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue29375 | Title: | SA failure: feature/dpvm/server/dpvm_mts.c |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 6.2(1.13) |
|
Known Fixed Releases: * | 6.2(1.15)S0, 6.2(2), 7.0(0.5), 7.0(3)IFC2(1), 7.0(3)IFC2(1.2), 7.0(3)IFC3(1), 7.0(3)IFC3(1.2), 7.0(3)IFD1(0.1), 7.0(3)IFD1(1), 7.0(3)ITI2(1) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.1(2), 7.1(1)N1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.54) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv66924 | Title: | Need to shorten the time to suspend ports when LACP min-link mis-config |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
With the current NX-OS release for N7K, it takes several seconds (~10sec, depending on number of LACP members) to suspend all member ports in the LACP port once LACP min-link condition is broken, such as member port brought down.
Conditions:
Using LACP with min-link feature.
Workaround:
none. The time cannot be shorten in the current implementation.
Further Problem Description:
|
|
Last Modified: | 17-NOV-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.48), 7.3(0)PDB(0.55) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv52259 | Title: | Restrict vpc on port-channels configured for port-security |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
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: | 17-NOV-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) |
|
|
| |
| |
|
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: | 03-NOV-2015 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)IB(0.40) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut89751 | Title: | N77/FP/vPC+: after peer-link down frwd table is not updated for 2-3 mins |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
forwarding table is not update after peer-link down in MPLS / Fabricpath / vPC+ testbed,
50 % of south bound traffic from MPLS core dropped after vPC peer-link down in secondary peer in PE6, and keep dropping for 3+ minutes and recovered.
Routing table is updated right after failure of peer-link, but forwarding table is not updated and keep the local vlan 11 which is suspended already because of vpc peer-link down.
And then 3+ minutes later forwarding table update to core[mpls] and traffic recovered.
Conditions:
In the setup we have 100 VRFs and each VRF has 10 prefixes each with the next hop in a different VLAN.
In this topology FIB dis processing around 500 MTS msgs (each msg packed differently), due to this the forwarding tables are not updated
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 12-NOV-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.437) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux25385 | Title: | Install all CLI should force kickstart and system image |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
User runs 'install all' and doesn't specify the kickstart AND system image name. The install all will fail.
Conditions:
Nexus switch doing ISSU (install all)
Workaround:
Specify the kickstart and system images when running the 'install all' command?
- install all kickstart bootflash: system bootflash:
Further Problem Description:
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv08276 | Title: * | GIR: Support Python script from Maintenance Mode for Nexus 5K/6K/7K |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
GIR mode to support executing Python script from Maintenance Mode for Nexus 5K/6K/7K
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 22-NOV-2015 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 20-NOV-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)ZD(0.155) |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论