| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy88547 | Title: | RISE CLI exits config mode for DIRECT & VPC mode |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
When user issues create a rise direct or rise vpc mode service, the cli exits the config mode
Conditions:
When user issues create a rise direct or rise vpc mode service,
Workaround:
No known workaround
Further Problem Description:
|
|
Last Modified: | 21-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1), 7.3(0)DX(0.124), 7.3(1)D1(0.14) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.26) |
|
|
| |
| |
|
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: | 24-MAY-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.2(2)D1(0.44), 7.2(2)ZD(0.135), 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: | CSCty30696 | Title: | Changes in IFTMC for Flanker ASIC |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
F-Series linecard may experience a core of the IFTMC component, and generate a core file. This may also lead to a HAP (High Availability Policy) reset of the linecard.
Conditions:
Error in hardware index management.
Exact triggers for issue are not clear, so the fix is in the IFTMC component handling.
Workaround:
N/A
Fix is in 6.2(6) and later codes.
More Info:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.1(4a), 7.0(0)FT(0.1) |
|
Known Fixed Releases: * | 6.2(0.214)S0, 6.2(0.228)S0, 6.2(0.233)S9, 6.2(0.243)S3, 6.2(0.247)S0, 6.2(0.248)S0, 6.2(0.253)S0, 6.2(0.260)S0, 6.2(0.282)S0, 6.2(0.61)S16 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz10518 | Title: | N5K-C5548UP got dot1x hap reset |
|
Status: | Fixed |
|
Severity: | 1 Catastrophic |
Description: | Symptom:
We saw N5K-C5548UP using n5000-uk9.7.3.0.N1.1a.bin had a hap reset:
Reason: Reset triggered due to HA policy of Reset
System version: 7.3(0)N1(1a)
Service: dot1x hap reset
Conditions:
Not known
Workaround:
Not known
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)N1 |
|
Known Fixed Releases: * | 7.3(0)N1(0.5), 7.3(0)N1(1a), 7.3(1)DX(0.32), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz51928 | Title: | icmpv6 crashes because of access to a non-readable memory region. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Nexus 5500s series switches may reset due to an icmpv6 service with certain icmpv6 commands such
as 'show ipv6 icmp vaddr pt-tree', 'show system internal icmpv6 internal info'.
These commands are included in show tech-support icmpv6 and tac-pac
Conditions:
The switch has went through non-disruptive upgrades sequence starting in 5.1(3) train and ending in 7.0 or 7.1 NX-OS release trains.
A switch that has been reloaded or upgraded with disruptive ISSUs is not susceptible to this issue.
Workaround:
N/A
Further Problem Description:
N/A
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.0(7)ZN(0.319) |
|
Known Fixed Releases: | 7.1(3)ZD(0.133), 7.1(3)ZN(0.280), 7.1(4)N1(0.814), 7.1(4)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw03713 | Title: | N7K: Layer 2 (L2) packet not dropped on length mismatch |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * |
Symptom:
The Cisco Nexus 7000 (N7K) Ethernet driver fails to properly drop a Layer 2 (L2) frame that should be evaluated as invalid.
The L2 frame will be flooded to all active ports on the associated VLAN due to a failure to match to a known Media Access
Control (MAC) in the Cisco Access Manager (CAM) table. This could allow the attacker to perform a traffic amplification
attack to consume bandwidth on all ports associated with the VLAN of the receiving port.
Conditions:
The N7K chassis contains a F1, F2, F3, M1 or M2 Linecard.
Workaround:
The CAT6K upstream router was configured with the command:
mac-address-table static 0000.0000.xxx vlan <#> drop
OR you can configure ACL on Nexus 7000 as :-
MAC access list DROP_ETHERYTYE0
10 deny any any 0x0
20 permit any any
More Info:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 3.3/3.1:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:P/E:F/RL:U/RC:C&version=2.0
No CVE ID has been assigned to this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz55002 | Title: | SSTE:Reliance Sol:BGP table with no nexthop when nexthop learnt thro LU |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
vpn vrf routes in BGP table have no labelled next hop
Conditions:
When the nexthop is learnt through labelled unicast
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)N1(0.438), 7.2(2)N1(1), 7.2(2)ZD(0.143), 7.2(2)ZN(0.146) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus22805 | Title: | N7K-SUP2/E: eUSB Flash Failure or Unable to Save Configuration |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
The following symptoms have been seen:
- Compact flash diagnostic failure
- Unable to perform a 'copy run start'
- eUSB becomes read-only or is non-responsive
-When running VTP, newly create VLANs are not propagated to other VTP switches and VTP Configuration Revision number does not increment locally.
To display the current status of the RAID devices, please run the following commands:
switch# show system internal raid | i i cmos|block | head line 5
RAID data from CMOS = 0xa5 0xf0
77888 blocks [2/2] [UU]
78400 blocks [2/2] [UU]
39424 blocks [2/2] [UU]
1802240 blocks [2/2] [UU]
Where x is the standby supervisor slot number:
switch# slot x show system internal raid | i i cmos|block | head line 5
RAID data from CMOS = 0xa5 0xf0
78016 blocks [2/2] [UU]
78528 blocks [2/2] [UU]
39744 blocks [2/2] [UU]
1760384 blocks [2/2] [UU]
Last number in the "RAID data from CMOS" lines indicate the number of disks failed:
0xf0 ==>> No failures reported
0xe1 ==>> Primary flash failed
0xd2 ==>> Alternate (or mirror) flash failed
0xc3 ==>> Both primary and alternate failed
We should also see [UU] in the respective entries for the flash to be correctly synced.
Conditions:
- N7K-SUP2 or N7K-SUP2E
- Several months or years of uptime
Workaround:
While system can operate with only one flash device, its highly recommended to recover and add the removed flash back into RAID configuration. Second flash device can also get into this condition over time triggering the read-only mode.
Flash Recovery Tool:
n7000-s2-flash-recovery-tool.10.0.2.tar.gz is available to be downloaded from Cisco support site. This works as a custom plug-in that can be run using the 'load' CLI.
- To run the tool, download and copy it to volatile:.
extract it
#tar extract volatile:n7000-s2-flash-recovery-tool.10.0.2.tar.gz
run with the load command
#load volatile:n7000-s2-flash-recovery-tool.10.0.2.gbin
- Tool automatically fixes any single flash errors when present.
- If a standby available, it will copy itself to standby and run there.
- No side effects if there are no errors reported at the time.
- Tool will not attempt dual flash recovery either on active or standby.
Single flash failure on active or standby:
Systems running with single flash failure can be repaired while in service using the flash recovery tool.
Dual flash failure on the standby:
This is a recoverable situation by reloading the standby and making sure that the flashes are healthy once it comes back online. Flash recovery tool should be run after reload to put both flashes back into service.
Dual flash failures on Active:
This is not a recoverable situation, unless there is at least one working flash on the standby. Otherwise, switch need to be reloaded during next maintenance window. If the standby is healthy a switchover can be attempted and then recover the old active. Latest running configurations, license files, kickstart and system images need to be saved external to the switch to be restored after reload. Flash recovery tool should be run after reload to make sure flashes back into service.
Additional verification steps and further information can be found in the Read Me file with the recovery tool.
NOTE: NPE versions of code cannot run this recovery tool.
Further Problem Description:
eUSB wakeup for Unigen is available in 6.2(14), 7.2(0)D1, and later for N7K only
Each Nexus 7000 Supervisor board are equipped with 2 identical eUSB flash devices i
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: * | 6.1(5a), 6.2(10), 6.2(12) |
|
Known Fixed Releases: | 6.2(12)E9, 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.26), 7.0(0)BZ(0.71), 7.0(0)HSK(0.433), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.1(0)IB(122), 7.2(0)AB(9) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy45648 | Title: | M3 GRE: Service not responding when changed the "tunnel destin" to DNS |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
M3 GRE: Service not responding when changed the "tunnel destin" to DNS
Conditions:
Change the tunnel destination of all the tunnels using range CLI.
Workaround:
DO NOT use range cli to configure the tunnel destination.
Configure tunnel destination individually on every tunnel interface.
Further Problem Description:
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy97188 | Title: | M3CB10: seeing eobc drop on the scale testbed |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
Occasionally, some packet drops may be seen on the Active Supervisor Eobc interface during LC or Standby Supervisor boot up, as shown below.
# sh hardware internal eobcsw stats | inc "drop events"
drop events 0
drop events 0
drop events 3
drop events 3
drop events 2
drop events 1
drop events 1
drop events 1
drop events 2
drop events 0
drop events 0
drop events 5
drop events 2
drop events 2
drop events 2
drop events 2
drop events 2
drop events 2
Conditions:
These drops are seen before the LC or Standby Sup come online. This is expected as the interface is being brought up and some configurations are pushed down. This is not control traffic and the applications are capable of retransmitting these dropped packets.
Workaround:
Further Problem Description:
The packets drops are normal only if seen during boot up. If the drops keep increasing after all the Line cards and Standby Supervisor have come online, then it may be a different problem.
|
|
Last Modified: | 03-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.127) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum16110 | Title: | N6K: OIF on mroute not removed when interface is remotely shut |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens.
Conditions:
When a remote shut happens for a particular interface which is in the OIF list for a particular mroute, the interface does not get removed from the OIF list.
Workaround:
None
Further Problem Description:
A particular interface is not removed from the OIF list in mroutes when a remote shut for the same interface happens. This causes a problem as traffic gets forwarded immediately on actually bringing the link up
|
|
Last Modified: | 03-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N2(2.43) |
|
Known Fixed Releases: * | 6.0(2)A6(5b), 6.0(2)A6(6), 6.0(2)A7(2), 6.0(2)A8(0.334), 6.0(2)A8(1), 6.0(2)U6(5), 6.0(2)U8(0.334), 6.0(2)U8(1), 7.0(3)I3(0.271), 7.0(3)I3(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCum42151 | Title: | Enable secret hashes improperly calculated |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
The salt of 'enable secrets' is not randomized properly.
Conditions:
'feature privilege' is configured.
Workaround:
None
Further Problem Description:
None
PSIRT Evaluation:
The Cisco PSIRT has evaluated this issue and does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 6.1(4) |
|
Known Fixed Releases: | 6.0(2)A4(0.764), 6.0(2)A4(1), 6.0(2)U4(0.764), 6.0(2)U4(1), 6.2(10), 6.2(8)KR(0.8), 6.2(8.13)S0, 6.2(9)FM(0.67) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy07224 | Title: | Physical VPC on FEX port stays suspended (suspended(LACP misconfig)) |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Physical VPC on FEX using LACP stays suspended after the connecting device reboots.
When the server connecting on physical VPC reboots the link bounces.
After the interface on server is up, it will not be sending any LACPDUs until the OS boots up.
When there is no LACPDUs received the Fex port states suspended with status "Ethernet110/1/1 is down (suspended(no LACP PDUs))"
Once the OS is up on the server, it starts sending the PDUs and when the switch receives the very first LACPDU, the interfaces changes to "Ethernet110/1/1 is down (suspended(LACP misconfig))"
Conditions:
Physical VPC configured on Fex port with LACP.
Workaround:
Shut/No shut on the interface recovers the port-channel.
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.0(0)BZ(0.115), 7.0(2)FIP(0.190), 7.2(2)D1(0.38), 7.2(2)ZD(0.84), 7.2(2)ZD(0.85), 7.2(2)ZD(0.86), 7.2(2)ZD(0.87), 7.2(2)ZD(0.88), 7.2(2)ZD(0.89) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy54998 | Title: | F3 port-sec static mac inserted into HW table regardless of int state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A static mac address is inserted into the HW table when port-security is configured on an interface *AND* an SFP/transceiver is inserted in the port
Conditions:
Workaround:
Remove port-sec on interface or remove SFP/transceiver.
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 7.3(1)D1(0.39), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
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: | 04-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.52), 7.3(1)D1(0.54), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
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: | 04-MAY-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)DG(0.3), 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) |
|
|
| |
| |
|
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: | 07-MAY-2016 |
|
Known Affected Releases: | 6.2(13) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.119), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCur56960 | Title: | VRRS pathway stuck in "Currently being removed" |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VRRS pathway stuck in "Currently being removed"
Conditions:
When we move from VRRS pathway to VRRP, VRRS pathway stuck in "Currently being removed" state for all slaves. Due to this error, we cannot configure the VIP when we try to move the slave to a vrrp group. The trigger of this issue is to remove the SVI completely.
Workaround:
Instead of removing the SVI completely, remove VRRS pathway config only.
Further Problem Description:
.
|
|
Last Modified: | 07-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.0(3)F1(0.230), 7.0(3)F1(0.232), 7.0(3)I3(1.7), 7.0(3)I3(2), 7.0(3)I4(0.46), 7.0(3)I4(1), 7.3(0)D1(0.190), 7.3(0)D1(1), 7.3(0)DG(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83217 | Title: | Tunnel intf is down(Hardware prog failed) with M3-F3 GRE Tunnel scenario |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: * | Symptom:
Tunnel interface stays down post ISSU with reason as "Hardware Prog Failed"
Conditions:
ISSU with tunnel interfaces configured
Workaround(s):
'shutdown tunnel ' followed by 'no shutdown tunnel ' is the workaround.
Workaround:
'no feature tunnel' followed by 'feature tunnel' is the workaround.
Further Problem Description:
|
|
Last Modified: | 09-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz35456 | Title: | SMU:Install operation 2 failed because patch is not found:libpmcli issue |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
-If the patch contains fix for libpmcli_common_fcoe.so, it will not support install operation.
-De-activation will fail if we have patches which involves libraries for line-cards.
Conditions:
-patching involving the library libpmcli_common_fcoe.so
The line card patch involves a library.
Workaround:
-Special cases like libpmcli_common_fcoe.so is not supported
- Line card patches involving library, make it a reload.
Further Problem Description:
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | 8.3(0)CV(0.429) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut67131 | Title: | ACL_Deny misprogrammed on F1 when creating a new VDC |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a switch with multiple VDCs having VPC domains, during the bringup of peer-link on an alternate VDC, if any the VPC legs of the local VDC consist of the first ports of F1 modules, broadcast packets may loop across VPC peers via this VPC port.
Conditions:
Only seen on a Nexus 7000 switch using F1 Linecards running 6.2.x. The switch must consist of multiple VDCs with VPC configured. The first ports of the F1 modules should be members of the VPC legs of 1 VDC. The alternate VDC's VPCs should have VPC with member ports distributed across other F1 modules and the affected F1 module.
Workaround:
To recover from this state after shut/no shut the VPC member (First port) on the F1 modules which is looping the broadcast.
Further Problem Description:
|
|
Last Modified: | 19-MAY-2016 |
|
Known Affected Releases: | 6.2(2) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S20, 7.2(2)D1(0.42), 7.2(2)ZD(0.130) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28874 | Title: | Complete traffic loss for HIF ports on F2E card |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: * | Symptom:
Host behind FEX can not ping default gateway or communicate to outside world
ARP for gateway IP remains incomplete on host
ARP of host remains incomplete on host
Output of "show system internal vntag info fex" would show Vif value to be in 300s range. Expected value is 0-50
Sample output of what a affected FEX looked like (look at second column i.e VIF ) :-
FEX143 Information:
online(true), module(75), sw_card_id(0x52), node_id(0x4c02), module_type(0)
lc_node(0x4c02), num_ports(32), pc_hash(0x300000), control vif(2049),
min vif (303), max vif(399), saved for ISSU(false),
vpc_peer_up_port_bitmap - (0),
vpc_plus - (0)
Fabric Port Channel: Po143
INTERFACE RLINK-ID INSTANCE #PORTNO.
================================================================
Eth3/40 20000080 9 3
Satellite Interface Information: DEF MIN MAX L3
INTERFACE VIF LTL LAYER MODE VLAN VLAN VLAN HIFPC LTL
===========================================================================
Eth143/1/1 303 0x11f0 2 ACCESS 1 1 1 0x0000
Eth143/1/2 304 0x11f1 2 ACCESS 1 1 1 0x0000
Eth143/1/3 305 0x11f2 2 ACCESS 1 1 1 0x0000
Eth143/1/4 306 0x11f3 2 ACCESS 1 1 1 0x0000
Eth143/1/5 307 0x11f4 2 ACCESS 1 1 1 0x0000
Eth143/1/6 308 0x11f5 2 ACCESS 1 1 1 0x0000
Eth143/1/7 309 0x11f6 2 ACCESS 1 1 1 0x0000
Eth143/1/8 310 0x11f7 2 ACCESS 1 1 1 0x0000
Eth143/1/9 311 0x11f8 2 ACCESS 1 1 1 0x0000
Eth143/1/10 312 0x11f9 2 ACCESS 1 1 1 0x0000
Eth143/1/11 313 0x11fa 2 ACCESS 1 1 1 0x0000
Eth143/1/12 314 0x11fb 2 ACCESS 1 1 1 0x0000
Eth143/1/13 315 0x11fc 2 ACCESS 1 1 1 0x0000
Eth143/1/14 316 0x11fd 2 ACCESS 1 1 1 0x0000
Eth143/1/15 317 0x11fe 2 ACCESS 1 1 1 0x0000
Eth143/1/16 318 0x11ff 2 ACCESS 1 1 1 0x0000
Eth143/1/17 319 0x1200 2 ACCESS 1 1 1 0x0000
Eth143/1/18 320 0x1201 2 ACCESS 1 1 1 0x0000
Eth143/1/19 321 0x1202 2 ACCESS 1 1 1 0x0000
Eth143/1/20 322 0x1203 2 ACCESS 1 1 1 0x0000
Eth143/1/21 323 0x1204 2 ACCESS 1 1 1 0x0000
Eth143/1/22 324 0x1205 2 ACCESS 1 1 1 0x0000
Eth143/1/23 325 0x1206 2 ACCESS 1 1 1 0x0000
Eth143/1/24 326 0x1207 2 ACCESS 1 1 1 0x0000
Eth143/1/25 327 0x1208 2 ACCESS 1 1 1 0x0000
Eth143/1/26 328 0x1209 2 ACCESS 1 1 1 0x0000
Eth143/1/27 329 0x120a 2 ACCESS 1 1 1 0x0000
Eth143/1/28 330 0x120b 2 ACCESS 1 1 1 0x0000
Eth143/1/29 331 0x120c 2 ACCESS 1 1 1 0x0000
Eth143/1/30 332 0x120d 2 ACCESS 1 1 1 0x0000
Eth143/1/31 333 0x120e 2 ACCESS 1 1 1 0x0000
Eth143/1/32 334 0x120f 2 ACCESS 1 1 1 0x0000
Once FEX is reloaded , issue would move to some other fex in same asic instance of F2E card
Conditions:
Seen during HIF flaps of layer 2 t
|
|
Last Modified: | 19-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq52327 | Title: | IPv6 static route not seen in RIB after reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
IPv6 static route configured using "ipv6 route " will not be on RIB (not seen in "show ipv6 route") after reload. The static route is seen in "show run" but "show ipv6 route" does not refect the static route to RIB.
IPv6 static route configured using "ipv6 route " does not have this problem but one configured using "ipv6 route " has this problem.
Conditions:
One of the trigger of the issue is reload of the box
Workaround:
We need to remove and re-add the ipv6 route
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.0(2)N1(1), 6.0(2)N2(1), 7.0(3)N1(0.125) |
|
Known Fixed Releases: | 7.0(0)BZ(0.46), 7.0(0)HSK(0.317), 7.1(0)AV(0.38), 7.1(0)D1(0.278), 7.1(0)OTT(0.36), 7.1(0)PDB(0.228), 7.1(0)ZD(0.327), 7.2(0)D1(1), 8.3(0)CV(0.297) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu38208 | Title: | VINCI: new member add to existing vpc+ PL fails for vlan 4045 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This happens when trying to add a new member port to the port channel.
This can also happen when removing the already mapped port and then again trying to map it again to the port channel.
Conditions:
There needs to be atleast one member port on the port-channel
Workaround:
There are two workarounds;
1. interface port-channel100
switchport trunk allowed vlan all
2. interface eth1/2
channel-group 100 force
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.508), 8.3(0)CV(0.304) |
|
Known Fixed Releases: * | 7.2(0)D1(1.20), 7.2(0)ZD(0.226), 7.3(0)SL(0.73), 8.3(0)CV(0.439) |
|
|
| |
| |
|
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: | 20-MAY-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: | CSCus94535 | Title: | SNMP crash during OIR of transceiver and walk ciscoEntitySensorMIB |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
SNMP may crash on a Nexus 7000 switch during OIR of 1G, 10G, 40G DOM capable transceiver.
Conditions:
Process snmpd dumps core when the following steps are met:
1. SNMP walk CISCO-ENTITY-SENSOR-MIB when a DOM capable transceiver is inserted.
2. Remove the DOM capable transceiver
3. SNMP walk CISCO-ENTITY-SENSOR-MIB again
Workaround:
1. Insert any transceiver back to the port
2. Once snmpd crashed, the newly started snmpd will not have the issue
unless the steps described in "Conditions" happen again.
3. Disable SNMP walk for CISCO-ENTITY-SENSOR-MIB
Further Problem Description:
Problem exists in 6.2(12) only.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.2(12)S33 |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.3), 7.1(0)AV(0.74), 7.1(0)ES(0.7), 7.2(0)D1(0.422), 7.2(0)D1(1), 7.2(0)FM(0.3), 7.2(0)PDB(0.352), 7.2(0)VZD(0.6) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu49365 | Title: | Wrong set of bd's are sent in TMC when no bridge-domain is done |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Here proper set of bd's or vlan's are not sent in port affected notif to ethpm for bringing them down.
This will lead to inconsistency in peer-link i.e. vpc_mgr, ethpm and vlan components.
This only pertains to vxlan setup and not vinci/autoconfig.
Conditions:
Only on "no bridge-domain " and vxlan setup.
This is not seen in vinci and autoconfig setup.
Workaround:
For peerlink do shut/no shut i.e. flap the port.
For normal ports aswell do the same flap them.
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.512), 7.2(0)D1(1), 7.3(0)D1(0.34), 8.3(0)CV(0.230), 8.3(0)CV(99.179) |
|
Known Fixed Releases: * | 7.2(0)D1(1), 7.2(0)D1(1.14), 7.2(0)ZD(0.221), 7.2(1)PIB(0.14), 7.3(0)SL(0.73), 8.3(0)CV(0.439) |
|
|
| |
| |
|
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: | 21-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S46, 7.2(2)D1(0.43), 7.2(2)ZD(0.132), 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)TSH(0.99) |
|
|
| |
| |
|
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: | 21-MAY-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.2(2)D1(0.43), 7.2(2)ZD(0.133), 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: | 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: | 21-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.125), 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.12) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy43188 | Title: | In "F2E F3" VDC, IPSG entries being pushed on F3 rather than F2E |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPSG entries are not getting pushed to F2E card while for other line card F3 it is working fine
Hardware programming on F2E:
====================
N2-ACCESS# sh forwarding security mac module 1 vrf all
IPv4 security information for table 0x5, prefix count 15
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
IPv4 security information for table 0xfffe, prefix count 3
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
N2-ACCESS#
Hardware programming on F3:
===================
N2-ACCESS(config)# sh forwarding security mac module 8 vrf all
IPv4 security information for table 0x5, prefix count 17
------------------+------------------------+-----------
Prefix | Mac-address M V P | Interface
------------------+------------------------+-----------
30.0.0.10/32 0022.19a7.5567 1 0 1 Eth1/25
30.1.0.10/32 0000.0000.0001 1 0 1 Eth1/1
Conditions:
Mixed VDC with F2E and F3 LC's
Workaround:
Not Known at this moment of Time
Further Problem Description:
N/A
|
|
Last Modified: | 21-MAY-2016 |
|
Known Affected Releases: | 6.2(16)S32, 7.3(0)DX(0.96) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(0.133), 7.3(0)DX(0.145) |
|
|
| |
| |
|
Alert Type: | Updated * |
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: | 21-MAY-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.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.133), 7.3(0)DX(0.141), 7.3(0)UCI(0.30), 8.3(0)CV(0.436) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy15221 | Title: | vPC: F3 module reload delay to unset VSL bit |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
System may take up to 1 minute to converge after module reload
Conditions:
This can potentially happen when peer-link member(s) share the same module as vPCs
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.43), 7.2(2)ZD(0.132), 7.3(0)TSH(0.99), 7.3(1)D1(0.18) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy37359 | Title: | Taurus CB40 Fails Op-shock (5G/11ms) at Y-axis (VE project) |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Taurus CB40 Fails twice during Op-shock (5G/11ms) at Y-axis. Reproducible with TRF spine snake.
- Setup: APEX-10, 1x Taurus Sup & 3x Taurus FM.
- Taurus CB40 is in slot 4.
- Latest B36 diags images.
- test cmd uses TRF 2 (spine_snake) p2p.
- Note: passed shock/vibe at x-axis.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 9.9(9.9) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy95714 | Title: | DAI with ARP ACL Filtering don't work with Layer 2 NetFlow |
|
Status: | Terminated |
|
Severity: | 2 Severe |
Description: | Symptom:
When we configure ARP ACL on VLAN interface for DAI Filtering and configure Layer 2 NetFlow under ARP reply ingress port, DAI did not work.
Conditions:
ARP ACL on VLAN interface for DAI Filtering and configure Layer 2 NetFlow under ARP reply ingress port.
Workaround:
Enable dynamic bank chaining to support these feature combination.
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh67765 | Title: | F3:: MTM crash after system reload |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.116) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.118), 7.0(0)FT(0.121), 7.1(0)D1(0.14), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy51803 | Title: | otm cores found after switchover and powerup of Lc |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall ()
from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70
#2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcpudp/clt/tcp_api.c:5185
#3 0xf70d7865 in mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../infra/mts/lib/libmts.c:1883
#4 0xf676054d in fu_mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../utils/fsmutils/fsm.c:6514
#5 0xf6965aac in sla_api_query_stats (clnt_q_mts=11, probeid=10136, stats=0xffd3ef50) at ../feature/sla/nxos/public/lib/sla_api.c:281
#6 0x0806ebf6 in otm_check_ipsla_object_state (obj_node=0x876ea30, state=0xffd3f1c8) at ../infra/track/server/otm_ipsla.c:346
#7 0x080693e4 in otm_track_ipsla_object (obj_node=0x876ea30, vdc_id=0) at ../infra/track/server/otm_track.c:91
#8 0x080626d6 in otm_create_object_node (vdc_id=0, object_id=136, otm_rec=0x8729f84, obj_inst=0xffd3fc8c, restart=1) at ../infra/track/server/otm_util.c:806
#9 0x08075fc5 in otm_restore_config (pss_runtime_config=141172496, version=0, pss_runtime_info=141122256) at ../infra/track/server/otm_restore_pss_data.c:319
#10 0x080769ab in fu_cb_restore_pss_data (arg=0xffd4015c) at ../infra/track/server/otm_restore_pss_data.c:94
#11 0xf67a9b2d in fu_restore_pss_data (cb_vdc_id=4, call_application_restore=1) at
Conditions:
otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall ()
from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70
#2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcpudp/clt/tcp_api.c:5185
#3 0xf70d7865 in mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../infra/mts/lib/libmts.c:1883
#4 0xf676054d in fu_mts_recv (q=11, this_msg=0xffd3ecca, options=0xffd3eca0) at ../utils/fsmutils/fsm.c:6514
#5 0xf6965aac in sla_api_query_stats (clnt_q_mts=11, probeid=10136, stats=0xffd3ef50) at ../feature/sla/nxos/public/lib/sla_api.c:281
#6 0x0806ebf6 in otm_check_ipsla_object_state (obj_node=0x876ea30, state=0xffd3f1c8) at ../infra/track/server/otm_ipsla.c:346
#7 0x080693e4 in otm_track_ipsla_object (obj_node=0x876ea30, vdc_id=0) at ../infra/track/server/otm_track.c:91
#8 0x080626d6 in otm_create_object_node (vdc_id=0, object_id=136, otm_rec=0x8729f84, obj_inst=0xffd3fc8c, restart=1) at ../infra/track/server/otm_util.c:806
#9 0x08075fc5 in otm_restore_config (pss_runtime_config=141172496, version=0, pss_runtime_info=141122256) at ../infra/track/server/otm_restore_pss_data.c:319
#10 0x080769ab in fu_cb_restore_pss_data (arg=0xffd4015c) at ../infra/track/server/otm_restore_pss_data.c:94
#11 0xf67a9b2d in fu_restore_pss_data (cb_vdc_id=4, call_application_restore=1) at
Workaround:
otm cores found after switchover and powerup of Lc,
#0 0xf68e7f92 in syscall ()
from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#0 0xf68e7f92 in syscall () from /ramfs/ucd_tmp/ucd.N0BSLyNRO2YwBfV4Sg/lib/libc.so.6
#1 0xf6f45f12 in os_syscall_ioctl (fd=11, request=-2143204091, arg=0xffd3e95f) at ../routing-sw/routing/tcpudp/clt/os_syscalls.c:70
#2 0xf6f35bcd in ioctl (desc=11, req=2151763205) at ../routing-sw/routing/tcp
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(16)S40 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S55, 7.2(2)D1(0.48), 7.2(2)ZD(0.139), 7.3(1)D1(0.47), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq77481 | Title: | ipfib crash at lfib_pi_get_cnh_adj_with_vpn_label after noshut core int |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
IPFIB crash while shutting the core interface
Conditions:
With MPLS core and 6 IGP paths in the system
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.1(0)D1(0.255), 7.3(0)DX(0.64) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.86), 7.3(0)EG(0.14), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux59834 | Title: | Limit OTV data-group configuration to /24 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
On a Nexus 7xxx chassis when using F3 modules for OTV; if the OTV data-group range is configured with a larger subnet mask than /24, some multicast groups could fail to pass across the OTV.
Conditions:
Because the CLI allows for configuration of the data-group subnet larger than /24, the current threshold is exceeded. If the following occurs some multicast groups will fail across OTV:
1) Have a data-group range configured under the overlay with a subnet mask greater than /24.
2) Have experienced an AED failover event.
Workaround:
Limit the CLI data-group configuration to prevent configuration of a subnet larger than /24.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S28, 7.0(0)BZ(0.108), 7.3(0)D1(1), 7.3(0)DG(0.3), 7.3(0)DX(0.88), 7.3(0)IZN(0.13), 7.3(0)N1(0.272), 7.3(0)N1(1), 7.3(0)TSH(0.99) |
|
|
| |
| |
|
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: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.82) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 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), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw69419 | Title: | VIP used as src ip in data path causing traffc to drop at the dest. leaf |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Traffic from a box that has "advertise-pip" configured could be dropped because of unknown source peer IP address.
Conditions:
Advertise-pip CLI allows EVPN BGP to advertise Route-type 5 routes with next-hop using the the primary IP address of the nve interface. This command is off by default. Users should turn on this command on the EVPN leaf if the leaf is running in VPC mode and falls in one of the following scenarios:
- The leaf and its VPC leaf have asymmetric external L3 connections that some IP prefix routes are only reachable from one of the leafs, not both. An example of this is a pair of border leafs which run in VPC mode, and are connected to DCI boxes asymmetrically. (Symmetric topology can become asymmetric due to link failure.)
- DHCP or DHCPv6 relay is configured on the leaf and the DHCP server is in the non default, non management vrf
- User needs to run traffic between the leaf and a remote host. An example of this is to initiate a ping from the leaf's loopback address in a non default vrf, to a remote host
"advertise-pip" can be enabled on a pair of EVPN VPC leafs by the following:
router bgp
address-family l2vpn evpn
advertise-pip
When 'advertise-pip' is configured, route-type 5 update will advertise NH using PIP. If there is no route-type 2 update from this box, VIP is not advertised and any traffic sourced from this box using VIP as source would be dropped by the remote VTEP.
Workaround:
When advertise-pip is configured on a VPC pair in the EVPN VXLAN fabric, user should also configure on one of the VPC switches a static MAC on an VXLAN enabled vlan so that the secondary IP address of the nve interface is also advertised to remote VTEPs. This will avoid that packets encapsulated by this leaf using the secondary IP address as the VTEP source address being discarded by the remote leafs due to an unknown peer. We recommend to pick an unused vlan and vni and configure the following on all leafs:
Nexus 56xx:
vlan 3000
vn-segment 1003000
interface nve 1
member vni 1003000 mcast-group 239.1.1.1
evpn
vni 1003000 l2
rd auto
route-target import auto
route-target export auto
mac address-table static 0200.e111.1111 vlan 3000 int port-channel 1
Please note that other than the "mac address-table static" command which should be entered on the box where 'advertise-pip' is enabled, the rest of the above commands should be added in all the leafs that could talk to the box that enables 'advertise-pip'. In the above configuration, the vlan value (3000 in this example) should be an unused vlan on the box, and the value vni (1003000 in this example) should be an unused vni in the fabric. The multicast-group value should be picked from the range of multicast group addresses supported in the underlay fabric. The mac address used is a dummy mac address not used by any host and switch. To avoid conflict, we suggest to set the Universal/Local bit (the second-least-significant bit of the most significant byte) of the MAC address to 1 to indicate that it is a locally administered mac. The interface should be one of the server facing ports or port-channels that is up.
Nexus 700x/77xx:
vni 1003000
bridge domain 200
member vni 1003000
encapsulation profile vni cisco
dot1q 100 vni 1003000
interface nve 1
member vni 1003000 mcast-group 239.1.1.1
evpn
vni 1003000 l2
rd auto
route-target import auto
route-target export auto
mac address-table static 0200.e111.1111 bridge-domain 200 interface port-channel 1
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.156) |
|
Known Fixed Releases: * | 7.3(1)DX(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj48042 | Title: | N7K-OFF-DIAG:Sup 2:spine_diagdsp falure w. BIOS v.2.12 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
a
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCug67177 | Title: | Flanker: Repeated ipfib process crash brought module to Failure state |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
multiple ipfib process crash leading to module in failure state.
Conditions:
Initially configured Flanker ports as L3 ports, later checked route commands on both SUP and module . Observed ipfib crash followed by sync loss on the module after issuing "default interface e6/5" ,.
Module went in to Failure state after this.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.71) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.79), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux47262 | Title: | STP stuck on LRN state after upgrade |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In vPC scenario, during the ISSU upgrade step, we found part of vlan (vlans 606, 1336, and 1340) on vpc port-channel 301 stuck in LRN state, and can not recover.
Conditions:
Workaround:
Issue only disappeared after remove vlans on peer-link and then add back. To resolve the problem, we removed the vlans 606, 1336, and 1340 off both N7Ks for VPC 301 (removed from trunk allowed list). We re-added the vlans back and STP went forwarding as we expected.
Further Problem Description:
As a sanity check procedure after ISSU, you can check the connectivity of VLANs (such as ping test to the SVI). If the situation happens, recycle the VLAN configuration. This will be the workaround.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(2), 6.2(8a) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.97), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux54153 | Title: | Deletion of route-map seq doesn't trigger OSPF external LSA deletion |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Deleting of Route-map seq (used in redistribution) doesn't trigger to delete External LSA in OSPF
Initial Config:
router ospf 2
router-id 6.3.42.42
vrf tenant-VJ
redistribute bgp 2 route-map vj
N9372-42(config)# show route-map vj
route-map vj, permit, sequence 3
Match clauses:
ip address prefix-lists: vj-test
Set clauses:
route-map vj, deny, sequence 5
Match clauses:
ip address prefix-lists: vj
Set clauses:
route-map vj, permit, sequence 10
Match clauses:
route-type: internal
Set clauses:
N9372-42(config)#
N9372-42(config)# sh ip prefix-list vj-test
ip prefix-list vj-test: 1 entries
seq 5 permit 10.166.6.13/32
N9372-42(config)# sh ip prefix-list vj
ip prefix-list vj: 3 entries
seq 3 permit 10.166.6.13/32
seq 5 permit 164.0.0.0/8 eq 32
seq 15 permit 10.0.0.0/8 eq 32
N9372-42(config)#
N9372-42(config)# show ip ospf database external vrf tenant-VJ
OSPF Router with ID (164.1.0.42) (Process ID 2 VRF tenant-VJ)
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.166.6.13 164.1.0.42 705 0x80000032 0x7d3c 3489660930
Conditions:
N9372-42(config)# no route-map vj permit 3
2015 Dec 15 16:53:19.025072 rpm: Processing policy vj from work queue.
2015 Dec 15 16:53:19.025104 rpm: ACN sent to client ospf-2 for policy vj, version 36
N9372-42(config)# undebug all
N9372-42(config)# show ip ospf event-history lsa
OSPF lsa events for Process "ospf-1"
OSPF lsa events for Process "ospf-2"
N9372-42(config)# show ip ospf database external vrf tenant-VJ
OSPF Router with ID (164.1.0.42) (Process ID 2 VRF tenant-VJ)
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.166.6.13 164.1.0.42 109 0x80000032 0x7d3c 3489660930 ?-------------Still here
N9372-42(config)#
N9372-42# show ip ospf database external det vrf tenant-VJ
OSPF Router with ID (164.1.0.42) (Process ID 2 VRF tenant-VJ)
Type-5 AS External Link States
LS age: 293
Options: 0x82 (No TOS-capability, No DC, DN)
LS Type: Type-5 AS-External
Link State ID: 10.166.6.13 (Network address)
Advertising Router: 164.1.0.42
LS Seq Number: 0x80000032
Checksum: 0x7d3c
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 3489660930
Workaround:
N9372-42(config)# router ospf 2
N9372-42(config-router)# vrf tenant-VJ
N9372-42(config-router-vrf)# no redistribute bgp 2 route-map vj <-----------Work-around to this issue
Further Problem Description:
The actual problem is the VPN BGP redistribution. When OSPF redistributes the BGP routes. it expects the Extended Community Attributes to be present and from OSPF. In this case, the source route is from connected/local and ECA is added for that routes. When OSPF sees the routes with ECA and not originated by the OSPF, it treats as normal redistribution.
While flushing it treats as VPN redistribution and missed to flush as normal redistribution. Thus the LSA remains in the database.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(3)I2(2) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(0)BZ(0.115), 7.0(3)I3(0.204), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.54), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.3(0)DG(0.3), 7.3(0)DX(0.120) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus77706 | Title: | Phy vpc: Can't bring up 2 orphan ports in I mode |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
PXE boot servers won't work with phy. port vPC.
Conditions:
PXE boot servers won't work with phy. port vPC.
Workaround:
There is no workaround.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.390) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.115), 7.3(0)DX(0.120), 7.3(0)DX(0.122), 7.3(0)DX(0.64), 7.3(0)DX(0.73), 7.3(0)DX(0.88), 7.3(0)DX(0.96) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy83572 | Title: | RIP routes not installed when RIP packet has same sequence as previous |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes present in the 1st update packet will be installed but those in other packets that are split due to there be many prefixes (in my case > 23) won't be installed.
RIP will log the following message in syslog:
2011 Oct 9 19:05:42 N6K-1 %RIP-4-VALIDATE_SRC: rip-1 [4477] (ucf-base) MD5 authentication failed(seq_no)for inf Vlan621
Conditions:
This is seen when there are more than 23 prefixes to be sent by neighbor, so the updates have to be split in multiple packets and the neighbor uses the same sequence number in the Auth header for these split packets.
Workaround:
As the issue is seen with MD5 Authentication header, if authentication is not used, or if Simple (clear text) authentication is used, issue won't trigger, as the sequence number field won't be present.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S66, 7.0(3)I3(1.7), 7.0(3)I3(2), 7.0(8)N1(0.2), 7.0(8)N1(1a), 7.1(3)N1(4), 7.1(3)ZD(0.115), 7.1(3)ZN(0.250), 7.2(2)D1(0.48) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy81855 | Title: | SGACL with > 1 ACE is not installed when policy caching is enabled |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Only one ACE is installed in the switch when a SGACL with more than one ACE rule is downloaded from ISE
Conditions:
Policy caching enabled + SGACL with more than one ACE is downloaded from ISE
Workaround:
Disable Policy Caching "no cts cache enable" and then issue "cts refresh role-based policy"
Further Problem Description:
This is issue is present in 6.2.6 to 6.2.14, 7.2(0)D1(1) and 7.3(0)D1(1).
Without disabling policy caching, refreshing the policy will not help. Whenever an SGACL is modified in ISE and the switch needs to be updated then ensure policy caching is disabled to get the update installed correctly, after confirming the update has been installed the user can then enable policy caching.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(10), 7.2(0)D1(1), 7.3(0)D1(1) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S62, 7.0(0)BZ(0.127), 7.2(2)D1(0.41), 7.2(2)ZD(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(0)TSH(0.99), 7.3(1)D1(0.19), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy61699 | Title: | ospfv3 route has not got advertised to another area |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
OSPF ABR is unable to generate the Inter-Area LSAs
Conditions:
Flapping the Intra Area routes in ABR for sometime(months).
Workaround:
Restarting the OSPF process in Nexus, will undergo the Graceful restart and will not cause any outage.
Further Problem Description:
The Link State ID is a running no. for generating the inter-area prefix LSAs. This LS ID will be unique for each advertised route and it can reach to the max 2^20.
Every time, we allocate the LS ID on generating new LSA for the new route. It has to be deallocated, when the same LSA being flushed.
In the problematic router, we are not deallocating the LS ID and the usage of the LS ID reached the max. Thus we are unable to generate any new Inter-area prefix LSAs.
To recover from this situation, we recommend to restart the process.
Restarting the OSPF process in Nexus, will undergo the Graceful restart and will not cause any outage.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(8) |
|
Known Fixed Releases: * | 6.2(14b)S2, 6.2(16), 6.2(16)S65, 7.0(0)BZ(0.127), 7.2(2)D1(0.47), 7.2(2)N1(0.434), 7.2(2)N1(1), 7.2(2)ZD(0.139), 7.2(2)ZN(0.142), 7.3(0)DG(0.3) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz29940 | Title: | MFIB fail to install route with Tunnel after LC reload |
|
Status: | Fixed |
|
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: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.23), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy21507 | Title: | BFDC crash seen during VDC suspend |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
A Nexus 7000 running BFD might experience a crash in the "bfdc" process.
Conditions:
The crash was seen during VDC suspend/shutdown.
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.132), 7.3(0)DX(0.140), 7.3(0)DX(0.83) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.131), 7.3(0)DX(0.132), 7.3(0)DX(0.133), 7.3(0)DX(0.135), 7.3(0)DX(0.137), 7.3(0)DX(0.140), 7.3(0)DX(0.141), 7.3(0)DX(0.142) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy17164 | Title: | 7.3(0)D1(1)S11 - observing ipfib core while running OTV regression |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Core in IPFIB and possible traffic lost for OTV broadcast traffic.
Conditions:
OTV setup with F3 based LCs. The problem may happen if configuring OTV and extending VLAN which does not have any member port.
Workaround:
In order to avoid hitting this issue, always make sure VLAN and vlan member ports are up before extending the vlan over the overlay.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)D1(1), 7.3(0)DG(0.3), 7.3(0)DX(0.89), 7.3(0)UCI(0.30), 7.3(1)D1(0.7), 7.3(1)D1(0.8), 7.3(1)FTO(0.7), 7.3(1)PIB(0.24), 8.3(0)CV(0.436) |
|
|
| |
| |
|
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-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.2(2)D1(0.46), 7.2(2)N1(0.433), 7.2(2)N1(1), 7.2(2)ZD(0.138), 7.2(2)ZN(0.141), 7.3(1)DX(0.11), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy28615 | Title: | some IPv6 prefixes not advertised to vrf-lite edge peer |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
This bug is seen for IPv6 prefixes only. This is a happens to a subset of ipv6 prefixes for for north south traffic. In some race condition where a update on a host comes very close to each other. For e.g. when a IPv6 host connects to a vPC leaf node. The border Leaf may not propagate this prefix to DC edge box. Since its a race condition it may not occur at other BL's and connectivity may still be maintained.
Conditions:
For e.g. when a IPv6 host connects to a vPC leaf node.
Workaround(s):
Deploying multiple Border leaf nodes may reduce probability of external router getting this host from at least one of the border leaf nodes
Workaround:
Clearing the Host address at leaf node may help
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90), 7.3(0)N1(0.290) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.124), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.12), 7.3(1)FTO(0.7), 7.3(1)PIB(0.26) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy30270 | Title: | LISP: synch leads to frequent uRIB writes, which block route reads |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In a deployment with lisp ESM mobility enabled, a standby HSRP box starts observing high delays in software forwarding.
As a consequence, HSRP suffers hello packet loss and periodically flaps.
Conditions:
The trigger for this is when the number of hosts that lisp detects goes above the recommended 250. The impact is higher when the number of hosts detected grows beyond 600 hosts and depending on the number of processes that are actively using software forwarding on the box.
Workaround:
The only available workaround now is to limit the number of lisp mobility hosts to values below 250 or deploy LISP without HSRP.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 6.2(14)E1, 6.2(16)S46, 7.0(0)BZ(0.127), 7.2(2)D1(0.41), 7.2(2)N1(0.407), 7.2(2)N1(1), 7.2(2)ZD(0.112), 7.2(2)ZN(0.109), 7.3(0)DG(0.3), 7.3(0)DX(0.133) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy45305 | Title: | port moved from vdc and errors for %DHCP_SNOOP-2-HWPGMFAILURE: Hardware |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Conditions:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Workaround:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
Further Problem Description:
%DHCP_SNOOP-2-HWPGMFAILURE: Hardware programming has failed
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.125), 7.3(0)DX(0.127), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy49147 | Title: | VTPV3_VPC - ERROR: Password mismatch seen in 7.3.0.DX.0.90.gbin.S0 |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Password mismatch is observed on becoming primary server for feature vlan/mst.
Conditions:
Workaround:
Set vtp password in hidden mode again or hit enter.
Further Problem Description:
Initially hidden password is set. Once we make mst instance or vlan instance primary, new password is accepted and instance become primary but password is set to empty. So, on setting 2nd instance primary, password is rejected - Passowrd mistmatch. VTP password is not configured. Hence, rejecting new password 2nd time.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.90) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.125), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz23741 | Title: | hardware qos mpls exp topmost pipe-mode is broken |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
"hardware qos mpls exp topmost pipe-mode" with "set mpls experimental topmost ? should not rewrite the packet DSCP, but in M3 its broken.
Conditions:
When qos action is "set mpls experimental topmost ? on PE-1, we treat this is a uniform mode. In uniform mode inner packet dscp is modified based on the .
But, "hardware qos mpls exp topmost pipe-mode? with ?experimental topmost " should not change the inner cos as per the customer needs. But in M3, its rewriting DSCP value.
Workaround:
Further Problem Description:
PE-1 :
PE-1# sh run | inc hard
hardware qos mpls exp topmost pipe-mode
PE-1#
PE-1# sh policy-map interface ethernet 1/4 type qos
Global statistics status : enabled
Ethernet1/4
Service-policy (qos) input: sample
SNMP Policy Index: 285214816
Class-map (qos): match_dscp_10 (match-all)====> IP packet ingressing with DSCP#10
Slot 1
3096152587 packets 142425355940 bytes
5 minute offered rate 2738140090 bps
Aggregate forwarded :
3096152587 packets 142425355940 bytes
Match: dscp 10
set mpls experimental topmost 7====> QOS action is : set mpls experiment topmost 7 with hardware qos mpls exp topmost pipe-mode.
====> This should not change the packet DSCP (inner). But in the case of M3, its getting rewritten in the ingress PE.
Class-map (qos): class-default (match-any)
Slot 1
28 packets 1722 bytes
5 minute offered rate 32 bps
Aggregate forwarded :
28 packets 1722 bytes
PE-1#
PE-2 :
E-1-PE-2# sh policy-map interface ethernet 1/44 type qos
Global statistics status : enabled
Ethernet1/44
Service-policy (qos) output: egress-new-qos
SNMP Policy Index: 285213778
Class-map (qos): match_dscp_10 (match-all)====> Expected : Ingress PE-1 should not rewrite the DSCP, and expected packet to be classified here, but its rewritten based on EXP set.
Aggregate forwarded :
0 packets
Match: dscp 10
police cir 2 gbps bc 200 ms
conformed 0 bytes, 0 bps action: transmit
violated 0 bytes, 0 bps action: drop
Class-map (qos): match_dscp_63 (match-all)
Slot 1
2817442757 packets 2105306975838 bytes
5 minute offered rate 2738131861 bps
Aggregate forwarded :
2817442757 packets 1105813614952 bytes
Match: dscp 63
police cir 2 gbps bc 200 ms
conformed 1105812579492 bytes, 1438155974 bps action: transmit
violated 999493360886 bytes, 1299976941 bps action: drop
Class-map (qos): match_dscp_0 (match-all)
Aggregate forwarded :
0 packets
Match: dscp 0
police cir 2 gbps bc 200 ms
conformed 0 bytes, 0 bps action: transmit
violated 0 bytes, 0 bps action: drop
Class-map (qos): match_dscp_5 (match-all)
Aggregate forwarded :
0 packets
Match: dscp 5
Class-map (qos): class-default (match-any)
Aggregate forwarded :
0 packets
PE-1-PE2
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.3), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz00345 | Title: | ISSU from < 6214 to > 6214 with policy caching en wont 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: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(16)S65, 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.2(2)D1(0.44), 7.2(2)ZD(0.134), 7.3(0)DG(0.3), 7.3(0)DX(0.133), 7.3(0)DX(0.141), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy00151 | Title: | NVT: Crash in feature-mgr when we use show feature cli on standby RP |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Executing "show feature" command on standby supervisor causes feature manager to crash.
Symptom:
Usually "show feature" CLI command is executed on active supervisor. If executed on standby supervisor, this causes feature manager to crash.
Conditions:
This above scenario is only seen if "show feature" CLI is executed on standby.
Workaround:
Please execute "show feature" CLI command only on active supervisor.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.33), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz67278 | Title: | VXLAN-EVPN:two RMAC are transported as transitive community,but shouldnt |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
EVPN-Setup with two fabrics: from the remote Leaf the tunnel RMAC is transported as transitive community, but should not. Only the local EVPN tunnel RMAC from the border should be included
Conditions:
EVPN setup with two fabrics
Workaround:
n/a
Further Problem Description:
n/a
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.3(1)DX(0.33), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47013 | Title: | MBGP local path is marked invalid if other path is learned from neighbor |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes in BGP multicast Address family not installed as per BGP best path selection / Nexus
Conditions:
Customer is setting up IPv4 BGP Multicast peering between Nexus 3k / 5k devices and we see that IBGP learned prefix is preferred over locally generated route at the IPv4 Multicast BGP table.
Workaround:
None
Further Problem Description:
Customer is setting up IPv4 BGP Multicast peering between Nexus 3k / 5k devices and we see that IBGP learned prefix is preferred over locally generated route at the IPv4 Multicast BGP table.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14), 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.0(3)I3(1.4), 7.0(3)I3(2), 7.0(3)I4(0.17), 7.0(3)I4(1), 7.0(3)IBT3(2), 7.0(3)IBT3(2.5), 7.0(3)IM3(1.75), 7.0(3)IM3(2), 7.3(0)DX(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz50557 | Title: | N77/VRRPv3: VRRP flaps on multiple SVIs upon SSO |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
VRRPV3 Backup routers may failover when VRRPV3 mater router is undergoing SSO/ISSU
Conditions:
VRRPV3 Backup routers may failover when VRRPV3 mater router is undergoing SSO. This is because VRRPv3 default timers maynot be sufficient to prevent failover.
Workaround:
Increase the Advert Timers at the Master router and the corresponding Backup Routers before SSO/ISSU.
This would prevent the Backups Failing over during the Master failover.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.28), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy96475 | Title: | N7K - elo memory leak in im_parse_l2_bundled_phy_port_state_change |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
elo leaks memory whenever a port channel member interface changes state.
Conditions:
- "feature ethernet-link-oam" must be configured
- There must be at least one port channel, with at least one member configured.
- The member interface changes state (e.g. goes up or down).
Workaround:
Restarting the elo process will not impact the protocol but would release the memory.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116), 7.3(0)DX(0.124) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.133), 7.3(0)DX(0.142), 7.3(0)UCI(0.30), 7.3(1)D1(0.46), 7.3(1)FTO(0.4), 7.3(1)FTO(0.7), 7.3(1)N1(0.329), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy81913 | Title: | After ISSU change the lkup mode globally from IP to MAC traffic drop |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
After changing l2 multicast lookup mode by "[no] layer-2 multicast lookup mac" before and after ISSU, the l2 mcast route is not programmed in hardware.
Conditions:
The problem is hit when l2 multicast lookup changes before and after MFDM restart - either due to ISSU, system switchover, or mfdm crash.
Workaround:
In steady state, change the lookup back and forth one more time. This will ensure the routes in old lookup mode be deleted in memory and new routes will be push to LC to be programmed in hardware.
Further Problem Description:
When l2 lookup mode changes, mfdm will clean up all the route in existing lookup mode. However this is a software bug that these routes are not deleted from PSS. So when mfdm restart happens - due to ISSU or system switchover, route in old lookup mode will be recovered in mfdm. So mfdm is hold the route with two lookup mode. If now the lookup mode is changed again back to old lookup mode, it will delete all the routes in new lookup mode but keep the route in old lookup mode. So after the lookup mode change, when control plane push down the route in old lookup mode, mfdm considers it as identical route, and ignores the update. As the result, LC (hardware) will not be programmed.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.123), 7.3(0)TSH(0.99), 7.3(1)D1(0.23), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
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: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116), 7.3(0)DX(0.131) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.4), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz54906 | Title: | LIF not published to SDB for port-channel on VRF removal |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
N7k having 2 layer3 port-channel spread across multiple F3 modules can experience hardware misprogramming for one L3 port-channel when VRF membership is changed in another port-channel.
Conditions:
1. Should have more than one layer3 port channel spread across multiple modules.
2. Affected port should share a member port with the port-channel where vrf membership was changed.
3. This defect only affects layer 3 port-channel, it will have no impact on other layer 3 physical ports or interface vlans.
4. This defect is only applicable if you are running 7.x code, this defect does not impact 6.x code.
Workaround:
1. Reconfigure the affected port-channel. if this does not work go to step 2
2. Shut down the affected port-channel. remove the member interfaces from affected port-channel delete the port-channel configuration using cli command "no interface port-channel X) . Then remove the member interfaces of the affected from vdc, reallocate them back into the current vdc and recreate the port-channel. If this does not work go to step 3
3. reload the line card.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.2(2)D1(0.47), 7.2(2)ZD(0.138), 7.3(1)DX(0.24), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux96194 | Title: | After ISSU from GBRMR1 to Helsinki when we flap vpc leg seei dup packets |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
In Vinci, duplicated multicast pkt received at remote leafs sourced from vpc leaf.
Conditions:
When ipfib restarted - either due to ISSU or due to crash, oiflist need to recover a field for vinci non-forwarder operation. This field is derived from oif flag of the oiflist. However the oif flag is not PSSed. As the result, the oiflist for non-forwarder is not properly recovered - it is recovered as forwarder. Since ipfib restart won't reprogram h/w, traffic won't be affected. When there is an update for the oiflist, h/w will be programmed as forwarder. As the result, both vpc peers are forwarding - causing duplicates at remote receivers.
Workaround:
clear ip mroute *
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(1)D1(0.12), 7.3(1)FTO(0.7), 7.3(1)PDB(0.17) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy85875 | Title: | Moved host route does not get installed in HW in LISP IGP Assist in ASM |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Really low performance is seen when traffic is sent to this host. All packets get punted up to the Supervisor in order to resolve the adjacency and will be subject to rate-limiting.
Conditions:
LISP ASM w/ IGP Assist deployment on N7k's running 7.2 code or above
And we are changing the LISP AD from the default value to prevent routing loops
When the host moves from his home network, to the away network, the issue is seen.
Workaround:
AD of LISP should be kept at 240
Increase the AD of the IGP/BGP to higher than 240 to avoid routing loops
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(2.1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.3), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy21050 | Title: | MBD OIFlist programming is incorrect in MFDM post swithover |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
L2 multicast traffic drops due to that L2 LTL driven by l2 lookup doesn't have correct oifs. These oifs are programmed by PIXM. However PIXM lost the oifs info after LC reloaded, and expect a trigger from mfdm to repopulate the oifs for the LTL.
Conditions:
All following conditions need to be met to hit the problem:
1. Vinci Spine switch with fabric VNIs configured.
2. system switch over, or ISSU from GRB to HSK
3. L2 multicast egress LC reload.
Workaround:
Since Fabric VNIs is used for pruning, without it, it will be flooded in spine. So temporarily remove it won't cause any traffic outage. This can be used as workaround as described below:
Before switchover, or ISSU, unconfig fabric VNIs. After switchover or ISSU, re-config fabric VNIs. After this, LC reload will not causing the problem.
Example:
10000 is fabric control VNI - this should not be removed.
50001-50050 is fabric VNI.
Before SSO, or ISSU, config:
"no vni 50001-50050"
After SSO or ISSU, config:
"vni 50001-50050"
Further Problem Description:
The root cause is that with "feature fabric multicast" configured on spine, Monster BD will have ftag entry created. These entry are not properly restored during switchover or ISSU that the tag entries restored lost vni value in it. Such entries are not from m2rib and will not be removed when LC is reloaded. As the result the oiflist pointed by these entries will never be removed and added back and PIXM won't get the expected trigger for them.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.127), 7.3(0)TSH(0.99), 7.3(1)D1(0.12), 7.3(1)FTO(0.7), 7.3(1)PDB(0.14) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz42373 | Title: | BGP Convergence on 7.2(1)D1(1) has items remaining on the new-list. |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: | Symptom:
Routes can take a long time to converge in BGP
Conditions:
MPLS CSC setup with RFC3107 labels
Workaround:
None
Further Problem Description:
Routes spend a long time being processed on the New List during convergence.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.48), 7.2(2)N1(0.435), 7.2(2)N1(1), 7.2(2)ZD(0.140), 7.2(2)ZN(0.143), 7.3(1)DX(0.37) |
|
|
| |
| |
|
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: | 29-MAY-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.2(2)D1(0.49), 7.2(2)ZD(0.141), 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) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy58448 | Title: * | Brabham Cb10: link flaps if the speed on the interface is mismatch on 1G |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Two linked 1G ports have unpredictable link status.
Conditions:
Two linked 1G ports configured as
Port 1 configuration - speed auto
Port 2 configuration - speed 1000
This is an invalid configuration.
Workaround:
Configure the two ports as
Port 1 configuration - speed auto
Port 2 configuration - speed auto
or
Port 1 configuration - speed 1000
Port 2 configuration - speed 1000
Further Problem Description:
This unpredictability persists irrespective of the LCs in use. For instance, the two linked ports could be on
1 - One Brabham CB10
2 - Two Brabham CB10
3 - Brabham and Pescara
4 - Brabham and Ricard
5 - Brabham and Autodromo
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.102) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy86259 | Title: | M3-10: 43% frame loss after changing PC load balance to ip-l4port |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | The hash functions are different in the two cases
MIXED mode hash function:
hashkey = (HashOrder(da_sa_sel,ip_da,ip_sa), HashOrder(da_sa_sel,dst_port,src_port), zero(13,0) ) ;
L3 hash function:
hashkey = (HashOrder(da_sa_sel,ip_da,ip_sa),zero(13,0));
With MIXED mode, when we do not change the src/dst port, the hash computation is not uniform as src/dst is in the lower order bits. Here the hashes are mapped to the same port.
With L3 mode, lower order terms change with src/dst ip and hence get better hash distribution.
It looks like in the practical scenarios, usually l4 port changes and hence with the l4, we expect it to change.
So, we can document the behavior.
Symptom:
In the following setup with L2U port-channel configuration. We were seeing about 0.73% frame loss for all frame size with default port channel load balance. After changing load balance to ip ip-l4port we are now seeing about 43% frame loss for all the frames.
Conditions:
With this traffic profile [Backbone test /partial mesh: SRC IP (varying) + DST IP (varying)+ SRC PORT (fixed) + DST PORT (fixed)] the traffic loss increased instead of decreasing after including L4-port in PC load balance hash.
Workaround:
In practice or real world, usually l4 port changes as there will be different apps running. So, in practice, there will be better load-balancing.
When there is no L4 port change, better use the "src-dst ip" load-balance scheme.
Further Problem Description:
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz13193 | Title: | M3 BootupPortLoopback UNTESTED when first inserting to the switch. |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
Bootup port loopback diagnostic test will show result as "DIAG TEST UNTESTED" with reason "Failed to send the loopback packets"
Conditions:
LC interfaces are not allocated to any VDC.
Workaround:
Allocate interfaces to VDC and save config. Test will run on all subsequent linecard/switch reloads.
Further Problem Description:
Since interfaces are not allocated to any vdc, pixm doesn't have port index/ltl info which is needed to send the diag test packets. As interfaces are not in use, running bootup test is not critical. Once interfaces are allocated, bootup test will run on all subsequent module or switch reloads.
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy14744 | Title: | N77 - C7702 for M3 not populated for cshcNetflowResourceUsageTable |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | This OID and a few other OIDs are not supported on any of the linecards including F2E, F3 or M3 on APEX platform.
Symptom:
SNMP get on cshcNetflowResourceUsage Table will not return correct values for F2E, F3 or M3 linecards on APEX platform.
Conditions:
SNMP get on cshcNetflowResourceUsage Table
Workaround:
No workaround.
Further Problem Description:
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.79) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy02586 | Title: | vPC+ both switches learn mac address on peer-link on receiving garp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When receiving gratuitous arp on orphan port in vPC+ environment,
both vPC switches might learn the source mac address of this gratuitous arp on vPC peer-link.
This symptom leads traffic drop since packets are not forwarded to the port where gratuitous arp is received.
Conditions:
Nexus 7000 series running with N7K-SUP2 and F2E modules only.
Software is 6.2(14), 7.2(0)D1(1)
Workaround:
Use vPC for connecting device that sends gratuitous arp if possible.
clear mac address will help to recover the situation since packets are flooded by clearing mac address table.
Further Problem Description:
This symptom is currently under investigation
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: * | 7.3(1)D1(0.57), 8.3(0)CV(0.419) |
|
|
| |
| |
|
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: | 04-MAY-2016 |
|
Known Affected Releases: | 6.2(12), 7.0(6)N1(1) |
|
Known Fixed Releases: * | 7.3(1)D1(0.47), 7.3(1)FTO(0.4), 7.3(1)N1(0.331), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy99477 | Title: | Change metrictype of redistributed routes from MPBGP-OSPF from E2 to E1 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ability to override default behavior of advertising the redistributed routes from MP BGP->OSPF from E2 to E1 using a route map on receiving PE.
Conditions:
Using MP BGP and different OSPF domains.
Workaround:
None, this is expected behavior as per RFC
Further Problem Description:
In a MP-BGP setup, when redistributing External OSPF routes ->BGP on PE1, PE2 gets these routes in MP-BGP and redistributes the same in OSPF to CE2. Domain IDs are different in this case & as per RFC 4577, the route is seen as E2 on CE2 device.
CE1--PE1--Provider--PE2--CE2
Customer would like the ability to change the metric-type on PE2 from E2 (default) to E1 by using a route-map on PE2.
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: * | 8.3(0)CV(0.426) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv04106 | Title: | need "MAINTENANCE" as (special) reset-reason for GIR |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
while in Maintenance Mode, if the switch reloads because of any reason that is not part of handful that are covered under mmode today ,it should come back up in Maintenance mode.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.507) |
|
Known Fixed Releases: * | /bin/sh:, 7.0(0)BZ(0.108), 7.0(3)F1(0.188), 7.0(3)I3(0.180), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.33), 7.0(3)IDP3(1.50), 7.0(3)IDP3(2), 7.0(3)ITI2(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy93686 | Title: | vpc+: fabricpath STP type-1 configuration incompatible msg |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When trying to configure vPC with many allowed vlans as a trunk port on N7K(vPC secondary),
we experienced "STP type-1 configuration incompatible" error as following.
# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
vPC+ switch id : 100
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
vPC fabricpath status : peer is reachable through fabricpath
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
--snipped--
vPC status
-------------------------------------------------------------------------------
id Port Status Consistency Reason Active vlans vPC+ Attribute
-- ---- ------ ----------- ------ ------------ --------------
100 Po100 down* failed STP type-1 - DF: No, FP
configuration MAC:
incompatible 100.11.1111
5
The error status was not recovered by itself.
The problem was easily reproduced when they configure many allowed vlans with a single cli line at once.
interface port-channel100
switchport
switchport mode trunk
switchport trunk allowed vlan 1, 49, 100, 152, 198, 200, 210, 234, 1021, 1033-1034, 1062-1064, 1101-1103, 1282-1284, 1292, 1521, 1925, 2341
vpc 100
Conditions:
vPC+ / Fabricpath enabled / vlan mode fabricpath
When adding many vlans as allowed vlan within a short period of time at once
Workaround:
Add allowed vlans with some time interval thru separated CLIs as following.
interface port-channel100
switchport
switchport mode trunk
switchport trunk allowed vlan 1, 2, 3, 4, 5
switchport trunk allowed vlan add 6-10, 13-20
switchport trunk allowed vlan add 30-100, 110-130
vpc 100
Further Problem Description:
none
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 6.2(14)S25 |
|
Known Fixed Releases: * | 7.3(1)D1(0.46), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
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: | 04-MAY-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)FTO(0.4), 7.3(1)N1(0.332), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy96793 | Title: | PCIE i/f reset is not handled per instance, LC goes to Failure state |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: | Symptom:
M3 board has multiple instance of SLF. If there is a PCIE link failure due to hardware failure, the board will result in failure state and will be reloaded. There are multiple instance of star lifter asic, single instance failure will also result in board failure
Conditions:
This issue can occur when PCIe link failure to any instance of starlifter asic. PCIe link failure is a hardware failure and can result only due to bad HW
Workaround:
There is no workaround for this issue. Single instance failure will result in board failure
Further Problem Description:
Single instance failure cannot be marked as instance failure as there is multiple drivers access the asic. Also, the functionality is kept unchanged and the behaviour is same as M1/F1/M2/F2 and F3
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.125) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy79367 | Title: * | M3:LC ISSU: Invalid intf state provided to IFTMC |
|
Status: * | Terminated |
|
Severity: | 3 Moderate |
Description: * | LC ISSU isn't something the customer should be able to perform as it is a hidden command.
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.
After LC is upgraded, the msg is replayed wrongly.
Workaround:
Flap the affected interfaces.
Further Problem Description:
|
|
Last Modified: | 04-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
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: | 05-MAY-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw86555 | Title: | N7K Silent/Unknown supervisor switchover |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
N7K supervisor may silently reload without a core file.
Conditions:
This issue is seen on the N7K platform.
Workaround:
Unknown at this time.
Further Problem Description:
|
|
Last Modified: | 07-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.3(0)DG(0.3), 7.3(0)DX(0.109), 7.3(0)DX(0.110), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux49719 | Title: | pam_aaa_motd:cannot open motd file : /vdc_4/etc/motd - dcos_sshd |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
when we do switchto vdc , PAM infra tries to read motd file specific to VDC .
However exec banner as a feature is specific to the box/device but not to vdc . This is vdc unaware file .
This is not an issue with respect to motd . so we can ignore this message.
it is not a harmful msg
Conditions:
This issue will be seen during switchto vdc
Workaround:
it will be seen in the console if logging level of the console is set to error level & above.
workaround:
1.logging level console 2
2 .if customer is not happy with changing the logging level to 2, then we can ignore this msg.
Further Problem Description:
when we do switchto vdc , PAM infra tries to read /etc/motd file specific to VDC .
However exec banner as a feature is specific to the box but not to vdc . This is vdc unaware file .
This is not an issue with respect to motd . so we can ignore this message.
it is not a harmful msg for the customers .
|
|
Last Modified: | 07-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.172), 7.3(0)D1(0.179), 7.3(0)DX(0.110), 7.3(0)DX(0.87) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.120), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy14048 | Title: | SNMP nonoperational status from a Nexus7700 7.2(1)D1(1) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Via SNMP it is received nonoperational status from a Nexus7700 7.2(1)D1(1), OID used is 1.3.6.1.4.1.9.9.91.1.1.1.1.5 or entSensorStatus
Some examples:
1021590 nonoperational (3)
1021591 nonoperational (3)
1021592 nonoperational (3)
1021593 nonoperational (3)
However, at the CLI everything is fully operational - ok:
Temperature Fex 101:
--------------------------------------------------------------------
Module Sensor MajorThresh MinorThres CurTemp Status
(Celsius) (Celsius) (Celsius)
--------------------------------------------------------------------
1 Outlet-1 70 65 40 ok
1 Inlet-1 55 48 37 ok
1 Die-1 115 105 51 ok
Fan Fex : 101:
------------------------------------------------------
Fan Model Hw Status
------------------------------------------------------
Chassis N2K-2348TQ-FAN -- ok
Chassis N2K-2348TQ-FAN -- ok
Chassis N2K-2348TQ-FAN -- ok
PS-1 N2200-PAC-400W -- ok
PS-2 N2200-PAC-400W -- ok
Power Supply Fex 101:
---------------------------------------------------------------------------
Voltage: 12 Volts
-----------------------------------------------------
PS Model Power Power Status
(Watts) (Amp)
-----------------------------------------------------
1 N2200-PAC-400W 396.00 33.00 ok
2 N2200-PAC-400W 396.00 33.00 ok
Conditions:
The messages are seen every time the OID entSensorStatus is polled.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 07-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.3(0)DG(0.3), 7.3(0)DX(0.123), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
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: | 07-MAY-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: * | 7.3(0)DG(0.3), 7.3(0)DX(0.88), 7.3(0)UCI(0.30) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz51766 | Title: | ascii-cfg service reset with rollback on a large vlan configuration list |
|
Status: | Terminated |
|
Severity: | 3 Moderate |
Description: * | Symptom:
On a nexus 7000/7700 series switches, ascii-cfg process resets and a supervisor switchover may be seen during a rollback operation or executing "show dill rollback patch running-config checkpoint " when there has been changes to a large number of vlans under vlan configuration mode.
Conditions:
crash is seen only with large range of vlan configuration greater than 512 bytes
Workaround:
no workaround is there
Further Problem Description:
|
|
Last Modified: | 09-MAY-2016 |
|
Known Affected Releases: | 6.2(16) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
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: | 18-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.132) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui33220 | Title: | SSTE: OSPF/BFD convergence time high after a trigger clear ip ospf nei |
|
Status: | Terminated |
|
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
Further Problem Description:
|
|
Last Modified: | 19-MAY-2016 |
|
Known Affected Releases: | 6.2(2)S17 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut16676 | Title: | NXOS: Standby supervisor stuck in power-up |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Standby supervisor stuck in "powered-up" state where HA state stays in "HA synchronisation". This can happen after standby is reloaded - either manual reload/oir or part of ISSU
Following log is a main symptom of this issue.
show module internal activity module
11) At 312758 usecs after Sun Feb 15 07:46:58 2015
Queueing event: (reason: LC(s) coming up
Conditions:
Issue can happen after one modules is removed during booting sequence (during booting up/testing/initialization state). Module removed can be any module in the system (not necessary supervisor)
Workaround:
Reinsert module that has been removed during booting
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | 6.2(13.3)S0, 6.2(14), 6.2(14)FB(0.22), 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)CF(0.11), 7.2(0)D1(0.459), 7.2(0)D1(1), 7.2(0)PDB(0.380), 7.2(0)PDB(0.381) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz77977 | Title: | Ucast MAC addresses learned in VLANs on FP Spines after upgrade |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
After upgrading from 6.2.8a to 6.2.14 MAC addresses are being learned in hardware on the Spine switches of a FabricPath topology even though SVIs are not defined.
This behaviour is observed even though the spine switch configuration contains the "no hardware fabricpath mac-learning module port-group" command is present in the configuration.
The learned MAC addresses can be checked with the following command:
show hardware mac address-table dynamic vlan
Conditions:
Upgrading Spines in Fabricpath environment from 6.2(8a) to 6.2(14)
Workaround:
Remove and re-add the command from/to the running configuration:
hardware fabricpath mac-learning module port-group
no hardware fabricpath mac-learning module port-group
Further Problem Description:
Issue is not observed when upgrading from 6.2(14) to newer releases.
|
|
Last Modified: | 23-MAY-2016 |
|
Known Affected Releases: | 6.2(8a) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
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: | 24-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S9, 7.2(2)D1(0.44), 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: | 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: | 24-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(3)I2(2e), 7.0(3)I4(0.140), 7.0(3)I4(1), 7.0(3)IPP4(2), 7.0(3)IPP4(2.28), 7.3(1)D1(0.47), 7.3(1)FTO(0.4), 7.3(1)N1(0.331), 7.3(1)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux14098 | Title: | N7K/N77: write error: No space left on device |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
After issue : switchto vdc <>
error message:AQ6-PT-7010-03# switchto vdc ixIA
/isan/bin/first-setup.core: line 45: echo: write error: No space left on device
date: write error: No space left on device
/isan/bin/first-setup.core: line 47: echo: write error: No space left on device
date: write error: No space left on device
/isan/bin/first-setup.core: line 80: echo: write error: No space left on device
/isan/bin/first-setup.core: line 81: echo: write error: No space left on device
/isan/bin/first-setup.core: line 82: echo: write error: No space left on device
date: write error: No space left on device
Conditions:
issue command : switchto vdc <>
AQ6-PT-7010-03# sh module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok
2 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
3 32 10 Gbps Ethernet XL Module N7K-M132XP-12L ok
5 0 Supervisor Module-2 N7K-SUP2E active *
6 0 Supervisor Module-2 N7K-SUP2E ha-standby
7 24 10 Gbps Ethernet Module N7K-M224XP-23L ok
8 32 1/10 Gbps Ethernet Module N7K-F132XP-15 ok
9 48 1/10 Gbps Ethernet Module N7K-F248XP-25E ok
10 12 10/40 Gbps Ethernet Module N7K-F312FQ-25 ok
Workaround:
1. reload switch .
2. load a debug-plugin and then free up some space from /nxos/tmp
Further Problem Description:
the error message has no function impact. the first-setup script logs the debugging to /nxos/tmp which is much smaller than /var/tmp that is used before.
|
|
Last Modified: | 24-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.44), 7.2(2)N1(0.431), 7.2(2)N1(1), 7.2(2)ZN(0.139), 7.3(0)D1(0.191), 7.3(0)D1(1), 7.3(0)HIB(0.3), 7.3(0)IZN(0.13), 7.3(0)N1(0.247), 7.3(0)N1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui51401 | Title: | HW acl entries are not correct when having IPv6 RACL with BFD enabled |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Ipv6 BFD sessions go down when a IPv6 RACL is applied on the SVI where BFD is applied. BFD sessions applied alone seem to work fine
permit aces may not work as expected when ipv6 bfd and ipv6 RACL applied on same interface.
Conditions:
ipv6 bfd and ipv6 RACL applied on same interface.
Workaround:
don't use ipv6 bfd and ipv6 RACL together on same interface.
Further Problem Description:
|
|
Last Modified: | 24-MAY-2016 |
|
Known Affected Releases: | 6.2(2)S21 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S27, 7.2(2)D1(0.44), 7.2(2)ZD(0.133), 7.3(1)D1(0.40), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz19597 | Title: | M3 GRE: Tunnel Path MTU ignored tunnel port MTU |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
MTU value is not proper in eltm
N7K-3# sh int tun 12 | i MTU
MTU 9000 bytes, BW 9 Kbit
Path MTU Discovery, ager 30 mins, min MTU 1000, PMTUD 9000
Programmed MTU 9000
N7K-3# sh ip int tun 12 | i MTU
IP MTU: 1276 bytes (using link MTU)
N7K-3# show system internal eltm info interface t12 | i mtu
mtu = 1276 (0x4fc), f_index = 0 (0x0)
N7K-3#
Conditions:
Workaround:
Unconfigure and configure "tunnel path-mtu-discovery" on tunnel interface
Further Problem Description:
|
|
Last Modified: | 24-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 8.3(0)CV(0.457) |
|
|
| |
| |
|
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: | 24-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | 6.2(16), 6.2(16)S39, 7.2(2)D1(0.42), 7.2(2)ZD(0.131), 7.3(0)DG(0.3), 7.3(0)DX(0.91), 7.3(0)UCI(0.30), 7.3(1)D1(0.40) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut19221 | Title: | OTV Unicast Flooding MAC Entry Lost |
|
Status: | Open |
|
Severity: * | 3 Moderate |
Description: | Symptom:
MAC associated with 'otv unicast flood' is removed from MAC address table. This results of a loss of traffic over the OTV cloud.
Conditions:
Static MAC entry replaced by dynamic entry which then expires.
Workaround:
Toggle 'otv unicast flood' command.
Further Problem Description:
This issue related to a device misbehaving and sending a packet which overrides the static entry applied by 'otv unicast flood' with a dynamic one. Once the MAC has naturally timed out, following the lack of further packet transmissions from the misbehaving device, the MAC is flushed from the CAM table. This enhancement requests that the static MAC entry be placed back in when the dynamic MAC expires.
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41326 | Title: | Evaluation of NX-OS for OpenSSL December 2015 vulnerabilities |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151204-openssl
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Cisco has reviewed and concluded that this product is affected by one or more of these vulnerabilities.
Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; is affected by:
CVE-2015-3194 and CVE-2015-3195
Cisco MDS 9000 Series Multilayer Switches ;Cisco Nexus 5000 Series Switches;Cisco Nexus 6000 Series Switches;Cisco Nexus 7000 Series Switches; is not affected by:
CVE-2015-3193, CVE-2015-3196 and CVE-2015-1794
Workaround:
Not available.
Further Problem Description:
Additional details about those vulnerabilities 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: 4.3/3.4
http://tools.cisco.com/security/center/cvssCalculator.x?version=2&vector=AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/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: | 26-MAY-2016 |
|
Known Affected Releases: | 7.3(0)N1(0.235), 7.3(0)N1(0.252), 7.3(0.99) |
|
Known Fixed Releases: | 5.2(8h)S2, 6.2(16)S39 |
|
|
| |
| |
|
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: | 26-MAY-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.2(2)D1(0.46), 7.2(2)N1(0.433), 7.2(2)N1(1), 7.2(2)ZD(0.138), 7.2(2)ZN(0.141), 7.3(0)D1(0.178), 7.3(0)D1(1) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz77805 | Title: | "switchport trunk allowed vlan" not programmed in HW |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
with "switchport trunk allowed vlan", still learning mac addresses from not allowed vlans
Conditions:
Apply the allowed list when interface is shut down
Workaround:
not to change the allowed VLAN list when the VPC leg is DOWN
Even if they change and get into this situation then follow these steps
Allow the VPC Leg to come back up
Add the same set of old VLANs to allowed VLAN list to the VPC
After some time remove those VLANS from allowed VLAN list
This will make sure STP will come and do the cleanup both in SW and HW
Further Problem Description:
NA
|
|
Last Modified: | 26-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.46), 7.2(2)ZD(0.138) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09020 | Title: | NSSA intern router originate default not ASBR post ISSU 6.2.8a to 6.2.12 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
OSPF ASBR capability of N7K router originating default in NSSA area becomes disabled following ISSU upgrade from 6.2.8a to 6.2.12 or from 6.2.12 to 6.2.14. Default route may not be installed on OSPF neighbour routers in NSSA area.
Conditions:
ISSU upgrade from 6.2.8a to 6.2.12 or from 6.2.12 to 6.2.14.
Workaround:
Restart OSPF process with 'restart ospf ' CLI command
Further Problem Description:
|
|
Last Modified: | 27-MAY-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(14) |
|
Known Fixed Releases: * | 6.2(14b)S2, 6.2(16), 6.2(16)S21, 7.0(3)I3(0.162), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.28), 7.0(3)ITI2(1), 7.0(3)ITI2(1.100), 7.2(2)D1(0.47) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz35179 | Title: | N7K Queue Limit is misprogramed for Port-channels |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Queue limit ratios shows improperly under oversubscription
Configured queue-limit ratios
queue-limit ratios: 31[1p7q4t-out-q-default] 30[1p7q4t-out-q2] 30[1p7q4t-out-q3] 1[1p7q4t-out-q4] 1[1p7q4t-out-q5] 1[1p7q4t-out-q6] 1[1p7q4t-out-q7] 5[1p7q4t-out-pq1]
Queue-limit ratios currently available in HW
queue-limit ratios: 30[1p7q4t-out-q-default] 30[1p7q4t-out-q2] 30[1p7q4t-out-q3] 1[1p7q4t-out-q4] 1[1p7q4t-out-q5] 1[1p7q4t-out-q6] 1[1p7q4t-out-q7] 5[1p7q4t-out-pq1]
Configured queue-limit ratios
queue-limit ratios: 31[1p7q4t-out-q-default] 30[1p7q4t-out-q2] 30[1p7q4t-out-q3] 1[1p7q4t-out-q4] 1[1p7q4t-out-q5] 1[1p7q4t-out-q6] 1[1p7q4t-out-q7] 5[1p7q4t-out-pq1]
Queue-limit ratios currently available in HW
queue-limit ratios: 5[1p7q4t-out-q-default] 11[1p7q4t-out-q2] 30[1p7q4t-out-q3] 1[1p7q4t-out-q4] 1[1p7q4t-out-q5] 1[1p7q4t-out-q6] 1[1p7q4t-out-q7] 5[1p7q4t-out-pq1]
Conditions:
Port is oversubscribed
Workaround:
None. Issue does not affect traffic and only affects the ouput of the show queueing command
Further Problem Description:
|
|
Last Modified: | 27-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz15172 | Title: | LISP Map-notify issues due to IGMP/MRIB Interaction when vPC Flaps |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LISP is unable to synchronize detected dynamic-eids between xTRs. Multicast map-notifies are used to notify our peer of new detected hosts. If the vPC peer-link flaps, the multicast group used for LISP control-plane messages is not programmed and hence the peers become unsynchronized which causes LISP forwarding problems.
Conditions:
This issue is seen only when the keepalive interface used for vPC is flapped and then the peer-link is flapped
Workaround:
Enable PIM on the SVI's and this issue is not seen
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.45), 7.2(2)N1(0.432), 7.2(2)N1(1), 7.2(2)ZD(0.137), 7.2(2)ZN(0.140), 7.3(0)DX(1), 7.3(1)DX(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuf81607 | Title: | pre-qual-flanker:Missing member ports SI |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Missing member port SI
Conditions:
If a port channel has 2 member ports one of the member ports does not have the SI programmed
Workaround:
No work around
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.44) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.64), 7.0(0)FT(0.65), 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)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui15370 | Title: | Intermittent CHASSIS-PS_INTR failure Emerson PS across all corners |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
During the diag test CHASSIS-PS_INTR test failure is seen intermittently across all corner conditions.
Conditions:
Diag Image Used:
diag-sup3dc3-el-6.2.0.238d1.046.gbin
diag-n7k-6.2.0.238d1.046.mzg
Failing Corners:
Failure seen at NT/NV, HT/NV, and LT/NV
Workaround:
Test was skipped to avoid further failure since the fix is not available at this time.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(0.302)S24 |
|
Known Fixed Releases: * | 6.2(10)FM(0.3), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73), 7.0(0)KM(0.64), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu47169 | Title: | Enhancements to GOLD corrective actions show commands |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
This is an enhancement for the GOLD (show diagnostic) CLI which will provide more information on the corrective actions that can be enabled though "diagnostic eem action conservative" command,
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(12), 6.2(8a) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.2(2)D1(0.45), 7.2(2)ZD(0.137), 7.3(0)DG(0.3), 7.3(0)DX(0.44), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)UCI(0.2), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCut41525 | Title: | Rx span not happening with vlan as source |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When 2 vlans are configured as rx sources in a span session. the rx span from one of the vlans does not reach the destination port, debugged with asiic and driver team (vinay ) as a bad vqi, which is programmed in the span copy, due to DE_bypass bit set in the asiic span_SCT register.
Conditions:
When 2 vlans are configured as rx sources in a span session. the rx span from one of the vlans does not reach the destination port, debugged with asiic and driver team (vinay ) as a bad vqi, which is programmed in the span copy, due to DE_bypass bit set in the asiic span_SCT register.
Workaround:
no workaround
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.373) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.46), 7.0(0)HSK(0.381), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4), 7.3(1)FTO(0.7), 8.3(0)CV(0.436) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuh48163 | Title: | F3:: Show system internal iftmc hardware lif command is not available |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Conditions:
Workaround:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FT(0.106) |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)FT(0.111), 7.1(0)D1(0.14), 7.2(0)D1(1), 7.3(0)DX(0.4), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtr38849 | Title: | N7K: Policy stats do not work when Object-groups are used in ACLs |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | QoS Policy stats do not work when object-groups are used in ACLs that define the class-maps.
Symptom:
packet count is 0 for object group acl's
Conditions:
when object groups are used
Workaround:
avoid use of object group if stats are critical .functionality of object group is not broken
Further Problem Description:
packet count is 0 for object group acl's match filters
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 5.1(3) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.11), 7.0(0)HSK(0.499), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux31915 | Title: | N7K:vsh crash on Linecard while collecting tacpac |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
On N7K Linecard , vsh process crashed while collecting tacpac
Following error logged at that time.
%SYSMGR-SLOT4-2-LAST_CORE_BASIC_TRACE: : PID 10147 with message vsh(non-sysmgr) crashed, core will be saved
Conditions:
Nexus7000
NXOS6.2(10)
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(10), 7.3(0)DX(0.73) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.83), 7.3(0)UCI(0.5), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
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: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.141) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.3), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47121 | Title: | SSTE: LISP Process crash during continuous process restart |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
LISP process crashes after continuously manually restarting lisp from CLI.
Conditions:
LISP is continuously restarted manually via CLI "process restart lisp" during bringup.
Workaround:
None. Not deterministic.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(16)S38, 7.3(0)DX(0.102) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.121), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
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: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(0.133), 7.3(0)DX(0.145), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy92720 | Title: | PeerLink has Vlan membership in ELTM although no config present |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Extra mac is learnt on a fabricpath port-channel.
Conditions:
Only happens in case of ASCII replay or in case where an empty port-channel is created and converted to mode fabricpath. Once a port is present in port-channel this issue is not suppose to happen.
Workaround:
int po10
switchport mode trunk
switchport mode fabricpath
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14)S25, 7.3(0)D1(1), 7.3(0)DX(0.125) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.1), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux80178 | Title: | SSTE: Error for ISIS topology changes during ISSU for BD Flood prog |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
PIXM syslog seen if there is any change in topo during ISSU
Conditions:
Topo change when LC ISSU going on.
Workaround:
No functional impact because ISSU done should automatically will recover.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.194) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.87), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy47125 | Title: | cshcNetflowResourceUsageTable return incorrect values in SNMP |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Object cshcNetflowResourceUsageTable from CISCO-SWITCH-HARDWARE-CAPACITY-MIB returns incorrect values for Netflow utilization.
Conditions:
None.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.124), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy82339 | Title: | HSK2:Few BFD sessions down with subinterface optimization on sh/no sh |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
When subinterface optimization is enabled together with BFD ACP offload on M3, if one subinterface is shut, BFD sessions on the other subinterfaces might also flap.
Conditions:
Subinterface optimization enabled together with BFD ACP offload on M3 linecards.
Workaround:
With BFD ACP offload enabled, subinterface optimization is actually a redundant configuration and need not be enabled on the interface. Hence the recommendation is to NOT enable subinterface optimization whenever BFD ACP offload is enabled.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.116) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.133), 7.3(0)DX(0.141), 7.3(0)DX(0.146), 7.3(0)DX(1), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz22955 | Title: | M3 : MFIB : ipv6 *,g summary route count showing -ve value |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
On M3 modules, sh system internal forwarding ipv6 [multicast] route summary can report incorrect/negative values while printing the entries programmed in the FIB TCAM.
Conditions:
Problem can occur for the following reasons:
frequent VDC reloads
Workaround:
None. If the same triggers are seen post module reload the CLI issue can recur.
Further Problem Description:
This is purely a CLI related issue that tracks the number and type of entries programmed in the FIB TCAM and there is no functional impact in forwarding traffic.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.14), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux62214 | Title: | L2FM consistency checker can cause memory leak / crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
L2fm process crashes with signal 6
Conditions:
Either running CLI "show forwarding consistency checker" every 5 minutes or at a higher frequency on switch Or running CLI in background via script (EEM with scheduler OR py script)
Workaround:
There is no workaround
Do not use this CLI more often than a day.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.2(2)D1(0.48), 7.2(2)ZD(0.140), 7.3(0)D1(1), 7.3(0)TSH(0.99), 7.3(0)ZD(0.238), 7.3(1)D1(0.2), 7.3(1)PIB(0.24) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz10630 | Title: | Interfaces not part of FP vlans show up as members of the vlan |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Just a show vlan issue. If we have different fabricpath topologies and different vlan-port mapping, all ports will show all vlan's.
Conditions:
vlan 60-61
mode fabricpath
fabricpath topology 10
member vlan 60
fabricpath topology 11
member vlan 61
interface Ethernet2/1
fabricpath topology-member 11
interface Ethernet3/1
fabricpath topology-member 10
Workaround:
Since it is just a show issue this is Not applicable.
Further Problem Description:
Please read the description.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.135) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)DX(0.1), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz38530 | Title: | M3: PeerKeepAlive vrf is not migrated: tatus: Suspended (UNUSABLE VRF) |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When user has "configure maintenance profile ... " configuration in the default VDC, while doing admin VDC migration, newly created VDC could have part of the original config gone missing.
Conditions:
1. Has "configure maintenance profile.." config in default VDC before admin VDC migration.(configure maintenance profile ..." config can be the result of being in maintenance mode earlier)
2. execute admin VDC migration (command "system admin-vdc migrate")
Workaround:
Remove the "configure maintenance profile.." config before migration and apply to the newly created VDC after migration.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.17), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz24338 | Title: | Cron_Timer_ED stopped working after clock set |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
CRON_TIMER_ED is not working after clock set
Conditions:
After configuring CRON_TIMER_ED applet if clock set command is executed CRON_TIMER_ED does not work.
Workaround:
Workaround is to reconfigure CRON_TIMER_ED event manager applet after clock set.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(0.133) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.27), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux03524 | Title: | N7k: Multicast traffic not transmitted towards FEX on same FE as source |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When multicast source exists on the same FE as the FEX fabric link, the receiver connected to the FEX HIF won't receive the multicast stream.
Conditions:
- Multicast source and receiver setup for pim sparse-mode
- LC: N7K-M224XP-23L
- SW: 6.2.2-14
Workaround:
Move the FEX fabric link to a different FE as the source (either same LC or different LC).
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14), 6.2(2) |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S51, 7.2(2)D1(0.48), 7.2(2)ZD(0.140), 7.3(0)DX(0.143), 7.3(1)D1(0.48), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy89705 | Title: | 4 way HSRP does not work on Nexus 5k/6k switches |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
If we have 4 way hsrp configured and n5k in VPC pair are in Active/listen[ or standby/listen] state then connectivity to VIP breaks.
Conditions:
4 way hsrp is configured and n5k/6k in VPC pair are in Active/listen[ or standby/listen] state
Workaround:
Make n5k/6k in VPC pair Active/standby or listen/listen state in 4 way hsrp.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(7)N1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.1(3)ZD(0.129), 7.1(3)ZN(0.275), 7.1(4)N1(0.809), 7.1(4)N1(1), 7.2(2)D1(0.41), 7.2(2)N1(0.426), 7.2(2)N1(1), 7.2(2)ZD(0.128), 7.2(2)ZN(0.134) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy16984 | Title: | 'otm' core on N7K running 7.3_D1_S12 |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When "show track" CLI is issued, there is a possibility that OTM might crash.
Conditions:
Some track objects are configured and at least one client like HSRP is tracking it.
Workaround:
Instead of running "show track", we can retrieve each object track info using CLI "show tack <1-500>"
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.0(3)I4(0.64), 7.0(3)I4(1), 7.3(0)DG(0.3), 7.3(0)DX(0.94), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy57603 | Title: | Wrong return value for MACAddress and SystemID in IEEE8023-LAG-MIB |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Return value for MACAddress and SystemID from lagMIB at NX-OS is wrong as follows: XX-XX-XX-XX-XX-XX.
Conditions:
Retreive following MIB OID
IEEE8023-LAG-MIB::dot3adAggMACAddress
IEEE8023-LAG-MIB::dot3adAggActorSystemID
IEEE8023-LAG-MIB::dot3adAggPartnerSystemID
Workaround:
No workaround.
Translate retrurn value to characters format as follows: XX-XX-XX-XX-XX-XX.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.1(2)E5, 6.2(14), 7.3(0)D1(1), 7.3(0)DX(0.102) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.114), 7.3(0)DX(0.120), 7.3(0)DX(0.127), 7.3(0)TSH(0.99), 7.3(0)UCI(0.30), 7.3(1)D1(0.24), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux82001 | Title: | N7K No ARP for VRF next hop address in MPLS VPN decapsulation |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
When a Nexus7000 is used as an MPLS PE for L3VPN with F3 modules, connectivity to remote destinations can fail. The identifiable symptom of this problem is a missing ARP entry for the next-hop address in the VRF ARP table on the Nexus7000 PE. The problem is observed on the PE in the MPLS Decapsulation direction (Receives an MPLS encapsulated frame, and should send out a plain IP Packet toward the CE).
Conditions:
This problem has been observed when using static routing in the VRF between the Nexus7000 PE and the CE device. If a dynamic routing protocol is used, then the next-hop ARP entry would be populated and maintained by control-plane traffic which would prevent this issue.
Workaround:
Two workarounds exist:
1) Use per-vrf label on the Nexus7000 PE. This results in a single label for all local VRF CE routes
Router bgp
vrf
Address-family ipv4 unicast
label-allocation-mode per-vrf
2) Use a dynamic routing protocol between the PE and CE to maintain the ARP entry on the Nexus7000 PE
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(1)D1(1), 7.3(0)DX(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(1)D1(0.12), 7.3(1)DX(0.4), 7.3(1)DX(0.5), 7.3(1)FTO(0.7), 7.3(1)PDB(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux77234 | Title: | F3 packets are flooded for 2-3 sec during receiving gratuitous arp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Packets are flooded for 2-3 seconds during receiving gratuitous arp.
Conditions:
Nexus 7700 series with F3 line cards. This symptom seen on both NX-OS release 6.2(14) and 7.2(1)D1(1).
Port where traffic is received and gratuitous arp is received are located on different SoC.
Workaround:
Not available at this moment.
Further Problem Description:
Root cause is identified and solution is provided in further software releases.
Fix is to change internal timer for quicker processing.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(14), 7.2(1)D1(1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.103), 7.3(0)UCI(0.30), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz43257 | Title: | Nexus 6K:Truncated console logs seen while enabling hsrp and vrrp |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Nexus6K - Truncated console logs message seen while enabling feature hsrp and vrrp with/without LAN_BASE license .
Conditions:
Enable feature hsrp and vrrp with or without LAN_BASE license .
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.3(0)NXA(0.1) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.127), 7.3(1)DX(0.26), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw85884 | Title: | N7K snmpd process seg fault crash |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
snmpd process may crash and trigger the hap reset:
`show system reset-reason`
----- reset reason for module 5 (from Supervisor in slot 5) ---
1) At 846639 usecs after Thu Oct 15 14:06:23 2015
Reason: Reset triggered due to HA policy of Reset
Service: snmpd hap reset
Version: 6.2(10)
Conditions:
this was observed on N7K running 6.2.10 code when snmp get on the non-existence FC port information.
Workaround:
unknown for now
Further Problem Description:
|
|
Last Modified: | 30-MAY-2016 |
|
Known Affected Releases: | 6.2(10)S99 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(2)ZD(0.142), 7.3(1)D1(0.47), 7.3(1)FTO(0.4) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy62745 | Title: | Master Bug to port fix for 2348 Issues from N5k to N7k,N9k |
|
Status: | Fixed |
|
Severity: * | 3 Moderate |
Description: | Symptom:
Master Bug to port fix for 2348 Issues from N5k to N7k,N9k
Conditions:
Issues seen on Nexus 2348UPQ platform which need to be fixed on other Nexus platforms
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-MAY-2016 |
|
Known Affected Releases: | 6.2(14)S1, 6.2(16)S9 |
|
Known Fixed Releases: | 7.0(0)BZ(0.127), 7.3(0)DX(1), 7.3(0)FXK(0.26), 7.3(0)FXK(0.27), 7.3(0)FXK(0.28), 7.3(1)DX(0.2), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz83616 | Title: | vpc command added automatically on some FEX HIFs (vpc_num > 4096) |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
"vpc xxxx" command is added on FEX interfaces automatically after the interfaces are brought up either as switchport access or as switchport trunk interfaces;
The "xxxx" in the command is greater than 4096, and hence this command could not be deleted;
"default int eth x/y/z" command for the affected interface does not help - the 'vpc xxxx' config stays on the interface;
Conditions:
The exact trigger is not known at the moment;
The issue was seen for one single-homed N2K-C2248TP-E-1GE FEX attached to Nexus 7706 chassis with VPC feature enabled;
At the same time the other FEX devices attached to the same N77 chassis did not have the issue;
Workaround:
The automatically added vpc command could be removed by the following steps:
- configure on the affected FEX interface vpc command with vpc number lower than 4096,
- remove the configured vpc command by negation of the command,
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuq62069 | Title: | QSFP BiDi gives out bogus DOM info when DOM is not supported |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
When issuing "show interface transceiver det" on an interface with QSFP BiDI with 6.2.8a and later releases, the output contains all 0 or N/A. The output should be either removed or clarified to indicate that DOM is not supported for BiDi.
Conditions:
Using QSFP BiDi on n7k runnig 6.2.8a and later
Workaround:
Expected behavior, refer to the DOM compatible matrix:
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html#36364
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(8a), 7.3(0)DX(0.18) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DG(0.3), 7.3(0)DX(0.40), 7.3(0)DX(0.41), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65667 | Title: | support for create/delete/modify BD, peer-id FIB entry via test hardware |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
Requirement to provide a command to create {BD, peer-id} entry via "test hardware internal" command
Conditions:
Workaround:
using the "test nve peer-add/peer-del" commands with the limitations
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.494) |
|
Known Fixed Releases: * | 8.3(0)CV(0.469) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz25183 | Title: | Incorrect lacp state in rx PDU 'show lacp internal pdu int <if> parse' |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
The 'show lacp internal pdu interface parse' reports incorrect actor and partner lacp state in all received LACP PDUs. While the port-channel is up the actor and partner state reports 'state:0x80 (Ac-0:To-0:Ag-0:Sy-0:Co-0:Di-0:De-0:Ex-1)' in all received LACP PDUs.
Conditions:
A port-channel is configured on a Nexus7000 running 6.2(12) release.
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 6.2(10), 6.2(12) |
|
Known Fixed Releases: * | 8.3(0)CV(0.449) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz67812 | Title: | subinterface has main iterface's MTU after restore config |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
subinterface has main iterface's MTU after restore config
Conditions:
- This issue occurred when restore configuration at factory default switch.
- Main interface has MTU:9000, and sub-interface has MTU:1500.
- MTU:1500 is default, and so there is not "mtu 1500" at backup of running-config.
- As a result, sub-interface has MTU:9000 when restore configuration.
Workaround:
use "show running-config all > BKUP.cfg"
Further Problem Description:
|
|
Last Modified: | 18-MAY-2016 |
|
Known Affected Releases: | 6.2(14) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCus53354 | Title: | N7K-OFF-DIAG:Pescara N7K 100: DSH can't start all dsps in BB |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
some dsp can't startup automatcially.
It need more time.
Conditions:
NTNV
Workaround:
init group need be refined
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.2(0)ZN(0.87) |
|
Known Fixed Releases: * | 6.2(10)CR(0.35), 7.0(0)BZ(0.46), 7.0(0)HSK(0.325), 7.1(320)MQ(0.60), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(0)TSH(0.4), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux09380 | Title: | IP PIM MTU to increase AUTORP packet size |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
AUTORP packet size increase not allowed beyond default 1500 bytes.
Conditions:
The IP PIM MTU command have no effect on this feature/protocol. This request is to include AUTORP in the packets affected by the IP PIM MTU command change.
Workaround:
None at this time. The group list will need to be summarized, so that the list is not that long and able to fit the currently allowed size.
Further Problem Description:
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: | 6.2(12), 7.2(0)D1(1) |
|
Known Fixed Releases: * | 8.3(0)CV(0.429), 8.3(0)CV(0.432), 8.3(0)SPB(0.43) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuy37022 | Title: | priv max length allowed 130 according to the user guide not working |
|
Status: | Open |
|
Severity: | 4 Minor |
Description: | Symptom:
priv max length allowed 130 according to the user guide not working
Conditions:
configuring snmp user with priv max length
Workaround:
NA
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 7.3(0)D1(0.201) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuy32910 | Title: | urib_rt_mod_del api does not delete a route |
|
Status: | Open |
|
Severity: * | 4 Minor |
Description: | Symptom:
Conditions:
Workaround:
instead use
Use
rc = urib_rt_mod_add(rbuf, af->table_id, prefix);$
/* loop and add all the Nhs for this route into urib_rt_mod_nh_del*/
rc = urib_rt_mod_nh_del(rbuf, nh_addr, nh->iod, nh->table_id);$
Further Problem Description:
|
|
Last Modified: | 19-MAY-2016 |
|
Known Affected Releases: | 7.3(1)XX(0.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtz50653 | Title: | OTV Enh: Clear OTV forwarding multicast counters |
|
Status: | Fixed |
|
Severity: | 4 Minor |
Description: | Symptom:
Enhancement request to clear otv forwarding counters shown in
sh forwarding otv multicast route vlan 10 mod 7
Conditions:
Currently no way to clear these counters manually.
Workaround:
NA. Enhancement request
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 5.2(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.65), 7.3(0)EG(0.14), 7.3(0)UCI(0.2), 7.3(1)FTO(0.7), 8.3(0)CV(0.436) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux54588 | Title: | Error disabled state for BootupPortLoopback test does not get cleared |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
Switch# diagnostic clear result module 1 ?
test Diagnostic test selection
Switch# sh diagnostic result module 1 test 11 de
Current bootup diagnostic level: complete
Module 1: 10 Gbps Ethernet Module
Diagnostic level at card bootup: complete
Test results: (. = Pass, F = Fail, I = Incomplete,
U = Untested, A = Abort, E = Error disabled)
______________________________________________________________________
11) BootupPortLoopback:
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-----------------------------------------------------
. E . . . . . . . . . . . . . .
Port 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
-----------------------------------------------------
. . . . . . . . . . . . . . . .
While Portloopback test for the same port will be passing at every fresh run.
Conditions:
Test results are checked after a Line card reload.
Prior to LC reload, PortLoopback for port in question was "E" or "F"
Workaround:
Now fix has been committed.
Meanwhile, cu can clear test results using:-
diagnostic clear result module 1 test 11 >>>>>>bootup test ID
and then reload card and see if bootupportloopback test passes.
If you do not want to clear test results/reload card, then try to use the foll. CLI to know actual test results for bootupPortLoopback" test :-
show diagnostic result module 2 test 11 statistics
Current bootup diagnostic level: complete
Module 2: 10 Gbps Ethernet XL Module
Diagnostic level at card bootup: complete
______________________________________________________________________
11) BootupPortLoopback
______________________________________________________________________
Port No Packet TX Packet RX Packet Loss
______________________________________________________________________
1 4 4 0
2 4 4 0
3 4 4 0
4 4 4 0
5 4 4 0
6 4 4 0
7 4 4 0
8 4 4 0
9 4 4 0
10 4 4 0
11 4 4 0
12 4 4 0
SNIP
last column i.e. "Packet Loss" column should be "0" in a pass state for port in question.
Further Problem Description:
This is a cosmetic show cli issue with no effect on functionality of port. As long as portloopback test passes for the port, then that port should work.
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(10) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.108), 7.3(0)DG(0.3), 7.3(0)DX(0.82), 7.3(0)EG(0.14), 7.3(0)UCI(0.5), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCub79046 | Title: | N7K-OFF-DIAG: PescaraCB-100 development |
|
Status: | Fixed |
|
Severity: | 5 Cosmetic |
Description: | Symptom:
for new product development
Conditions:
for new product development
Workaround:
pescaraCB-100 is a new product, we create this ID for new product development
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(0.28) |
|
Known Fixed Releases: * | 6.2(0.225)S0, 6.2(0.237)S0, 6.2(0.240)S0, 6.2(0.273)S0, 6.2(0.282)S0, 6.2(0.287)S0, 6.2(0.293)S0, 6.2(0.294)S0, 6.2(0.298)S0, 6.2(5.7)S0 |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz60566 | Title: | NX-OS Support for Multicast BGP |
|
Status: | Open |
|
Severity: * | 6 Enhancement |
Description: | Symptom:
Multicast BGP routes are not installed in the RIB table or the MP-BGP neighborship is torn down as soon as multicast routes are advertised via Multicast BGP
Conditions:
NX-OS device setup with only Multicast BGP adjacency.
Workaround:
To prevent the flapping of MP-BGP when advertising multicast routes configured the devices to also peer up with IPv4 AF
Further Problem Description:
|
|
Last Modified: | 27-MAY-2016 |
|
Known Affected Releases: | 7.0(4)N1(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCui99939 | Title: | N7K-OFF-DIAG : Pescara N7K-100 : Development |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Create code for product pescara N7K-100
Conditions:
Workaround:
Create code for product pescara N7K-100
Further Problem Description:
Create code for product pescara N7K-100
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)FR(0.5) |
|
Known Fixed Releases: * | 6.2(0)HS(0.10), 6.2(10)CR(0.3), 6.2(10)EC(0.12), 6.2(10)FM(0.3), 6.2(10)NO(0.19), 6.2(12)FM(0.6), 6.2(8)KR(0.8), 6.2(8)TS(0.28), 6.2(8.9)S0, 6.2(9)FM(0.73) |
|
|
| |
| |
|
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: | 28-MAY-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), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCud96635 | Title: | Gibraltar:Feature mvrp |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Feature implementation
Conditions:
Feature implementation
Workaround:
Feature implementation
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.2(5.7), 7.0(0.1)S0, 7.0(0.5)S0 |
|
Known Fixed Releases: * | 6.2(5.7)S0, 6.2(6), 7.0(0)KM(0.64), 7.0(0)MV(0.1), 7.0(0)MV(0.10), 7.0(0)MV(0.11), 7.0(0)MV(0.12), 7.0(0)MV(0.13), 7.0(0)MV(0.14), 7.0(0)MV(0.15) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw82759 | Title: | Nexus 5600/6000: No LAN_BASE should disable FHRP CLI or throw error |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
+ FHRP hellos do not get punted to CPU.
+ Both peers assume active (master) roles and do not resolve active/standby or master/backup states
+ HW programming of router VMAC points to l2mp-nh instead of sup-eth
HOU-CORESW-02# sh platform fwm info hw-stm asic 0 | grep 0000.5e00.0111
1.17 0000.5e00.0111 l2mp-nh 1:12298:0 1:0:1 2.a.bd.0.0.0 (e:0)
+ ELAM shows sup-redirect is not set
Conditions:
configured VRRP or HSRP
LAN_BASE_SERVICES_PKG is NOT installed
Workaround:
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 8.3(0)CV(0.261) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.0(0)BZ(0.127), 7.3(0)DG(0.3), 7.3(0)DX(0.102), 7.3(0)UCI(0.30), 7.3(1)DX(0.26), 7.3(1)FTO(0.7), 8.3(0)CV(0.436) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCtj60428 | Title: | Need for PBR with next-hop pointing out or to Tunnel interface |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | This is an enhancement for PBR with the set ip next-hop keywords pointing to a tunnel interface or out a tunnel interface to the next-hop.
Currently PBR with set ip next-hop pointing to a tunnel interface is NOT supported configuration.
This is an enhancement for PBR with the set ip next-hop keywords pointing to a tunnel interface, or to a next hop IP address via a tunnel interface.
Currently PBR with set ip next-hop pointing to a tunnel or to a next hop IP address via a tunnel interface is NOT a supported configuration on the N7k.
Symptom:
NA
Conditions:
NA
Workaround:
NA
Further Problem Description:
NA
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 5.0(2a) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.115), 7.3(0)DG(0.3), 7.3(0)DX(0.104), 7.3(0)UCI(0.30), 7.3(1)DX(0.32), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65654 | Title: | show system internal forwarding nve command crashes the LC ipfib process |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
module-3# sh system internal forwarding nve
2015 Aug 5 19:21:32 switch %$ VDC-1 %$ %SYSMGR-SLOT3-2-SERVICE_CRASHED: Service "ipfib" (PID 3470) hasn't caught signal 6 (core will be saved).
2015 Aug 5 19:21:35 switch %$ VDC-1 %$ %SYSMGR-SLOT3-2-SERVICE_CRASHED: Service "ipfib" (PID 26454) hasn't caught signal 6 (core will be saved).
module-3# sh system internal forwarding nve peer 1
NVE Vtep interface: 0x49000001, name: nve1
--------------------
Could not find the PEER VLAN object for peer_id : 1, VLAN-ID: 4294967295
Conditions:
show system internal forwarding nve command
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.494) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.16), 7.0(0)HSK(0.533), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7), 8.3(0)CV(0.436) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuc29276 | Title: | Cannot bring up FEX if switchport trunk native vlan is configured |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
If the native vlan of the fex-fabric port channel connecting to a FEX is not 1, the FEX cannot be brought online. Any fex-fabric interfaces should ignore any switchport trunk commands.
Conditions:
This bug applies to 5.2(7), 6.0(4), and 6.1(1).
Workaround:
Do not configure any switchport trunk commands in fex-fabric interfaces.
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 6.0(4) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.98), 7.3(0)DG(0.3), 7.3(0)DX(0.29), 7.3(0)EG(0.14), 7.3(0)GLF(0.53), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv65642 | Title: | configuring vni crashes the Line Card UFIB process |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
LC ufib crash
Conditions:
vni config command
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 28-MAY-2016 |
|
Known Affected Releases: | 7.0(0)HSK(0.494) |
|
Known Fixed Releases: * | 7.0(0)BZ(0.71), 7.0(0)FFW(0.11), 7.0(0)HSK(0.522), 7.3(0)DX(0.4), 7.3(0)EG(0.14), 7.3(1)FTO(0.7) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuu36374 | Title: | cli indicator for maintenance mode |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
we need a visible cli indicator stating that system is in maintenance mode
Conditions:
N/A
Workaround:
N/A
Further Problem Description:
we need a visible cli indicator stating that system is in maintenance mode
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.407) |
|
Known Fixed Releases: * | 8.3(0)CV(0.456), 8.3(0)CV(0.459), 8.3(0)CV(0.467), 8.3(0)CV(0.468) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz81809 | Title: | N7k- IP SLA UDP Probe Delay |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
When ASR1k uses UDP Probe N7k switch we see significant latency intermittently.
Conditions:
While using UDP probe to N7k
Workaround:
Further Problem Description:
|
|
Last Modified: | 26-MAY-2016 |
|
Known Affected Releases: | 6.2(9.49) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux77124 | Title: | No source info in "%USER-3-SYSTEM_MSG: NTP Receive dropping message:" |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
The following message is not of much help other than telling that there is DDOS attack. A Source IP needs to be included to make it any useful.
%USER-3-SYSTEM_MSG: NTP Receive dropping message: Received NTP private mode packet.
Conditions:
NTP is configured.
NX-OS 6.2(14)
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 6.2(14)S1 |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv67713 | Title: | Make MTU Change for FabricPath Transit switch to allow for VN-Seg |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Traffic from VN-Segment enabled Leaf switches gets dropped on the Spine when the network is configured for a default MTU of 1500.
Conditions:
Leaf switch vlans are configured for VN-Segmentation
Workaround:
Configure "system jumbomtu 1542" and configure "mtu 1542" on the N7K Spine interfaces.
Any value greater then 1542 can be used as well including 9216.
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(1) |
|
Known Fixed Releases: * | 7.2(2)D1(0.44), 7.2(2)D1(0.45), 7.2(2)ZD(0.137) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCut43703 | Title: | Need a seperate adjacency for DBA addresses |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
We are not auto fixing the adjacency during ISSU. If we are upgrading from a release before 7.2 (Gibraltar), even after ISSU to 7.2, the existing prefixes will still point to the glean adjacency.
Conditions:
upgrading from versions < 7.2.
Workaround:
clear ip route * vrf all
Further Problem Description:
|
|
Last Modified: | 25-MAY-2016 |
|
Known Affected Releases: | 7.2(0)D1(0.437) |
|
Known Fixed Releases: | 7.1(0)AV(0.74), 7.1(0)ES(0.18), 7.2(0)BA(0.25), 7.2(0)CF(0.11), 7.2(0)D1(0.437), 7.2(0)D1(0.472), 7.2(0)D1(1), 7.2(0)RTG(0.150), 7.2(0)VZD(0.26), 7.2(0)ZD(0.152) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCts65715 | Title: | MAC sync needed after L2 inconsistency is detected b/w sup and LC |
|
Status: | Terminated |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
This is not a bug but an enhancement request. Once MAC sync inconsistency is detected between sup and line card, we need a feature to sync it.
Conditions:
None
Workaround:
Clear mac address may act as a workaround.
Further Problem Description:
|
|
Last Modified: | 23-MAY-2016 |
|
Known Affected Releases: | 5.1(3) |
|
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: | 21-MAY-2016 |
|
Known Affected Releases: | 6.2(14)S24 |
|
Known Fixed Releases: * | 6.2(16), 6.2(16)S16, 7.2(2)D1(0.43), 7.2(2)ZD(0.132), 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)TSH(0.99), 7.3(0)ZD(0.225) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCun41202 | Title: | Weak CBC mode and weak ciphers should be disabled in SSH server |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: * | Symptom:SSH servers on Cisco Nexus devices may be flagged by security scanners due to the inclusion of SSH ciphers and HMAC algorithms that are considered to be weak.
These may be identified as 'SSH Server CBC Mode Ciphers Enabled' and 'SSH Server weak MAC Algorithms Enabled' or similar.
Conditions:This issue applies to Cisco Nexus 7000, Cisco Nexus 5000 and MDS 9000 series switches. SSH functionality is enabled by default in Cisco NX-OS. The current SSH server status is displayed using the show ssh server command.
Workaround:None.
More Info:If an SSH client configured to use weak ciphers is used to log in to a Cisco device with this fix, the login may fail. The following messages are logged in the switch syslog:
%DAEMON-2-SYSTEM_MSG: fatal: no matching cipher found: client 3des-cbc,blowfish-cbc server aes128-ctr,aes192-ctr,aes256-ctr - sshd[6542]
Reconfigure any SSH clients not to use weak ciphers like 3des-cbc or blowfish-cbc. DCNM uses SSH to manage Cisco devices and must be upgraded to at least Cisco NX-OS 7.2(1) to work with devices with this fix.
|
|
Last Modified: | 20-MAY-2016 |
|
Known Affected Releases: | 5.2(8g)S8, 6.2(10)S102, 6.2(13)S17, 6.2(2)S27 |
|
Known Fixed Releases: | 5.2(8g), 5.2(8g)S9, 6.2(11c), 6.2(11c)S7, 6.2(13)FM(0.66), 6.2(13.1)S0, 7.0(0)BZ(0.46), 7.0(0)HSK(0.357), 7.0(0)KM(0.110), 7.1(0)AV(0.38) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuj88841 | Title: | Corrective actions on GOLD failure |
|
Status: | Fixed |
|
Severity: | 6 Enhancement |
Description: | Symptom:
Gold component needs to take corrective action depending on cu topology to give them advantage of redundancy.
This is an enhancement to code we are making.
Conditions:
n/a
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 19-MAY-2016 |
|
Known Affected Releases: * | 5.2(7), 5.2(9), 6.0(4), 6.1(3), 6.2(2.2) |
|
Known Fixed Releases: | 6.2(0)HS(0.10), 6.2(7.5)S0, 6.2(7.7)S0, 6.2(8), 6.2(8)FM(0.16), 6.2(8)FM(0.17), 6.2(9)FM(0.37) |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz58243 | Title: | OTV - Allow per VLAN Unknown Unicast flood across OTV |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:Connectivity issues due to host MAC's not constantly refreshed on OTV ED's based on traffic flows.
Conditions:Upon Firewall or other L3 Gateway failover to other DC.
Workaround:Do not allow MAC's to timeout on OTV ED's. Either by ensuring some broadcast is sent from such hosts in the VLAN or disabling MAC aging on OTV ED's (MAC table then needs to be sanitized periodically to avoid hitting the limit)
Selective flood knob is available since 6.2:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/otv/command/reference/nxos_otv_cr/basics_otv_cmds.html#pgfId-1236972
More Info:OTV by design does not allow flood and learn. If local MAC is not present on OTV Edge locally, traffic from other DC will never reach such hosts across Overlay.
This is an enhancement request to explore a possibility to have per VLAN flood option for Unknown Unicast to flow across Overlay.
|
|
Last Modified: | 10-MAY-2016 |
|
Known Affected Releases: | 6.2(12) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz88051 | Title: | Netflow debug Infra |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Symptom:
FPL Code in BFD has good Debug Infra to Print the Buffers,
Similar Functionality in Netflow for M3 and F3 Needed.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 31-MAY-2016 |
|
Known Affected Releases: | 7.3(1)DX(0.5) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuz35151 | Title: | M3 infra: ASCII replay with Booting modules can be unpredicatable |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Multiple Cores/ Modules powered down/ Unstable system
Conditions:
ASCII replay was started before Brabham modules Boot up completely
Workaround:
Wait Brabham Modules to boot up completely before do ASCII replay.
Further Problem Description:
|
|
Last Modified: | 02-MAY-2016 |
|
Known Affected Releases: | 7.3(0)DX(1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuz54423 | Title: | MDS 9700 enhancement to handle FR credited packet CRC errors on sup |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: | Enhancement
Symptom:
If incorrectly formatted frames arrive at the supervisor, the supervisor can run out of credits and the entire switch will effectively stop all FC traffic. This is an enhancement request to have the switch detect this condition automatically and take appropriate recovery actions.
Conditions:
Occurs only on MDS 9700 switches.
Workaround:
system switchover will normally recover from the situation.
Further Problem Description:
show hardware internal errors
EB egress credited FR drops
EB INT CREDIT FRAME DROP DUE TO EGRESS REWRITE BUFFER FULL
Credited packet drop
Resolution Summary:
To be determined once resolved.
|
|
Last Modified: | 06-MAY-2016 |
|
Known Affected Releases: | 6.2(13) |
|
Known Fixed Releases: | |
|
|
| |
:
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论