Troubleshooting Cisco Data Center Infrastructure — Free Practice Questions
10 free sample questions from a bank of 194, with the correct answers and explanations. No signup required — start practising right now.
1An engineer troubleshoots a VXLAN EVPN data center. The applications in the data center fail to reach the DNS server that is located at IP 10.10.10.10. The engineer examines the BGP EVPN routing table and notes that the IP prefix route covers the DNS server is missing. Which action resolve the issue?
Set the IP prefix route to represent [5]:[0] :[0]:[32] :[10.10.10.10]/224 in the routing table.
Configure an IP ARP entry to represent [2]:[0] :[0]:[48] :[0050.569f.1285]:[32] :[10.10.10.10]/272 in the routing table
Set the IP prefix route to represent [2]:[0] :[0]:[48] :[0050.569f.1285]:[0] :[0.0.0.0]/216 in the routing table
Configure an IP ARP entry to represent [4]:[0300.0000.00fc.bd00.0309l[32] :[10.10.10.10]/136,n the routing table
Answer: A
The short version
A — Missing Type-5 prefix route is the DNS reachability blocker. Without the EVPN IP prefix route for 10.10.10.10, remote VTEPs have no L3 route to the DNS server, so adding the Type-5 route restores reachability.
Key concepts in this question
EVPN Type-5 route: IP prefix route used for inter-subnet and external prefix advertisement in VXLAN EVPN fabrics.
EVPN Type-2 route: MAC plus IP host route used for ARP suppression and host mobility, not subnet prefix distribution.
BGP EVPN control plane: VTEPs learn remote prefixes only when the correct route type is originated and imported.
Why A is correct
The engineer confirmed the IP prefix route covering the DNS server is missing. A Type-5 route carries prefix length and prefix, and the value shown encodes a /32 host prefix for 10.10.10.10. Originating or restoring that Type-5 route gives every remote VTEP an L3 forwarding entry toward the DNS server, which directly fixes the application failure.
Why the others are wrong
B. A Type-2 entry advertises a host MAC-to-IP binding for ARP suppression, not a routable IP prefix, so it does not replace a missing Type-5 prefix.
C. A Type-2 entry pointing at 0.0.0.0 is a MAC-only or default construct, not the specific DNS host prefix needed here.
D. The garbled Type-4 style entry relates to Ethernet segment election for multihoming, not IP prefix reachability for a server address.
300-615 exam tip — memory hook
Type 2 = host MAC+IP, Type 5 = prefix; no prefix route means no L3 reachability across the EVPN fabric.
2Refer to the exhibit. A network engineer must use BGP to route IPv4 and IPv6 routes between R1 and R2.The IPv4 addresses are exchanged as expected between the routers through BGP. The routers have reached an Established BGP state. However, the IPv6 routes from R2 fail to show in the routing table of R1. Which action resolves the issue?
Create a route map that sets the IPv6 next hop.
Advertise L2VPN EVPN under IPv4 unicast address family
Configure an IPv6 BGP neighbor on R1
Enable IPv6 routing on R1
Answer: A
The short version
A — IPv6 routes need a usable IPv6 next hop to be installed. When IPv6 prefixes are carried over an IPv4 BGP session, a route-map that sets the IPv6 next hop makes the received routes installable in R1's routing table.
Key concepts in this question
Multiprotocol BGP: IPv4 and IPv6 unicast families are negotiated and populated separately even over one Established session.
NEXT_HOP reachability: a BGP route is not installed or used unless its next hop is reachable through the local routing table.
Extended next-hop capability: IPv6 NLRI carried over IPv4 peering can arrive with an IPv4-mapped next hop that the IPv6 RIB cannot resolve.
Why A is correct
IPv4 routes exchange normally and the session is Established, so peering and the IPv4 family are healthy. The isolated IPv6 RIB failure is the classic symptom of an unresolvable IPv6 next hop on routes learned through the IPv4 peering. Applying an inbound or outbound route-map that sets a valid IPv6 next hop gives R1 a resolvable next hop, so the R2 IPv6 prefixes can be installed and used.
Why the others are wrong
B. L2VPN EVPN is unrelated to plain IPv4 plus IPv6 unicast routing between two routers and does not repair next-hop reachability.
C. The session is already Established and exchanging families; adding a separate IPv6 neighbor is a redesign, not the targeted fix for next-hop handling.
D. Enabling IPv6 routing is a prerequisite, but it does not by itself supply a reachable next hop for already-received IPv6 NLRI.
300-615 exam tip — memory hook
BGP shows routes but RIB is empty: check next-hop reachability first, especially with IPv6 over IPv4 peering.
3Refer to the exhibit. A VXLAN fabric is configured on Cisco Nexus 9000 Series Switches but the traffic is dropped on VLAN 88 between VTEP1 and VTEP2. Which configuration resolves the issue?
Add VLAN 88 using switchport trunk allowed VLAN add 88 on VTEP2.
Enable VLAN 88 using no shutdown on VTEP2.
Add VLAN 88 using switchport trunk allowed VLAN add 88 on VTEP1.
Enable VLAN 88 using no shutdown on VTEP1.
Answer: C
The short version
C — VTEP1 is dropping VLAN 88 because its trunk does not permit it. Adding VLAN 88 to the allowed list on VTEP1 lets the traffic enter the VXLAN VLAN-to-VNI path toward VTEP2.
Key concepts in this question
VLAN-to-VNI mapping: a VLAN must exist and be carried on the ingress switch before it can be encapsulated into its VNI.
Trunk allowed VLAN list: frames for a VLAN are dropped on a trunk that does not explicitly permit that VLAN.
VTEP ingress filtering: the drop occurs at ingress, so the fix belongs on the source-side uplink shown in the exhibit.
Why C is correct
The exhibit isolates the loss to traffic entering at VTEP1 on VLAN 88. If the uplink trunk on VTEP1 does not include VLAN 88 in its allowed list, those frames never reach the NVE encapsulation logic and never traverse the underlay to VTEP2. Adding VLAN 88 with the trunk allowed-VLAN command on VTEP1 directly removes that ingress filter while leaving the healthy VTEP2 side unchanged.
Why the others are wrong
A. VTEP2 is the egress side in this flow; changing its trunk does not repair frames already dropped at VTEP1 ingress.
B. A shutdown versus no-shutdown VLAN state is a different fault from trunk pruning, and the exhibit points to allowed-VLAN filtering, not a suspended VLAN.
D. Enabling the VLAN administratively on VTEP1 does not add it to a trunk that is still pruning it.
300-615 exam tip — memory hook
VXLAN drops on one VLAN: verify VLAN exists, maps to a VNI, and is allowed on every ingress trunk.
4An IOM fails during a firmware upgrade and is unresponsive. Which action recovers the module?
C . Reinstall the firmware using Auto Install .
D . Restore the Cisco UCS Manager configuration from backup .
B . Reset the faulty module from the peer IOM
Answer: A
The short version
A — A failed IOM firmware upgrade is recovered by reinstalling firmware with Auto Install. Auto Install pushes the correct firmware package to the unresponsive module and brings it back under management.
Key concepts in this question
IOM role: I/O modules extend the fabric interconnect to blade chassis and depend on matched firmware.
Auto Install: Cisco UCS Manager workflow that installs infrastructure and server firmware in the supported order.
Firmware mismatch behavior: an interrupted upgrade can leave a module unable to join the cluster until firmware is reapplied.
Why A is correct
Because the outage was caused during a firmware upgrade and the module is unresponsive, the root cause is incomplete or corrupted firmware rather than configuration loss. Reinstalling firmware through Auto Install delivers the correct IOM image, retries the failed step, and returns the module to a manageable state without rebuilding the domain configuration.
Why the others are wrong
B. Restoring a UCS Manager backup recovers configuration, not a corrupted IOM firmware image, so it does not repair an upgrade-interrupted module.
C. Resetting the faulty module from its peer does not reload missing firmware; an unresponsive module generally cannot be revived by a peer reset alone.
300-615 exam tip — memory hook
Upgrade-bricked IOM: fix firmware with firmware; fix config loss with backups.
5Refer to the exhibit.An engineer installed a UCS rack mount server and received this error after upgrade. Which action resolves the issue?
Copy the license file to the kernel module folder.
Enable disabled Ethernet ports.
Regenerate the modules map file.
Install the license on the fabric interconnect.
Answer: D
The short version
D — The post-upgrade error is a fabric-interconnect license problem. Installing the required license on the fabric interconnect clears the fault on the attached rack server.
Key concepts in this question
Fabric interconnect licensing: port and feature licenses are enforced at the fabric interconnect, not on individual rack servers.
Upgrade-triggered enforcement: upgrades can newly enforce license checks that previously passed silently.
Kernel module symptoms: missing licenses can surface as module or port errors on downstream servers.
Why D is correct
The error appeared after an upgrade on a rack server connected through the UCS domain, which points to centralized license enforcement rather than a local server file fault. UCS rack integration depends on the fabric interconnect holding valid licenses for its ports and features. Installing the correct license there satisfies the check and resolves the downstream server error in one action.
Why the others are wrong
A. Copying a license file into a server kernel module folder is not the Cisco UCS licensing workflow and does not satisfy fabric-level enforcement.
B. Enabling disabled Ethernet ports treats a symptom; without the license the ports remain unusable or the fault persists.
C. Regenerating a modules map file addresses driver mapping issues, not a license enforcement failure after upgrade.
300-615 exam tip — memory hook
UCS upgrade error on a rack server: check fabric-interconnect licenses before touching server files.
6Refer to the exhibit. A network engineer configures an authentication domain through an LDAP provider on the Cisco UCS Manager for users from different companies to log into their respective organizations created in the UCS Manager. The engineer tests the configuration and notices that any user has login access to any organization in the UCS Manager. Which action should be taken to resolve the issue?
Configure the Filter field with sAMAccountName=$company
Configure the Attribute field with the company
Configure the Attribute field with sAMAccountName=$company
Configure the Filter field with the company
Answer: A
The short version
A — The LDAP search filter must scope users to their company. Setting the Filter field to match sAMAccountName against the company variable stops any user from matching any organization.
Key concepts in this question
LDAP authentication domain: UCS Manager binds to the provider and searches for the logging-in user.
Filter versus Attribute: the Filter field constrains which directory objects match; Attribute selects which field is read.
sAMAccountName: Active Directory login name commonly used to distinguish users across organizations.
Why A is correct
The symptom is over-permissive matching: every user authenticates into every organization, meaning the directory search is too broad. Placing the company-scoping expression in the Filter field narrows the LDAP query so only users whose sAMAccountName belongs to the target company match that organization's domain. That restores per-company login isolation without changing the schema mapping.
Why the others are wrong
B. Setting only the Attribute field changes which value is retrieved, but it does not constrain the search, so cross-organization logins still succeed.
C. Putting the match expression in the Attribute field misplaces the logic; attributes do not filter candidate directory entries.
D. A Filter containing only a company name without binding it to the login attribute is too vague to isolate users correctly.
300-615 exam tip — memory hook
Filter narrows who matches; Attribute selects what is read — scope access in the Filter.
7An engineer is investigating traffic loss on a Cisco UCS B-Series blade server. The engineer discovers high rates of RX CRC STOMPED errors on the fabric interconnect ports to which the server traffic is pinned Which action resolves the issue?
Update the firmware version on the virtual interface card adapter
Configure the VLANs on the fabric interconnect
Change the flow control settings on the l/O module.
Change the cables to fix physical connections
Answer: D
The short version
D — RX CRC STOMPED errors point to the physical path. Replacing or reseating cables fixes the corrupt frames arriving on the fabric interconnect ports.
Key concepts in this question
CRC STOMPED counter: indicates frames already found corrupt upstream and marked on ingress to the fabric interconnect.
Physical-layer faults: damaged cables, dirty optics, and loose seating are leading causes of CRC errors.
Pinning: server traffic pinned to specific uplink ports concentrates the symptom on those ports.
Why D is correct
High rates of RX CRC STOMPED errors mean frames are being damaged before or on the wire to the fabric interconnect, not mis-VLANed or misconfigured at Layer 2. Firmware and VLAN changes do not repair bit errors introduced by a marginal cable or optic. Changing cables and verifying physical connections removes the error source, which clears the counters and stops the traffic loss on the pinned paths.
Why the others are wrong
A. VIC firmware affects features and stability, but it does not cure wire-level CRC corruption arriving on fabric ports.
B. VLAN configuration controls forwarding scope, not frame checksum integrity, so it cannot stop CRC faults.
C. IOM flow control manages congestion pauses, not physical corruption marked as CRC STOMPED.
300-615 exam tip — memory hook
CRC and stomped counters climbing: think Layer 1 first — cables, optics, seating.
8Refer to the exhibit A Cisco VXLAN must use bidirectional PIM so thatSpine2 is the active RP for multicast group 225 0 0 0V24Loopback 254 is used as a logical interface for PIM configurationAfter configuration was applied, Spine1 became the active RP for multicast group 225.0.0.0/24 instead of Spine2. Which action resolves the issue?
Configure the IP pim ssm range 232.0.0.08 on Spme1
Delete the bidir keyword from ip pim rp address command on Spine1
Change the IP address of Loopback 254 to 10 254 254 254 on Spine2
Modify the subnet mask of Loopback 254 to ' 30 on Spine2
Answer: D
The short version
D — Spine2 loses the RP election because its Loopback 254 mask is wrong. Correcting the Loopback 254 subnet mask on Spine2 restores it as the active bidirectional RP for 225.0.0.0/24.
Key concepts in this question
Bidirectional PIM: both spines advertise the same logical RP address, commonly called a phantom RP.
RP reachability: routers select the RP path based on the advertised RP address and its covering route.
Loopback addressing: mask differences change which route is advertised and preferred for the shared RP address.
Why D is correct
Both spines are configured with Loopback 254 as the logical RP, so the election hinges on how that address is advertised rather than on a different RP address. The exhibit outcome where Spine1 wins indicates Spine2 advertises the shared address with an incorrect mask, making its path less preferred. Modifying the Loopback 254 mask on Spine2 aligns its advertisement with the intended phantom-RP design, so receivers again resolve the active RP through Spine2.
Why the others are wrong
A. An SSM range of 232.0.0.0/8 is unrelated to bidirectional operation for 225.0.0.0/24 and does not move the RP.
B. Removing the bidir keyword breaks the required bidirectional mode instead of repairing the RP election.
C. Changing the Loopback IP address itself would diverge from the shared phantom-RP address both spines must use.
300-615 exam tip — memory hook
Bidir phantom RP: same RP address on both spines; election follows the advertised route, so check masks.
9Refer to the exhibit.A Cisco UCS B-Series Blade Server is configured to boot from a shared storage via an iSCSI network. When a service profile is associated with the blade, the blade fails to attach the LUN. Which action resolves the issue?
Place VLAN 0 on the interface that connects to the storage
Register the blade as an initiator on the storage array
Implement a Layer 3 connection between the blade and the storage
Establish a Layer 2 connection between the blade and the storage
Answer: A
The short version
A — The iSCSI boot path needs its expected VLAN placement to attach the LUN. Placing the correct VLAN on the storage-facing interface lets the blade reach the target and complete LUN attachment.
Key concepts in this question
UCS iSCSI boot: the blade logs into the storage target through a dedicated vNIC and VLAN.
Layer 2 adjacency: iSCSI discovery and login require VLAN continuity between initiator and target.
Service profile networking: the profile's VLAN assignment determines which storage network the blade actually joins.
Why A is correct
Association applies the service profile, but the blade still fails at LUN attachment, which isolates the fault to initiator-to-target reachability rather than boot policy existence. Correct VLAN placement on the storage-facing interface puts the blade on the same iSCSI network as the array, so discovery, login, and LUN attachment can proceed over the intended Layer 2 path.
Why the others are wrong
B. Array-side initiator registration matters later, but the blade cannot even reach the array to log in if it is on the wrong VLAN.
C. Inserting Layer 3 between blade and storage complicates iSCSI boot, which is designed for the provisioned Layer 2 storage VLAN.
D. Simply asserting Layer 2 connectivity without the assigned storage VLAN does not guarantee the blade joins the correct iSCSI network.
300-615 exam tip — memory hook
iSCSI boot fails at LUN attach: verify initiator VLAN and target reachability before array zoning.
10Refer to the exhibit.An upgrade operation fails with an error displayed. Which action resolve the issue?
Use a different system image
Use a different kickstart image
Allocate extra space on a flash drive to extract a kickstart image
Allocate extra space on a flash drive to extract a system image
Answer: A
The short version
A — The failure is an incompatible or corrupt system image. Loading a different, correct system image lets the upgrade proceed past the displayed error.
Key concepts in this question
Kickstart versus system images: kickstart boots the kernel while the system image carries NX-OS features.
Image compatibility: platform, release train, and integrity must match the switch being upgraded.
Space versus image faults: storage errors call for space cleanup, while validation errors call for a new image.
Why A is correct
The exhibit error occurs during the upgrade operation and points at the system software payload rather than at flash capacity. A different system image that matches the platform and target release replaces the incompatible or damaged file, satisfies the installer checks, and allows extraction and boot to continue without altering kickstart handling.
Why the others are wrong
B. A kickstart image problem would fail at boot-loader or kernel load, not at the system-image validation stage shown.
C. Allocating space for kickstart extraction fixes capacity faults, not an incompatible or corrupt system payload.
D. Allocating space for system extraction helps only when flash is full; the indicated fix here is image correctness.
300-615 exam tip — memory hook
Upgrade error names the image: replace that image; space errors ask for space.