| |
|
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: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(8.13), 7.3(0)D1(0.165) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)ZD(0.208), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw58529 | Title: | repeating aclqos crashes caused N7K line card hap reset |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
N7K line card may see service "aclqos" crashes
Conditions:
this was seen on N7K running code 6.2.12 on M1 card.
Workaround:
no known for now.
Further Problem Description:
This issue may be seen on N7K line cards under the following conditions -
1. Bank chaining is enabled
2. Statistics is enabled for ACLs
3. Due to resources being fully utilized, policies are not split across tcams.
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(1)D1(1), 7.2(1)ZD(0.110), 7.2(2)D1(0.1), 7.3(0)D1(0.141), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)OTT(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux20846 | Title: | Nexus 6k: IGMP HAP Reset during "install all" upgrades with IGMPv3 |
|
Status: | Fixed |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.0(7)ZN(0.266), 7.0(8)N1(0.314), 7.0(8)N1(1), 7.1(3)ZD(0.61), 7.1(3)ZN(0.125), 7.1(4)N1(0.690), 7.1(4)N1(1), 7.3(0)D1(0.166) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc94570 | Title: | N7k: Fabricpath traffic loss for unicast flooded traffic |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
Unidirectional North-South traffic does not flow through VPC+ ports in F2 modules
Conditions:
When the core ports and vpc+ edge ports are part of the same F2/F2E ASIC instance, the unknown unicast flood may be incorrectly pruned and not make it out of the vpc+ ports
Workaround(s):
Locate the vpc+ ports in a separate ASIC instance than the core ports.
The ports and the corresponding ASIC instances in a F2 card are as follows
--------------------
ASIC | ports
---------+---------
1 : 1-4
2 : 5-8
3 : 9-12
4 : 13-16
5 : 17-20
6 : 21-24
7 : 25-28
8 : 29-32
9 : 33-36
10 : 37-40
11 : 41-44
12 : 45-48
Issue affects F3 cards only if in the same VDC as F2 or F2E
Workaround:
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: * | 6.1(2), 6.2(5.27)S0, 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut86729 | Title: | vPC Multicast optimization doesn't work after disable/enable the CLI |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multicast traffic flows through the MCT link (vpc peer-link) even though VPC Multicast optimization is enabled using CLI "no ip igmp snooping mrouter vpc peer-link".
Conditions:
VPC Multicast optimization is enabled using CLI -
"no ip igmp snooping mrouter vpc peer-link"
Workaround:
If vPc multicast optimization is required such that multicast traffic doesn't traverse MCT link and if this issue is observed in the network, enabling the command by configuring "ip igmp snooping mrouter vpc peer-link" and disabling the command after some time by using "no ip igmp snooping mrouter vpc peer-link" will work.
Further Problem Description:
Enabling Multicast optimisation through CLI doesn't take effect in a scale setup. No issue is seen if we do not enable VPC Multicast optimization. It is disabled by default.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.163) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 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.22), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux30775 | Title: | ipfib crash during ISSU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
ipfib on F2 module may crash during ISSU
Conditions:
F2 module has some VRF with no local member ports before ISSU.
Workaround:
Unknown.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.157), 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.191) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw38904 | Title: | LIM is not maintaining its encap's correctly |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Not able to Modify VSI after SSO
Conditions:
SSO and Modification of VSI
Workaround:
no workarounds
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.99X), 7.3(0)D1(1A) |
|
Known Fixed Releases: * | 7.3(0)D1(0.122), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.7), 7.3(0)N1(0.160), 7.3(0)N1(1), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.111) |
|
Known Fixed Releases: * | 7.3(0)D1(0.145), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.162) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut89986 | Title: | N77: module in failure state after power cycle due to BFDC hogging CPU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With L2 fabricpath BFD on one side is up and the peer side is not applied or delay in applying the BFD config, but link is up, then the BFDC process on the LC will hog the CPU and line card will be reset.
Conditions:
L2 Fabricpath BFD configured on one side and other side is not configured or configuring with some delay
Workaround:
Remove the L2 Fabricpath BFD configurations on all the switches.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.472), 7.2(0)D1(0.475), 7.2(0)D1(1.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.175), 7.3(0)D1(0.178), 7.3(0)D1(0.179), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.191), 7.3(0)ZD(0.195) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.112) |
|
Known Fixed Releases: * | 7.3(0)D1(0.122), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.60) |
|
Known Fixed Releases: * | 7.3(0)D1(0.141), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RSP(0.7), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.159) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.195), 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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)D1(1), 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), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv64056 | Title: | N7K/N77 support NX-OS mechanism to upgrade firmware on eUSB flash |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Over a period of several months or years, eUSB flash goes unresponsive. When the first flash fails GOLD's CF test report fails. At a later point in time,the boot-flash mounted will go to a state of read-only causing configuration copy to fail.
Conditions:
This happens after several months of system being in use.
Workaround:
6.2.14 has a plugin Load the plugin on the active, which will attempt to repair single flash failures on both active and standby. Double flash failures cannot be repaired; a reload of the affected sup is needed for that.
Further Problem Description:
kickstart images for 7.2(1)D1(1) and 7.3 have the eUSB firmware upgrade solution which is more than a workaround. Kickstart images will upgrade the firmware for the eUSB bootflash and eUSB obfl from Unigen vendor if the eUSB is responding at time of the firmware upgrade. The solution in CSCuv64056 is available for both N77 and N7K. This N77 and N7K solution in CSCuv64056 is unlike CSCus22805 which is only a workaround for N7K and does not help with N77.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12), 6.2(13.16), 6.2(14), 6.2(14)FB(0.49), 7.2(0)D1(1), 7.2(1)D1(0.32), 7.3(0)D1(0.53) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(14.4)S0, 6.2(14b)S1, 6.2(16), 6.2(16)S1, 7.2(1)D1(0.90), 7.2(1)D1(1), 7.2(1)ZD(0.81), 7.3(0)D1(0.120), 7.3(0)D1(1) |
|
|
| |
| |
|
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-APR-2016 |
|
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)D1(1), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.195) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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(1), 7.3(0)D1(1A), 7.3(0)EG(0.3), 7.3(0)IB(0.67), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv87645 | Title: | Traffic not classified according to the static SGT |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
If an IP-SGT mapping overlapping with a VLAN-SGT mapping is first learned over SXP and then deleted the 7k will not classify the traffic with the static VLAN-SGT configured.
Conditions:
Workaround:
force-delete the ARP entry for the source IP
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)E3, 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.156), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)RSP(0.7), 7.3(0)RTG(0.115), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.171) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw96276 | Title: | CVE-2013-4548 Vulnerability Nexus 7000 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus 7000 (N7K) Series Switch includes a version of the Open Secure Host (OpenSSH) protocol
that is affected by the vulnerabilities identified by the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2013-4548
This bug was opened to address the potential impact on this product.
Conditions:
Device with default configuration.
Workaround:
As a workaround, customers may disable AES-GCM in the SSH client configuration. The following sshd_config option will disable AES-GCM while leaving other ciphers active:
Ciphers aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc.
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 6/5.7:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:M/Au:S/C:P/I:P/A:P/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2013-4548 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: | 21-APR-2016 |
|
Known Affected Releases: | 5.2(8), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(15)S10, 6.2(15.2)S0, 6.2(17)S0, 7.3(0)D1(0.147), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IZN(0.13), 7.3(0)N1(0.196), 7.3(0)N1(1), 7.3(0)PDB(0.112) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | 7.3(0)D1(0.89), 7.3(0)D1(1), 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)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | 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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)RTG(0.97), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv48908 | Title: | Cisco NX-OS IGMP Malformed Packet DoS Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Internet Group Management Protocol (IGMP) Version 3 (IGMPv3) input
packet processing of the Nexus Operating System (NX-OS) could allow an unauthenticated,
adjacent attacker to cause the IGMP process to restart due to a malformed IGMP packet.
This can cause a denial of service (DoS) condition on the device.
The vulnerability is due to improper input validation when ensuring that the memory allocated
is large enough for the number of included sources in the IGMPv3 packet. An attacker could
exploit this vulnerability by sending a crafted IGMPv3 packet to the device. An exploit could
allow the attacker to cause the IGMP process to restart due to a buffer overflow which causes
the DoS condition. If the malformed IGMPv3 packet is continuously sent the device the DoS
condition will remain and the device is unavailable.
Conditions:
IGMP Version 3 snooping is configured on one or more Virtual Local Area Networks (VLANs).
Workaround:
The IGMP Version 3 snooping configuration has to be removed.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-4324 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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.1) |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S6, 6.2(14.3)S0, 7.0(3)I2(0.546), 7.0(3)I2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1.36), 7.0(7)N1(0.293), 7.0(7)N1(1), 7.0(7)ZN(0.188) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(1), 7.2(1)N1(0.9) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)D1(0.175), 7.3(0)D1(1), 7.3(0)DX(0.56), 7.3(0)EG(0.14), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.229), 7.3(0)N1(1), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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: | 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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.131) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.216), 7.3(0)N1(1), 7.3(0)PDB(0.121), 7.3(0)RSP(0.7), 7.3(0)SC(0.14) |
|
|
| |
| |
|
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-APR-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(8b), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16), 6.2(16)S1, 7.2(2)D1(0.3), 7.2(2)ZD(0.1), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.103), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv11993 | Title: | Cisco IOS NX-OS Malformed LISP Packet Denial of Service Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Locator/ID Separation Protocol (LISP) of Cisco IOS Software running on the Cisco Catalyst 6500 and 6800 Series Switches and Cisco NX-OS Software running on the Cisco Nexus 7000 and Nexus 7700 Series Switches with an M1 Series Gigabit Ethernet Module could allow an unauthenticated, remote attacker to cause a reload of the vulnerable device.
The vulnerability is due to a lack of proper input validation when a malformed LISP packet header is received. An attacker could exploit this vulnerability by sending a malformed LISP packet on UDP port 4341. An exploit could allow the attacker to cause a denial of service (DoS) condition.
Cisco has released software updates that address this vulnerability.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160323-lisp
Conditions:
Cisco Catalyst 6500 and 6800 Series Switches running Cisco IOS Software, and Cisco Nexus 7000 and Nexus 7700 Series Switches with an M1 Series Gigabit Ethernet Module running Cisco NX-OS Software are vulnerable when LISP is configured. LISP is not enabled by default on either platform.
Workaround:
None.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5/4.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:N/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:OF/RC:C&version=2.0 CVE ID CVE-2016-1351 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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(16)S30, 7.3(0)D1(0.151) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(2)D1(0.33), 7.2(2)ZD(0.63), 7.3(0)D1(0.157), 7.3(0)D1(0.161), 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)IB(0.122), 7.3(0)PDB(0.110) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.169) |
|
Known Fixed Releases: * | 7.3(0)D1(0.179), 7.3(0)D1(1), 7.3(0)PDB(0.130), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv71201 | Title: | Evaluation of n7k-infra for OpenSSL June and July 2015 Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptoms:
This product includes a version of OpenSSL that is affected by the vulnerability identified by the Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-4000, CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1792, CVE-2015-1791, CVE-2014-8176
This bug has been opened to address the potential impact on this product.
Conditions:
Workaround:
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the
time of evaluation are: 7.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: | 21-APR-2016 |
|
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, 6.2(15.2)S0, 6.2(17)S0, 7.3(0)BZN(0.47), 7.3(0)D1(0.73), 7.3(0)D1(0.74), 7.3(0)D1(1), 7.3(0)EG(0.3), 7.3(0)IB(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu77825 | Title: | port profile crash with port-profile refresh script |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | When a profile delete (like no configure profile) and refresh happens in parallel.
Symptom:
port-profile crash
Conditions:
delete of configure profile is taking place
Workaround:
delete a configure profile after completing the refresh
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.104), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.74), 7.3(0)RSP(0.7), 7.3(0)RTG(0.88), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.118) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00345 | Title: | ISSU from 6214 to 6216 policy caching enabled will not download >1 ACE's |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cold boot/ ISSU from 6214 to 6216 with policy caching enabled , will not download SGACL's with multiple aces even after refreshing the cts policy using the cli "cts refresh role-based-policy
Conditions:
Cold boot/ ISSU from 6214 to 6216 with policy caching enabled and SGACL's with multiple aces
Workaround:
Try adding an ace for that SGACL and then issue "cts refresh role-based-policy"
In 7.3.0.DX release a new cli "cts refresh role-based-accesslist all" has been added to refresh the SGACLs irrespective of gen-id criteria. So user need not update the SGACL in ISE to issue the refresh command on the switch.
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 6.2(16)S65, 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.3(0)DX(0.133), 7.3(0)DX(0.141) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur54182 | Title: * | Tacacs service triggers supervisor reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
The tacacs+ service crashes 2 times triggering a supervisor reload. The supervisor reset reason logs the following:
Reason: Reset triggered due to HA policy of Reset
Service: Tacacs Daemon hap reset
Conditions:
This issue only occurs on systems running NX-OS 6.2(8a) or later if a command longer than 255 characters is
issued while tacacs+ remote authorisation is enabled.
Workaround:
Do not execute CLI commands longer than 255 characters when tacacs+ command authorisation is enabled.
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are
4.4/3.6:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:M/Au:S/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2014-8013 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.0(2)A6(0.41), 6.0(2)A6(1), 6.0(2)U6(0.41), 6.0(2)U6(1), 6.1(2)I3(2.15), 6.1(2)I3(3), 6.2(10.21)S0, 6.2(12), 6.2(12)FT(0.12), 7.0(0)BZ(0.46) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz51047 | Title: | RBACL programming is missing from hardware |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
RBACL policies are shown in "show cts role-based policy" but they are not programmed in the hardware and hence not hit by the traffic.
Conditions:
This issue happens only on system reload & when there are a large number of IP-SGT mappings in the start-up config. (This bug was seen with 67K mappings)
Workaround(s):
Once the CTS process shows low CPU utilization after the programming,
- Issue the CLI commands for static policies
- "cts refresh role-based-policy" for dynamic policies
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 6.2(0.211)S0, 6.2(2), 8.3(0)CSS(0.4), 8.3(0)CV(0.398), 8.3(0)SF(0.94) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua34546 | Title: | CTS: Policy download fails for supplicant when N7K is authenticator. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A CTS link between a Catalyst 6500 and Nexus 7000 may fail re-authentication if
radius server access for catalyst 6500 fails.
Conditions:
1. The catalyst 6500 (or any other device) should be in Authenticator mode and
the nexus 7000 in Supplicant mode on the CTS link, before re-authentication.
2. Radius server access to catalyst 6500 is not available during
re-authentication.
More Information:
During re-authentication because of failure to access the radius-server, the
catalyst 6500 will change role from Authenticator to supplicant and the Nexus
7000 from Supplicant to Authenticator. In this scenario the Nexus 7000 fails to
relay the re-auth requests from the catalyst 6500 to the radius server.
Workaround:
Shut and no-shut the link will clear the problem.
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: * | 6.2(1.17)S0, 6.2(2), 6.2(2)S19, 6.2(5.2)S0, 7.0(0)ZD(0.84), 7.0(0.6), 8.3(0)CSS(0.4), 8.3(0)CV(0.398), 8.3(0)SF(0.94) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33019 | Title: | diag_port_lb HAP reset |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
A SUP2E may experience a diag_port_lb HAP reset:
1) At xxxxxx usecs after ddd mmm hh:mm:ss yyyy
Reason: Reset triggered due to HA policy of Reset
Service: diag_port_lb hap reset
Version: 6.2(8b)
yyy Mmm dd hh:mm:ss Hostname %SYSMGR-2-SERVICE_CRASHED: Service "diag_port_lb" (PID xxxx) hasn't caught signal 11 (core will be saved).
Conditions:
Unknown at this time.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 6.2(8b) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui88768 | Title: | HSRP mac not updating after role change |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
HSRP virtual mac points to local supervisor instead of newly active HSRP router following an HSRP state change.
Conditions:
HSRP state change triggers above issue
Workaround:
Flap the SVI for the vlans whose macs fail to move
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 5.2(7) |
|
Known Fixed Releases: | 6.2(5)FE(0.7), 6.2(5.22)S0, 6.2(6), 7.1(0)D1(0.14), 7.1(0)D1(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy92109 | Title: | N7k: M1/M2 Mixed VDC TCAM Merge failure |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
M2 or M108 card interfaces will be kicked out of VDC
Note: M148GS, M148GT, M132(all 3-XL modules) are NOT affected when this problem is triggered.
Conditions:
-M1 and M2(both XL) cards should be present within the same VDC
-VDC or chassis reload(or even M2 module reload)
-Bank mapping should be enabled in the default VDC(using the command- hardware access-list resource feature bank-mapping)
-Atomic Updates are disabled
Workaround:
a) Power off any M1 modules allocated to the VDC and bring up the VDC only with M2. This will make sure that the M2 interfaces are allocated properly to the VDC. Once M2 is online, initiate ?no poweroff? for the M1 modules.
b) Other workaround would be to follow below steps.
1) Take backup of the startup configuration for the VDC and do a write erase for the affected VDC.
2) Reload the VDC and once the same is Active, Allocate the interfaces back and make sure those are online within the VDC
3) After this, copy back the configuration into running.
c)Third option would be to delete the QoS configuration which is causing the TCAM to get filled. Once configuration is cleaned up, a VDC reload would be required to restore the interfaces.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: * | 6.2(14), 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy73277 | Title: | Mac Addresses at last 2 ports on FEX are out of range in allocated ones |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Mac Addresses at last 2 ports on FEX are out of range in allocated ones
Conditions:
Use FEX
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.52) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33853 | Title: | M3:CTS rol-based enforcement is not effective for one specfic scenario. |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
CTS IP-SGT maps are not programmed in FIB even if role-based enforcement is enabled after VDC reload
Conditions:
VDC with all interfaces of a LC and 200K ip-sgt configs then do a vdc reload trigger.
Workaround:
re-issue cts role-based enforcement for that VRF/VLAN.
Further Problem Description:
Agnostic to Line card, probably Line card boot time might influence this timing issue.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy77708 | Title: | Optimize the Bytes stats and remove the syslog for RIT stats exhaustion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
We would see a SYSLOG message indicating "F4_FIB_RIT_EXHAUSTED: RIT entry for packet stats"
Conditions:
When there are more than 40K prefix's which require stats.
Workaround:
None
Further Problem Description:
10k prefixes which have both byte and packet stats supported
and the remaining 30k we have pkt stats, but we would provide the byte counts by multiplying 512 bytes per packet.
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116), 7.3(0)DX(0.131) |
|
Known Fixed Releases: | 7.3(0)DX(1), 7.3(1)DX(0.4) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz25546 | Title: | SSTE: LISP Process crash during continuous process restart |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: |
Symptom:
lisp process crashes
Conditions:
continous process restart from cli
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz29940 | Title: | MFIB fail to install route with Tunnel after LC reload |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
For systems with multicast over GRE configuration (multicast with tunnel in the oiflist), it's possible that a module reload will result in the some routes not being installed on the reloaded module. This will result in traffic drops for all affected routes.
Conditions:
The problem is more likely to occur in a scale topology with >20K multicast routes, but may happen with less. This problem has only been seen thus far with Flanker (F3) based modules. However, the condition applies to other module types.
Workaround:
The CLI "clear ip mroute" for the affected VRFs will fix up the HW programming.
Further Problem Description:
None
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz21326 | Title: | Aclmgr Crashes on 6214 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multiple aclmgr crash
Conditions:
frequent ACL add/delete/edit of ACEs is done using config session
changes can be done manually or via script
Must condition :-
During the time changes are done, and config
session is not committed yet. Now, if there is a switch reload , then cleanup of the session post switch reload causes crash.
Other condition for crash is TBD
Workaround:
tbd
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(16)E1, 7.3(1)D1(0.51) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz41729 | Title: | Police with remarking is not getting classified properly |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Inner tag is getting rewritten for dscp values.
Conditions:
Police with remarking is not getting properly classified.
Workaround:
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz35540 | Title: | SSTE: Reliance Sol: Label issue with BGP send label enabled on 7.2 MR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Labels that should be present in ULIB are not present. This cascades to forwarding as well.
Conditions:
When a routing protocol allocates FEC in ULIB and a second routing protocol deletes the FEC without first allocating it, the FEC and associated local label is deleted from ULIB for both routing protocols.
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.11) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz43417 | Title: | mvpn qos : Discard-class classification is not working on P box |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
'discard-class' classification is not working in P router (egress qos) in MVPN setup
Conditions:
when QoS policies applied on VLAN
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz42342 | Title: | NXOS:ISIS:FP - ISIS crash during ISSU on PSS recovery |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
ISIS crash with error:
%SYSMGR-2-SERVICE_CRASHED: Service "__inst_001__isis_fabricpath" (PID 6120) hasn't caught signal 6 (core will be saved).
Conditions:
ISSU crash could happened during ISSU upgrade
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy72326 | Title: | M3CB10: During Rollback CFGWRITE_FAILED, ERROR: Rollback Patch not Empty |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
When rollback is performed from admin vdc, rollback operation is failing.
Conditions:
If the current vdc is admin vdc and rollback is performed from this vdc then rollback process will fail.
Workaround:
Since, from day 1 rollback is not supported from admin vdc, this is a limitation and there is no work around in this situation.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.110) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz24167 | Title: * | N77/N7K - M3 SNMP cshcModRxTotalDroppedPackets - all zeros for M3 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
snmp walk output for cshcModRxTotalDroppedPackets MIB is not matching with sh int eth x/y counters errors.
Conditions:
show hardware capacity interface? CLI support added for M3 - which follows the new design and it only shows the accumulation of all the drops whichever is disclosed to stats client through LPSS
Workaround:
compare "sh int eth x/y counters errors snmp" CLI to match SNMP walk output for cshcModRxTotalDroppedPackets MIB.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz12626 | Title: | IGP label has been missed after MPLS TE FRR |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
when protected link goes down and active TE traffic is diverted over the backup tunnel, packets go out with additional one label on tunnel head
Conditions:
mpls te frr is triggering the issue
Workaround:
flap the tunnel-te
Further Problem Description:
n/a
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | 7.3(0)DX(1), 7.3(1)DX(0.3) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy19010 | Title: | SNMPd causes boot loop after reload with unload-MIB configuration |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
SNMPd may crash repeatedly immediately after boot. While a single crash of the SNMPd service will not cause a reload, multiple crashes in quick succession are considered fatal and so the system will reboot.
Due to this issue, the system will enter a boot loop that can be recovered only by erasing the configuration (via 'write erase' from kickstart) and re-applying it.
Conditions:
The trigger for this issue is to configure 'no snmp-server load-mib ' and save the configuration. This does not cause any impact during runtime, but if the switch later reboots for any reason this will trigger the crashes and bootloop.
This is known to affect all currently available versions of code in the 7.1, 7.2 and 7.3 code trains for the Nexus 5000. The 7.0 code train is not affected.
The code problem is platform-independent and therefore likely affects other Nexus switching platforms as well.
Workaround:
Do not unload MIBs via the 'no snmp-server load-mib' command.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.300) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy52663 | Title: | 6.2(16) (S40) - ipfib core @ fln_ufib_pd_ecmp_adj_handles_pss_insert |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | The problem happens because MPLS is configured and this release (6.2(16) does not support MPLS.
Symptom:
Configuration of MPLS may lead to crash and MPLS malfunction.
Conditions:
MPLS configuration.
Workaround:
Do not configure MPLS
Further Problem Description:
The problem happened when a route pointing to two MPLS paths was received by FIB
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: | 6.2(16), 6.2(16)S46, 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz06671 | Title: | SSTE:Per-vlan consistency check failed with ISSU + both vPC peers reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In the scale setup, the vPC consistency check failed after sequence of ISSU and reload both vPC switches
Conditions:
- ISSU from HSK2 to UPG
- Reload both vPC devices
- The switches were auto-configured in scale setup of > 1K vlans
Workaround:
Option1:
Make sure to config the vPC peer-link port-channel after all LC modules are up
Option2:
Manually recover the particular inconsistent vlan(s)
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.125), 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.3(0)DX(1), 7.3(1)DX(0.12) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCtj70898 | Title: | NX-OS/SNMP - loopback interface gives erroneous output for snmp counters |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When polled from SNMP, loopback interface provides erroneous output.
Conditions:
Multiple SNMP pollers fetching data or multiple repeated attempts to pull interface counters/statistics.
Workaround:
not available. For N5k/6k switches fix is available in 7.0 and later releases
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 5.1(1) |
|
Known Fixed Releases: | 5.2(0.221)S0, 7.2(0)ZN(0.111) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10098 | Title: | FPC members in error disabled state with error as INVALID INTERFACE |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | FEX uplink interfaces are in error state
Symptom:
FEX uplink interfaces are in error state:
switch# show interface ethernet 2/9
Ethernet2/9 is down (Error disabled, sim: invalid interface)
Conditions:
After ISSU/switchover a FEX module is removed / reloaded. It may come back up in an error state.
Workaround:
Reload of switch will resolve the issue
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 7.3(0)DX(1), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)DX(0.10), 7.3(1)DX(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy26997 | Title: | eirgp core @ urib_rt_mod_nh_del |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Crash seen while withdrawing routes from rib since eigrp tid is being set to BAD_TID_VALUE.
Conditions:
On doing a "no vrf context xxx" we set tid = BAD_TID_VALUE, if by that time routes are not withdrawn from
rib , we encounter this issue since as an invalid tid is passed to rib.
Workaround:
No work around
Further Problem Description:
refer Eng-Notes
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 6.2(16)S25 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S46, 7.3(0)DX(1), 7.3(1)D1(0.54), 7.3(1)N1(0.340), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz15332 | Title: | SSTE: ipfib crash on F3 during longevity - 7.3.0.DX.0.141.S1 |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
1> Syslogs for LS_MET table exhaustion / high usage :
2016 Mar 1 01:26:04 N77-A %$ VDC-1 %$ %IPFIB-SLOT5-4-FLN_FIB_LSMET_EXHAUSTED: ls-met entry allocation from unicast region failed on instance 7
2016 Mar 1 01:26:04 N77-A %$ VDC-1 %$ %IPFIB-SLOT5-4-FLN_FIB_LSMET_EXHAUSTED: ls-met entry allocation from unicast region failed on instance 7
2> Inconsistency in programming causing traffic drops (when we reach high scale)
Conditions:
This issue is seen :
1> When there is a high scale ( number of paths, BGP peers, prefixes) and path table utilization is high.
For example :
If there are two BGP peers, advertising the same route then the number of paths that can be taken totally is 16k and on a config that has a large number of routes ( such that the number of routes * number of next hop paths ~ 13-15k) with path changes , this error maybe encountered.
2> The network is unstable and the next hop is continuously flapping.
* There is a higher probability on hitting this issue on high scale L3VPN/Inter AS Option B setups
Workaround:
1> Reload Linecard if the network conditions caused path change to the next hop adjacencies.
2> Reduce the scale to reduce the utilization of the LS MET
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz45422 | Title: | eltm cores while modify association of secondary trunk configs |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
eltm cores while modify association of secondary trunk configs
Conditions:
eltm cores while modify association of secondary trunk configs
Workaround:
eltm cores while modify association of secondary trunk configs
Further Problem Description:
eltm cores while modify association of secondary trunk configs
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu87265 | Title: | OTV UDP ISSU: Packet decap is broken on ISSU from S28 to UPG |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
While OTV UDP encapsulation mode enabled, after ISSU there is a traffic interrupt.
Conditions:
ISSU with OTV UDP encapsulation mode enabled.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.2(1)ZD(0.100), 7.2(1)ZN(0.94), 7.2(2)D1(0.2), 7.3(0)N1(1), 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw76844 | Title: | N77-F348XP-23 may reload on executing some show CLI on down-rev firmware |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Line card reloads with syslog :-
MODULE-2-MOD_DIAG_FAIL: Module 1 reported failure Ethernet1/1-8due to non-fatal error in device DEV_FLN_FWD (device error 0xcbb00203)
Conditions:
Running following CLI :-
show tech detail
OR
show tech module X
on some "N77-F348XP-23" cards with VID = V03 and affected NXOS SW versions (6212 or 6214 or 7.2.0.D1 )
Workaround:
none.
Do not run mentioned CLIs if you have exactly above combination of SW+HW
Further Problem Description:
Please call TAC to upgrade firmware for your affected line card. New firmware takes affect post reload of line card.
For module X you can check VID , like so:-
N7700# show sprom module X 1 | egrep -i VID
VID : V03
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14), 7.2(0)D1(1.9) |
|
Known Fixed Releases: * | 6.2(16)S29, 7.2(1)D1(1), 7.2(1)ZD(0.110), 7.2(2)D1(0.1), 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47006 | Title: | SSTE: MEv6 BGP neighbours not coming up after Admin VDC migration |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
After executing Admin VDC Migration (moving the configs from default VDC to non-default VDC), MEv6 BGP neighbours adjacencies will not come up .
Conditions:
Move Configs from default VDC to non-default VDC
Workaround:
We need to configure dynamic BGP peering in the peer so that when request comes with new MAC address embedded, it will respond back.
Further Problem Description:
After the Admin VDC migration, the MAC on the new VDC will change and the request will be sent with new MAC embedded, so if we have static neighbor configured in peer it will response back for the opensent.
|
|
Last Modified: | 04-APR-2016 |
|
Known Affected Releases: | 6.2(16)S38 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum10704 | Title: | 465 byte leak with epld during show run can cause copy r s to abort |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
It is not possible to save the configuration anymore and the memory shows up as full :
%SYSMGR-2-NON_VOLATILE_DB_FULL: System non-volatile storage usage is unexpectedly high at 100%.
N7K# copy run start
[########################################] 100%
Configuration update aborted: request was aborted
N7K#
Conditions:
Each time "copy run start" or "show run" is issued, the size of the epld_auto_log file in /mnt/pss/epld_log is growing.
This fills up /mnt/pss space. When the /mnt/pss gets full, "copy run start would fail. This can be seen with
N7K# show system internal dir /mnt/pss/epld_log
Workaround:
Prevent such commands from being run by scripts and call TAC to delete the file.
Further Problem Description:
Affected releases are from 6.2(1) to 6.2(6a).
It has been fixed in 6.2(8).
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 6.2(6)S10 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy77657 | Title: | BGP did not update the NH of all MAC routes in l2rib |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
BGP did not update the NH of all MAC routes in l2rib
Conditions:
mac routes via bgp evpn.
Workaround:
There's no workaround. To recover:
Shut bgp neighbor ; wait for all mac-routes to be removed; re-establish bgp neighbor.
Clear bgp all * will not work.
Further Problem Description:
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 7.0(3)IAB3(0.102) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy48431 | Title: | PHY port VPC in F2/F2E cards does not work with F3 card in same VDC |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
PHY port VPC with F3 cards is not supported in 6.2.x train. When having PHY port with F2/F2E interfaces, F3 interfaces should not be present in the same VDC. If present, the ltl programming would go wrong.
Conditions:
PHY port VPC is configured with either F3 interfaces or with F2/F2E interfaces with presence of F3 card in the same VDC
Workaround:
Remove the PHY port configuration on F3 interfaces. OR when having PHY port configuration on F2/F2E interfaces, make sure that F3 card is in another VDC.
Further Problem Description:
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 6.2(16)S38 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy99701 | Title: | N77 - N77-F3 modules not populated for cshcMacUsageTable |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SNMP MIB cshcMacUsageTable is not populated for Nexus 7k F3 Line cards. There are no functionality impact.
Conditions:
No specific condition is required. SNMP MIB cshcMacUsageTable foes not get populated for F3 line cards for Nexus 7k.
Workaround:
There is no workaround.
Further Problem Description:
SNMP MIB cshcMacUsageTable fails to get populated for F3 line cards for Nexus 7k. It is seen 6.2.x/7.2.x. There is no functionality impact.
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(16)S67, 7.2(3)S8, 7.3(0)DX(0.124), 7.3(1)D1(0.20) |
|
Known Fixed Releases: | 7.3(0)DX(0.141) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu83574 | Title: | Error in syslog of interface flap event after reload in remote server |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This can occur when logging source interface loopback is configured with ipv6 address and logging server is configured.
Conditions:
This issue occurs in certain conditions when ipv6 address configured on loopback being used as logging source interface is in compact form:
ex:
1::1/64
Workaround:
Reconfigure the logging source interface with the loopback interface after reload.
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.2(0)D1(1), 7.3(0)D1(0.86) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S40, 7.2(1)D1(0.5), 7.2(1)D1(1), 7.2(1)N1(0.239), 7.2(1)N1(1), 7.2(1)ZD(0.5), 7.2(1)ZN(0.5), 7.3(0)N1(1), 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw70817 | Title: | "port-profile type <type>" should not be expected in the rollback diff. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Rollback should not modify port-profiles when port-profiles configs are not user-modified and not part of user-defined checkpoint.
Conditions:
User-defined rollback is executed and FP vlans are rolled back
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S46, 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)IB(0.101), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux28796 | Title: | OIL is not copied from (*,G) to (S,G) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On an intermediate hop router sometimes, the OIF list of *,G is not inherited into S,G entry correctly.
It happens in certain conditions such as this.
src---rtr1---rtr2- intf1----rtr3---rcvr
|
rp
rtr2 has a *,G entry with oif (intf1) towards rcvr.
when the source starts, the rtr2 receives a SG join from RP.
rtr2 create the SG entry with oif (intf2) only towards RP, instead of two OIFs. (intf1 and intf2)
Only after receiving a SG join the rtr3, does the intf1 gets added to the entry. This causes a traffic blackholing upto a minute.
Conditions:
This typically happens on a IHR only where the SG creation happens due to receiving a SG join and there is already a *,G entry with other oifs.
Workaround:
As such there is no workaround and the system correctly itself within a minute.
The other possible workaround is to change the topology. For example if we connect the RP router to the rtr3 in the above topology, the problem will no longer be seen.
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.0(3)I3(0.271), 7.0(3)I3(1), 7.3(0)D1(0.166), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.220) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy42849 | Title: | Wrong PIM assert sent by the PE device in MPLS network (Nexus device) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Multicast packet drop observed at receiver side.
Conditions:
Two PE must connect to the CE in a Ethernet segment and has same subnet .
Workaround:
Remove and re add the MDT configuration under VRF .
Further Problem Description:
PE is running SSM in the core and the customer routes are in VRF DCT .
vrf context DCT
ip pim rp-address 8.8.8.8 group-list 239.0.0.0/8
ip pim ssm range 232.0.0.0/8
mdt default 232.100.99.1
mdt source loopback0
mdt data 232.100.99.128/25 threshold 10
RP 8.8.8.8 is CE1 in the device . Source is with IP address 50.50.50.2 sending Multicast traffic to 239.1.1.1
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 9.9(9.9) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S46 |
|
|
| |
| |
|
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 module generates PIXMC core
Conditions:
1. SPAN/ESPAN config is there on the switch
2. More than 128 PHY ports should be present in that VDC
Workaround:
Remove SPAN/ESPAN config before inserting new SUP/Module or during module reload. Later apply back the SPAN/ERSPAN config.
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(14)S25, 7.3(0)D1(0.79) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S1, 7.3(0)D1(0.126), 7.3(0)D1(1), 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: | CSCuy51650 | Title: | iscm cores for vdc deletion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40
Core was generated by `/isan/bin/iscm'.
Program terminated with signal 6, Aborted.
[New process 17360]
#0 0x455fc3d8 in wait ()
from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672
#2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043
#3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/rise/iscm_rise_msg_handlers.c:1412
#4 0x080fe939 in iscm_demux (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/iscm_fu.c:3112
#5 0xf676e273 in fu_fsm_engine_process_app_ev (event=0x8fb7040, new_ev=0x8fb70f0, fsm_event_list_ref=0xffb5f568, demux_ev_ref=0xffb5f564) at ../utils/fsmutils/fsm.c:2431
#6 0xf677d83d in fu_fsm_engine () at ../utils/fsmutils/fsm.c:2782
#7 0x081147b9 in main (argc=, argv=) at ../feature/iscm/server/iscm_main.c:393
warning: .dynamic section for "/ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/isan/lib/libsse_common.so" is not at the expected address
All.Done.
Conditions:
iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40
Core was generated by `/isan/bin/iscm'.
Program terminated with signal 6, Aborted.
[New process 17360]
#0 0x455fc3d8 in wait ()
from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672
#2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043
#3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/rise/iscm_rise_msg_handlers.c:1412
#4 0x080fe939 in iscm_demux (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../feature/iscm/server/iscm_fu.c:3112
#5 0xf676e273 in fu_fsm_engine_process_app_ev (event=0x8fb7040, new_ev=0x8fb70f0, fsm_event_list_ref=0xffb5f568, demux_ev_ref=0xffb5f564) at ../utils/fsmutils/fsm.c:2431
#6 0xf677d83d in fu_fsm_engine () at ../utils/fsmutils/fsm.c:2782
#7 0x081147b9 in main (argc=, argv=) at ../feature/iscm/server/iscm_main.c:393
warning: .dynamic section for "/ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/isan/lib/libsse_common.so" is not at the expected address
All.Done.
Workaround:
iscm cores for vdc deletion ,
bld type is :: /auto/andfreetown/REL_6_2_16_S40
Core was generated by `/isan/bin/iscm'.
Program terminated with signal 6, Aborted.
[New process 17360]
#0 0x455fc3d8 in wait ()
from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#0 0x455fc3d8 in wait () from /ramfs/ucd_tmp/ucd.4YBr0whV0khlcUGkNl/lib/libpthread.so.0
#1 0x082e4115 in push_nice_configuration (cfg_file_name=0x839bdf5 "/tmp/itd_no_cfg_file") at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:2672
#2 0x082ec977 in iscm_svc_nice_clear_config (svc_ent=0x8fd99e0) at ../feature/iscm/server/nice/iscm_svc_nice_fsm_ac.c:1043
#3 0x0823b5f0 in iscm_mts_fm_handler (event=0x8fb7040, ret_fsm_event_list=0xffb5f568) at ../f
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S46, 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq18021 | Title: | SNMPset to community strings with special characters cause hap reset |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
NX-OS SNMPd process crashes with HAP reset.
Conditions:
Community string has leading ''%'' and ends with a number.
(however some other combination of special characters may cause this problem, we haven't seen them yet but can't exclude)
Workaround:
don't use leading % as a character. Better to avoid using special characters in RW communities or at least not as a leading characters
Further Problem Description:
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via
normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another
evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 7.1(0)ZD(0.278) |
|
Known Fixed Releases: * | 5.2(1)N1(8.156), 5.2(1)N1(9), 6.0(2)N2(5.107), 6.0(2)N2(6), 6.2(16), 6.2(16)S16, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(1)ZN(0.772), 7.0(6)N1(0.264) |
|
|
| |
| |
|
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: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(14a)S2, 6.2(14a)S3, 6.2(16), 6.2(16)S2, 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)D1(1), 7.3(0)GLF(0.25) |
|
|
| |
| |
|
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: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(13)S8, 7.0(3)I4(0.15), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.0(3)I4(0.23), 7.0(3)I4(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw51522 | Title: | Mac learnt on ES ID for host vpc+ port operating in individual mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a pair of nexus 7000 series switches configured for fabricpath vpc+, the mac address for an host vpc+ operating in individual mode may point to an incorrect interface on the non-parent nexus 7000, either pointing to the local vpc+ leg that is down, or to the fabricpath address for the emulated switch (ES ID.1.65535). Traffic destined for devices behind the host vpc+ ingressing the non-parent nexus 7000 will not reach its destination.
Conditions:
- This is seen in a host vpc+ configuration, a port-channel configured for vpc made of HIF interfaces residing on seperate FEXes, each connected to a single parent nexus 7000
- The port is running in standalone mode allowed by the configuration of no lacp suspend-individual on the port-channel and the absence of lacp configuration on the attached system.
Workaround:
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(14), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S1, 7.2(1)D1(0.99), 7.2(1)D1(1), 7.2(1)ZD(0.90), 7.3(1)D1(0.29) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf45721 | Title: | RD in config out of sync with BGP for VRF |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
RD in running config out of sync with RD in BGP. Per prefix labels for VRF routes held in ULIB
Conditions:
In a short window, RD change to new RD followed nu old RD. Latter operation did nor require RD delete.
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.254), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth47931 | Title: | 288: Copying 3950 vrfs configs to running cfg takes more than 100mins |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Configs from 51 to 4k vrfs takes long time to get copied to running cfg. 50 vrfs are already configured on the router before copying the cfgs and all the bgp,RIB and FIB was up and running fine
Conditions:
Check description section
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.2(0.217)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth36775 | Title: | 288:%BGP-3-TX_TXLIST_ERRO BGP traceback after shut/no shut of interfaces |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Traffic never coming up
Conditions:
Check repro steps in the description section
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.302), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz98916 | Title: | HSRP Interface state changes observed during Sys-Switchover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
HSRP Interface state changes observed during System Switchover
Conditions:
When links are established and a system switchover is performed, the HSRP interface state changes are observed.
Workaround:
N/A
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(0.288)S0 |
|
Known Fixed Releases: * | 6.1(0.298)S0, 6.2(0.217), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty01628 | Title: | Some BGP routes remain invalid on 'restart bgp' |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In rare occasions, 'restart bgp <>' may cause valid paths to be stuck at 'invalid' state.
Conditions:
This issue had only been seen when the next-hops of the paths are directly attached and in setup with large number of directly attached peers (~1000).
Workaround:
Restart bgp again will usually fix the issue. Or a 'clear ip route ' where next-hop is the next-hop of the paths stuck at 'invalid' state, will also help to recover.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 5.2(4.86)S0, 6.1(0.282)S0, 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub11461 | Title: | ip mroutes are stuck in "initializing - suppressing MFDM updates" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
MRIB context will be stuck in initializing after the SUP switchover when "ip routing multicast holddown" is set to 0/Disabled.
Conditions:
when "ip routing multicast holddown" is set to 0/Disabled.
Workaround:
Not to disable "ip routing multicast holddown"
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(1) |
|
Known Fixed Releases: * | 6.1(1)S41, 6.1(1.42)S0, 6.2(0.217), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn13055 | Title: | BGP does not filter updates with incorrect AS-PATH values |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path values. This could allow an upstream BGP neighbor to pass
an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in a rest of and
resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4098 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4098
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: * | 5.2(0.218)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf40008 | Title: | LESS allows bash access |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Cisco Nexus OS contains a vulnerability that could allow an authenticated,
local attacker to execute arbitrary commands on a targeted device. The
vulnerability is due to improper sanitization of user-supplied values to
command line interface commands.
An authenticated, local attacker could exploit the vulnerability by issuing
commands that contain malicious options on the device command line interface.
If successful, the attacker could gain elevated privileges on the targeted device.
Conditions:
Injection can be done via either the less or the section sub command. Full
details below:
----------------------------------------------------------------------
NX-OS - "less" sub-command - Command injection / sanitization issues.
----------------------------------------------------------------------
Affected Products:
==================
The following products are affected by this vulnerability:
+-----------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+----------------|
| Cisco Nexus 7000 Series Switches | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 5000 Series Switches | CSCtf40008 | 4.2(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 2000 Series Switches | CSCtf40008 | 4.1(1)N2(1) |
|-----------------------------------+------------+----------------|
| Cisco Nexus 1000V Series Switches | CSCtf40008 | 4.2(1)SV1(5.1) |
|-----------------------------------+------------+----------------|
| Cisco MDS 9000 Software | CSCtf40008 | 4.2(6) |
| | | 5.1(1) |
|-----------------------------------+------------+----------------|
| Cisco Unified Computing System | CSCtg18363 | 1.3(1c) |
| | | 1.4(1i) |
+-----------------------------------------------------------------+
The following are not affecfed by the "less" sub-command - command injection
vulnerability.
* Cisco Nexus 3000 Series Switches
* Cisco Nexus 4000 Series Switches
-------------------------------------------------------------------------
NX-OS - "section" sub-command - Command injection / sanitization issues.
-------------------------------------------------------------------------
Affected Products:
==================
The following products are affected by this vulnerability:
+--------------------------------------------------------------+
| Affected Product | Cisco Bug | First Fixed |
| | ID | Release |
|-----------------------------------+------------+-------------|
| Cisco Nexus 7000 Series Switches | CSCtr44645 | 5.2(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 5000 Series Switches | CSCtr44645 | 5.1(3)N1(1) |
|-----------------------------------+------------+-------------|
| Cisco Nexus 3000 Se
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(4), 4.2(6), 5.1(1a), 5.1(2) |
|
Known Fixed Releases: * | 4.2(1)N2(1), 4.2(5.10), 5.1(0.76), 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth16459 | Title: | 274:IPFIB-SLOT1-4-FIB_TCAM_PF_INSERT_FAIL:FIB TCAM prefix insertion fail |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
TCAM insertion failures after loading 500vrfs and 200k routes
Conditions:
Check repro steps in description
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.324), 5.0(0)MP1(0.365), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto45260 | Title: | 245_S6: BGP tracebacks after bgp restart |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic never converges after bgp process restart
Conditions:
Load the scale setup of 1k vrfs and 490k routes in per-vrf mode.
Send traffic from remote to local
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.245) |
|
Known Fixed Releases: * | 5.2(0.270)S6, 5.2(0.276)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua00534 | Title: | N7K: mvpn bgp mdt-safi has old bgp rd value |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
mvpn bgp mdt-safi has old bgp rd value
Conditions:
mvpn bgp mdt-safi has old bgp rd value
Workaround:
none
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(5)S5 |
|
Known Fixed Releases: * | 5.2(5)S14, 5.2(5)S19, 5.2(5.21)S0, 5.2(5.27)S0, 6.1(1)S4, 6.1(1.6)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf37179 | Title: | BGP label allocated to iBGP route |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP assigns label to iBGP routes
Conditions:
Configure multihome topology where route is learned from both eBGP & iBGP
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.182), 5.0(1), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn13043 | Title: | BGP does not filter updates with invalid AS Path Segment type |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path Segment Types. This could allow an upstream BGP
neighbor to pass an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in
a rest of and resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4097 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4097
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: * | 5.2(0.218)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto72759 | Title: | IBGP to IGP redistribution is enabled by default in NX-OS |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | By default in NX-OS IBGP routes are redistributed into the IGP when redistribution is configured. In IOS
"bgp redistribute-internal" router bgp command is needed. We need to have this behavior consistent with
IOS
Workaround:
Redistribution of IBGP into IGP can be blocked via a route-map:
router ospf 1
redistribute bgp 1 route-map bgp-to-ospf
route-map bgp-to-ospf deny 5
match route-type internal
route-map bgp-to-ospf permit 10
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(6), 5.1(3) |
|
Known Fixed Releases: * | 5.2(1)S13, 5.2(1)S19, 5.2(1.16)S0, 5.2(1.23)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg90667 | Title: | OSPF service crashes @ip_get_secondary_count on restarting netstack |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
When the netstack process crashed, existing BGP sessions may flap and routes may be re-learnt. This may cause traffic loss.
Conditions:
This only happens when the netstack process had crashed or was terminated ungracefully.
Workaround:
None.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(0.288)S1, 6.1(2)S29, 6.2(0.166) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.332), 5.2(1)S1, 5.2(1.3)S0, 6.1(0.143)S0, 6.2(0.228)S0, 6.2(2), 7.2(0)N1(1), 7.2(0)ZN(0.111), 8.3(0)CV(0.297), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz78495 | Title: | BGP-3-ALLOCFAIL - Private malloc failed for: URIB buf - BGP unresponsive |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
BGP may leak memory when outbound route-map and/or filter-list is configured. The leak is usually very slow, but will happen and accumulate every time an update is generated when the condition is met. Usually it took days or months to observe any adverse effect. Eventually (may take weeks or months), the entire address space of the BGP process could be filled and all memory allocation will fail with 'BGP-3-ALLOCFAIL' errors.
Conditions:
Happens when an outbound route-map/filter-list with prefix matches and actions to be taken (like set commands). Only setup/config with outbound route-map filtering is subject to this bug. However, not every setup/config with with outbound route-map filtering will observe the bug, it also depends on match condition, etc. Instead of enumerating all possible cases, the most accurate and reliable way is to use the following simple procedure to test for memory leak for a particular peer:
sh bgp internal mem-stats detail | egrep rpm
! note the current #bytes allocated for librpm_dl
clear bgp soft out
! wait till all updates had been sent to
sh bgp internal mem-stats detail | egrep rpm
! compare current #bytes allocated for librpm_dl with previous value for leak
Workaround:
There's no workaround. The situation can be recovered via a restart of the bgp process.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: * | 5.2(5)S5, 5.2(5.6)S0, 6.0(2)A1(1), 6.0(2)N1(1), 6.0(2)U1(1), 6.0(4)S1, 6.1(0.292)S0, 6.2(0.217), 6.2(2), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn13065 | Title: | BGP does not filter BGP update with incorrect AS-PATH Segment Length |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: |
Symptom:
Cisco NXOS based devices configured for BGP routing do not properly filter invalid AS Path Segment Lengths. This could allow an upstream BGP
neighbor to pass an invalid update to an NXOS based device that would then be propagated down stream of the affected device. This will likely result in
a rest of and resync with the BGP peer that received the invalid update.
Conditions:
Cisco devices running an affected version of NXOS software and configured for BGP.
This issue affects:
Nexus 7000
Workaround:
None
Further Problem Description:
This issue was identified during an internal security audit of Cisco NXOS based devices.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score and has issued this Release Note Enclosure. There will be no further
communications from the Cisco PSIRT regarding this issue.
The Base and Temporal CVSS scores as of the time of evaluation are 4.3/3.4:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=&version=2.0
dispatch=1&version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C
CVE ID CVE-2012-4099 has been assigned to document this issue.
Additional details about the vulnerability described here can be found at:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-4099
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.180)S14 |
|
Known Fixed Releases: * | 5.2(0.218)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub46108 | Title: | ASCII config is lost for some modules in "power supply combined" mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Certain linecards might loose interface specific configurations
Conditions:
power mode needs to be combined to power up all the line cards in the switch
Workaround(s):
After all the linecards go online, please issue the following command to update ASCII configuration again on all the linecards to ensure interface configuration on all line cards are set correctly:
copy startup-config running-config
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(1)S62 |
|
Known Fixed Releases: * | 6.1(1.65)S0, 6.1(2), 6.2(0.285), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn84156 | Title: | N7K-Reg: SPAN session not coming up with PVLAN as source |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
SPAN session will not come up on primary vlan
Conditions:
When private-vlan is enabled and SPAN session is created on primary vlan
Workaround:
None.
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.2(0.249)S0, 8.3(0)SF(0.10), 8.3(0)SF(0.2), 8.3(0)SF(0.75) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz16227 | Title: | dot1x proc reset at malloc/realloc_internal after few days of MAB/EAPrun |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
When EAP and MAB authentication happening in scaled environment and periodic frequent interface flaps used to recover the error disabled interfaces this issue is seen.
Conditions:
When memory allocation and re-allocation happens very frequently due to authentication, failed authentication, link flaps etc., at some rare race condition this crash is observed.
Workaround:
There is no direct workaround.
But avoiding lot of interface going to error-disable (auth failures/frequent link flaps) and giving few seconds (3 to 5 sec for range of 5 interfaces) delay between link flaps and avoiding flapping large no. of interfaces with range command in one shot will minimize the chances the hitting this issue greatly.
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.295) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux59548 | Title: | Chnage CLP_EB_INT_ECC_ERR_FLD_EE_TILE0_2ERR from FATAL to non-fatal |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
An active supervisor may reset during an ISSU/D very soon after becoming active but while the standby supervisor is still reloading. This causes the switch to reboot.
Conditions:
This is a rare issue which applies only to MDS 9700 supervisors. All reported instances have occurred specifically during an ISSU/D.
Workaround:
None.
Further Problem Description:
The active supervisor reload is triggered when an uncorrectable memory error is detected during startup.
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 6.2(13) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DX(0.119) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz17787 | Title: | after ISSU with 0.141 UPG and delete of pvlan l2fm cores |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
after ISSU and delete of pvlan lwfm cores
Conditions:
after ISSU and delete of pvlan lwfm cores
Workaround:
after ISSU and delete of pvlan lwfm cores
Further Problem Description:
after ISSU and delete of pvlan lwfm cores
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz16968 | Title: | delete of vlan would error %ETHPORT-2-IF_SEQ_ERROR mmunicating with MTS |
|
Status: | Other |
|
Severity: | 2 Severe |
Description: | Symptom:
upon deleting vlan associated to PVLAN the following error occurred ,
<>
2016 Apr 12 11:35:04 XBOW last message repeated 6 times
2016 Apr 12 11:46:28 XBOW %ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") co
mmunicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RI
D_PORT: port-channel222) (Follow PM FAQ #3 at: http://wikicentral.cisco.com/conf
luence/display/KGP/Port+Manager+FAQ)
2016 Apr 12 12:35:45 XBOW last message repeated 3 times
2016 Apr 12 12:47:37 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 1 rrtoken 0x1e6e671
2016 Apr 12 12:49:47 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 5 rrtoken 0x1e741e2
Conditions:
upon deleting vlan associated to PVLAN the following error occurred ,
<>
2016 Apr 12 11:35:04 XBOW last message repeated 6 times
2016 Apr 12 11:46:28 XBOW %ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") co
mmunicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RI
D_PORT: port-channel222) (Follow PM FAQ #3 at: http://wikicentral.cisco.com/conf
luence/display/KGP/Port+Manager+FAQ)
2016 Apr 12 12:35:45 XBOW last message repeated 3 times
2016 Apr 12 12:47:37 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 1 rrtoken 0x1e6e671
2016 Apr 12 12:49:47 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 5 rrtoken 0x1e741e2
Workaround:
upon deleting vlan associated to PVLAN the following error occurred ,
<>
2016 Apr 12 11:35:04 XBOW last message repeated 6 times
2016 Apr 12 11:46:28 XBOW %ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") co
mmunicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RI
D_PORT: port-channel222) (Follow PM FAQ #3 at: http://wikicentral.cisco.com/conf
luence/display/KGP/Port+Manager+FAQ)
2016 Apr 12 12:35:45 XBOW last message repeated 3 times
2016 Apr 12 12:47:37 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 1 rrtoken 0x1e6e671
2016 Apr 12 12:49:47 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 5 rrtoken 0x1e741e2
Further Problem Description:
upon deleting vlan associated to PVLAN the following error occurred ,
<>
2016 Apr 12 11:35:04 XBOW last message repeated 6 times
2016 Apr 12 11:46:28 XBOW %ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") co
mmunicating with MTS_SAP_PVLAN for opcode MTS_OPC_ETHPM_PORT_LOGICAL_CLEANUP (RI
D_PORT: port-channel222) (Follow PM FAQ #3 at: http://wikicentral.cisco.com/conf
luence/display/KGP/Port+Manager+FAQ)
2016 Apr 12 12:35:45 XBOW last message repeated 3 times
2016 Apr 12 12:47:37 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 1 rrtoken 0x1e6e671
2016 Apr 12 12:49:47 XBOW %VLAN_MGR-2-VLAN_SEQUENCE_TIMEOUT: VLAN_MGR Event Seq.
Timed Out while communicating for Seq. Id 5 rrtoken 0x1e741e2
|
|
Last Modified: | 15-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.135) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup03080 | Title: | continuous snmp polling observing process crashes |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
With continuous snmp polling trigger device to crash
Conditions:
SNMP is stuck in TCP api
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.130), 7.1(0)D1(0.136), 7.1(0)D1(0.143) |
|
Known Fixed Releases: | 6.1(2)I3(1.19), 6.1(2)I3(2), 6.2(10), 6.2(10)S71, 6.2(10.16)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.162), 7.1(0)D1(0.169), 7.1(0)FC(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy35651 | Title: | Removing IPSG config from one Client int, clears other entries from H/W |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Problem:
I am observing that on removal of IPSG config on one Client facing interface, the IPSG entry of the other is being removed from the hardware programming.
The issue is seen even in 6.2.12, 7.2.1.D1
RCA:
DHCP is sending "MTS_OPC_IPSG_DISABLE" event for a vlan when entry deleted is last entry for the vlan. Upon receiving "MTS_OPC_IPSG_DISABLE" event in SAL we are removing the complete table. We are assuming that there's a one to one mapping for vlan to table-id but this is not true for SVI where table id is getting allocated based on VRF. So for default VRF all entries will be under single table-id and upon receiving disable event we are deleting the table which will delete all other entries in table too
Conditions:
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)DX(0.110) |
|
Known Fixed Releases: * | 6.2(16)S51, 6.2(16)S64, 7.0(0)BZ(0.115), 7.3(0)DX(0.122), 7.3(0)DX(0.133), 7.3(0)DX(0.141) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus52139 | Title: | post L3, l2 flood traffic not going out on peer-link |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Post L3 Flood to BD packet are not forwarded in the Peer Link
Conditions:
VPC setup with VxLAN configuration.
Workaround:
MAC table should be populated.
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: * | 7.2(0)D1(0.383), 7.3(0)D1(0.111), 7.3(0)D1(0.142) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00514 | Title: | Rollback removes switchport mode trunk in port-profile |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | The port-profile with switchport mode trunk an doing rollback removes the switchport mode trunk command which is the day 1 issue in rollback
Symptom:
Create port-profile with switchport mode trunk and take the checkpoint, do any config changes which are not related with port-profile. After that when we do rollback the switchport mode trunk gets removed from port-profile in running config
Conditions:
Rollback with port-profile containing switchport mode trunk
Workaround:
workaround is to after rollback done with port-profile and switchport mode trunk we need to manually configure the switchport mode trunk under port-profile
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.2(16)S46, 7.3(1)D1(0.21) |
|
Known Fixed Releases: * | 6.2(16)E1, 7.3(1)D1(0.49) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)SN, 15.6(1.1)T |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.44), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39946 | Title: | MAC learnt on non existent F2e port |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
MAC address learnt on a non existent port
"show sys int l2fm info move_db" will show stale entries.
Conditions:
Seen when a loop occurs and multiple mac flaps were seen. While this happens, if the port-channel is deleted, the process responsible for mac learning still believes the interface exist
When PeerLink is in VPC+ and legs are still in VPC , STP mac moves may cause this situation.
Workaround:
create the port-channel again and issue clear mac address-table and then delete the port-channel.
OR
issue "debug l2fm clear move_db" in affected VDC.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.79), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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-APR-2016 |
|
Known Affected Releases: | 5.2(4), 6.1(3)S5, 6.1(3)S6, 6.2(1.121)S0, 7.2(1)D1(1), 7.3(0)ZN(0.161), 7.3(1)N1(0.1) |
|
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: | CSCuv75088 | Title: | Phyport vPC with Esxi does not come up thr FEX |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Phyport vPC with Esxi does not come up thr FEX
Conditions:
When trying to bring up phyport vPC thr FEX
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.55), 7.2(1)D1(0.62), 7.2(1)D1(0.63), 7.2(1)D1(1), 7.2(1)ZD(0.54), 7.2(1)ZD(0.56), 7.3(0)D1(0.81), 7.3(0)D1(1), 7.3(0)DX(0.16) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RSP(0.7), 7.3(0)RTG(0.80), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw18366 | Title: | OTV core while bringing up 42+ OTV adjacency |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OTV process crash.
Conditions:
While add more than 42 OTV adjacency are added for on N7k.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RSP(0.7), 7.3(0)RTG(0.80), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv82106 | Title: | Multicast traffic gets blackholed when MVR configured |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
New Setup's with MVR configured will have issue with traffic getting blackholed in egress direction due to MVR vlan pruning
Conditions:
7.x Release
Workaround:
shut / no shut of the receiver port will solve the issue
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.0(1)N1(1) |
|
Known Fixed Releases: * | 7.0(7)N1(0.302), 7.0(7)N1(1), 7.0(7)ZN(0.206), 7.1(3)N1(0.633), 7.1(3)N1(1), 7.1(3)ZD(0.20), 7.1(3)ZN(0.41), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)PIB(0.15) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.6), 7.3(0)PDB(0.112), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw52501 | Title: | GBMR1: Multicast traffic loss post ISSU due to incorrect PIM DR election |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Receiver doesn't get traffic from source ( RP doesn't get register packet from first hop router)
Conditions:
In LAN, when more than one PIM node exists, the router higher metrics may not elect DR as himself ( When all nodes support dr priority)
Workaround:
One of the following can be used as workaround
Increase dr priority in problematic node
[OR]
reduce priority in DR which has been incorrectly elected
[OR]
shut and unshut the interface
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.93) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.3(0)D1(0.137), 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)IB(0.122), 7.3(0)IZN(0.7), 7.3(0)N1(0.185), 7.3(0)N1(1), 7.3(0)OTT(0.73) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39581 | Title: | OSPF sessions flap seen when scaled upto 1000 sessions. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPF session flap continuously when configured in 1000 sub-interfaces between 2 routers back to back.
Conditions:
OSPF running in 1000 sub-interfaces between 2 routers back to back:
Box bring up.
Interface flap.
Reload.
Workaround:
"timers throttle lsa 50 5000 15000" in router ospf mode.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.82), 7.3(0)D1(0.98) |
|
Known Fixed Releases: * | 7.2(1)D1(1), 7.2(1)ZD(0.101), 7.2(1)ZN(0.95), 7.2(2)D1(0.2), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.87), 7.3(0)N1(1), 7.3(0)PDB(0.112) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.125), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03410 | Title: | Nexus 6.2.x OSPF taking long time in LSA generation |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
- Customer reported that there was a delay in LSA generation.
- The cost was increased at 03:42:36 but the LSA was generated at 03:43:20 which caused an impact for the customer as all the traffic moved to this router and cause congestion on the port-channel causing an impact for nearly 45 seconds.
- The first LSA was generated at the same time for the first port-channel but for the next 3 port-channels it throttled and took over 40+ seconds
Conditions:
> Info:
1. OSPF maintains a wheel with 600 slots in which LSAs will be inserted if they are to be generated and also tracks the current slot which is being processed. Lets say an LSA is to be generated after 100 msec, then it will be inserted in (current + 2) slot (1 slot equals 50 msec).
2. There is a common throttle timer which fires every 50 msec and increments the current slot. This is done by timer thread.
3. The flooding thread picks the LSA's from the current slot and generates the LSA's. Both these happen independently.
> Sequence of steps leading to problem:
In the customer's case, an LSA was to be generated after 5000 msec and hence was inserted at (current + 100) slot. Looks like the timer thread incremented the current slot before the flooding thread could process the LSA's in current slot.
This could happen if the order of thread execution is:
Lets say that the current slot is 199 and there is an LSA at 200.
Timer thread executes and increments current slot to 200.
Scheduler schedules some other OSPF thread for the next 50 msec or more. This means the throttle timer would have fired.
Scheduler schedules timer thread which will increment the current slot to 201.
Now, OSPF will have to wait for the current slot to reach 600, then cycle back, and then from 1 to 200 again. This will take 50 * 600 = 30000 msec or 30 sec.
Workaround:
Though the issue is timing related, using interface range command seems to not lead to the problem.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 6.2(12)E6, 6.2(14.3)S0, 7.0(3)I2(1.19), 7.0(3)I2(2), 7.2(1)D1(0.79), 7.2(1)D1(1), 7.2(1)N1(0.307), 7.2(1)N1(1), 7.2(1)ZD(0.71), 7.2(1)ZN(0.70) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.402) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.1(0)ES(0.5), 7.3(0)D1(0.86), 7.3(0)D1(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv61321 | Title: | Cisco Nexus 7000 ARP Denial of Service (DoS) Vulnerability |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A vulnerability in the Address Resolution Protocol (ARP) input packet
processing of the Cisco Nexus Operating System (NX-OS) devices
unauthenticated, adjacent attacker to cause a denial of service (DoS)
condition.
The vulnerability is due to improper input validation of the ARP packet and
the Maximum Transmission Unit (MTU) size which results in a buffer overflow
which can cause the DoS condition. An attacker could exploit this vulnerability
by sending a crafted ARP packet to the device. An exploit could allow the attacker
to cause the device to be unavailable due to a DoS condition of the ARP module.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
The MTU size should be configured lower.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-4323 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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(14)S1 |
|
Known Fixed Releases: * | 6.2(14), 6.2(14)S13, 6.2(14.3)S0, 7.1(3)N1(0.616), 7.1(3)N1(1), 7.1(3)ZD(0.11), 7.1(3)ZN(0.22), 7.2(1)D1(1), 7.2(1)ZD(0.105), 7.2(1)ZN(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)EG(0.3), 7.3(0)MMD(0.9) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)SN, 15.6(1.1)T, 15.6(1.3)S |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | CSCuu34174 | Title: | UIN-1::After switch reload macs are not in sync between VPC peers |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Duplicate traffic is noticed on downstream FEX connected to F2 cards (not F2CR or F3)
Conditions:
On switch reload, mac missing on one side of VPC and traffic hashes to the side missing.
Workaround:
clear mac address dynamic
OR clear mac address on the side present.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.506) |
|
Known Fixed Releases: * | 7.3(0)D1(0.69), 7.3(0)D1(1), 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.15), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux94893 | Title: | N77: There is difference to detect removing linecard by slot number |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N77: There is difference to detect removing linecard by slot number
Conditions:
- port-channel member port is in one slot.
- when remove module, there is difference by slot number.
- time for down lag
- remove connected route
- slot of highest number is about one second.
- slot of lowest number is about three seconds.
Workaround:
none in this time.
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S39, 7.3(0)DX(0.91), 7.3(1)D1(0.40) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy49752 | Title: | N7K-C7700 : Unable to manually walk nexus coppoids cbQosPoliceStatsTable |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Cu reported, they are not able to poll CoPP OIDs ( cbQosPoliceConformedPkt64 & cbQosPoliceViolatedPkt64) for their Nexus 7700 SWs.
NX-SW - Nexus7700
NX-OS version : 6.2(10)
Conditions:
This issue is noticed for only Nexus 7700 platform release : 6.2(10).
Not applicable for Nexus 70xx platforms.
Workaround:
None
Further Problem Description:
BU DE team identified as the other bug fix brake the CoPP MIB functionality.
Engineering team confirmed that, this issue is exist in 6.2.12 and 6.2.14 releases also.
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S47, 7.3(1)D1(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCup81570 | Title: | npacl filter missing for line vty, also action logged is incorrect |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
committed into bender barnch
Conditions:
committed into bender barnch
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(10)S17 |
|
Known Fixed Releases: * | 6.2(14a)S3, 6.2(16), 6.2(16)S16, 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)D1(0.228), 7.1(0)D1(0.233), 7.1(0)N1(0.280), 7.1(0)N1(0.290), 7.1(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr91121 | Title: | NX-OS isis auth configuration not retained under p2p ethernet interface |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When ISIS authentication configuration is applied under a point-to-point Ethernet interface
on a Cisco Nexus 7000 series switch with NX-OS releases 5.1(2), 5.1(3), 5.1(4),
the configuration does not appear under the "show run interface ethernet x/y" and
therefore cannot be saved into the startup-config.
If isis authentication is configured without specifying level-1 or level-2, it will not function.
If isis authentication is configured with a level, i.e. level-2, it will function but only until a reload.
Conditions:
The interface is configured as isis point-to-point, i.e. with the "medium p2p" command.
Workaround:
Configure the interface as isis broadcast, i.e. remove the "medium p2p" command.
Other:
The issue applies to port-channel interfaces as well as long as they are configured as isis point-to-point, i.e. with the "medium p2p" command.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.1(2), 5.2(1) |
|
Known Fixed Releases: * | 5.2(1)N1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz13215 | Title: | VSH library memory leak (libutils.) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
A memory leak occurs in the VHS library , which can lead to a tacacs crash
Conditions:
This symptom is seen when you have aaa authorization enabled and you issue commands that require authorization checking. Note, each time the leak happens is relatively small but over time (months, years, etc ) it can grow large enough that it causes the tacacs process to crash
Workaround:
None, this issue is resolved in 5.2(5) and 6.1(1).
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.1(5) |
|
Known Fixed Releases: * | 5.2(4.73)S0, 6.0(2)U2(1), 6.0(2)ZD(0.5), 6.1(0.273)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn53150 | Title: | Nexus does not send new BGP updates |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus does not send new attribute updates to RR
Conditions:
The issue happens when the bgp attributes from an external ASs are changed
Workaround:
Sof Clear BGP
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.0(3) |
|
Known Fixed Releases: * | 4.2(8)S16, 4.2(8.60)S0, 5.2(1)S7, 5.2(1.8)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr88741 | Title: | Interface commands not working when pushing configuration with SNMP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Interface related configurations are not being processed and are causing an error to be printed in the form of a syslog message. Configurations could not be properly applied using SNMPSET.
Conditions:
Configurations cannot be applied using SNMPSET.
Workaround(s):
Workaround is to manually make the interface configuration changes through the CLI or XML interface, instead of using the SNMPSET option.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.1(4) |
|
Known Fixed Releases: * | 5.1(10.40)S0, 5.1(5)S1, 5.1(5)S2, 5.1(5)S5, 5.2(2)S14, 5.2(2)S22, 5.2(2.12)S0, 5.2(2.19)S0, 6.0(0.31)S0, 6.0(0.35)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn13332 | Title: | Peers shutdown due to NOMEM on receiving around 63K attributes |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N7K runs into BGP related errors:
2011 Feb 8 01:52:02 N2 %BGP-3-ATTRID_OP: bgp-65001 [12126] Failed to find attribute ID
2011 Feb 8 01:52:02 N2 %BGP-3-NOMEMORY: bgp-65001 [12126] Could not allocate Attr entry, attr id
Conditions:
Seen on NXOS 5.1 code
Workaround:
None. Fix is available in 5.2.1
More Info:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.180) |
|
Known Fixed Releases: * | 5.2(0.218)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto36485 | Title: | XML requests rejected when AAA login enabled but CLI accepted |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
- DCNM discovery for Nexus platform devices will fail with message as 'Insufficient user privileges to set the DCNM required log levels' even if the user has sufficient privileges when TACACS+ AAA login is enabled in the device
Conditions:
This issue could occur if we discover the switch in DCNM with the following setup:
- TACACS+ AAA authentication enabled in the switch by disabling the shell service in AAA server( eg. ACS server) for the User used to login to the switch.
Workaround:
- Enable shell service in AAA server(eg. ACS server) for the user with role which has privilege to configure the device.
eg., network-admin
- After enabling the shell service in AAA server(eg. ACS server) as specified above, rediscover the device in DCNM.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 5.2(0.264)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCti35846 | Title: | 346: bgp crash while creating 4k interfaces |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP crash is seen while creating 1k subinterfaces
Conditions:
Create 4k subinterfaces
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.0(0)MP1(0.354), 5.1(0.231)S0, 5.1(1), 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc54335 | Title: | NXOS range creates MST region boundaries |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: |
Symptom:
Cisco Nexus 5k/7k NXOS vlan range is as follows:
1-3967,4048-4093
So the following vlans are reserved:
3968 to 4047 and 4094
This differs from the Cisco Catalyst switch reserved vlans:
0, 4095, 1002-1005 reserved by the cat6k
Best practice is to create mapping for all used and non-used vlans from the
very beginning. Because of this change of vlan mapping between the two set of
switches, it causes MST regions to be separated and as a result it creates a
region boundary.
Conditions:
The problem happens only when Cisco Nexus switch is connected to Cisco Catalyst
switch running MST and which has different range of reserved vlans
Workaround(s):
In the MST region, please specify the range of vlans which does not contain a
vlan which is in the reserved list of any of the switches.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 4.2(1)N2(1), 5.0(0.253), 5.0(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz18472 | Title: | bgp process crash on "clear ip bgp vrf < > *" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
BGP process somtimes may crash after attempting clear ip bgp < > or restart BGP
Conditions:
when sendbuf msg limits exceeds the max_buf limit.
Workaround:
So far seen over a user CLI driven activity, track CLI used prior to the crash.
Further Problem Description:
sendbuf and the previous sendbuf overwrites the malloc header of the next
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(0.249)S7 |
|
Known Fixed Releases: * | 6.1(0.267)S0, 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus67129 | Title: | vrf import map doesn't process multiple paths |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
vrf import map doesn't process multiple paths in VRF-lite scenario
Conditions:
When importing ECMP's from a source VRF to a target VRF locally, if the import-map is configured in the target VRF to set any attribute, the "set" operation will only be performed on one of the multiple paths. Due to this, ECMP is broken (one path has different attribute after import-map processing).
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(2), 7.2(0.1) |
|
Known Fixed Releases: * | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.39), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.0(3)I1(1.198), 7.0(3)I1(2), 7.0(3)IST2(1.2), 7.1(0)AV(0.74), 7.1(0)ES(0.18) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu06829 | Title: | SUP switchover causes duplicate connection on switchover device |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On sup switchover or BGP process restart, duplicate connection request error is seen on switchover device.
Conditions:
1. Multiple sessions between switchover peer and helper peer.
2. High route scale
Workaround(s):
Workaround:
If multiple sessions are to be run between two boxes, configure one peer to be a passive listener always.
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(5), 7.0(3)I1(1.206), 7.0(3)I1(1.233) |
|
Known Fixed Releases: * | 7.0(3)I2(0.365), 7.0(3)I2(0.367), 7.0(3)I2(0.381), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub32420 | Title: | bgp show cmds timeout, after configuring template/password for 1k peers |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP commands get stuck after removing a password command.
Conditions:
MD5 authentication has to be enabled on BGP peers
Workaround(s):
to restart BGP issue "restart bgp ".
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(1)S50 |
|
Known Fixed Releases: * | 6.1(1.65)S0, 6.1(2), 6.2(0.285), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl21401 | Title: | RBAC, Nexus show role feature does not map IF-MIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RBAC, Nexus show role feature does not map IF-MIB
Conditions:
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.2(0.225)S0, 7.0(1)ZD(0.3), 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty57734 | Title: | igmp snoping not enabled back if vlan configuration <> cmd is remo first |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Removing VLAN configuration doesn't remove IGMP Snooping configuration under VLAN Configuration.
(1) disable IGMP Snooping
Switch(config)# vlan configuration 2
Switch(config-vlan-config)# no ip igmp snooping
Switch(config-vlan-config)# show ip igmp snooping | inc ooping
Global IGMP Snooping Information:
IGMP Snooping enabled
IGMP Snooping information for vlan 1
IGMP snooping enabled <========### default is enabled
IGMP Snooping information for vlan 2
IGMP snooping disabled
(2) Delete VLAN Configuration
Switch(config)# no vlan configuration 2
(3) IGNMP Snooping Configuration remains
Switch(config)# show ip igmp snooping | inc ooping
Global IGMP Snooping Information:
IGMP Snooping enabled
IGMP Snooping information for vlan 1
IGMP snooping enabled
IGMP Snooping information for vlan 2
IGMP snooping disabled <========= It should be enabled
Conditions:
Remove VLAN Configuration
Workaround:
Manually "enable IGMP"(default) Snooping under VLAN Configuration.
More Info:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(0.226) |
|
Known Fixed Releases: * | 6.0(2)U3(0.655), 6.0(2)U3(1), 6.1(0.282)S0, 6.1(1)S14, 6.1(1.12)S0, 6.2(0.217), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua68725 | Title: | 'mpls static binding' CLI missing after rollback operation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On rolling back to a checkpoint containing 'mpls static binding' command which uses dynamic integer label values,label value is not retained.
Conditions:
Configure 'mpls static binding ' using a label range.Remove this configuration.Rollback to the checkpoint.Not able to retain the label value.
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(9)S2, 6.1(1)S10 |
|
Known Fixed Releases: * | 5.2(9.18)S0, 6.1(1)S29, 6.1(1.31)S0, 6.1(4.1)S0, 6.2(0.217), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz48447 | Title: | Block non-default vrf creationin admin VDC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
"Default VRF" is not deleted on sup2. Only non-default VRF's are deleted.
Conditions:
Happens when a switch boots directly as admin-vdc.
Workaround(s):
"Default VRF" cannot be removed, there is a lot of dependency on default VRF information.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.1(0.267)S1, 6.1(1)S24 |
|
Known Fixed Releases: * | 6.1(1)S38, 6.1(1.42)S0, 6.2(0.217), 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCto88789 | Title: | NXOS: L3VPN-MIB; issue with mplsL3VpnVrfVpnId object |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:mplsL3VpnVrfVpnId object returns wrong data
Conditions:mplsL3VpnVrfVpnId object walk
Workaround:check configured VpnId via cli
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(0.1) |
|
Known Fixed Releases: * | 5.2(1)S6, 5.2(1.8)S0, 7.0(1)ZD(0.3), 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk46878 | Title: | SNMP community not removed in show tech when using an ACL |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a Nexus 5000 or 7000 series switch, SNMP community is not removed in the output of show run in the output of show tech when the community has an ACL tied to it
snmp-server community group network-operator
snmp-server community group network-admin
snmp-server community group network-admin
snmp-server community testing123 use-acl snmp-acl
Conditions:
There is an access-list tied to the snmp-server community.
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.0(2)N1(1) |
|
Known Fixed Releases: * | 5.1(10.1)S0, 5.1(2.16)S0, 5.2(0.225)S0, 7.0(1)ZD(0.3), 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCta10776 | Title: | n7k: 4.2.0.232.S3: sshd: Broken pipe length of packet |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Syslog message displayed when sshd session to NXOS platform is abruptly
interrupted and NXOS fails to record the IP address for the syslog function.
Symptom:
%DAEMON-2-SYSTEM_MSG: fatal: Write failed: Broken pipe length of packet causing
error 140 140 - sshd[14913]
Conditions:
Workaround:
None at this time. The log message is not indicative of any known serious issue.
Further Problem Description:
Resolution Summary:
Syslog warnings will still appear if SSH session is prematurely terminated.
However, now the message will log the associated Client IP address.
Example:
fatal: Write failed: Broken pipe .Client is ,length of packet causing error 52 52 - ssh
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.1(4) |
|
Known Fixed Releases: | 4.2(0.247), 4.2(1), 4.2(1)N1(1), 5.0(0.153), 5.0(0.156), 5.0(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy92780 | Title: | bgp table-map filter not applying to routes already in rib |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP Routes that are in RIB already are not withdrawn from RIB even though they are denied by table-map
Conditions:
table-map filter is configured, and routes are already in RIB before the table-map filter config.
Workaround:
None without impact - e.g. neighbor shut/noshut., or clear ip route
Further Problem Description:
|
|
Last Modified: | 09-APR-2016 |
|
Known Affected Releases: | 7.0(3)I3(0.315) |
|
Known Fixed Releases: * | 7.0(3)I4(0.60), 7.0(3)I4(1), 8.3(0)SF(0.70) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtn85246 | Title: | bridgemib walk can cause infinite walk on NMS |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMP walk on bridge MIB can cause infinite walk on NMS when there are private vlan is enabled.
Workaround:
Disable private-vlan before doing SNMP walk on bridge MIB.
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(0.249)S0, 8.3(0)SF(0.10), 8.3(0)SF(0.2), 8.3(0)SF(0.75) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut94161 | Title: | EEM: Configuration failed with: 0x412c000d validation timed out |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Configuring EEM with syslog as trigger is not accepted in a Nexus 5500/5600/6000
esc-5648-left(config)# event manager applet ntp
esc-5648-left(config-applet)# event syslog pattern "%PFMA-5-MOD_STATUS: Module 1 current-status is MOD_STATUS_ONLINE"
Configuration failed with: 0x412c000d validation timed out
Conditions:
Configuring EEM
Workaround:
Restart of evmc process can be done. Please open a TAC case for this since it needs to be done from the linux prompt.
Further Problem Description:
|
|
Last Modified: | 12-APR-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.0(3)I2(0.528), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 7.1(2)N1(0.556), 7.1(2)N1(1), 7.1(2)ZD(0.11), 7.1(2)ZN(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq69790 | Title: | 'sh spanning-tree internal event-history all' causes STP instability |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
In large scale configurations running 'sh spanning-tree internal event-history all' may cause network instabilities (BPDU loss, other control plane protocol traffic loss) at the time command is ran
Conditions:
Workaround:
Issue is being investigated
Only workaround known at present is to avoid running command
Further Problem Description:
|
|
Last Modified: | 13-APR-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 6.1(2)I3(3.44), 6.1(2)I3(4), 7.0(3)I1(0.264), 7.0(3)I1(1), 7.0(3)I2(0.101), 7.0(3)I2(0.97T), 7.0(3)I2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy38146 | Title: | RIP keep advertising route even though original route source is down |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
RIP keeps prefix in RIP database as "redistributed", even though original prefix gone from RIB:
N7K-1# sh ip rip ro 10.0.5.0/24
>10.0.5.0/24 next-hops 2
via 0.0.0.0, metric 1, tag 0, redistributed route <<<<<<<<<<<<<<<<<
via 10.0.12.2 Ethernet8/1, metric 2, tag 0, timeout 00:02:40
Conditions:
Prefix (for example, static) is redistributed into RIP.
Same prefix is learnt from RIP with higher metric.
Original (static) prefix has been removed from configuration.
Workaround:
Redistribute the prefix with metric higher, than learnt from RIP.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 6.2(12), 7.0(6)N1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.47), 7.3(1)N1(0.331), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy64775 | Title: | EIGRP redistributed routes wedged in topology table |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If the nexus is redistributing a route into EIGRP (a floating static route for example), then receives an update for the same route via EIGRP from a neighbor, the nexus will compare the routes based on metric rather than based on AD. The defect has been observed on 7.3(0)D1(1) and 7.2(1)D1(1) code versions on the nexus 7k.
Conditions:
The Static route the nexus has configured, must be installed in the RIB and redistributed into EIGRP firstly on the Nexus, creating a local redistributed entry in the EIGRP topology table. The EIGRP route received from the neighbor has to have a less preferred metric than the calculated metric of the redistributed static route on the Nexus.
Workaround:
clear ip eigrp topology x.x.x.x/yy on the nexus
set a less preferred metric on the redistributed route on the nexus
Further Problem Description:
The defect has only been observed in EIGRP on Nexus devices.
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.47), 7.3(1)N1(0.331), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz18325 | Title: | Outage may be observed during vPC recovery |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
In a vPC environment, when the vPC domain on the vPC primary (or operational secondary) is reloaded, the STP state of the vlans on the peer-link may remain in blocking state until the delay-restore timer expires.
This results in the vlan remaining in Vlan/BD down status.
Conditions:
This issue is observed when all of the following conditions are true:
- peer-switch is configured on the device
- There are no orphan trunk ports carrying the vlan.
Workaround:
Remove peer-switch from the vPC pair or add an orphan trunk port carrying the vlans.
Further Problem Description:
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut94652 | Title: | Adding basic show commands to feature show techs (N7K) |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
some commands are missing in feature show tech which causes BDB/BORG data analysis automation to fail
Conditions:
all
Workaround:
na
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui33220 | Title: | SSTE: OSPF/BFD convergence time high after a trigger clear ip ospf nei |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
OSPF takes 45 sec to converge and BFD takes around 2 min 30 sec to converge after doing clear ospf neighbor for a large number of sessions on physical interfaces.
Conditions:
BFD takes around 2min 10 sec to converge after a clear ospf is done from a steady state. This is seen only with a clear of large number of OSPF/BFD neighbors together and there be should be no major difference in convergence for a small number of BFD sessions.
Workaround:
None
More Info:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: | 6.2(2)S17 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy71149 | Title: | show logging log mixed old and new log after logging monitor command |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
show logging log output broken after configuring "logging monitor".
After configuring it , old log and new log are showed alternately like below.
2016 Mar 11 17:56:17 N5672-G12 %ETHPORT-5-IF_UP: Interface loopback0 is up
2016 Mar 11 17:59:09 N5672-G12 %ETHPORT-5-IF_UP: Interface loopback300 is up <====
2016 Mar 11 17:56:17 N5672-G12 %ETHPORT-5-IF_UP: Interface loopback2 is up
2016 Mar 11 17:59:09 N5672-G12 %ETHPORT-5-IF_UP: Interface loopback301 is up <====
2016 Mar 11 17:56:17 N5672-G12 %ETHPORT-5-IF_UP: Interface loopback3 is up
Conditions:
Nexus5672
NXOS7.2(0)N1(1),7.3(0)N1(1)
After configuring "logging monitor [number]"
Workaround:
clear log after configuring "logging monitor [number]"
Further Problem Description:
|
|
Last Modified: | 20-APR-2016 |
|
Known Affected Releases: * | 7.0(3)I4(0.61) |
|
Known Fixed Releases: * | 7.0(3)I4(0.91), 7.0(3)I4(1), 7.3(1)D1(0.48), 7.3(1)N1(0.332), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu76369 | Title: | Random characters in show ip igmp policy statistics reports vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Random characters are observed in the output of 'show ip igmp policy statistics vlan <>
Nexus9k# show ip igmp policy statistics reports vlan 100
Interface \6?? doesn't exist
Nexus 9k# show ip igmp policy statistics reports vlan 100
Interface tN?? doesn't exist
Conditions:
If a SVI is not deployed on Nexus 9k and , show ip igmp policy statistics reports vlan <> is executed for the VLAN ,
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 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)TSH(0.99), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw55057 | Title: | urib not updating FIB when the RP has the same admin distance as AM |
|
Status: | Fixed |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14) |
|
Known Fixed Releases: * | 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)PIB(0.9) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81067 | Title: | DFA: Multicast SG join state missing in BGP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
L3 multicast over DFA fabric may not be forwarded to some receivers connected behind DFA leaves
Conditions:
L3 multicast over DFA with receivers behind leaf switches
Workaround:
Clear the bgp mvpn table on DFA switches
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.1(2)N1(0.599) |
|
Known Fixed Releases: * | 7.1(3)N1(0.673), 7.1(3)N1(1), 7.1(3)ZD(0.44), 7.1(3)ZN(0.85), 7.2(2)D1(0.5), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.10), 7.2(2)ZN(0.9), 7.3(0)D1(0.178) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv12718 | Title: | G bit set for HSRP VMAC in vPC setup with state Listen/Listen |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Reachability to gateway IP (HSRP VIP) breaks when HSRP state is Listen/Listen.
Issue seen in a DCI setup where HSRP state across DCs with Active/Standby in one site and Listen/Listen in other site is preferred.
Conditions:
vPC setup maintaining HSRP state with 4 gateways.
Peer-link configured on F1 where proxy routing occurs with F1-M1 combination.
Device running 6.2.8 code, seen with 6.2.8b.
Not seen with 6.2.10, 6.2.12
Workaround:
If the setup is a DCI, apply FHRP isolation filters for the vlans in question.
If all 4 gateways in the same site, limit the hsrp number of gateway only to 2 devices by shutting down SVIs on two devices is the only workaround possible.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(8b), 7.3(0)D1(0.64) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.31), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)S87 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.29), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)EG(0.3), 7.3(0)FMD(0.9), 7.3(0)OTT(0.55), 7.3(0)PDB(0.57) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz11696 | Title: | ISSU during upgrade process, removal of SFP is not recognized |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After ISSU is completed, the port which has no SFP inserted still shows as "connected". Although DOM and SPROM values are empty, the switch port still sees the SFP details of the removed SFP (show int ethx transceiver details).
The peer port has the correct "notconnected" state
Conditions:
Issue only appears when you remove of a SFP during the module upgrading phase of ISSU.
Workaround:
Shut the affected port, plug the SFP back in, then "no shut" the port.
SFP status of affected port and peer port will be corrected.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.3(1)DX(0.3) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.499) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.9), 7.3(0)PDB(0.112), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S4, 7.3(0)D1(0.165), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)OTT(0.73), 7.3(0)PDB(0.127), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)DHB(0.31) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCua39152 | Title: | Command injection with CA functionality |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptoms:
Cisco Nexus devices contain a local command injection vulnerability within the CA configuration commands of the CLI. An authenticated, local attacker could inject commands
that are subsequently executed on the underlying operating system with elevated privileges.
The vulnerability exists due to a failure to properly sanitize all user supplied input prior to using it to execute commands on the underlying operating system. An attacker with
administrative level privileges on an affected device could inject arbitrary commands that are then executed on the underlying operating system with elevated privileges.
Conditions:
Cisco Nexus devices running an affected version of Cisco NX-OS software.
Workaround:
None.
Further Problem Description:
This vulnerability can only be exploited by an administrator with sufficient privileges to execute the affected commands.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.8/6.5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:L/AC:L/Au:S/C:C/I:C/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2012-4139 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: | 21-APR-2016 |
|
Known Affected Releases: | 6.0(2) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)D1(0.67), 7.3(0)D1(1), 7.3(0)DHB(0.31), 7.3(0)EG(0.3), 7.3(0)IB(0.43), 7.3(0)MMD(0.9), 7.3(0)OTT(0.30), 7.3(0)PDB(0.32), 7.3(0)RTG(0.68) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | 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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.121), 7.3(0.121) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16), 6.2(16)S9, 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)RTG(0.90), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw99731 | Title: | Multicast routing doesnt work if IPv4 routes are learnt over IPv6 NH |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Multicast routing doesn't work and RPF stays if even
Conditions:
Ipv4 unicast route has IPv6 next-hop.
Workaround:
Using a default route to reach IPv4 prefixes via a IPv4 Next-hop.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1.6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)RSP(0.7), 7.3(0)RTG(0.114), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.195), 7.3(0)ZN(0.211) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw09891 | Title: | BGP peers flap continuously |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
BGP peers will flap continuously and not stabilize even after several hours have passed.
Conditions:
Outbound policy with multiple AS Path regex matches that deny the route, coupled with non-default holdtimers (4/12, 10/30).
Workaround:
Change holdtimer to default values. Simplify the regex is possible and match the access-list *after* the prefix list in the route-map sequence.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)S102 |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)PDB(0.131), 7.3(0)RSP(0.7), 7.3(0)RTG(0.71), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(2)FIP(0.158), 7.2(2)D1(0.32), 7.2(2)D1(0.33), 7.2(2)D1(0.34), 7.2(2)D1(0.35), 7.2(2)D1(0.36), 7.2(2)ZD(0.47), 7.2(2)ZD(0.48), 7.2(2)ZD(0.49) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.226) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 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), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | CSCuu36071 | Title: | Packets encaped with wrong VNI after addition of new link to Peerlink PC |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Receivers at remote vxlan L2 gateway may experience traffic lose. This is because the packets at vPC L3 gateway is encapped with wrong VNI value. This can be confirmed by examine the VNI field of the vxlan encapped packet received at remote L2 gateway.
Conditions:
The condition to hit the issue is to configure new vPC peer-link in a new hardware instance. This may cause timing issue when program the encap route in the new peer-link instance.
Workaround:
unconfig, then reconfig the multicast encap for this bridge-domain under nve interface will clear the wrong encap route and reprogram with correct information.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.490), 7.2(0)VZD(0.33) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.1(0)ES(0.24), 7.2(1)D1(0.36), 7.2(1)D1(1), 7.2(1)ZD(0.31), 7.3(0)D1(0.34), 7.3(0)D1(0.45), 7.3(0)D1(0.52), 7.3(0)D1(0.53), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur18621 | Title: | Show snmp trap cmd doesn't show status of msdp trap configs. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Status of MSDP trap is not shown in the output of 'show snmp trap'
Conditions:
Trap type, Description and status is not shown for show snmp trap command for MSDP.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)S89 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38), 7.1(0)EV(0.137), 7.1(0)PDB(0.317), 7.1(0)SIB(99.82), 7.2(0)D1(0.360), 7.2(0)D1(1), 7.2(0)N1(0.43) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.11), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0.149) |
|
Known Fixed Releases: * | 7.3(0)D1(0.174), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IZN(0.13), 7.3(0)N1(0.228), 7.3(0)N1(1), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.189) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut71442 | Title: | "PIM Data Register" debug message missing after receiving data packets |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When the FHR receives the data packets, a data register is sent to the RP. As part of the conformance test, the script expects following debug msg -
2014 Dec 2 00:58:13.070567 mcastfwd: libpim [6339] Sent PIM Data Register for (10.10.2.201, 239.23.23.23) to RP 10.10.10.1, ttl 254 (1 registers in last sec)
But the above debug is not observed on the console
Conditions:
There is no functionality impact here. Only when we enable mcastfwd debugs, we expect the debugs to show up on the console but for some reason the debugs are not showing up on the console.
Workaround:
No workaround. The bug is purely for development purpose.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.475), 7.2(0)D1(0.499), 7.2(1)D1(0.54) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 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)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12)E5 |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 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)TSH(0.99), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.120) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)D1(1), 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)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw66926 | Title: | errors observed in xml validation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
The XML generated by ELOAM in response to manageability requests does not conform to the schema.
Conditions:
This impacts all ELOAM show commands.
Workaround:
Running the show commands from the CLI works successfully.
Further Problem Description:
The XML interface returns all the correct data but not in a schema compatible form.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IB(0.114), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
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...
Further Problem Description:
None.
Resolution Summary:
show tech-support fcoe is renamed to show tech-support fcoe_mgr and continues to contain just fcoe manager information.
show tech-support fcoe will now contain a large amount of information specifically for troubleshooting FCoE related problems. It will include show tech-support fcoe_mgr and other FC/FCoE related show techs.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.148), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.122), 7.3(0)IZN(0.13), 7.3(0)N1(0.197), 7.3(0)N1(1), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S20, 7.3(0)D1(0.72), 7.3(0)D1(1), 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) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.156), 7.3(0)D1(1) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.6), 7.2(2)N1(0.334), 7.2(2)N1(1), 7.2(2)ZD(0.11), 7.2(2)ZN(0.10), 7.3(0)D1(0.202), 7.3(0)D1(1), 7.3(0)IZN(0.13), 7.3(0)N1(0.264), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv90027 | Title: | NXOSv Interface ACL config should be blocked until supported |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
NXOSv (virtual) will allow interface ACL configs to be configured without error. But if applied to non management interfaces, they won't block traffic.
Conditions:
ONly applies to virtual NXOS (a.k.a. titanium)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.57) |
|
Known Fixed Releases: * | 7.2(1)D1(0.70), 7.2(1)D1(1), 7.2(1)ZD(0.62), 7.3(0)D1(0.91), 7.3(0)D1(1), 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.67) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.33), 7.3(0)PDB(0.112) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv34380 | Title: | vPC switch keeps sending (S, G) joins even after (*, G) entry gone. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIM (S, G) joins are sent upstream even when corrosponding (*, G) entry has expired.
Conditions:
vpc-peers with "ip pim pre-built spt" configured. Active source but receivers are expired.
Workaround:
clear ip mroute will remove the unwanted (S, G) entry.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)ZD(0.99) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 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.43), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.471) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 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), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.96) |
|
Known Fixed Releases: * | 7.3(0)D1(0.126), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.90), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv81861 | Title: | OSPF NSSA sending type 7 LSA after converted to regular area |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Type 7 LSA being sent by a device that is not a NSSA device
Conditions:
After changing from NSSA to regular area
Workaround:
None
Further Problem Description:
Recovery: restart ospf
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I2(1.19), 7.0(3)I2(2), 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.47), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75242 | Title: | ISSU upgrade: igmp HAP reset |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
An ISSU upgrade on a Nexus 6000 experiences a HAP reset when upgrading to 7.0(5)N1. On the vPC peer, each chassis crashes while the other is in the process of upgrading:
At 764728 usecs after
Reason: Reset triggered due to HA policy of Reset
Service: igmp hap reset
Version: 7.0(2)N1(1) << crash on standby as primary is in the process of upgrading during ISSU
At 203979 usecs after
Reason: Reset triggered due to HA policy of Reset
Service: igmp hap reset
Version: 7.0(5)N1(1) << crash on primary as standby is in the process of upgrading during ISSU
Conditions:
The device(s) experiences an 'igmp' process HAP reset during this upgrade regardless of whether or not the Aggregate is provisioned for igmp/multicast.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)N1(0.117) |
|
Known Fixed Releases: * | 7.0(3)I2(0.519), 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.0(7)N1(0.293), 7.0(7)N1(1), 7.0(7)ZN(0.188), 7.2(1)D1(0.9) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | 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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.93), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw81680 | Title: | ELOAM syslog to all VDCs does not work during LC boot |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During LC boot, if ELOAM hits any errors it is unable to syslog to alert the user.
Conditions:
- ELOAM must be configured
- The linecard must be booting up
- ELOAM must hit an unexpected error condition
Workaround:
This is a secondary failure in which the user might not be alerted to potential errors. No workaround should be needed, but the "show ethernet oam" commands can be used to verify protocol state.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.127) |
|
Known Fixed Releases: * | 7.3(0)D1(0.135), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.41), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu39870 | Title: | NAM Module flooding accounting log |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When a N7K-SM-NAM-9G-K9 Network Analysis Module is inserted into a chassis and powered up, it floods the accounting logs with unhelpful information:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd=
Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd=
Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd=
Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
Conditions:
- Neuxs 7K with NX-OS 6.2(12) or other newer NX-OS
- This problem happens when the NAM module is powered on.
Workaround:
No workaround except to poweroff the NAM module.
Further Problem Description:
This is an issue for the accounting log that impacts TAC's ability to troubleshoot. This is a very serious issue. When the NAM module is inserted and powered up, it floods 4 empty accounting log messages every minute, which basically makes the "show accounting log" command useless to TAC. See below for an example of the flooding:
Wed May 6 04:20:05 2015:type=start:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:05 2015:type=stop:id=vsh.5698:user=root:cmd=
Wed May 6 04:20:07 2015:type=start:id=vsh.5714:user=root:cmd=
Wed May 6 04:20:08 2015:type=stop:id=vsh.5714:user=root:cmd=
Wed May 6 04:21:05 2015:type=start:id=vsh.5758:user=root:cmd=
Wed May 6 04:21:05 2015:type=stop:id=vsh.5758:user=root:cmd=
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.188), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)TSH(0.99), 7.3(0)ZD(0.206), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux38743 | Title: | VPC - IGMP membership query is leaked to IGMP router port |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
IGMP membership query is leaked to router port if leave is received on an orphan port
Conditions:
The leave is received on an orphan port
Workaround:
Do not use orphan port, use VPC port instead.
The second workaround is to increase the group timeouts in the network.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)ZN(0.105) |
|
Known Fixed Releases: * | 7.3(0)TSH(0.99), 7.3(1)D1(0.17), 7.3(1)N1(0.309), 7.3(1)N1(1) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)TE(0.9) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.21), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.114), 7.3(0)ZN(0.125) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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: | 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: | 21-APR-2016 |
|
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)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw46432 | Title: | GBR MR1: dcefib crash @ *__GI_raise post ISSU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After ISSU from GBR MR to upgrade images followed by manually issued line-card upgrades for F2E modules, the process DCEFIB may at times crash on the module.
Conditions:
In a VPC+ topology with Fabricpath multi-topo feature enabled, after the VPC peers are upgraded from GBR MR1 to the upgrade images , if line-card upgrade is manually issued for the F2E modules in the VDC, the process DCEFIB may sometimes crash.
Workaround:
The process should recover after a single crash. IF it does not, module reload may be required to fix the issue.
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(0.89), 7.3(0.140) |
|
Known Fixed Releases: * | 7.3(0)D1(0.169), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.120), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu06999 | Title: | adding a large number of Vlans to a port-profile failing. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:Viewing or adding port-profile with a large number of VLAN ranges my fail.
Conditions:The limit for VLAN ranges is currently set to 64, adding more than this will cause the following error:
"ERROR: Command Parsing Failed"
Workaround:Reduce the number of VLAN ranges to less than 64
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: * | 6.2(13.4)S0, 6.2(14), 7.0(0)BZ(0.98), 7.0(0)FHS(0.23), 7.0(0)HSK(0.587), 7.1(0)ES(0.24), 7.2(0)BA(0.25), 7.3(0)D1(0.27), 7.3(0)D1(1), 7.3(0)DHB(0.2) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw71136 | Title: | Static Mac address assigned on interface after default interface command |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Static mac address got configured on L2 port after defaulting the interface configuration
Conditions:
This problem is seen when Supervisor is staged in Chassis 1 and then moved to Chassis 2. Now on chassis 2 if you run default interface command on L2 ports then you will observed static mac address got configured on those L2 ports. This problem was seen on 6.2.10 code.
Workaround:
Remove the static mac address using the command "no mac address xxxx.xxxx.xxx"
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S9, 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.115), 7.3(0)RSP(0.7), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.114), 7.3(0)PDB(0.128), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I3(0.267), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.100), 7.0(3)IDM3(0), 7.0(3)IDM3(0.6), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.1(3)N1(0.611), 7.1(3)N1(1) |
|
|
| |
| |
|
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:
Clear the checkpoint database and try to do the session commit
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)S92 |
|
Known Fixed Releases: * | 7.3(0)D1(0.87), 7.3(0)D1(1), 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)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut83347 | Title: | MFDM crashes due to HB loss |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MFDM crashes due to Heartbeat loss to sysmgr
Conditions:
This failure can occur if there is a high number of Fex host side or network side port changes such as port flaps and PC membership updates. We do not have a quantifiable number of port change events that can lead to this crash since it is highly dependent on other components at the time of the port change events. There is a low risk of this problem occurring in normal scenarios.
Workaround:
None
Further Problem Description:
This crash will be seen under heavy system load (overall mts queues being stuck) and not under normal scenarios.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 7.3(0)FMD(0.9), 7.3(0)GLF(0.25), 7.3(0)OTT(0.55), 7.3(0)PDB(0.42), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw29235 | Title: | "restart igmp" command or ND ISSU results in "igmp hap reset" |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Non-Disruptive ISSU is performed from version 7.1(2)N1(1) (or older version) to version 7.2(1)N1(1).
Conditions:
1. Have L2 Multicast/Unicast on N5k vPC pair switches running with 7.1(3)N1(1) build.
2. Perform ND ISSU to 7.2(1)N1(1) image on vPC primary switch.
3. vPC Primary switch will be crashing due to "IGMP hap reset".
Workaround:
N/A
Further Problem Description:
N/A
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(1)N1(0.328), 7.2(2)N1(0.349), 7.3(0)N1(0.113) |
|
Known Fixed Releases: * | 7.3(0)N1(0.276), 7.3(0)N1(1), 7.3(0)TSH(0.99), 7.3(0)ZN(0.254), 7.3(1)D1(0.5), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
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:
None.
Further Problem Description:
This is a cosmetic bug; no service is impacted. The log message can be safely ignored.
LDP needs to know the destination of traffic engineering (TE) tunnels, and so listens for changes in L3 parameters on interfaces. In this case there was a change (the non-TE tunnel addition or removal) and LDP is assuming that it's a TE tunnel when it's not. LDP attempts to query OIM about the TE tunnel, but OIM is not running because TE is not running. For that reason LDP unable to get the information from OIM's SDB about the tunnel, and so logs that message.
Since TE is not supported in 7.2 releases and thus customers are not using TE, there is no need for LDP to be aware of the TE tunnel destinations, and so the log message can be safely ignored.
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.49), 7.3(0)PDB(0.102), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.155), 7.3(0)ZN(0.170) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.98) |
|
Known Fixed Releases: * | 7.3(0)D1(0.140), 7.3(0)D1(1), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun84222 | Title: | Error in help command for python cli/clid/clip apis |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Error in help command for python cli/clid/clip apis
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(8)S1 |
|
Known Fixed Releases: * | 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)IB(0.96), 7.3(0)IB(0.98), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 7.3(0)ZD(0.194), 7.3(0)ZN(0.210) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz27017 | Title: | bridge-domain and mapping it to a particular VNI doesnt shown in config |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
bridge-domain and mapping it to a particular VNI doesnt shown in config
Conditions:
Issue is present only for fabric bridge domain
Workaround:
n/a
Further Problem Description:
.
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz39613 | Title: | F3: null0-routed traffic hits CPU with IP redirects enabled |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Null0-routed traffic hits CPU and L3 TTL rate-limiter. With large amount of null0-routed traffic this may lead to ingress drops on interface
Conditions:
Traffic comes through F3 linecard interface
IP redirects configured on ingress interface
Traffic routed to Null0
Workaround:
Disable IP redirects on ingress interface
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux35766 | Title: * | Incorrect power mode w supplies are shutdown on N7k PS-Redundant config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Incorrect power mode is indicated as Non-Redundant for ps redundant mode while having enough power for the chassis and modules
Conditions:
- Configured with ps redundant mode
switch(config)# power redundancy-mode ps-redundant
- Present with shutdown power supplies.
10 N77-AC-3KW 706 W 3000 W Ok
11 N77-AC-3KW 706 W 3000 W Ok
12 N77-AC-3KW 0 W 0 W Shutdown
13 N77-AC-3KW 701 W 3000 W Ok
14 N77-AC-3KW 703 W 3000 W Ok
15 N77-AC-3KW 705 W 3000 W Ok
16 N77-AC-3KW 0 W 0 W Shutdown
Workaround:
Physically remove the shutdown power supplies from the chassis
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | 7.3(0)DX(0.88) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz22196 | Title: | Nexus: snmpd Program terminated with signal 8, Arithmetic exception. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
%SYSMGR-2-SERVICE_CRASHED: Service "snmpd" (PID 3927) hasn't caught signal 8 (core will be saved)
Conditions:
All Nexus platforms
When device is being polled with GetBulk requests.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.1(1)N1(1) |
|
Known Fixed Releases: | 7.3(1)D1(0.51), 7.3(1)N1(0.338), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz32937 | Title: | SNMPd process crash: N7k |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
SNMPd encounters an unexpected HAP reset and a core file could be seen/generated as a result.
Conditions:
SNMP is enabled and configured on the device/VDC.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy79367 | Title: | M3:IFTMC_INTERFACE_INTERNAL_ERROR: Invalid intf state provided to IFTMC |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
During LC ISSU, an IFTMC_INTERNAL_INTERFACE_ERROR syslog may appear.
Conditions:
A large number of interfaces (thousands) are flapped or receive a trigger during LC ISSU (generally needs to be on the scale of 4k subinterfaces), which is too large to be cached in MTS, so it is only partially saved.
Workaround:
Flap the affected interfaces.
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz34593 | Title: | N7K: Incorrect filename when issuing 'copy run ftp' |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
The Nexus 7K does not save the configuration filename correctly on the remote host when performing a "copy running-config ftp". This behaviour has been observed on both the default and non-default VDC's.
When performing an FTP copy to a remote host, the command allows the user to use the default filename or to specify a different name. In either case the result always writes the file as "HOSTNAME-running-config".
Example:
N7K# copy run ftp://ftp.cisco.com/system.cfg
filename on remote host: N7K-running-config
Conditions:
Workaround:
Rename the file on the remote host
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz39212 | Title: | FP & VPC ports has Vlan membership in ELTM although no config present |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Extra mac learning on fabricpath port for non-fabricpath vlan
Conditions:
copy r s vdc-all
followed by,
vdc reload with configuration,
vlan 10-100
vlan 10-50
mode fabricpath
int ethernet 3/1
switchport mode fabricpath
no shutdown
Workaround:
shut/no shut on the interface port
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz34391 | Title: | Multicast traffic loss during ISSU or SSO |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Multicast traffic loss for brief interval during SSO or ISSU
Conditions:
SSO or ISSU
Workaround:
Traffic recovers after brief interval
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz10925 | Title: | F2 ports failed with error CLP_PS_INT_ERR_FLD_EG_PKT_PNUM_ERR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LC resets with the following error -
MODULE-2-MOD_SOMEPORTS_FAILED Module 8 (Serial number: XXXX) reported failure on ports X/X-X/X (Ethernet) due to error in device DEV_CLP_FWD (error 0xca80b600)
Conditions:
ASIC interrupts could be seen when packets with random packet headers are seen, and these interrupts should be ignored. From the 'show accounting log' output, the following error will be seen -
type=update:id=invalid_ip@pts/0:user=svc-isan:cmd=exceptionlog module 8 syserr 0x424f001b devid 168 errtype 2 errcode 3397432832 phylayer 2 ports 45-48 harderror 0 desc CLP_PS_INT_ERR_FLD_EG_PKT_PNUM_ERR inband 0 (SUCCESS)
The key part of this error is "CLP_PS_INT_ERR_FLD_EG_PKT_PNUM_ER".
Workaround:
None.
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: * | 6.0(2), 6.0(3)S2 |
|
Known Fixed Releases: | 6.0(3)S6, 6.1(0.261)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui18245 | Title: | LACP BPDUs should always be untagged irrespective of Port-ch config |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When forming LACP port-channel, the port channel does not come up. The interface goes to suspended state stating the following: 'Suspended: No LACP PDUs.'
Conditions:
One of the following configured:
Globally: vlan dot1q tag native
Per Interface: switchport trunk native vlan
Workaround:
Set the configuration above to it's default value on both sides of the link.
Further Problem Description:
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: * | 6.1(3)S50, 6.1(4), 6.1(4)S26, 6.2(1.143)S5, 6.2(2)S5 |
|
Known Fixed Releases: | 6.2(10), 6.2(10)CM(0.10), 6.2(10)CM(0.8), 6.2(10)CM(0.9), 6.2(10)MS(0.1), 6.2(10)MS(0.2), 6.2(8)E1, 6.2(8)ES(0.5), 6.2(8)KR(0.8), 6.2(8)TS(0.28) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz24669 | Title: | M3-10 : 7k ACL config failed due to TCAM Spanlogic |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Configuration of an acl/qos/pbr or any policies that use access-lists on an M1-XL, M2-XL or M3 cards fail with the following error:
"Failed - Insertion of TCAM entry failed due to Spanslogic"
Conditions:
When there are large number of randomly generated source/destination address masks in ACEs, mostly non prefix masks. Ex:
10 permit tcp 157.145.112.100 0.22.216.207 127.101.157.94 0.188.86.95
20 permit udp 89.86.177.144 0.174.101.91 127.59.154.69 0.219.160.164
Workaround:
Try to avoid random masks & use prefix masks
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz19882 | Title: | non initial frag pkt does not match tcp/udp any any entry |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Non initial fragment packet (frag offset != 0) does not match acl entry
Conditions:
With the following ACE entry
permit tcp any any
permit udp any any
Workaround:
Add another entry with the fragment keyword:
permit tcp any any
permit tcp any any fragment
permit udp any any
permit udp any any fragment
Workaround:
Add another entry with the fragment keyword:
permit tcp any any
permit tcp any any fragment
permit udp any any
permit udp any any fragment
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz33057 | Title: | ACLQOS failure: ELTMC COMMIT ERROR 0x42650010, when VDC is suspended |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
A harmless error message like:
2016 Apr 19 10:03:09 SW12-admin %$ VDC-1 %$ %ACLQOS-SLOT1-2-ACLQOS_FAILED: ACLQOS failure: ELTMC COMMIT ERROR 0x42650010 for Inst:2 VDC-5 Inband_vrf_table 9, dir egress
Conditions:
When a vdc is suspended.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz42524 | Title: | FEX: BLOGGERD_INVALID_IP_ADDRESS in ISSU from 7.2.1.D1.1 to HSK2 |
|
Status: | Other |
|
Severity: | 3 Moderate |
Description: | Symptom:
While performing ISSU from 7.2.0(D1)1 to 7.3.0 (DX)1 or from 7.2.1.(D1)1 to 7.3.0(DX)1, a syslog containing the phrase "BLOGGERD_INVALID_IP_ADDRESS" might appear.
Conditions:
ISSU from 7.2.0(D1)1 to 7.3.0 (DX)1 or from 7.2.1.(D1)1 to 7.3.0(DX)1
Workaround:
This has no functionality impact and there is no workaround.
Further Problem Description:
|
|
Last Modified: | 29-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz23469 | Title: | Port profile crash in N7K DCI ( Opflex setup) on doing "no feature ipp" |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When the feature ipp which being turned off by doing no feature ipp, the ppm process crashes.
Conditions:
When the tenants are configured onto the switch using the feature ipp
Workaround:
ipp process need to wait before it exits, because with no feature ipp, ppm process will being cleaning up the profile applied for ipp to configure the tenants.
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.132) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz45591 | Title: | BFDC core generated on M1 module |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
BFDC core generated on M1 module
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy91444 | Title: | Enabling vtp in Fabricpath enabled setup should throw error |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
No error is thrown on enabling vtp when fabricpath is already enabled on the system
Conditions:
fabric path is enabled & user trying to enable vtp
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy90969 | Title: | N7K Eompls decap uses wrong MTU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
EoMPLS packets with size more than MTU of the interface - 26 bytes are dropped on the egress interface of decap.
Conditions:
- This happens when packet size is more than 26 short of the MTU of the interafce
- Smaller packets does not have any issues.
- F3 Linecards are used
- Seen in 7.2(1)D1(1)
Workaround:
Increase the MTU on the egress interface of decap with original size + 26 bytes
Further Problem Description:
If the interface MTU is 1500, packets bigger than 1474 were getting dropped. Ideally packets bigger than 1500 bytes only should be dropped.
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | 7.3(0)DX(0.133), 7.3(0)DX(0.145) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy96171 | Title: | Few BFD sessions flapping after vdc suspend/resume, reload, lc reload |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
1000 SVI's are configured, and the SVI's are allowed through ports from different LC's. On vdc suspend/resume, reload, lc reload few BFD sessions flap continuously.
Conditions:
1000 SVI's are configured, and the SVI's are allowed through ports from different LC's. On vdc suspend/resume, reload, lc reload few BFD sessions flap continuously.
Workaround:
No workaround
Further Problem Description:
|
|
Last Modified: | 30-APR-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.125) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc24985 | Title: | cannot configure interface description that starts with ';' character |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
NX-OS does not support the interface description that starts with a ';' character.
Conditions:
When you configure the interface description that starts with a ';' character the following message appears: Invalid command at '^' marker.
Workaround(s):
No workaround.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(1), 4.2(3) |
|
Known Fixed Releases: * | 5.1(0.64), 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui06909 | Title: | ENH: Nexus 7000 RMON events limit needs to be raised |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
This is seen error when more than 128 RMON Events are attempted:
"You have exceeded the max number of events that can be configured".
The number of events at the time:
samplemachine# show run | in "rmon event" | count
128
Conditions:
Nexus 7000 running NX-OS 5.1(2)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 5.1(6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.52), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.0(3)I3(0.123), 7.0(3)I3(1), 7.0(3)IDP3(1.12), 7.0(3)IDP3(2), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)D1(0.178), 7.3(0)D1(1), 7.3(0)RSP(0.7), 7.3(0)RTG(0.102) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj28897 | Title: | N7k logging level all # does not change logging facility pim or pim6 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The bug I see is that pim/pim6 do not go to ?6? but stay at their previous values when the ?logging level all 6? command is issued. This is a minor bug.
B16u1-DC1-Agg1-vdc1(config)# logging level all 6
Then via ?show logging?:
Facility Default Severity Current Session Severity
-------- ---------------- ------------------------
pim 5 7
pim6 5 5
Conditions:
B16u1-DC1-Agg1-vdc1(config)# no logging logfile
B16u1-DC1-Agg1-vdc1(config)# clear logging logfile
B16u1-DC1-Agg1-vdc1(config)# logging logfile log 7 size 2000000
B16u1-DC1-Agg1-vdc1(config)# logging level all 6
B16u1-DC1-Agg1-vdc1(config)# logging level sysmgr 1
B16u1-DC1-Agg1-vdc1(config)# clear logging logfile
Workaround:
User can try changing the pim and pim6 levels individually by logging level ip pim <> " and "logging level ipv6 pim "
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 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.53), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(6)S12 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.85), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz41935 | Title: | KERN-0-SYSTEM_MSG: tracback for memrlimit_cgroup_uncharge_as |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
%KERN-n-SYSTEM_MSG: messages seen for a kernel traceback like:
78483140.693744] Pid: 8066, comm: sysinfo Tainted: P W 2.6.99.99 #1
[78483140.693794]
[78483140.693795] Call Trace:
[78483140.693860] [] warn_on_slowpath+0x5d/0x84
[78483140.693913] [] ? jiffies_to_msecs+0x9/0x11
[78483140.693965] [] ? _raw_spin_unlock+0x83/0xd7
[78483140.694016] [] ? _spin_unlock+0xe/0x10
[78483140.694066] [] ? unmap_vmas+0x5a9/0x801
[78483140.694118] [] res_counter_uncharge_locked+0x27/0x31
[78483140.694183] [] res_counter_uncharge+0x30/0x44
[78483140.694233] [] memrlimit_cgroup_uncharge_as+0x2d/0x2f
[78483140.694282] [] exit_mmap+0x92/0x100
[78483140.694326] [] mmput+0x41/0xb6
[78483140.694367] [] exit_mm+0x107/0x113
[78483140.694412] [] ? _spin_unlock_irq+0xe/0x11
[78483140.694455] [] do_exit+0x257/0x89e
[78483140.694496] [] ? jiffies_to_msecs+0x9/0x11
[78483140.694542] [] do_group_exit+0x78/0xa5
[78483140.694584] [] sys_exit_group+0x17/0x19
[78483140.694630] [] ia32_syscall_done+0x0/0x21
[78483140.694676]
[78483140.694712] ---[ end trace de7fa95f2c32e752 ]---
Conditions:
Unknown.
Workaround:
Further Problem Description:
The process reported varies.
The messages are harmless
|
|
Last Modified: | 28-APR-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy89883 | Title: | TACACS+ authorization request with single-connection using flags 0x04 |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
TACACS+ authorization requests are intermittently sent using flags 0x04 (encrypted payload, single connection), while most of the time the requests are sent using flags 0x00 (encrypted payload, multiple connections).
Conditions:
"single-connection" keyword not configured for the tacacs-server definition.
Nexus 7000/7700 sends hundreds of TACACS+ authorization requests in a very short time.
Workaround:
None at the moment.
Further Problem Description:
|
|
Last Modified: | 01-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug96112 | Title: | Configuration Session editable for user with same privilege |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The user gets an error when trying to access the configuration session of a second user when the roles are the same.
Conditions:
The user of "configuration sessions" with different usernames and roles.
Workaround:
Use role network-admin or user admin. Further workarounds being investigated. The code is fixed to make the users with the same role to access and modify the session
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.1(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.52), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk54101 | Title: | N7K: BGP graceful restart may fail when BGP MD5 password set |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
BGP graceful restart fails
Conditions:
BGP peer established with
- BGP MD5 authentication
- BGP hold timer is within 20 seconds
Workaround:
not use BGP password or use default bgp timer
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.0(5), 5.2(0.222) |
|
Known Fixed Releases: * | 5.3(0.169)S0, 6.0(0.2)S0, 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz25484 | Title: | LACP flags in RECV PDU shows up as wrong |
|
Status: | Other |
|
Severity: | 4 Minor |
Description: | Symptom:show lacp internal pdu interface eth < > parse output will show wrong flags for RECV PDUs only.
Ideally after LACP FSM has reached final stage of up/up port-channel, flags seen for actor and partner in SEND PDU and RECV PDU should be exactly same. Note, that flags can be different when the channel is not up/up or in any other transient state.
Conditions:n/a
Workaround:none
More Info:
There is no operational impact due to this show cli output being wrong.
|
|
Last Modified: | 24-APR-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14), 6.2(16) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc39072 | Title: | N7K: Arrow keys do not work for retrieving commands |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
NXOS up arrow key doesn't retrieve old commands after "copy tftp: bootflash:" under "Enter source filename:".
"Later in "Enter vrf .." or "Enter hostname for the tftp server:", only the commands just entered from "Enter source filename:" can be retrieved.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(1) |
|
Known Fixed Releases: * | 5.1(0.149)S0, 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtk54167 | Title: | N7K: BGP graceful restart may fail in aggregate route |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | N7K: BGP graceful restart may fail in aggregate route
Symptom:
BGP graceful restart fails in aggregate route
Conditions:
Graceful restart by BGP speaker who executes aggregate bgp route
Workaround:
not to use bgp aggregate route
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.0(5) |
|
Known Fixed Releases: * | 5.2(0.215)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf86297 | Title: | N7k VDC should create tac-pac in VDC directory instead of bootflash root |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When using the tac-pac command into a VDC, if the file is saved to the bootflash, the default VDC bootflash is used instead of the VDC directory
Conditions:
Use of VDC
Workaround:
Use the following command:
tac-pac bootflash:///vdc_X/filename
where X is the VDC number
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 4.2(8)S29, 4.2(8.102)S0, 5.1(0.107)S0, 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.0(3) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut80582 | Title: | logging level spm6 missing after non-ISSU from 6.0.4 to 6.2.10 |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
After upgrade from 6.0(4) to 6.2(10), customer lost the config: 'logging level spm6'
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.171), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.131), 7.3(0)RTG(0.72), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.54), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCth86446 | Title: | %XMLMA-3-XMLMAERR: XML master agent: XML sub agent session 6283 termina |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
XML agent error message.
Conditions:
n/a
Workaround:
no workaround.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(3), 5.0(3) |
|
Known Fixed Releases: * | 4.2(7.47)S0, 5.1(0.197)S0, 5.1(1), 5.2(0.57)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 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)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)ZD(0.6) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.17), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf34078 | Title: | remove side effect of 'human' (switches output permanently to xml) |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
cli output for a session switches permanently to xml format when a '... | human' command is used.
Conditions:
all.
Workaround:
reissue another '... | human' command to switch back to human readable format.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(4) |
|
Known Fixed Releases: * | 5.1(0.114)S0, 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.51), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtu36649 | Title: | BGP sends TCP SYN even if link to peer is down |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: * | Symptom:
When using update-source on a neighbor where the the source is a physical interface, BGP will still try and establish a neighbor with this source even if the interface is down.
Conditions:
The problem will occur whenever there is some prefix in the routing table that can be used to send to the destination, including the default route or a route to null0.
Workaround:
There is no workaround
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: * | 5.2(1), 6.0(1) |
|
Known Fixed Releases: * | 6.1(0.170)S0, 8.3(0)SF(0.67) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10)S98 |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.46), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99), 8.3(0)CV(0.337), 8.3(0)KMT(0.24) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 7.3(0)TD(0.1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.143), 7.3(0)D1(1), 7.3(0)GLF(0.43), 7.3(0)IB(0.27), 7.3(0)PDB(0.112), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)D1(0.72), 7.3(0)D1(1), 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)TSH(0.99), 7.3(0)ZD(0.85) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(0.107), 7.3(0)D1(1), 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), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 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), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo02299 | Title: | Overlay1 Last link flapped timer is flushed after 24 hours |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
In "show interface Overlay1" output , counter "Last link flapped" never goes above 24 hours. It is reseted to 00:00:00 every 24 hours , so it can't be used to access how long interface was UP.
sh int o1
Overlay1 is up
Last link flapped 23:59:59
Last clearing of "show interface" counters 07:45:30
zixu-PE2# sh int o1
Overlay1 is up
Last link flapped 00:00:00
Last clearing of "show interface" counters 07:45:31
Conditions:
Normal operations
Workaround:
None. It' just a cosmetic issue it doesn't affect OTV communications. To check liveliness of OTV connections please use "show otv isis adjacency detail" and check for how long ISIS sessions has been stable.
show otv isis adjacency detail
OTV-IS-IS process: default VPN: Overlay1
OTV-IS-IS adjacency database:
System ID SNPA Level State Hold Time Interface Site-ID
nexus-OTV1 001b.54c2.4242 1 UP 00:00:12 Overlay1 0000.0000.0001
Up/Down transitions: 1, Last transition: 20:23:22 ago <---------------- last transition 20 hours ago
...
nexus-OTV2 001b.54c2.4244 1 UP 00:00:12 Overlay1 0000.0000.0002
Up/Down transitions: 1, Last transition: 20:19:26 ago <---------------- last transition 20 hours ago
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 7.3(0)D1(0.91), 7.3(0)D1(1), 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.57), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtl42946 | Title: | nxos: less do not work (more used instead) |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: * | Symptom:
Instead of "less" pager when show long output is always used "more" regardless cli
Workaround:
none
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: * | 4.2(6), 5.1(1a), 5.1(2) |
|
Known Fixed Releases: * | 4.2(8.8)S0, 5.2(0.189)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtt31905 | Title: | 'Show interface status' output is not aligned correctly |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
'Show interface status' output is not aligned correctly
Conditions:
Issue observed on 5.1.3 and 5.1.4.
Could be caused by a new line feed in the description field.
Workaround:
Manually removing the description and adding it back can fix the issue
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 5.2(8.16)S0, 5.2(9), 6.0(1)S28, 6.1(0.120)S0, 6.1(4.1)S0, 6.1(5), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuo77368 | Title: | N7K interface config is out of position |
|
Status: * | Terminated |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
N7K running config is out of position .
interface Vlan2
description "interface Vlan2"
no shutdown
no ip redirects
ip address 2.2.2.2
ip ospf authentication message-digest
ip ospf cost 10
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
interface Vlan3
description "interface Vlan3"
no shutdown
no ip redirects
ip address 3.3.3.3
ip ospf authentication message-digest
ip ospf cost 10
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
-------------------------------------------------------------------------
< when hit this issue>
#show running-config
interface Vlan1
interface Vlan2
interface Vlan3
description "interface Vlan2" <<<<<no shutdown
no ip redirects
ip address 2.2.2.2
ip ospf authentication message-digest
ip ospf cost 10
ip ospf hello-interval 5
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.6
Conditions:
when insert the all commands below at one time.
nexus4# show version?
show running-config
show startup-config
show ip interface brief
show interface brief
show interface status
show interface transceiver
show interface
show udld
show port-channel summary
show ip route summary
show ip route
show ip ospf
show ip ospf interface
show ip ospf neighbor
show ip ospf database
show ip bgp
show ip bgp summary
show ip bgp neighbors
show udld neighbor
show hsrp brief
show ip arp
show mac address-table
show hardware rate-limiter
show hardware internal cpu-mac inband stats
show process cpu sort
show module
show environment
show inventory
show logging
terminal length 24
terminal length 0
show version
show running-config
show startup-config
show ip interface brief
show interface brief
show interface status
show interface transceiver
show interface
show udld
show port-channel summary
show ip route summary
show ip route
Workaround:
insert one line command at the same time.
Further Problem Description:
|
|
Last Modified: | 06-APR-2016 |
|
Known Affected Releases: | 6.2(6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur80960 | Title: | eigrp interface configs not removed after eigrp process is disabled |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
eigrp interface configs not removed after eigrp process is diabled
Conditions:
++ eigrp should be configured and then removed
Workaround:
disable eigrp feature and then re-enable it
Further Problem Description:
|
|
Last Modified: | 27-APR-2016 |
|
Known Affected Releases: | 6.1(4.6) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz37129 | Title: | N7K - IPv6 tunnel support |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Documentation to be updated regarding non-support of IPv6 GRE tunnels on N7K.
Conditions:
Ipv6 in Ipv6 GRE tunneling
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 26-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtx27232 | Title: | need a way to get CLI output in TCL without showing it on terminal |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Request to add capability to TCL to have CLI output collected to variable without showing it on terminal
Symptom:When redirecting output to variables or files, output is still shown on the terminal/screen.
Conditions:All conditions where output is redirected.
Workaround(s):
Use clis instead of cli
Workaround:Use clis instead of cli
|
|
Last Modified: | 25-APR-2016 |
|
Known Affected Releases: | 5.2(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCue27895 | Title: | NXOS/OTV: sh tech otv need include also sh tech forwarding otv |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | This is enhancement to have sh tech forwarding otv unicast/multicast included already in sh tech otv
Symptom:
N/A
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: | 7.3(0)TSH(0.99), 7.3(1)D1(0.24), 7.3(1)N1(0.316), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtc97478 | Title: | CTS: Implement the use of ACS/ISE timer 'Download SGACL lists' |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The Nexus does not refresh policies periodically.
It should comply with the 'Download SGACL lists' timer sent from ACS or ISE
Conditions:
Occurs when CTS policies have been downloaded to the Nexus. Default 'Download
SGACL lists' timer in ACS or ISE is 1 day or 86400 seconds.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 4.2(1), 6.1(2) |
|
Known Fixed Releases: * | 6.2(4), 6.2(5.7)S0, 6.2(6), 7.0(0)FM(0.5), 7.0(0)FM(0.6), 7.0(0.51)S0, 8.3(0)CSS(0.4), 8.3(0)CV(0.398), 8.3(0)SF(0.94) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux25385 | Title: | Install all CLI should force kickstart and system image |
|
Status: | Fixed |
|
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:
When you run install all with only kickstart image specified, the installer will use the current system image that the switch is booted up with to continue with the installer.
Similarly, if you run install all with only a system image specified, installer will use the current kickstart image that the switch is booted up with.
The command error out because it was trying to use your new kickstart image with a different version of the system image, which generally is not compatible.
N3K:
Verifying image bootflash:/n3000-uk9-kickstart.6.0.2.U6.4.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS
Verifying image bootflash:/n3000-uk9.5.0.3.U5.1e.bin for boot variable "system".
[####################] 100% -- SUCCESS
N7K:
Verifying image bootflash:/n7000-s2-kickstart.7.2.0.D1.1.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS
Verifying image bootflash:/n7000-s2-dk9.6.2.14.bin for boot variable "system".
[####################] 100% ? SUCCESS
|
|
Last Modified: | 22-APR-2016 |
|
Known Affected Releases: | 6.2(13), 6.2(13)S26, 6.2(14), 8.3(0)CV(0.249) |
|
Known Fixed Releases: * | 8.3(0)CV(0.414) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)D1(1), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut78155 | Title: | Add granular GM-LSP statistics for FabricPath IS-IS |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
"sh fabricpath isis traffic ethernet x/y" shoes all LSPs summed into a single value. Needs to show GM-LSP in a separate row:
S1# sh fabricpath isis traffic ethernet 4/5
Fabricpath IS-IS domain: default
Fabricpath IS-IS Traffic for Ethernet4/5:
PDU Received Sent RcvAuthErr OtherRcvErr ReTransmit
P2P-IIH 1195500 1195504 0 0 n/a
CSNP 2 1 0 0 n/a
PSNP 127592 151578 0 0 n/a
LSP 154109 128906 0 0 0
S1#
Conditions:
When you run fabricpath and monitor the traffic using "sh fabricpath isis traffic ethernet x/y" or "sh fabricpath isis traffic"
Workaround:
No Workaround
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0.10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)D1(0.63), 7.3(0)D1(1), 7.3(0)DHB(0.2), 7.3(0)EG(0.3), 7.3(0)HM(0.47), 7.3(0)OTT(0.19), 7.3(0)PDB(0.25), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty67801 | Title: | SVI should not be allowed for vpls vlan |
|
Status: | Open |
|
Severity: | 6 Enhancement |
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: | 21-APR-2016 |
|
Known Affected Releases: | 5.2(0)LV1(0.274), 6.2(1.125)S6, 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.0(0)KM(0.97), 7.1(0)NF(0.32), 7.1(0)OTT(0.27), 7.1(0)PDB(0.166), 7.3(0)GLF(0.25), 7.3(0)OTT(0.73), 7.3(0)PDB(0.80), 7.3(0)RSP(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw39246 | Title: | Change Severity for "%VPC-2-VPC_SVI_EXCLUDE" to informational |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
changing Sev for %VPC-2-VPC_SVI_EXCLUDE to informational
Conditions:
Every time a vPC bounces or is turned up, we will see the
"%VPC-2-VPC_SVI_EXCLUDE:" error message. this need not be a SEV-2 message.
Workaround:
Change the severity level
Further Problem Description:
NA
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.3(0)D1(0.162), 7.3(0)D1(1), 7.3(0)GLF(0.44), 7.3(0)PDB(0.91), 7.3(0)RSP(0.7), 7.3(0)SC(0.14), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv52259 | Title: | Restrict vpc on port-channels configured for port-security |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
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: | 21-APR-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)D1(1), 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), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)PDB(0.8) |
|
|
| |
| |
|
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: | 21-APR-2016 |
|
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)BZ(0.98), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut75676 | Title: | VSI_OVER_FEX changes |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
This bug is used to track the development of VSI Over Project
Conditions:
This bug is used to track the development of VSI Over Project
Workaround:
Enhancement
Further Problem Description:
|
|
Last Modified: | 21-APR-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.462) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.0(0)FHS(0.23), 7.1(0)ES(0.24), 7.2(0)EVF(0.3), 7.2(0)VOF(0.11), 7.2(0)VOF(0.2), 7.2(0)VOF(0.3), 7.2(0)VOF(0.4), 7.2(0)VOF(0.6), 7.2(0)VOF(0.8) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz09493 | Title: | PTP over Fabricpath does not work when there are multiple FTAG trees |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
When PTP is enabled on Fabricpath links connecting multiple switches and there are multiple paths, PTP may not work on some links. PTP will remain in Master state on both sides of the non-working links, instead of going to Master-Slave states at both ends. If PTP packets are captured, it will be seen that no PTP packet is received on the non-working links.
Conditions:
There has to be multiple Fabricpath trees (i.e., multiple paths) between the non-working switches.
Workaround:
Using non-fabricpath links to propagate PTP packets (i.e., configuring PTP on non-fabricpath based links) will be a work-around in this condition.
Further Problem Description:
|
|
Last Modified: | 19-APR-2016 |
|
Known Affected Releases: | 6.2(14), 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh10646 | Title: | gibt-mvrp project collapse into Gibraltar |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
this is an internal tracking ID for a source code merge
Conditions:
not a bug, tracking ID
Workaround:
N/A
More Info:
N/A
|
|
Last Modified: | 14-APR-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.7) |
|
Known Fixed Releases: * | 7.0(0)KM(0.64), 7.0(0.8)S0, 7.0(1)ZD(0.3), 7.1(0)D1(0.14), 7.1(0)D1(0.15), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 8.3(0)CSS(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCty67352 | Title: | ER: need to prevent "system switchover" command during ISSU |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | This enhancement request is to limit the commands a user can issue during ISSU upgrade.
Symptom:
You can execute a "system switchover" cli command while the "upgrade all" cli command is still in progress (from another cli session). There should be a warning that this might not be the most opportune time to start a switchover.
Conditions:
happens each time, except in releases >= Edinburgh2 (6.1.x) where a a fix is present.
Workaround:
no work around, just be careful...
You could try to enter config mode and execute the "system switchover" from there, since config mode ("configure terminal") is locked during ISSU.
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.2(3a) |
|
Known Fixed Releases: * | 6.1(0.283)S0, 6.2(0.143)S0, 6.2(2), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtg09812 | Title: | definitions of the systems define roles in Nexus 7000 |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Customer wants to know the definition of each of the systems define roles
Conditions:
N/A
Workaround:
N/A
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(2) |
|
Known Fixed Releases: * | 5.1(0.107)S0, 5.1(1), 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtf04410 | Title: | Citi requires full command accounting to AAA |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
"terminal log-all" command has become a configuration command starting from 5.0.5. The new command replaces existing exec mode command.
Conditions:
From 5.0.5 and forward.
Workaround:
N/A
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(3) |
|
Known Fixed Releases: * | 5.0(5)S18, 5.0(5)S22, 5.1(0.126)S0, 5.1(1), 5.1(1.66)S0, 7.0(1)ZD(0.3), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtq53578 | Title: | router-id is 0.0.0.0 in "show ip bgp" for locally originated route |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The way of command output "show ip bgp " for locally originated prefix
differs between NX-OS and IOS. See below.
# NX-OS 5.2(1)
0.0.0.0 (metric 0) from 0.0.0.0 (0.0.0.0) <-------- Router-ID in the bracket is 0.0.0.0
# IOS 12.4
0.0.0.0 from 0.0.0.0 (1.1.1.2) <-------- Router-ID in the bracket is local system
Conditions:
Locally originated routes.
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 5.1(3), 5.2(1) |
|
Known Fixed Releases: * | 5.3(0.212)S0, 6.0(0.2)S0, 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj79451 | Title: | BGP eror message logging is not appropriate |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
When there is a mismatch between the neighboring parameters like AS number, password etc the Nexus does not report any specific error message instead the only thing that will happen is either the neighbor ship would go down or it will never come up.
Conditions:
Mismatch between neighboring parameters
Workaround:
None
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 4.2(6), 5.1(1) |
|
Known Fixed Releases: * | 5.2(0.223)S0, 7.2(0)ZN(0.111), 8.3(0)SF(0.67) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz11312 | Title: | N7K: Replication engine monitoring cli for F-Series |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Tracking for F-series support of `show hardware replication statistics`
Currently only supported for M-series modules
Conditions:
Tracking for F-series support of `show hardware replication statistics`
Currently only supported for M-series modules
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 08-APR-2016 |
|
Known Affected Releases: | 6.2(16) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux19585 | Title: | Increase the auto-recovery to 1 day (86400 secs) |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
The maximum current delay time for vpc auto-recovery is 1 hour (3600 secs) only which could be a bottleneck sometimes in larger topologies with more and more number of vpc legs. We need the maximum delay time to be 24 hrs (86400 secs).
Conditions:
When the auto-recovery reload-delay is about to be configured.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 07-APR-2016 |
|
Known Affected Releases: | 6.2(14)S24 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.3(0)D1(0.198), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)RSP(0.7), 7.3(0)ZD(0.225), 7.3(1)PDB(0.19), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun85740 | Title: | RPM crash when route-map assigned to interface (w/ ~450 seq entries) |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Unable to use more than 512 sequences in a single route-map used for PBR.
Conditions:
In PBR when a single route-map containing match and set statements attached at an interface.
Workaround:
Split the single route-map into multiple route-maps and try to use multiple route-maps instead of single route-map for PBR.
Further Problem Description:
When a single route-map containing more than 512 sequences is used for PBR, we bail out with an error. With the enhancement we can configure more than 2048 sequences in a single route-map.
|
|
Last Modified: | 05-APR-2016 |
|
Known Affected Releases: | 4.1(3), 6.1(1)S60, 6.2(8)S1 |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(3)I3(1.11), 7.0(3)I3(2), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)CF(0.11), 7.2(0)D1(0.408), 7.2(0)D1(1), 7.2(0)FM(0.3) |
|
|
| |
没有评论:
发表评论