Description: * | Symptom:
Nexus 3132/3172 switches (T2-based switches) may experience an incorrect soft parity error recovery that can result in packet loss for one or more affected traffic flows. This is the result of a Broadcom SDK defect impacting Software Error Recovery (SER) functionality, which automates the recovery of soft memory parity errors. Known affected memory tables are the L2_ENTRY and L3 LPM tables. Software releases prior to 6.0(2)U3(4) may also experience an unexpected reload due to plog_sup process crash.
A syslog message with the following format is associated with incorrect parity error recovery and can be used to identify the presence of this defect on a device (though there are certain conditions where this defect can be triggered without generation of such as syslog event):
%USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb_log:: slot_num 0, event , memory error type: (0xaddress), table name: (), index: - bcm_usd
Sample messages:
%USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb_log:805: slot_num 0, event 2, memory error type: Correction(0x5), table name: L2 table(0x7d6), index: 62432 bcm_usd
%USER-3-SYSTEM_MSG: bcm_usd_isr_switch_event_cb_log_new_fmt:805: slot_num 0, event 2, memory error type: Correction(0x9), table name: L3 LPM table(0x7fe), index: 2685
Conditions:
Nexus 3132/3172 switches (T2-based switches)
Workaround:
1) reload should recover from the condition temporarily.
2) Software upgrade.
Further Problem Description:
|
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(1) | |
Known Fixed Releases: | 6.0(2)A4(3.41), 6.0(2)A4(3.42), 6.0(2)A4(4), 6.0(2)U4(3.41), 6.0(2)U4(3.42), 6.0(2)U4(4), 6.0(2)U5(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCus43770 | Title: | BSR RP information lost for more than 67 group | |
Status: | Fixed | |
Severity: | 2 Severe | Description: | Symptom:
When we have a RP for 67 multicast group we see RP information for all of these one . When we add 68 group rest of 67 group RP information is lost
Conditions:
issue occurs only when there are more than 67 groups .
Workaround:
NA
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 7.2(0)VX(0.60) | |
Known Fixed Releases: * | 6.0(2)A6(0.62), 6.0(2)A6(1), 6.0(2)U6(0.62), 6.0(2)U6(1), 7.0(3)F1(0.168), 7.0(3)I2(1.66), 7.0(3)I2(2), 7.0(3)I3(0.153), 7.0(3)I3(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux68642 | Title: * | LH 1G transceiver is not coming up in 7.0(3)I2(2.70) | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptom:
When front portmode is changed to sfp plus and we insert a 1g fiber sfp the link stays in not connected state
Conditions:
When customer tries to use the sfp plus ports on 3132 boxes with 1g fiber sfps after running speed 1000 command
Workaround:
none
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(2.34) | |
Known Fixed Releases: | 7.0(3)I2(2.78), 7.0(3)I2(3) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuv29193 | Title: | ECMP route installed with single NH in certain scenario | |
Status: | Fixed | |
Severity: | 2 Severe | Description: | Symptom:
In certain conditions a prefix that is ECMP is installed with single NH
Conditions:
This is seen in the following conditions
ECMP table usage crosses and comes below maximum group usage (64)
There are 16 SVI over which ECMP adjacencies are learnt
These 16 SVI ride on a single physical link
All 16 SVI are flapped aggressively
Workaround:
Clear the entire v4 and v6 routing table
Further Problem Description:
| |
Last Modified: | 28-JAN-2016 | |
Known Affected Releases: * | 6.0(2)U6(1), 6.0(2)U6(1.72) | |
Known Fixed Releases: | 6.0(2)A6(3.74), 6.0(2)A6(4), 6.0(2)U3(7.106), 6.0(2)U3(8), 6.0(2)U3(9), 6.0(2)U6(1.74), 6.0(2)U6(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux98881 | Title: | Neptune: packet loss due to runts and CRC errors after reload or upgrade | |
Status: | Open | |
Severity: | 2 Severe | Description: * | Symptom:
Packet loss due to runts and CRC errors after reload or upgrade. BGP Keepalives are dropped, causing route churn and trafficis black holed.
Conditions:
When a 3132 running 6.0(2)U6(4) is connected to another 3132 running 6.0(2)U3(3) . Triggers on normal reload or regular Upgrade to 6.0(2)U3(4) and above. Takes about 3 to 4 reloads to trigger the issue.
Not applicable to Fast-reload cases
Workaround:
Workaround:
Admin shut and unshut the ports
Preventive methods:
1) Move ports to "shut" mode on connected peer switchs running 6.0(2)U3(3) and below.
2) After upgrade or regular reload is fully complete, unshut the ports on peer switches
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(2), 6.0(2)U3(8), 6.0(2)U5(3), 6.0(2)U6(4) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCux99853 | Title: | bcm_usd service crash | |
Status: | Other | |
Severity: | 2 Severe | Description: | Symptom:
A Nexus3000 switch may reload unexpectedly, a bcm_usd core will be generated.
`show cores`
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
1 1 1 bcm_usd 1234
Conditions:
Unknown
Workaround:
Unknown
Further Problem Description:
| |
Last Modified: | 27-JAN-2016 | |
Known Affected Releases: | 7.0(3)I1(1.251) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuu78074 | Title: * | Cisco Nexus 3000 / Nexus 9000 ARP Denial of Service (DoS) Vulnerability | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptoms:
A vulnerability in the Address Resolution Protocol (ARP) input packet
processing of the Cisco Nexus Operating System (NX-OS) devices
unauthenticated, adjacent attacker to cause a denial of service (DoS)
condition.
The vulnerability is due to improper input validation of the ARP packet and
the Maximum Transmission Unit (MTU) size which results in a buffer overflow
which can cause the DoS condition. An attacker could exploit this vulnerability
by sending a crafted ARP packet to the device. An exploit could allow the attacker
to cause the device to be unavailable due to a DoS condition of the ARP module.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
The MTU size should be configured lower.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C&version=2.0
CVE ID CVE-2015-4323 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
| |
Last Modified: | 16-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(0.373), 7.3(0)ZN(0.9) | |
Known Fixed Releases: | 7.0(3)I1(2.15), 7.0(3)I1(3), 7.0(3)I2(0.377), 7.0(3)I2(1), 7.0(3)ITI2(1), 7.0(3)ITI2(1.36), 8.3(0)CV(0.72) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCui63140 | Title: | Duplicates seen when IIF for (S,G) is different from that of (*,G) | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptom:
Duplicate multicast traffic seen periodically in a network with N3K platform.
Conditions:
In a network with N3K where (S,G) and (*,G) entries have different incoming interface, if multicast traffic comes down the (*,G) tree, the traffic wont be dropped, instead will be forwarded out all the interfaces in the OIFL of (*,G) entry.
Workaround:
Use the 'hardware profile multicast prefer-source-tree eternity' command to drop any traffic coming in on the (*,G) incoming interface, a new 'limit ' is added to this CLI to specify the number of (S,G)s for which this duplication should be prevented.
Further Problem Description:
| |
Last Modified: | 14-JAN-2016 | |
Known Affected Releases: | 6.0(2)U1(1.122) | |
Known Fixed Releases: | 6.0(2)A2(1), 6.0(2)U1(2), 6.0(2)U2(1), 6.0(2)U3(0.22), 6.0(2)U3(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCun82427 | Title: | Nexus 3000: Multicast feed not flooded out mrouter port to PIM DR | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptom:
A multicast source feed is received on a Nexus 3000 from a directly connected server does not get flooded out the mrouter port to the PIM-DR. It gets silently dropped.
Conditions:
Issue occurs when the mrouter port is a port channel with "hardware multicast hw-hash" added under the interface config and the switch is then upgraded to 6.0(2)U2(2). After the upgrade that line will be missing from the running config.
Workaround:
Workaround 1:
- Remove "hardware multicast hw-hash" from all port-channels prior to upgrade
- After upgrade is complete re-add "hardware multicast hw-hash" back to all port channels
Workaround 2:
If the upgrade is performed without removing "hardware multicast hw-hash" follow these steps:
- backup the config
- erase the config (write erase and reload)
- re-apply the config
- add "hardware multicast hw-hash" back to the port channels
Workaround 3:
If the upgrade is performed without removing "hardware multicast hw-hash" follow these steps:
- Roll back to 5.0(3)U3(X)
- Remove "hardware multicast hw-hash"
- Save config
- Upgrade to 6.0(2)U2(2)
- Add "hardware multicast hw-hash" back to the port channels after upgrade
Workaround 4:
The "multicast hardware hw-hash" command is not needed in Nexus 3000/3100/3500 platforms as the hardware hashing is done by default and please do NOT use this command.
Further Problem Description:
Refer CSCuo24740 where change in documentation is requested.
| |
Last Modified: | 14-JAN-2016 | |
Known Affected Releases: | 6.0(2)U2(2) | |
Known Fixed Releases: | 6.0(2)U3(0.685), 6.0(2)U3(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux33013 | Title: | Nexus 3k crash with "mtc_usd hap reset". | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptom:
Device can crash with "mtc_usd hap reset" as interrupt for virtual-time rate shaping is triggered.
Conditions:
Suspicious control plane traffic is flooded to mgmt0 interface.
Workaround:
Potential Workarounds:
- disconnect mgmt0 interface.
- find the source of excessive PDUs that are flooded to mgmt0 interface.
Further Problem Description:
| |
Last Modified: | 13-JAN-2016 | |
Known Affected Releases: | 6.0(2)A7(1) | |
Known Fixed Releases: | 6.0(2)A6(5.187), 6.0(2)A6(5.188), 6.0(2)A6(6), 6.0(2)A7(0.17), 6.0(2)A7(1), 6.0(2)U7(0.17), 6.0(2)U7(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCut86141 | Title: | SFP-H10GB-CU2.255M, hardware type changed to No-Transceiver on N3k | |
Status: | Fixed | |
Severity: | 2 Severe | Description: * | Symptom:
SFP not detected on the ports. The same SFP works on other ports
Conditions:
interface remain down with following error
%ETHPORT-5-IF_HARDWARE: Interface Ethernet1/30, hardware type changed to No-Transceiver
in the bcm_shell interface shows FAUTL remote
bcm-shell.0> port 8
PORT: Status (* indicates PHY link up)
xe7 LS(SW) Forced(10GFD) STP(Disable) Lrn(ARL,FWD) UtPri(0) Pfm(FloodNone) IF(SFI) Max_frame(1518) MDIX(ForcedNormal, Normal) Medium(Copper) Fault(Remote) VLANFILTER(3)
Workaround:
power drain of the switch seems to be recovering the issue some times
Further Problem Description:
In the problem state it seems that the driver is saturated due to larger value of idrv, predrv SI values. Updating the new set of SI setting solves the issue.
| |
Last Modified: | 12-JAN-2016 | |
Known Affected Releases: | 6.0(2)U5(0.37) | |
Known Fixed Releases: | 6.0(2)A6(2.45), 6.0(2)A6(2.61), 6.0(2)A6(3), 6.0(2)A6(3.76), 6.0(2)A6(4), 6.0(2)U6(1.45), 6.0(2)U6(1.61), 6.0(2)U6(1.76), 6.0(2)U6(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuv48722 | Title: | 3048T : After upgrade to 6.0(2)U3(8), 100 M links are down. | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
100 m links stay down after upgrade to 6.0(2)U3(8).
Conditions:
100 M links peer configured in HD
Workaround:
configure AN and set the speed or set the other end of the peer with FD
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(7.99) | |
Known Fixed Releases: * | 6.0(2)A6(5), 6.0(2)U6(3.123), 6.0(2)U6(4), 7.0(3)F1(0.168), 7.0(3)I2(1.82), 7.0(3)I2(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux89481 | Title: | Removed FRUs are not listed as absent or not-present in N3K comp to N5K | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
When customer removes one of the powersupplies show environment power will not display any information about that powersupply. Ideally it should display that the powersupply is absent.
Conditions:
remove one of the power supplies
Workaround:
none
Further Problem Description:
With this fix the cli will display that the power supply is absent
| |
Last Modified: | 31-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(2.70) | |
Known Fixed Releases: | 7.0(3)I2(2.75), 7.0(3)I2(3), 7.0(3)I3(0.281), 7.0(3)I3(1) | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCux87710 | Title: | NX-OS 3500 Distributed reflective denial-of-service vulnerability NTP | |
Status: | Open | |
Severity: | 3 Moderate | Description: | Symptom:
A vulnerability in Network Time Protocol (NTP) package of Cisco NX-OS Software and Cisco Multilayer Director Switch (MDS) could allow an unauthenticated, remote attacker to
cause a Denial of Service (DoS) condition on an affected device.
The vulnerability is due to processing of MODE_PRIVATE (Mode 7) NTP control messages which have a large amplification vector. An attacker could exploit this vulnerability by
sending Mode 7 control requests to NTP servers and observing responses amplified up to 5500 times in size. An exploit could allow the attacker to cause a Denial of Service (DoS)
condition where the affected NTP server is forced to process and respond with large response data.
Conditions:
This is a day 1 issue and all versions of NX-OS and MDS with support for NTP are vulnerable.
Fixed Software:
This bug will apply to the Cisco Nexus 7000 (N7K), Cisco Nexus 6000 (N6K), Cisco Nexus 5000 (N5K)
and Cisco Multilayer Director Switch (MDS) and the fix is currently targeted for a release towards the end of
CY2015.
Cisco NX-OS Software and Cisco MDS switches are vulnerable to attacks utilizing Mode 7 NTP requests. Mode 7 requests can have amplification vector up to 5500.
To see if a device is configured with NTP, log into the device and issue the CLI command
''show running-config | include ntp''. If the output returns either of the following commands
listed then the device is vulnerable:
ntp master
ntp peer
ntp server
ntp broadcast client
ntp multicast client
For a Cisco MDS switch to confirm the NTP feature is disabled:
# show running-config | include ''no feature ntp
no feature ntp
Information about Cisco NX-OS and MDS Software release naming conventions is available in
''White Paper: Cisco IOS and NX-OS Software Reference Guide'' at the following link:
http://www.cisco.com/web/about/security/intelligence/ios-ref.html
Workaround:
There are no solid workarounds other than disabling NTP on the device via the ''no feature ntp'' command. The following mitigations have been identified for this vulnerability; only
packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability.
Note: NTP peer authentication is not a workaround and is still a vulnerable configuration.
* NTP Access Group
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender's IP address, which may defeat access control lists (ACLs) that permit communication to these ports
from trusted IP addresses. Unicast Reverse Path Forwarding (Unicast RPF) should be considered to be used in conjunction to offer a better mitigation solution.
Additionally, ''serve-only'' keyword added to the NTP access-group will limit the exposure of the server to
only respond to valid queries.
Note: NTP Access Group groups are not supported by the Cisco MDS switch.
For additional information on NTP access control groups, consult the document titled ''Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 4.x'' at
the following link:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_3ntp.html
* Infrastructure Access Control Lists
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender
| |
Last Modified: | 19-JAN-2016 | |
Known Affected Releases: | 7.3(0)ZN(0.98) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuw20837 | Title: | PO delete fails with "port-channel membership is being updated" error | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
Po delete attempt fails with error "failed to delete port-channel1: port-channel membership is being updated"
Conditions:
1) When one of the member port is in "suspended" state. AND 2) po members belong to 2 separate channel groups OR 3) PO is connect to 2 separate switches
Workaround:
Remove the member port in 'S' state before deleting the PO
Further Problem Description:
Allowed deletion of port-channel members in Suspended state also
| |
Last Modified: | 22-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(5.95) | |
Known Fixed Releases: * | 6.0(2)A6(5.209), 6.0(2)A6(6), 6.0(2)U6(5.209), 6.0(2)U6(6) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuv95675 | Title: | Fast-reload upgrade from U6 to Camden delayed in applying qos config | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
On N3064 device when executing a fast-reload upgrade from U6 to Camden, the network qos config gets delayed in being applied which causes long convergence time.
Conditions:
On N3064 device when executing a fast-reload upgrade from U6 to Camden, the network qos config gets delayed in being applied which causes long convergence time.
Workaround:
None
Further Problem Description:
| |
Last Modified: | 26-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(0.580), 7.0(3)I2(1) | |
Known Fixed Releases: * | 7.0(3)I2(0.596), 7.0(3)I2(0.597), 7.0(3)I2(1), 7.0(3)IMK2(1), 7.0(3)IMK2(1.65), 7.0(3)ITI2(1), 7.0(3)ITI2(1.37), 8.3(0)CV(0.248), 8.3(0)KMS(0.31) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuw40975 | Title: | GRE tunnel terminating on N3K drops OSPF packets with ttl not 1 in hw | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
Establishing an OSPF neighbor over a tunnel interface terminating on a Nexus 3100 switch will fail if the sending device is transmitting the OSPF packets with a TTL value greater than 1.
These OSPF packets will be dropped in hardware and not sent to the cpu for further processing.
Conditions:
The GRE tunnel must be terminating on the Nexus 3100 switch, and the GRE payload must be an ip OSPF packet with the TTL set to a value other than 1.
Workaround:
This configuration will work on other Cisco devices, however, RFC 2328 - OSPF Version 2 states the following:
Use of IP multicast. Some OSPF messages are multicast, when
sent over broadcast networks. Two distinct IP multicast
addresses are used. Packets sent to these multicast addresses
should never be forwarded; they are meant to travel a single hop
only. To ensure that these packets will not travel multiple
hops, their IP TTL must be set to 1.
The only workaround is to correct the OSPF implementation on the sending device.
Further Problem Description:
| |
Last Modified: | 26-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(1) | |
Known Fixed Releases: * | 7.0(3)I2(2.60), 7.0(3)I2(3), 7.0(3)I3(0.141), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.10) | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCux99069 | Title: | No syslog messages for DOM thresholds overrruns | |
Status: | Open | |
Severity: | 3 Moderate | Description: | Symptom:
You can observe persistent FCS-err on eth interface in case of significant optical attenuation. Despite DOM is able to detect the high/low threshold overruns, it will not generate a message to syslog:
show interface e1/52 counters errors
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/52 0 51 0 51 0 0
--------------------------------------------------------------------------------
Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts
--------------------------------------------------------------------------------
Eth1/52 0 0 0 0 0 0
--------------------------------------------------------------------------------
Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err
--------------------------------------------------------------------------------
Eth1/52 0 -- 0 0 0 0
Conditions:
show interface e1/52 transceiver details
Ethernet1/52
transceiver is present
type is 10Gbase-LR
name is CISCO-FINISAR
part number is FTLX1474D3BCL-C1
revision is A
serial number is FNS18120RW4
nominal bitrate is 10300 MBit/sec
Link length supported for 9/125um fiber is 10 km
cisco id is --
cisco extended id number is 4
SFP Detail Diagnostics Information (internal calibration)
----------------------------------------------------------------------------
Current Alarms Warnings
Measurement High Low High Low
----------------------------------------------------------------------------
Temperature 23.68 C 75.00 C -5.00 C 70.00 C 0.00 C
Voltage 3.27 V 3.63 V 2.97 V 3.46 V 3.13 V
Current 38.19 mA 70.00 mA 1.00 mA 68.00 mA 2.00 mA
Tx Power -2.22 dBm 3.49 dBm -12.21 dBm 0.49 dBm -8.21 dBm
Rx Power -20.00 dBm -- 3.49 dBm -18.53 dBm 0.49 dBm -14.43 dBm
----------------------------------------------------------------------------
Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
Workaround:
NONE
Only manual monitoring of DOM statistics through the "show interface <> transceiver details"
Further Problem Description:
show logging logfile
2015 Aug 13 16:47:33 sh122-mgt-a1 %SYSLOG-1-SYSTEM_MSG : Logging logfile (log.text) cleared by user
2015 Aug 13 16:50:20 sh122-mgt-a1 %ETHPORT-5-IF_ADMIN_UP: Interface Ethernet1/52 is admin up .
2015 Aug 13 16:50:21 sh122-mgt-a1 %ETHPORT-5-SPEED: Interface Ethernet1/52, operational speed changed to 10 Gbps
2015 Aug 13 16:50:21 sh122-mgt-a1 %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/52, operational duplex mode changed to Full
2015 Aug 13 16:50:21 sh122-mgt-a1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface Ethernet1/52, operational Receive Flow Control state changed to off
2015 Aug 13 16:50:21 sh122-mgt-a1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface Ethernet1/52, operational Transmit Flow Control state changed to off
2015 Aug 13 16:50:21 sh122-mgt-a1 %CDP-5-NEIGHBOR_ADDED: Device d42-mgt-c6.ftc.ru(FOC1837R1BS) discovered of type N3K-C3048TP-1GE with port Ethernet1/52 on incoming port Ethernet1/52 with ip addr 192.168.78.2
11 and mgmt ip 192.168.78.211
2015 Aug 13 16:50:24 sh122-mgt-a1 %ETH_PORT_CHANNEL-5-PORT_UP: port-channel3048: Ethernet1/52 is up<
| |
Last Modified: | 26-JAN-2016 | |
Known Affected Releases: | 6.2(5)MD | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux38660 | Title: | Encoder error on executing `show lldp neighbor | xml` | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
When running `show lldp neighbor | xml` or `show lldp neighbor | json` chassis may response with `encoder error` message
Conditions:
So far issue was observed on N3K-C3164PQ running 7.0(3)I1(2). Please note, other NX-OS version may also be affected.
Workaround:
As temporary workaround, you may use `show lldp neighbor detail | xml` or `show lldp neighbor detail | json`
Further Problem Description:
True cause is under investigation
| |
Last Modified: | 26-JAN-2016 | |
Known Affected Releases: | 7.0(3)I1(1.251) | |
Known Fixed Releases: * | 7.0(3)I2(2.55), 7.0(3)I2(3), 7.0(3)I3(0.191), 7.0(3)I3(0.192), 7.0(3)I3(1), 7.0(3)IAB3(0), 7.0(3)IAB3(0.53), 7.0(3)IDP3(1.62), 7.0(3)IDP3(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuv17837 | Title: * | NX-OS N3K Distributed reflective denial-of-service vulnerability NTP | |
Status: | Open | |
Severity: | 3 Moderate | Description: * | Symptom:
A vulnerability in Network Time Protocol (NTP) package of Cisco NX-OS Software and Cisco Multilayer Director Switch (MDS) could allow an unauthenticated, remote attacker to
cause a Denial of Service (DoS) condition on an affected device.
The vulnerability is due to processing of MODE_PRIVATE (Mode 7) NTP control messages which have a large amplification vector. An attacker could exploit this vulnerability by
sending Mode 7 control requests to NTP servers and observing responses amplified up to 5500 times in size. An exploit could allow the attacker to cause a Denial of Service (DoS)
condition where the affected NTP server is forced to process and respond with large response data.
Conditions:
This is a day 1 issue and all versions of NX-OS and MDS with support for NTP are vulnerable.
Fixed Software:
This bug will apply to the Cisco Nexus 7000 (N7K), Cisco Nexus 6000 (N6K), Cisco Nexus 5000 (N5K)
and Cisco Multilayer Director Switch (MDS) and the fix is currently targeted for a release towards the end of
CY2015.
Cisco NX-OS Software and Cisco MDS switches are vulnerable to attacks utilizing Mode 7 NTP requests. Mode 7 requests can have amplification vector up to 5500.
To see if a device is configured with NTP, log into the device and issue the CLI command
''show running-config | include ntp''. If the output returns either of the following commands
listed then the device is vulnerable:
ntp master
ntp peer
ntp server
ntp broadcast client
ntp multicast client
For a Cisco MDS switch to confirm the NTP feature is disabled:
# show running-config | include ''no feature ntp
no feature ntp
Information about Cisco NX-OS and MDS Software release naming conventions is available in
''White Paper: Cisco IOS and NX-OS Software Reference Guide'' at the following link:
http://www.cisco.com/web/about/security/intelligence/ios-ref.html
Workaround:
There are no solid workarounds other than disabling NTP on the device via the ''no feature ntp'' command. The following mitigations have been identified for this vulnerability; only
packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability.
Note: NTP peer authentication is not a workaround and is still a vulnerable configuration.
* NTP Access Group
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender's IP address, which may defeat access control lists (ACLs) that permit communication to these ports
from trusted IP addresses. Unicast Reverse Path Forwarding (Unicast RPF) should be considered to be used in conjunction to offer a better mitigation solution.
Additionally, ''serve-only'' keyword added to the NTP access-group will limit the exposure of the server to
only respond to valid queries.
Note: NTP Access Group groups are not supported by the Cisco MDS switch.
For additional information on NTP access control groups, consult the document titled ''Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 4.x'' at
the following link:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/system_management/configuration/guide/sm_3ntp.html
* Infrastructure Access Control Lists
Warning: Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the
sender
| |
Last Modified: | 18-JAN-2016 | |
Known Affected Releases: | 5.0(3)U5(1b) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCux75065 | Title: | N3K - Unable to remove flowcontrol config on interfaces | |
Status: | Open | |
Severity: | 3 Moderate | Description: | Symptom:
Box locks up often. All ports stop working but appear to be OK.
At a closer look, notice that the TX unicast counters do not increase on the interfaces we were testing with meaning we were not putting the packets in the line.
Conditions:
"flowcontrol receive on" configured
and/or "flowcontrol send on" configured.
Workaround:
Copy the running-config to bootflash. Export from bootflash, open with notepad++ or similar, and remove all the flowcontrol lines from the interfaces config. Write erase the box, then re-add the configurations after removing all flowcontrol config from the interfaces.
Further Problem Description:
| |
Last Modified: | 06-JAN-2016 | |
Known Affected Releases: | 6.0(2)U6(3.114) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuw02037 | Title: | Cisco NX-OS Malformed ARP Header Vulnerability | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
A vulnerability in Address Resolution Protocol (ARP) feature of the Cisco Nexus Operating System (NX-OS) could allow an
unauthenticated, adjacent attacker to cause a partial denial of service (DoS) condition due to the ARP process unexpectedly
restarting.
The vulnerability is due to improper input validation of the fields in the ARP packet header. An attacker could exploit this
vulnerability by sending a crafted ARP packet from an adjacent network to the affected device. An exploit could allow the
attacker to cause a partial DoS condition because the ARP process could unexpectedly restart when processing the
crafted ARP packet.
Conditions:
Device running with default configuration running an affected version of software.
Workaround:
None.
Further Problem Description:
None.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 6.1/5.8:
http://tools.cisco.com/security/center/cvssCalculator.x?vector=AV:A/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:U/RC:C&version=2.0
CVE ID CVE-2015-6277 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
| |
Last Modified: | 04-JAN-2016 | |
Known Affected Releases: | 7.3(0)ZD(0.47) | |
Known Fixed Releases: * | 6.0(2)A6(5.193), 6.0(2)A6(6), 6.0(2)A7(0.228), 6.0(2)A7(1), 6.0(2)U6(4.193), 6.0(2)U6(5), 6.0(2)U7(0.228), 6.0(2)U7(1) | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCuw17399 | Title: | EPMR8:N3K:Active optical cable does not show up transceiver details. | |
Status: | Open | |
Severity: | 3 Moderate | Description: | Symptom:
When you check the transceiver details after an active optical cable of length seven meters is connected from the Cisco UCS VIC 1387 adapter to a Nexus 3016Q switch, it fails to detect the QSFP type. When we check the transceiver details, it does not detect the QSFP type of connector.
Conditions:
Workaround:
None.
Further Problem Description:
| |
Last Modified: | 07-JAN-2016 | |
Known Affected Releases: | 5.0(3)U5(1g) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux40831 | Title: | Packets not sent out of interfaces when priority level config is applied | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
N3k might stop transmitting packets on some interfaces, during the issue the affected interfaces remain in "Up" state.
Conditions:
The issue might happen when priority level command is applied for 'qos-group 7' in global output queuing policy;
This issue is specific to 40G ports on N3172 switches
Workaround:
Remove priority level command from 'qos-group 7' and reload the device
Further Problem Description:
| |
Last Modified: | 07-JAN-2016 | |
Known Affected Releases: | 6.0(2)U5(2), 6.0(2)U6(1), 6.0(2)U6(4) | |
Known Fixed Releases: | 6.0(2)A6(5.184), 6.0(2)A6(6), 6.0(2)U6(4.184), 6.0(2)U6(5) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuj59318 | Title: | Show platform fwm info mac only logs the first and last operation | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
show platform info mac is supposed to log the last 35 operations for MAC address insertion or removal. The command only log the last operation and the first operation in Mac history. Below is a sample output:
N3K#show platform fwm inf mac EEEE.EEEE.EEEE 112:
mac vlan 1.112 mac EEEE.EEEE.EEEE: vlan 1.112
mac vlan 1.112 mac EEEE.EEEE.EEEE: learned-on Eth1/3 age 10 ref_map = 'vlan if' <--- last operation
mac vlan 1.112 mac EEEE.EEEE.EEEE: nohit_count 0 hw_programmed 1 mac_clone 1, hw
_leant 0
mac vlan 1.112 mac EEEE.EEEE.EEEE: clone from VLAN: 0
mac vlan 1.112 mac EEEE.EEEE.EEEE: old_if_index 'null'
mac vlan 1.112 mac EEEE.EEEE.EEEE: pss_flags 0
mac vlan 1.112 mac EEEE.EEEE.EEEE cfg attrs - not-cli-cfg not-static movable no-
drop no-regmac non-netstack-learnt not-secure not-src-drop
mac vlan 1.112 mac EEEE.EEEE.EEEE: mcec_flags 0x1, mac_info_flags 0, rem_if 0, s
ync_count 0 rcv_count 0
mac vlan 1.112 mac EEEE.EEEE.EEEE: CDCE Address 0:0:0:0:0:0
Mac history (Last 35 operations): <--- suppose to log the last 35 operations. Only one is logged
Total operations: 1:
Operation: Mac create (9)
(flags: Loc (0x1) mac_info_flags (0x200) if: 0x1a004000 hint: 0)
at Wed Oct 2 23:27:14 2013
N3K# sh interface snmp-ifindex | in 1a004000
Eth1/5 436224000 (0x1a004000)
Conditions:
this bug is verified exists in 6.0(2)U1(2)
Workaround:
None
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U1(2) | |
Known Fixed Releases: | 6.0(2)U2(0.30), 6.0(2)U2(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux05817 | Title: | CR4 cables are not displaying PID | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
CR4 cables not displaying PID QSFP-H40G-CUXM and displaying type as QSFP-40G-CR4
Conditions:
CR4 cables only
Workaround:
Added the pid for CR4 cable as QSFP-H40G-CUXM whose type is QSFP-40G-CR4. The pid information will be displayed in a new field called "Cisco product id" at the bottom.
Further Problem Description:
| |
Last Modified: | 27-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(1) | |
Known Fixed Releases: * | 7.0(3)I2(2.81), 7.0(3)I2(3) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCup42948 | Title: | IPv6 ping fail after configuring correct add in a duplicate add scenario | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
When we have same ipv6 address configured on both the SVIs (on either side of a L2 ether channel link) and then if we configure the correct ipv6 address on one side, ping6 fails.
this is seen if N3064 has 6.0(2)U3(1) or 6.0(2)U3(2) image
Conditions:
N3064 has the above images and SVIs are configured with duplicate IPv6 address and then the peer switch is configured with the correct ipv6 address
Workaround:
flap the SVI on the N3064 switch
Further Problem Description:
| |
Last Modified: | 28-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(1) | |
Known Fixed Releases: * | 6.0(2)U4(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuq83575 | Title: | Improve serviceability of message neutron_usd - failed to set mux addr | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
This is not a software bug. It is an enhancement request to improve the serviceability of the following error message:
%KERN-3-SYSTEM_MSG: [2654954.489403] neutron_usd - failed to set mux addr 0xYY ch Y err Y -
kernel
Conditions:
This bug applies to software up to 6.0(2)U3(3)
Workaround:
none
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(1) | |
Known Fixed Releases: * | 6.0(2)A5(1.38), 6.0(2)A5(2), 6.0(2)A6(1.90), 6.0(2)A6(2), 6.0(2)U5(1.38), 6.0(2)U5(2), 6.0(2)U6(0.90), 6.0(2)U6(1), 7.0(3)F1(0.168), 7.0(3)I2(1.69) | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCui93304 | Title: | Nexus 3000 Kernel NVRAM traces are not saved every time | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
Kernel NVRAM traces may not be saved following a kernel panic
Conditions:
Unknown
Workaround:
None
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 5.0(3)U3(2b) | |
Known Fixed Releases: | 6.0(2)U3(0.688), 6.0(2)U3(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux41329 | Title: | Evaluation of nexus-3500 for OpenSSL December 2015 vulnerabilities | |
Status: | Terminated | |
Severity: | 3 Moderate | Description: * | Symptom:
Cisco Nexus 3X00 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 Nexus 3X00 Series Switches is affected by:
CVE-2015-3195
Cisco Nexus 3X00 Series Switches is not affected by:
CVE-2015-3193, CVE-2015-3194, 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: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)A7(1) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuq59586 | Title: | back space hits 73rd character will "blank" out all characters | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
when entering long CLI command that exceeded 73 characters, if back space was used, when back space hits the 73rd character, all characters then disappeared from the command line.
Conditions:
CLI command exceeds 72 characters long and back space bar was used
Workaround:
set the terminal width to a bigger number. By default terminal width is set at 72. This can the set to a maximum number of 511.
BLR-SCL-QI2-28# terminal width ?
<24-511> Number of characters on a screen line
BLR-SCL-QI2-28# terminal width 511
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 5.0(3)U5(1h) | |
Known Fixed Releases: * | 6.0(2)A6(0.74), 6.0(2)A6(1), 6.0(2)U6(0.74), 6.0(2)U6(1), 7.0(3)F1(0.168), 7.0(3)I2(1.66), 7.0(3)I2(2), 7.0(3)I3(0.128), 7.0(3)I3(1), 7.0(3)IDP3(1.12) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuv56748 | Title: | N3172TQ - "no negotiation auto" fails to bring port in 100Mbps | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
N3172TQ switch may fail to bring port UP with speed 100Mbps when Auto negotiation is disabled.
Conditions:
linking N3172TQ port to a switch with speed/duplex hardcoded
Workaround:
Enabled Auto-negotiation on N3100 and restrict peer side to only negotiate at 100Mbps to have a successful connection. On Catalyst switches something like this is required:
speed auto 100
If connection is between two N3100 switches, then using this configuration will work:
speed 100
duplex full
negotiate auto
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U5(3.53) | |
Known Fixed Releases: * | 6.0(2)A6(4.119), 6.0(2)A6(5), 6.0(2)U6(3.119), 6.0(2)U6(4), 7.0(3)F1(0.168), 7.0(3)I2(1.82), 7.0(3)I2(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux74951 | Title: | cant read the bootflash from the switch(boot) prompt mode | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
switch(boot) prompt, dir command not listing contents.
Conditions:
when the switch enters in the switch(boot) prompt
Workaround:
None. Only way to see the dir contents is either go to the Loader>prompt or load NXOS image and check from NXOS prompt.
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 7.0(3)I2(3) | |
Known Fixed Releases: * | 7.0(3)I2(2.76), 7.0(3)I2(3), 7.0(3)I3(0.288), 7.0(3)I3(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuu69356 | Title: | VPC peer-link between Camden & Prev releases | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
For Cisco Nexus 3000 vPC topologies, a non-disruptive upgrade from Cisco NX-OS Release 6.0(2)U6(X) to 7.0(3)I2(1) is not supported as the upgrade will cause a traffic disruption. An upcoming maintenance release will support non-disruptive upgrades for vPC topologies.
Conditions:
For Cisco Nexus 3000 vPC topologies, a non-disruptive upgrade from Cisco NX-OS Release 6.0(2)U6(X) to 7.0(3)I2(1) is not supported as the upgrade will cause a traffic disruption. An upcoming maintenance release will support non-disruptive upgrades for vPC topologies.
Workaround:
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 7.3(0)ZN(0.14) | |
Known Fixed Releases: * | 6.0(2)A6(4.108), 6.0(2)A6(4.109), 6.0(2)A6(5), 6.0(2)U6(2.108), 6.0(2)U6(2.109), 6.0(2)U6(4), 7.0(3)F1(0.168), 7.0(3)I2(0.599), 7.0(3)I2(0.600), 7.0(3)I2(0.601) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux05949 | Title: | Multipath unmarked when an update with different AS_PATH is received | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
When BGP multipath is enabled only a single path is installed to a destination even though the multipath flag should be set. In other words, you will only see one path in the routing table even though there should be more then one paths. BGP table will show no paths marked with the multipath flag
Nexus-1# show ip bgp 10.8.67.0/24
Path type: external, path is valid, received and used AS-Path: 65000 65001 65002 , path sourced external to AS
10.10.10.1 (metric 0) from 10.1.1.1 (10.173.253.71)
Origin IGP, MED 0, localpref 100, weight 0
Path type: external, path is valid, received and used <== this path update, with different AS_PATH, triggered the unmarking of the other paths
AS-Path: 65000 65005 65002 , path sourced external to AS
10.10.10.2 (metric 0) from 10.1.1.2 (10.173.253.64)
Origin IGP, MED 0, localpref 100, weight 0
Path type: external, path is valid, received and used, is best path
AS-Path: 65000 65001 65002 , path sourced external to AS
10.10.10.3 (metric 0) from 10.1.1.3 (10.173.253.66)
Origin IGP, MED 0, localpref 100, weight 0
Conditions:
Issue occurs after a path is introduced with different AS_PATH as the best path but the same length.
Workaround:
Configure the following under the BGP process to avoid this issue.
bestpath as-path multipath-relax
Further Problem Description:
| |
Last Modified: | 12-JAN-2016 | |
Known Affected Releases: | 6.0(2)U4(5) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCup28346 | Title: | Increase Frequency of Hash Display in install all | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: | Symptom:
When upgrading a N3K from 6.0(2)U2(10Z) to 6.0(2)U3(5) using install all, it takes around 120 seconds to complete from
Verifying image type.
[########### ] 50%
to
Verifying image type.
[########### ] 100%
Conditions:
Upgrade a Nexus 3000 using install all command
Workaround:
Further Problem Description:
| |
Last Modified: | 29-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(2) | |
Known Fixed Releases: * | 6.0(2)A6(0.55), 6.0(2)A6(1), 6.0(2)U6(0.55), 6.0(2)U6(1), 7.0(3)F1(0.168), 7.0(3)I2(1.76), 7.0(3)I2(2) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuo31623 | Title: | SVI interface unreachable, if "management" feature configured | |
Status: | Fixed | |
Severity: | 3 Moderate | Description: * | Symptom:
When "management" feature configured for particular SVI interfaces, it may become unreachable.
Conditions:
SVI interface needs to be configured as "management":
# show running-config interface VlanABC
version 6.0(2)U1(1a)
interface VlanABC
no shutdown
management
ip address a.b.c.d/z
Workaround:
Remove "management" feature from the interface.
Further Problem Description:
N/A
| |
Last Modified: | 12-JAN-2016 | |
Known Affected Releases: | 6.0(2)U1(1a) | |
Known Fixed Releases: | 6.0(2)A3(0.15), 6.0(2)A3(1), 6.0(2)U3(0.15), 6.0(2)U3(1) | |
|
| | | | |
Alert Type: | New | Bug Id: | CSCus71682 | Title: | Two 10/100/1000-Mbps management ports (only mgmt0 functional) | |
Status: | Terminated | |
Severity: | 5 Cosmetic | Description: | Symptom:
On Nexus 3048/Nexus 3500 switches, online datasheets shows that it has two mgmt ports available. Data-sheet says 'Two 10/100/1000-Mbps management ports'
User can also see two mgmt ports on back side of the switch.
Conditions:
n/A
Workaround:
In reality , Only mgmt0 port is available to use. There are no plans to fix this issue as its HW limitation. Online information will be updated soon.
Further Problem Description:
| |
Last Modified: | 14-JAN-2016 | |
Known Affected Releases: | 6.0(2)U1(3) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCux37181 | Title: | N3k - wrong syslog when creating another user using tacacs+ | |
Status: | Open | |
Severity: | 5 Cosmetic | Description: * | Symptom:
"Secure password mode is enabled. Please use "change-passwd" CLI to change the password is printed by switch when user with network-operator role tries to create another new user
Conditions:
user with network-operator role logs into switch
Workaround:
none
Further Problem Description:
| |
Last Modified: | 14-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(4.92), 6.0(2)U4(5) | |
Known Fixed Releases: | | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCus11180 | Title: | N3K: Enable Copy File Start capabilities with Fast-Reload | |
Status: | Fixed | |
Severity: | 6 Enhancement | Description: | Symptom:
The "copy file start" command cannot be executed immediately before a fast-reload is instantiated.
This is known unsupported combination.
The data-plane will not meet the =<30 second outage windows originally required for the fast-reload outage window.
Conditions:
This issue occurs when the "copy file start" command right before executing "fast-reload"
Workaround:
Alternative configuration methods and/or sequences should be be used to prevent extended fast-reload downtimes.
Further Problem Description:
| |
Last Modified: | 28-JAN-2016 | |
Known Affected Releases: | 6.0(2)U5(1) | |
Known Fixed Releases: * | 6.0(2)U6(1) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCul19094 | Title: | Non-ECN capable behavior enhancement | |
Status: | Fixed | |
Severity: | 6 Enhancement | Description: * | Problem:
When ECN and non-ECN capable traffic is present on the same egress queue, non-ECN-capable traffic gets dropped on exceeding the MAX threshold configured.
Requirement:
Under low congestion / queue build scenario, allow low rate non-ECN capable traffic to go through without drops, even if the ECN thresholds are exceeded. To keep the solution generic for any traffic stream with ECN bits set, avoid a stream type based classification.
Symptom:
ECT = 0 packets are dropped based on WRED thresholds applied on ECN enabled traffic classes.
Conditions:
Packets having ECT=0 and classfied to traffic classes where ECN is enabled.
Workaround:
NA
Further Problem Description:
| |
Last Modified: | 12-JAN-2016 | |
Known Affected Releases: | 6.0(2)U2(1) | |
Known Fixed Releases: * | 7.0(3)IDP3(1.40), 7.0(3)IDP3(1.76), 7.0(3)IDP3(1.79), 7.0(3)IDP3(2), 7.0(3)ITM3(0), 7.0(3)ITM3(0.7) | |
|
| | | | |
Alert Type: | Updated * | Bug Id: | CSCuu91387 | Title: | PFC - Enable configurable actions when egress queue is stuck for no-drop | |
Status: | Fixed | |
Severity: | 6 Enhancement | Description: | Symptom:
PFC enhancement for stuck no-drop queue
Conditions:
Workaround:
Further Problem Description:
| |
Last Modified: | 26-JAN-2016 | |
Known Affected Releases: | 6.0(2)U3(7.99) | |
Known Fixed Releases: * | 7.0(3)IDP3(1.71), 7.0(3)IDP3(1.72), 7.0(3)IDP3(1.73), 7.0(3)IDP3(1.76), 7.0(3)IDP3(2), 7.0(3)ITM3(0), 7.0(3)ITM3(0.7) | |
|
| |
|
2015 Cisco and/or its affiliates. All rights reserved.
没有评论:
发表评论