Virtualization practice questions

The route-target export is not configured in VRF-A.

Why it fails: Incorrect. The stem already states that route-target import/export is configured; missing export on VRF-A would contradict that and would affect routes from A to B, not the reported direction.

The router is using VRF-lite, which does not support route leaking.

Why it fails: Incorrect. VRF-lite supports route leaking via RT import/export.

The import map is missing in VRF-B.

Why it fails: Incorrect. An import map is optional; basic RT import is sufficient.

Check if EVPN type-3 routes are being advertised for VNI 10100.

Why it fails: Type-3 routes are for multicast, not for unicast MAC/IP.

Confirm that multicast group 239.1.1.1 is reachable across the underlay.

Why it fails: EVPN uses BGP, not multicast.

Check if the MTU on the underlay is set to at least 1550 bytes.

Why it fails: MTU issue would affect all VNIs, not just one.

Use two separate routed interfaces, each with a routing protocol.

Why it fails: Using two separate routed interfaces on different stack members with a routing protocol creates equal-cost paths that are independent, causing per-flow forwarding to become asymmetric between the upstream switch and the stack. Asymmetric routing can lead to out-of-order packets, TCP performance degradation, and complex troubleshooting. The routing protocol fails over at Layer 3, which is inherently slower than EtherChannel link aggregation and requires careful tuning of metrics and timers.

Connect each uplink to the active switch member.

Why it fails: Connecting both uplinks to the active stack member concentrates all north/south traffic on one switch, so the stack's forwarding capacity is limited to a single member's interfaces. If the active switch fails, the standby and any other members lose all connectivity to the upstream network, and the stack must elect a new active before traffic can flow. This design violates the redundancy goal of stacking and would be rejected in any high-availability design.

Configure the uplinks in active/standby mode using STP.

Why it fails: Configuring the uplinks in active/standby mode with Spanning Tree Protocol blocks one of the two links, wasting half the available uplink bandwidth for the entire time it is in the blocking state. In a single stack domain, STP is not needed for internal redundancy because the stack appears as one logical switch to the upstream, and its job is to prevent loops, not to provide failover. The blocked port fails over only after a forward delay, typically 30 seconds, which is far slower than EtherChannel's seamless failover.

Use VXLAN to encapsulate traffic and send it to a firewall.

Why it fails: VXLAN encapsulates Layer 2 frames in UDP to extend networks across Layer 3 boundaries, but it is a network virtualization overlay, not a security control. Redirecting VXLAN traffic to a firewall would require the firewall to terminate the tunnel, yet the fundamental problem remains: intra-host VM traffic never leaves the vSwitch and is not automatically directed to an inspection point. A VXLAN overlay does not offer inline redirection or filtering capabilities, so it cannot enforce security policies on east-west traffic.

Use a vSphere Standard Switch and configure port mirroring.

Why it fails: Port mirroring on a vSphere Standard Switch duplicates packets to a monitoring interface, but the original traffic still flows directly from source to destination VM. A firewall attached to a mirrored port passively observes copies of frames but cannot drop, reroute, or modify them, so it has no enforcement capability. Since the firewall is not placed inline in the forwarding path, port mirroring is suitable for troubleshooting or monitoring, not for protecting VM-to-VM communication.

Deploy a physical firewall and route all VM traffic through it.

Why it fails: Routing all VM traffic through a physical firewall would require intra-host traffic to hairpin out through a physical NIC to the firewall and back into the host, adding significant latency and complexity. The vSwitch forwards VM-to-VM traffic locally and does not send it to the physical network unless special routing or VLAN configurations are engineered to force it out. Even then, the physical firewall can only inspect traffic that leaves the host, making this an inefficient and impractical approach for filtering east-west traffic within a single ESXi host.

VLAN 999

Why it fails: VLAN 999 is configured as the native VLAN on Ethernet1/1, but native VLAN settings are per-interface and do not carry over to other ports. Ethernet1/3 has its own trunk configuration and allowed VLAN list, which does not include VLAN 999. An untagged frame on Ethernet1/3 would use that port's own native VLAN, not VLAN 999; and this frame is tagged with VLAN 10 anyway, so VLAN 999 is irrelevant.

VLAN 1

Why it fails: The frame is not classified into VLAN 1, even though VLAN 1 is the native VLAN on Ethernet1/3. The native VLAN applies only to untagged frames, but this frame carries an 802.1Q tag containing VLAN 10. Because the tag is present, the switch attempts to match the tag against the trunk's allowed list; since VLAN 10 is not allowed, the frame is dropped instead of being assigned to VLAN 1.

VLAN 10

Why it fails: Choosing VLAN 10 assumes the 802.1Q tag alone determines the frame's destination VLAN, but a trunk interface also requires the VLAN to be present in its allowed list. Ethernet1/3 does not permit VLAN 10, so the frame is not placed into VLAN 10; it is discarded before any forwarding decision is made. The tag indicates an attempted VLAN, but without permission in the allowed list, the frame cannot be accepted into that VLAN.

Enable vNUMA for both VMs to improve memory access, and set CPU affinity to dedicate specific cores.

Why it fails: vNUMA exposes the virtual NUMA topology to the guest OS and is only beneficial for memory locality in large multi-socket VMs; it does not alter the ESXi CPU scheduler's run-queue behavior or reduce CPU ready time. Setting CPU affinity manually can actually increase latency by pinning vCPUs to specific physical cores, which prevents the scheduler from migrating vCPUs to idle cores and reduces flexibility under load. Neither action addresses the NFS datastore latency that contributes to the application slowdown.

Increase the RAM for both VMs to reduce disk swapping, and enable Hyperthreading on the ESXi host.

Why it fails: Adding RAM to both VMs would only help if memory ballooning, swapping, or insufficient guest memory were the reported symptoms, but the problem is CPU ready time, meaning vCPUs are queued waiting for physical CPU execution, not waiting for memory pages. Enabling Hyperthreading on the ESXi host adds logical processors, but on an already oversubscribed host it can worsen CPU contention because sibling logical processors share execution resources and increase scheduling pressure. This option completely misses both the CPU run-queue issue and the storage latency issue that are driving the trading application's poor performance.

Migrate the VMs to another ESXi host with faster CPUs, and upgrade the storage network to 10 Gbps.

Why it fails: Migrating to a host with faster CPUs might reduce per-vCPU execution time, but it does not fix the underlying oversubscription problem; if the destination host is also overcommitted, CPU ready time will continue. Upgrading the storage network to 10 Gbps increases available bandwidth, but NFS latency issues are typically caused by storage array response time, queue depth, or round-trip processing delay, not by link bandwidth exhaustion. This option is also disruptive because live migration moves the entire VM memory state and may cause a brief service impact, while it ignores the datastore-level I/O prioritization that Storage I/O Control would provide.

Router: Filters traffic based on security rules

Why it fails: Incorrect — filtering traffic is primarily a firewall function, not a router's primary role.

Switch: Forwards packets between different networks

Why it fails: Incorrect — forwarding between networks is a router's job; switches operate within a network.

Firewall: Forwards frames within the same network

Why it fails: Incorrect — forwarding frames is a switch's function, not a firewall's primary role.

show vxlan vni

Why it fails: The show vxlan vni command displays the mapping between VLANs and VNIs as well as VNI status, but it does not show the remote VTEP peer IP addresses or their operational state. It helps verify VNI configuration but not the learned peer relationships required in this scenario.

show interface nve1

Why it fails: The show interface nve1 command provides interface counters, line protocol status, and MTU information for the NVE interface. While it confirms the interface is up, it does not list remote VTEP peers or their addresses, so it does not fulfill the requirement to verify learned VTEPs.

show nve interface nve1

Why it fails: The show nve interface nve1 command displays the NVE interface status, source interface, and encapsulation type, but it does not list the remote VTEP peers learned through the control plane. It confirms the local VTEP configuration only, so it would not satisfy the requirement of verifying learned remote VTEP IP addresses.

vrf forwarding GUEST

Why it fails: The command vrf forwarding is used in NX-OS, not in IOS-XE. On Catalyst 9000 switches, the correct command is ip vrf forwarding. Using the NX-OS syntax would result in an error, and the interface would not be associated with the VRF.

ip vrf GUEST

Why it fails: The command ip vrf is used in global configuration mode to create a VRF, not to associate an interface. Under interface configuration, it is not valid. To assign an interface, the ip vrf forwarding command is required.

vrf definition GUEST

Why it fails: The vrf definition command is used in global configuration mode to create a VRF with support for both IPv4 and IPv6. It does not associate an interface with a VRF. The interface association is done with ip vrf forwarding.

Anycast RP with MSDP peering between spines

Why it fails: Anycast RP with MSDP is a multicast rendezvous point redundancy technique for the underlay. It does not determine which VTEPs receive BUM traffic for a given VNI, so it cannot restrict replication to leaves with active local members and is unrelated to the stated requirement.

Ingress replication with a static unicast flood list

Why it fails: Ingress replication with a static unicast flood list sends BUM traffic to every VTEP configured in the list regardless of whether that VTEP has active local members. It cannot dynamically prune leaves that lack members in the VNI, so it does not meet the requirement for member-only replication.

Multicast underlay using PIM sparse mode for the VNI

Why it fails: A multicast underlay using PIM sparse mode replicates BUM traffic to VTEPs that joined the group, but the group membership is driven by VTEP configuration rather than by active local host membership in the VNI. It therefore does not guarantee replication only to leaves with active members.

show vxlan vni

Why it fails: The show vxlan vni command is not a valid command on Cisco Nexus 9000 switches. VXLAN-related information is typically displayed using commands under the show nve and show bgp l2vpn evpn families, so this option is incorrect.

show interface nve1

Why it fails: The show interface nve1 command provides statistics and status for the NVE interface, such as packet counters and line protocol state. It does not list the individual VNIs or their operational status, so it is not the best command for verifying VNI status.

show nve interface

Why it fails: The show nve interface command displays the status of the NVE interface, including whether it is up or down and the source interface. However, it does not provide detailed information about the VNIs or their status; additional commands are needed for that.

Assign the VRF to the interface using the 'vrf forwarding CUSTOMER_A' command under the interface configuration.

Why it fails: Assigning the VRF to an interface is necessary to place the interface into the VRF, but it does not by itself ensure isolation from the global routing table. Route leaking is controlled by route targets and import/export policies in MPLS L3VPN or by explicit route-map configurations. Without proper import/export control, routes might still be leaked if the VRF is part of a larger VPN.

Enable 'ip routing' in the global configuration and assign an IP address to the VRF interface from the global pool.

Why it fails: Enabling IP routing is a prerequisite for any routing, but it does not create isolation. Assigning an IP address from the global pool to a VRF interface is not recommended because it can cause overlap and confusion. Each VRF should have its own IP address space, and isolation is enforced by the VRF's separate routing table and route targets.

Configure a static route in the global routing table pointing to the VRF's next-hop interface.

Why it fails: Static routes in the global table do not provide isolation; they could potentially leak traffic into the VRF if not properly controlled. The goal is to keep the VRF separate, so adding global static routes is counterproductive. Isolation is achieved by not importing global routes into the VRF, which is controlled by route targets and import policies.

Configure the tunnel interface with `tunnel vrf VRF-A` and set the `ip vrf forwarding VRF-A` on the physical interface.

Why it fails: Setting `ip vrf forwarding VRF-A` on the physical interface would place the physical interface in VRF-A, which is not desired if the physical interface carries traffic for multiple VRFs. The `tunnel vrf` command is used to specify the VRF for the tunnel's transport, but it does not alone determine which traffic is encrypted.

Configure a route map that matches traffic from VRF-A and apply it to the tunnel interface with the `ip policy route-map` command.

Why it fails: A route map can be used for policy-based routing, but it does not inherently provide encryption. While it could direct traffic into a tunnel, it does not handle the IPsec encryption itself. The question asks for encryption of VRF-A traffic, which requires a crypto map or IPsec profile, not just a route map.

Apply the crypto map to the tunnel interface and specify the VRF using the `vrf` keyword under the crypto map.

Why it fails: Crypto maps are applied to physical interfaces, not tunnel interfaces. The `vrf` keyword under a crypto map is used for VRF-aware IPsec to specify which VRF the crypto map applies to, but it is not applied to a tunnel interface. This option incorrectly suggests applying it to a tunnel interface.

route-target import 65000:100

Why it fails: The route-target import command controls which received EVPN routes are imported into the local VRF or bridge domain based on the Route Target extended community. It affects inbound route selection, not local origination of Type-2 or Type-3 routes. Configuring import alone will not advertise anything to EVPN peers.

host-reachability protocol bgp

Why it fails: This command is used in a VXLAN EVPN configuration to specify that host reachability is learned via BGP EVPN control plane. It is typically applied under the NVE interface configuration. It tells the NVE how to signal MAC reachability, but it does not enable the BGP EVPN address family to originate Type-2/Type-3 routes.

send-community extended

Why it fails: send-community extended allows BGP to attach extended community attributes such as Route Target and Encapsulation to EVPN routes. It is necessary for proper route import/export but does not by itself cause the switch to generate Type-2 or Type-3 EVPN routes for local hosts and VTEPs. Enabling it alone leaves the EVPN RIB empty of local advertisements.

feature vn-segment-vlan-based; interface nve1; source-interface loopback0; member vni 10100 mcast-group 239.1.1.1; interface vlan100; vn-segment 10100

Why it fails: This option uses a multicast group for ingress replication, which is a valid method but not what the scenario requires. The question specifies a manually created tunnel interface with a primary loopback source and static ingress replication. While the commands are syntactically correct, they do not match the requirement for static peer configuration.

interface nve1; no shutdown; source-interface loopback0; member vni 10100; ingress-replication protocol static; peer-ip 10.1.1.1; interface Ethernet1/1; switchport mode trunk; switchport trunk allowed vlan 100

Why it fails: This option correctly configures the NVE interface with static ingress replication but fails to map VLAN 100 to VNI 10100. The vn-segment command under the VLAN interface is missing, so traffic on VLAN 100 will not be encapsulated into VXLAN. The trunk configuration on the physical interface is irrelevant to the VXLAN mapping.

interface nve1; no shutdown; source-interface loopback0; member vni 10100; ingress-replication protocol bgp; interface vlan100; vn-segment 10100

Why it fails: Using BGP for ingress replication is part of an EVPN control plane, which is not mentioned in the scenario. The question asks for a manual VXLAN tunnel, implying static configuration. BGP would require additional EVPN address-family configuration and is not the correct method for a standalone manual tunnel.

VRF-lite

Why it fails: VRF-lite is a technique that allows multiple VRFs on a single device without MPLS. It provides isolation by default, but it is not a feature that is configured to isolate VRFs; rather, it is the implementation of VRFs itself. The administrator already has VRFs configured; the question asks for a feature to ensure isolation, which is inherent to VRF operation, not a separate feature.

VRF-aware NAT

Why it fails: VRF-aware NAT translates IP addresses between VRFs, which is used for overlapping address spaces, not for isolation. It allows communication between VRFs by translating addresses, which is the opposite of what the administrator wants. Enabling it would permit traffic to flow between the guest and corporate VRFs, violating the isolation requirement.

VRF leaking

Why it fails: VRF leaking is the process of selectively allowing routes to be shared between VRFs. It is used when some communication is desired, not for isolation. Configuring VRF leaking would intentionally allow traffic from the guest VRF to reach the corporate VRF, which directly contradicts the goal of preventing traffic leakage.

Application Network Profile (ANP)

Why it fails: An Application Network Profile (ANP) is a collection of EPGs and contracts that define how applications communicate. While ANPs are important for policy definition, they do not directly define the forwarding behavior or isolation at the Layer 2 and Layer 3 level. The underlying components that define forwarding are BDs and EPGs, making ANP incorrect for this specific requirement.

VXLAN Network Identifier (VNI)

Why it fails: VNI is used in VXLAN to identify Layer 2 segments, but in Cisco ACI, the VNI is automatically assigned and not directly configured by the administrator for defining forwarding behavior. The ACI fabric uses VXLAN internally, but the configuration is abstracted through BDs and EPGs. Therefore, VNI is not a component that the architect configures to define forwarding and isolation.

Virtual Routing and Forwarding (VRF)

Why it fails: While VRF is used in Cisco ACI to provide Layer 3 isolation between tenants, it is not the primary component for defining forwarding behavior and isolation in the context of Layer 2 and Layer 3 forwarding. VRFs are used for routing separation, but BDs and EPGs are more directly involved in defining forwarding and policy enforcement within the fabric. Thus, VRF is not the best answer here.

system mtu 9216

Why it fails: The global configuration command 'system mtu 9216' changes the maximum transmission unit for all switch ports but requires a reload to take effect. On Catalyst 9300, the default system MTU is 1500 bytes, and this command sets the MTU for Gigabit Ethernet ports. However, it does not support the per-interface flexibility needed for iSCSI traffic and may not apply to all port types. The command is not the recommended method for enabling jumbo frames on a per-interface basis.

mtu 9216

Why it fails: The interface-level command 'mtu 9216' is used on routers to set the IP MTU for a Layer 3 interface. On a switch, this command may not be available or may only affect routing, not Layer 2 switching. For iSCSI storage traffic that traverses a Layer 2 domain, the correct approach is to set the system MTU or use per-port MTU settings. This command alone would not enable jumbo frames for switched traffic.

ip mtu 9216

Why it fails: The interface command 'ip mtu 9216' sets the IP MTU for a Layer 3 interface, affecting the maximum size of IP packets that can be sent or received. This command is used on routers or Layer 3 switches for routed traffic, not for Layer 2 switched frames. For iSCSI traffic that is Layer 2 switched, this command would not enable jumbo frame support for the switch ports. It is not the correct command for this scenario.

The underlay routing protocol is not advertising the loopback interfaces.

Why it fails: If the underlay were not advertising loopbacks, the VTEPs would not be reachable, and EVPN Type 2 routes would not be installed because the next-hop would be unreachable. Since Type 2 routes are present, the underlay is likely advertising loopbacks correctly. The problem is more specific to VXLAN data plane configuration.

The BGP EVPN peering is down between the leaf switches.

Why it fails: If BGP EVPN peering were down, EVPN Type 2 routes would not be present on both leaf switches. The question states that Type 2 routes are present, so BGP peering is likely up. The issue is more likely a data plane misconfiguration, such as VLAN-to-VNI mapping.

The VXLAN UDP port is blocked by an ACL on the underlay.

Why it fails: If the VXLAN UDP port (4789) were blocked, the underlay would not be fully operational for VXLAN traffic. However, the question states that EVPN Type 2 routes are present, which implies that BGP EVPN peering is working. Typically, BGP peering uses TCP port 179, but VXLAN data plane uses UDP 4789. It is possible but less likely if routes are present; other issues like VLAN-to-VNI mapping are more common.

MPLS LDP in the underlay for label switching

Why it fails: MPLS LDP is not required for VXLAN. VXLAN uses IP routing in the underlay and does not rely on MPLS labels. While MPLS can be used in some data center designs, it is not a component of VXLAN encapsulation. The underlay for VXLAN is typically a pure IP network with an IGP, not MPLS.

A dedicated out-of-band management network for all switches

Why it fails: An out-of-band management network is good practice for switch management, but it is not a required component for VXLAN operation. VXLAN tunnels operate over the in-band data plane, not the management plane. While management connectivity is important, it does not enable VXLAN functionality. The question specifically asks for components required to support VXLAN.

A multicast-enabled core for BUM traffic replication

Why it fails: While multicast can be used for BUM (Broadcast, Unknown unicast, Multicast) traffic replication in VXLAN, it is not strictly required in modern EVPN-based fabrics. Cisco SD-Access typically uses ingress replication or multicast, but the question asks for required components for VXLAN underlay. Multicast is an optional design choice, not a mandatory requirement for VXLAN operation.