Troubleshooting practice questions

Loss of redundancy on the fabric interconnect

Why wrong: Driver version does not affect fabric interconnect redundancy.

Inability to boot the server

Why wrong: A non-recommended driver may still allow boot, but performance could suffer.

Increased security vulnerabilities

Why wrong: Security vulnerabilities are possible but not the most likely impact of a non-recommended driver.

High CRC errors on the link.

Why wrong: CRC errors are input errors, not output discards.

Insufficient bandwidth due to latency.

Why wrong: Latency can cause buffer credit starvation, but the direct cause is lack of credits.

Mismatched zone configurations.

Why wrong: Zoning mismatch prevents communication, but does not cause output discards.

Dynamic ARP Inspection (DAI)

Why wrong: DAI validates ARP packets, not DHCP.

Control Plane Policing (CoPP) dropping DHCP packets

Why wrong: CoPP might drop if rate-limited, but DHCP is typically not rate-limited aggressively.

Port security with maximum MAC limit

Why wrong: Port security limits MACs but does not block DHCP.

The VRF is not correctly associated with the EPGs.

Why wrong: EPGs are in the same VRF, so routing is fine.

A Layer 3 Outside (L3Out) is required for communication between EPGs in the same VRF.

Why wrong: L3Out is for external connectivity, not internal EPG communication.

The filter 'mysql' does not match TCP port 3306.

Why wrong: The filter likely matches 3306, given it's named mysql.

STP root guard setting

Why wrong: Root guard is not a consistency check parameter.

MTU size

Why wrong: MTU is not part of vPC consistency checks.

Spanning-tree port type

Why wrong: Port type can differ; consistency checks focus on VLAN and interface parameters.

The vNIC placement policy is set to fabric failover.

Why wrong: vNIC placement is for network, not SAN boot.

The QoS policy is applied to the vHBA.

Why wrong: QoS is not a requirement for boot from SAN.

The server has a local disk installed.

Why wrong: Local disk is not required for SAN boot.

The host is using an incorrect FCID

Why wrong: FCID assignment is automatic; this is not the likely cause.

The VSAN mismatch between edge and core switches

Why wrong: A VSAN mismatch would prevent communication, but the symptom is missing WWPN in name server.

The zone set is not activated on the edge switch

Why wrong: Zone set activation is required but does not explain the missing WWPN in core's name server.

API rate limiting has been exceeded

Why wrong: Rate limiting returns 429 Too Many Requests.

Network connectivity issue between the script and the switch

Why wrong: Connectivity issues would result in timeouts or connection refused errors.

The user account does not have admin privileges

Why wrong: Insufficient privileges would return 403 Forbidden.

show processes cpu history

Why wrong: This command shows historical CPU usage data, not the current top consuming processes.

show system resources

Why wrong: This command shows overall CPU and memory utilization, but does not break down by process.

show cpu usage

Why wrong: This is not a valid command on Cisco Nexus switches.

Enable 'feature netstack' to get more details.

Why wrong: No such feature exists.

Reboot the switch to clear the process.

Why wrong: Rebooting is not a troubleshooting step and may cause downtime.

Check for broadcast storms using 'show interface'.

Why wrong: Broadcast storms can cause CPU issues but netstack may be from other causes.

Server firmware mismatch

Why wrong: Firmware mismatch might cause issues but is less specific to SAN boot failure.

Missing vNIC template

Why wrong: vNIC templates define Ethernet connectivity; not directly related to SAN boot.

VLAN mismatch

Why wrong: VLAN mismatch affects network connectivity, not SAN boot.

Hold timer mismatch

Why wrong: Hold timer mismatch causes adjacency to go down, not stuck in EXSTART.

Incorrect area ID

Why wrong: Area ID mismatch prevents neighbor discovery, not EXSTART.

Duplicate router ID

Why wrong: Duplicate router IDs prevent adjacency formation entirely, not just EXSTART.

Verify that the multicast group for BUM traffic is reachable.

Why wrong: Multicast group reachability is only required for BUM traffic, not unicast forwarding.

Verify that the VXLAN tunnel endpoint IP addresses are in the same subnet.

Why wrong: VTEP IPs can be on different subnets as long as underlay routing exists.

Verify that the VXLAN routing table is populated correctly.

Why wrong: VXLAN is a Layer 2 overlay; routing is not directly involved in forwarding within the same VNI.

NVE interface not enabled

Why wrong: NVE interface is needed for data plane, not control plane.

Incorrect VNI configuration

Why wrong: VNI mismatch would affect traffic but not BGP route learning.

MTU mismatch on the underlay

Why wrong: MTU could cause packet drops but not specific to EVPN routes.

Review logs first, then check physical connections, then verify interface status, then check VSAN and zoning, then perform FLOGI verification

Why wrong: Reviewing logs should be the final step after all other checks, as logs may contain errors from earlier layers but are not the starting point for troubleshooting a link not coming up.

Check VSAN and zoning first, then verify interface status, then check physical connections, then perform FLOGI verification, then review logs

Why wrong: Starting with VSAN and zoning skips physical and interface checks, which are more fundamental; a link cannot come up if the physical layer is faulty, regardless of zoning configuration.

Perform FLOGI verification first, then check physical connections, then verify interface status, then check VSAN and zoning, then review logs

Why wrong: FLOGI verification should occur after ensuring the physical link and interface are operational and VSAN/zoning are correct; doing it first risks misinterpreting results due to underlying issues.

Disable CoPP globally to allow all control-plane traffic.

Why wrong: Disabling CoPP removes protection against DoS attacks.

Modify the class-map to reclassify the dropped packets to a higher priority class.

Why wrong: Reclassification may starve other traffic and is not a direct fix.

Increase the ingress buffer size on the control-plane interface.

Why wrong: Buffering only delays drops, does not solve policer drops.

Congestion on the target port

Why wrong: Target port congestion would likely show other signs like high latency, not BB_Credit zero.

High link error rates

Why wrong: Link errors would show CRC or other error counters, not BB_Credit utilization.

Incorrect zoning configuration

Why wrong: Zoning affects connectivity, not throughput on a working link.

The port LED firmware is corrupted.

Why wrong: This is unlikely; LED behavior is simple.

The interface is administratively down.

Why wrong: The interface is up/up, so it is not admin down.

The SFP is faulty.

Why wrong: A faulty SFP would cause the interface to be down.

Jumbo frames are disabled on the switch ports

Why wrong: Jumbo frames are required for FCoE, but disabling them would cause different errors.

The FCoE VLAN is not trunked to the storage array

Why wrong: Missing VLAN trunking would cause no connectivity, not buffer drops.

FIP snooping is not enabled on the FCoE VLAN

Why wrong: FIP snooping prevents unauthorized FCoE devices, doesn't cause buffer drops.

The overlay VNI is not mapped to a VLAN

Why wrong: If VNI is not mapped to a VLAN, Type-3 routes would also not appear for that VNI (but Type-3 may be seen for other VNIs).

The BGP neighbor is not from the same AS

Why wrong: BGP neighbor AS mismatch would prevent all route exchange, including Type-3.

The EVPN address-family is not enabled

Why wrong: If EVPN address-family were not enabled, no EVPN routes (including Type-3) would be seen.