Hard Difficulty Questions

This is a local SPAN session that sends traffic to Gi1/0/24.

Why it fails: The type is Remote Source, not Local.

The destination port Gi1/0/24 is used to receive mirrored traffic from another switch.

Why it fails: In a source session, the destination port sends traffic out.

Only egress traffic from Gi1/0/1-3 is captured.

Why it fails: Both directions are captured (Both keyword).

SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.

Why it fails: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.

BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.

Why it fails: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.

Loop Guard is enabled on the uplink ports, which delays port transition.

Why it fails: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.

Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.

The internal routers have a route to the default network with a better metric from another source.

Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.

The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.

Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.

SGTs are assigned to endpoints based on their IP address only.

Why it fails: SGTs are assigned through static port or VLAN mappings, IP-to-SGT mappings, or dynamic 802.1X and SXP propagation, so IP address is only one possible source. It is tempting because IP-to-SGT static mappings are a legitimate assignment method in legacy or non-802.1X environments where endpoints cannot authenticate.

The fabric border node enforces all policies for traffic within the fabric.

Why it fails: Policy enforcement occurs at the fabric edge nodes where endpoints attach, via VXLAN group policy tags; the border handles external connectivity and SGT propagation, not intra-fabric enforcement. It is tempting because border nodes do carry SGT information between fabric sites and transit traffic, which is the correct answer for inter-site policy scenarios.

The fabric edge nodes have not been configured with the proper SGT mappings.

Why it fails: SGT mappings are IP-to-SGT bindings distributed by the Control Plane node via LISP to fabric edge nodes, primarily used for SXP propagation to legacy devices and for classifying traffic. However, SGT-based enforcement (SGACL) is applied only when traffic crosses Virtual Networks; same-subnet, intra-VN traffic is bridged at Layer 2 without any policy lookup. Therefore, missing SGT mappings on the fabric edge nodes are irrelevant here—they would not prevent enforcement for traffic that is not subject to enforcement in the first place.

The fabric edge nodes are operating in Layer 2 mode and do not support SGT enforcement.

Why it fails: The fabric edge node's forwarding mode (Layer 2 or Layer 3) determines how packets are switched or routed, but it does not affect SGT enforcement capability. In Layer 2 mode, the edge node performs bridging; in Layer 3 mode, it routes inter-VN traffic—but in both cases, the node is fully capable of enforcing SGACLs when traffic enters or leaves a VN. Since the endpoints are in the same subnet, the traffic never crosses a VN boundary, so the edge node's mode is irrelevant to the missing enforcement.

The control plane node has not been configured with the correct IP-SGT mappings.

Why it fails: Although the Control Plane node maintains the IP-to-SGT mappings that are critical for VN routing and policy classification, these mappings are only consulted when traffic is subject to SGT enforcement—namely, inter-VN traffic. Even with perfect IP-SGT mappings, traffic between endpoints in the same subnet and same VN will be bridged without a policy lookup. Thus, incorrect mappings on the Control Plane node cannot be the cause of the issue, as the traffic path does not invoke SGT enforcement.

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

The IP SLA operation must be configured with a 'request-data-size' value to match the remote router's MTU.

Why it fails: The request-data-size parameter for a UDP jitter operation only controls the payload size of the probe packets; it is optional and does not affect whether the remote router answers. The IP SLA responder on the destination processes jitter probes regardless of the configured data size, so this setting has no bearing on the failure. An MTU mismatch is a separate forwarding issue and is not relevant to the absence of a responder.

The source router needs a 'frequency' setting that matches the remote router's response interval.

Why it fails: The frequency command on the source router determines how often the IP SLA operation sends a new probe iteration; it is purely a local scheduling knob and has no corresponding value that must be matched on the remote router. The responder does not maintain its own 'response interval' that needs to align with that frequency, and jitter calculation is unaffected by this scheduling parameter. Changing frequency only changes the sample interval, not whether the remote responder generates a response.

The firewall on the remote router is blocking the UDP port 16384, preventing the probe from reaching the target.

Why it fails: A firewall blocking UDP 16384 could prevent a jitter probe from arriving, but that is a secondary issue and not the root cause described by the need for a responder. Even if the firewall permitted the probe, the remote router would still need an IP SLA responder to listen on that port and generate the return traffic; otherwise the packet is simply discarded. Moreover, the presence of a firewall does not explain why the operation can never establish with the responder, because the responder is mandatory regardless of firewall state.

The destination session on the central switch is configured with 'monitor session 2 destination remote vlan 999' instead of 'monitor session 2 destination interface Gi1/0/1'.

Why it fails: The destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.

The source sessions on the remote switches are configured with 'monitor session 1 source vlan 100' but the destination is not set to 'remote vlan 999'.

Why it fails: A valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.

The RSPAN VLAN is not created as a remote SPAN VLAN; it must be configured with 'remote-span' command.

Why it fails: Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.

Cisco UCS Manager

Why it fails: Cisco UCS Manager manages Cisco UCS blade and rack servers, providing hardware abstraction and server profiles. While it can be used in a data center with ACI, it is not required for integrating ACI with VMware vSphere and the Cisco AVS. The integration focuses on network virtualization at the hypervisor level, which involves APIC and vCenter. UCS Manager is not a component of the ACI-VMware integration for AVS.

Cisco DCNM

Why it fails: Cisco Data Center Network Manager (DCNM) is a management platform for Cisco Nexus switches, but it is not used for ACI fabric management. ACI uses the APIC for policy and automation. DCNM can manage standalone Nexus switches and some ACI environments, but it is not required for integrating ACI with VMware vSphere and AVS. The integration specifically relies on APIC and vCenter, not DCNM.

Cisco Nexus 1000V

Why it fails: Cisco Nexus 1000V is a virtual switch for VMware vSphere, but it is not used for ACI integration. The Cisco Application Virtual Switch (AVS) is the successor to the Nexus 1000V for ACI environments. Nexus 1000V is managed by a Virtual Supervisor Module (VSM) and does not support OpFlex or direct integration with Cisco APIC. Therefore, it is not a required component for integrating ACI with vSphere using AVS.

The static route must be configured on the global table using a next-hop inside VRF CUSTOMER_A, because IOS-XE forbids static routes within VRFs.

Why it fails: IOS-XE fully supports static routes inside a VRF using the `ip route vrf CUSTOMER_A` syntax, so the premise is false. A global static route cannot use a next hop that resides in a VRF without a leak, because the global RIB cannot resolve a VRF next hop. The issue is the missing leak, not a prohibition on VRF static routes.

The interfaces Gi0/1 and Gi0/2 need `ip vrf forwarding CUSTOMER_A` removed so all interfaces share the global table.

Why it fails: Removing VRF forwarding from those interfaces would collapse the segmentation the design requires and place all three interfaces back in the global table, defeating VRF-Lite's purpose. The problem is not that the interfaces are in a VRF, but that no route-leaking mechanism connects the VRF and global tables. Removing the VRF assignment changes the topology rather than fixing reachability.

A route distinguisher must be configured on VRF CUSTOMER_A before any static route becomes usable.

Why it fails: Route distinguishers are used with MPLS L3VPN and MP-BGP to make VPNv4 prefixes unique across VRFs; they are not required for VRF-Lite static routing. VRF-Lite uses separate routing tables on a single device without MPLS labels or route targets. The static route is valid inside the VRF regardless of a route distinguisher, so its absence does not explain the failure.

Cisco DNA Center Assurance can capture and analyze full packet captures in real time for every flow.

Why it fails: Assurance stores flow telemetry and NetFlow records, not continuous full packet capture for every flow; that volume is impractical. It is tempting because Assurance does offer on-demand packet capture for troubleshooting specific clients, which is where the feature genuinely applies.

Cisco DNA Center Assurance only monitors wired clients and does not provide visibility into wireless client performance.

Why it fails: Assurance correlates both wired and wireless clients, giving wireless performance visibility through telemetry from WLCs and APs. It is tempting because Assurance's client health scoring originated with wired switching telemetry, yet wireless monitoring is equally core to the platform.

RADIUS uses TCP for reliable transport, while TACACS+ uses UDP.

Why it fails: The transports are reversed: RADIUS runs over UDP, while TACACS+ uses TCP port 49. It is tempting because pairing one protocol with each transport feels tidy, and the statement would be correct if it swapped the two protocols, since TCP does provide the reliable delivery described.

TACACS+ encrypts only the password in the packet, similar to RADIUS.

Why it fails: TACACS+ encrypts the entire packet body, not just the password; only RADIUS conceals the password alone. It is tempting because RADIUS does encrypt just the password field, and the statement would hold if it described RADIUS rather than claiming the two protocols behave similarly.

The routers have a different IOS version that interprets 'outbound' as 'in'.

Why it fails: The direction parameter is validated by the Ansible module itself, not by the router's IOS. The `ios_acl_interfaces` module only accepts the exact string values `in` or `out` for `direction`, so passing `outbound` would either cause a validation error or be ignored/defaulted; it cannot be reinterpreted by the device. Different IOS versions do not change how the module handles the parameter because the module runs on the control node and translates the validated value into the correct CLI command. Thus, the router's IOS version is irrelevant to the symptom.

The engineer forgot to include the 'state: present' parameter, so the module did not apply the ACL.

Why it fails: In Ansible's `ios_acl_interfaces`, `state: present` is the default behavior, so omitting it would still apply the configured ACLs to the interface. If the module for some reason did not apply the ACL, the interface would have no `ip access-group` binding at all, resulting in no ACL filtering for either direction. The problem here is an ACL that is actually active but applying inbound, which indicates a successful application with the wrong direction parameter—not a failure to apply anything. Hence, this option does not explain the symptom.

The ACL itself is defined with the wrong direction in the playbook.

Why it fails: The ACL definition itself is direction-agnostic; it contains only match criteria (like source/destination addresses) and actions (permit/deny). The direction in which the ACL is evaluated is determined exclusively by the `direction` field in the interface's `access_groups` configuration, which is part of the module's interface-level parameters. If the ACL rules themselves were incorrect, the filtering action would be wrong irrespective of direction, but the symptom of applying inbound when outbound was intended points to the binding configuration, not the ACL content. Therefore, defining the ACL with a 'wrong direction' is not a valid explanation.

Fabric Control node

Why it fails: The Fabric Control node is the LISP control plane responsible for maintaining the Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. It does not physically attach to any endpoints; wireless clients are registered with the Control node through the Fabric Edge, which discovers them. Since it only provides mapping and registration services, it cannot directly integrate or enforce policies on user traffic.

Fabric Border node

Why it fails: The Fabric Border node serves as the exit or entry point between the SD-Access fabric and external networks such as a WAN or the Internet. It translates VXLAN encapsulated traffic to traditional IP routing and applies inter-VRF routing policies for north-south flows, but it never terminates wireless user connections. Wireless endpoints are always attached to a Fabric Edge node, not a Border node.

Wireless LAN Controller (WLC)

Why it fails: While the Wireless LAN Controller (WLC) manages access points, handles RF, and supports roaming, in an SD-Access deployment it does not enforce segmentation or policy on wireless clients. The WLC forwards wireless traffic to the Fabric Edge, which applies VXLAN encapsulation, SGT-based policy, and anycast gateway features. Therefore, the WLC is a management component, not the policy-integration point for wireless users.

The IP SLA operation is not configured with a 'request-data-size' that matches the remote router's MTU, causing fragmentation and delay variations.

Why it fails: Configuring a 'request-data-size' that exceeds the path MTU between the source and destination would cause IP fragmentation, possibly increasing delay and jitter or causing packet drops, but it cannot produce a negative one-way delay value. One-way delay is calculated as receive timestamp minus send timestamp; fragmentation only adds transit time, so the result would remain positive (or the probe would fail). Thus, this misconfiguration explains performance degradation, not the reported negative delay.

The IP SLA operation is using a 'frequency' that is too high, causing the probes to overlap and corrupt the statistics.

Why it fails: Setting the IP SLA 'frequency' to a value shorter than the operation's actual execution time can cause probes to overlap or be skipped, which may corrupt the statistics or cause false timeouts. However, overlapping probes would affect packet timing, loss, and jitter metrics, not the sign of the computed one-way delay. A negative delay is a mathematically impossible result under normal timing and is specifically a symptom of clock desynchronization, not probe scheduling.

The remote router's IP SLA responder is not configured, so the source is using a different method to estimate delay.

Why it fails: If the remote router did not have an IP SLA responder configured, the UDP jitter operation would fail entirely because it relies on the responder to process and timestamp the probe packets and return control messages. There is no fallback 'different method' for estimating one-way delay; the operation would report an error or no data. Consequently, a missing responder could not yield a negative delay value, as the measurement would never complete.

Overcommitment guarantees that each VM receives its allocated resources without interference.

Why it fails: Overcommitment permits contention: when demand exceeds physical capacity, VMs compete and may not receive allocated resources. It is tempting because allocation figures suggest guaranteed reservations, but overcommitment deliberately sells more than exists, so guarantees apply only with explicit reservations.

Resource overcommitment is only applicable to memory, not CPU or storage.

Why it fails: Overcommitment applies to CPU, memory and storage; each resource has its own ratio and contention behaviour. It is tempting because memory overcommitment is commonly discussed and memory ballooning is well known, but CPU overcommitment via scheduling and thin-provisioned storage are equally standard.

YANG defines the transport protocol for data exchange.

Why it fails: YANG is a data modelling language describing configuration and state; transport is handled separately by NETCONF, RESTCONF or gNMI. It is tempting because YANG models are commonly exchanged over those protocols, but the model itself specifies no transport binding.

The 'leaf' statement in YANG defines a list of key-value pairs.

Why it fails: A leaf holds a single scalar value with a type; a list of key-value entries is defined by the list statement, whose keys come from leaf statements marked as keys. It is tempting because leaves do appear inside lists, but a leaf itself is atomic.

An L3Out configured on a leaf switch to peer with the remote site's router.

Why it fails: An L3Out is indeed needed to reach the remote site, but the stem already assumes extension over an L3Out and asks for the constructs enabling the overlay and routing context. The L3Out is the external routing attachment, not the construct that maps endpoints to a Layer 2 segment or provides the VRF. Selecting it duplicates a given rather than identifying the enabling constructs.

A contract applied between EPGs to permit the required traffic flows.

Why it fails: Contracts define which protocols and ports are allowed between EPGs, which is a policy control rather than a reachability or extension mechanism. The question asks for constructs that provide cross-leaf reachability and L2 extension, not permission for traffic. A contract alone would not create the VNI-backed segment or the routing context needed for the L3Out.

A fabric-wide SPAN session that mirrors all endpoint traffic to an external analyzer.

Why it fails: SPAN is a monitoring feature that copies traffic for analysis; it does not provide reachability, policy enforcement, or Layer 2 extension. It cannot make an endpoint reachable across leaves or extend a bridge domain over an L3Out. While useful for troubleshooting, it is unrelated to the design requirements of overlay reachability and site extension.

Configure a separate flow monitor for each customer interface and export to different collectors.

Why it fails: Creating a separate flow monitor per customer interface assumes each customer has its own interface, but the question states they share a single interface (e.g., an MPLS VPN), so there are no distinct per-customer interfaces to attach monitors to. Even if you tried to apply multiple monitors to the same interface, each monitor without a filter would capture identical traffic, and exporting to different collectors would double the export bandwidth while still not separating the flows. This approach adds operational complexity and does not solve the core problem of flow attribution on the shared link.

Use NetFlow v9 export with the 'match ipv4 source address' field only, and rely on the collector to separate by source IP.

Why it fails: NetFlow v9 export using only the source IP address as the identifying key fails when customers use overlapping private address space, such as RFC 1918 10.x addresses inside different VRFs. The collector would merge flows that share a source IP, making it impossible to tell which customer generated them, and the actual destination and port may also be identical. VRF or VLAN context is the only reliable way to disambiguate customers in a shared infrastructure; source IP alone is insufficient.

Enable SNMP interface polling to track per-customer traffic statistics.

Why it fails: SNMP interface polling reads cumulative counters like ifInOctets and ifOutOctets for the entire shared interface every polling interval, so it provides only aggregate bandwidth utilization with no per-flow or per-customer visibility. NetFlow is specifically designed to record individual flows with timestamps, IP addresses, protocols, and ports, whereas SNMP cannot tell you which customer's TCP session contributed to the byte count. Moreover, polling at 5-minute intervals misses short-lived flows and provides no attribution on a multi-tenant link.