VLAN and Inter-VLAN Routing Scenarios

VTP transparent mode prevents RSPAN from working correctly.

Why it fails: VTP transparent mode still propagates and supports RSPAN VLANs; it merely stops the switch participating in VTP domain advertisements. Transparent mode is the right answer when the question concerns local VLAN database independence from VTP server updates.

The source VLAN 50 is not allowed on the trunk ports.

Why it fails: VLAN 50 is the source, not the RSPAN transport; if it were disallowed on trunks, monitoring would fail entirely rather than intermittently. Verifying source VLAN trunk allowance is correct when no traffic reaches the destination at all.

The monitor session 2 is missing the 'no shutdown' command.

Why it fails: Monitor sessions and destination interfaces are enabled by default, so 'no shutdown' is not required; the intermittent symptom stems from VLAN 200 also serving as native VLAN on trunks, which strips or misforwards tagged RSPAN traffic. The command would matter only if the interface were administratively down.

IPv6 Source Guard is blocking inter-host traffic because the hosts' bindings are not in the binding table.

Why it fails: IPv6 Source Guard drops traffic whose source address lacks a binding-table entry, but it validates the source, not the destination, so it would not stop host-to-host pings between validly bound hosts. It is correct for preventing source-address spoofing, not for isolating hosts within a VLAN.

RA Guard is blocking Neighbor Advertisements between hosts.

Why it fails: RA Guard filters Router Advertisement and Redirect messages on access ports; Neighbor Advertisements between hosts are unaffected. It is the correct control for blocking rogue routers advertising on a VLAN, not for stopping Neighbor Discovery between hosts.

DHCPv6 Guard is blocking DHCPv6 messages between hosts.

Why it fails: DHCPv6 Guard filters server-to-client DHCPv6 messages on untrusted ports; it does not block host-to-host traffic, and these hosts may use static or SLAAC addresses anyway. It is the right control for stopping rogue DHCPv6 servers, not for inter-host reachability.

An IP address on the destination interface.

Why it fails: RSPAN carries mirrored frames at Layer 2 inside a designated VLAN, so the destination interface never needs an IP address. The actual omission is configuring VLAN 100 as an RSPAN VLAN using the remote-span command. IP addressing belongs to ERSPAN, which tunnels mirrored traffic over a routed IP network.

A destination interface on the source switch.

Why it fails: RSPAN forwards mirrored traffic over the remote VLAN itself; no physical destination port is needed on the source switch. The stem's real gap is that VLAN 100 lacks the remote-span VLAN designation, which the switch requires before it will carry monitored frames. A destination interface applies only to local SPAN sessions.

The 'no shutdown' command on VLAN 100.

Why it fails: An RSPAN VLAN must be designated with the 'remote-span' VLAN configuration command; without it the destination remote vlan statement is rejected. The 'no shutdown' command is tempting because VLAN 100 must be up, but an unconfigured RSPAN VLAN fails regardless of interface state.

The ACL is applied only on the VLAN 10 subinterface, so return traffic from VLAN 20 is not filtered but the ACL on VLAN 10 drops it because the source address matches a deny entry.

Why it fails: This is incorrect because return traffic sourced from VLAN 20 enters the router through the VLAN 20 subinterface, so an inbound IPv6 ACL on VLAN 10 never sees it. Even if the ACL's deny entry matched the source address, the router would not evaluate it for packets arriving on VLAN 20; only an outbound filter on VLAN 10 could affect that flow, and the issue is a missing permit, not a deny match on the wrong interface.

The router has 'ipv6 unicast-routing' disabled, preventing inter-VLAN routing.

Why it fails: This is wrong because disabling 'ipv6 unicast-routing' globally stops the router from forwarding any IPv6 packet between subinterfaces, breaking all inter-VLAN communication, not just return traffic. The observed behavior—forward traffic succeeding and only return traffic failing—is a classic sign of a one-way ACL, not a missing routing enablement. Additionally, the router would not even build the IPv6 FIB for the subnets if unicast routing were off.

The ACL uses 'deny ipv6 any any' which blocks all traffic, but the permit statement for VLAN 10 to VLAN 20 is placed after the deny, causing it to be ignored.

Why it fails: This is wrong because IPv6 ACLs are processed sequentially with first-match semantics; a permit statement placed before the deny entry is evaluated first, so it is not ignored. If the ACL really ended with 'deny ipv6 any any' after a permit for VLAN 10 to VLAN 20, the forward traffic would be allowed and only unmatched return traffic would hit the deny. The actual problem is the absence of a permit for the return flow, not ordering—if ordering were as described, all traffic from VLAN 10 would be blocked too.

The source VLAN is not configured correctly on the source switch.

Why it fails: VLAN 30 is already the monitored source; misconfiguring it would drop that traffic entirely, not deliver unrelated broadcasts. This option tempts engineers who assume source-side faults, yet the symptom of other VLANs' broadcasts arriving points to the RSPAN VLAN itself being flooded as a normal VLAN rather than isolated.

The destination port is in the wrong VLAN.

Why it fails: Placing the destination port in RSPAN VLAN 200 is exactly what the design requires, so this is not the fault. The option tempts candidates who see a VLAN mismatch, but the real issue is that VLAN 200 was not declared as an RSPAN VLAN, so it floods broadcasts like any ordinary VLAN.

The trunk is not pruning VLAN 200 correctly.

Why it fails: Pruning controls which VLANs traverse a trunk; it does not cause a single VLAN's broadcasts to leak onto a destination port. The option tempts engineers focused on trunk filtering, but the actual fault is that VLAN 200 was not configured as an RSPAN VLAN, so it behaves as a normal flooding VLAN.

The trunk interface is not configured with 'switchport trunk encapsulation dot1q'.

Why it fails: Encapsulation governs how trunk frames are tagged on the wire; misconfiguration would break VLAN traffic entirely rather than make every flow report one VLAN ID. It is tempting because trunk encapsulation genuinely causes VLAN visibility problems, making it correct when subinterfaces fail to pass tagged traffic at all.

The flow monitor is applied only to the physical interface, not the subinterfaces.

Why it fails: Applying the monitor to the physical interface means Flexible NetFlow reads the trunk's outer header, so all flows inherit the native VLAN ID instead of per-VLAN tags. It is tempting because subinterface-level monitoring genuinely yields per-VLAN visibility, making it correct when the monitor must distinguish traffic by VLAN.

The collector does not support VLAN fields.

Why it fails: The collector simply receives exported records; it cannot force every VLAN to report an identical ID, so this does not explain uniform values. It is tempting because collector capability genuinely limits which exported fields are stored and displayed, making it correct when records arrive with correct VLAN tags but the collector drops that field.

Check that the destination port is not in a shutdown state.

Why it fails: A shutdown destination port would show down/down, but the stem gives no indication of link-state failure, and RSPAN destination ports stay in the RSPAN VLAN rather than forwarding normally. It is tempting because interface shutdown is a common first check, yet the real issue is the RSPAN VLAN not being designated as remote-span.

Ensure that the source interface is not configured with 'no monitor session'.

Why it fails: The 'no monitor session' command removes an entire session, so if it were applied the source would not be monitored at all — but the stem confirms monitoring is configured. It is tempting because session removal does stop traffic, yet the actual fault lies with the RSPAN VLAN's remote-span designation, not session deletion.

Confirm that the trunk between switches is configured as a dot1q trunk.

Why it fails: The trunk already carries VLAN 50, so dot1q encapsulation is not the fault; RSPAN requires the destination port to be removed from VLAN 50 and configured as a monitor destination, since a port in that VLAN cannot forward monitored traffic. Dot1q trunking is correct when VLANs must traverse a link.

Use the 'show authentication sessions interface' command to view the session status and method.

Why it fails: The 'show authentication sessions interface' command shows the authentication session details, such as the method used (dot1x, mab, webauth) and the status. While it can confirm if a session exists, it does not directly indicate whether EAPOL packets are being received or processed. It is less specific for EAPOL troubleshooting.

Check the 'show mac address-table interface' command to see if the supplicant's MAC address is learned.

Why it fails: The MAC address table shows learned MAC addresses, which can indicate if the supplicant is sending traffic. However, it does not confirm that EAPOL packets are being received or processed by the 802.1X authentication process. EAPOL frames are not learned in the MAC address table in the same way as regular data frames.

Use the 'show radius statistics' command to verify RADIUS server reachability.

Why it fails: The 'show radius statistics' command displays RADIUS packet statistics, such as access-requests and access-challenges. While it can help diagnose RADIUS communication issues, it does not show whether the switch is receiving EAPOL packets from the supplicant. The issue is between the supplicant and the switch, not the switch and the RADIUS server.

authentication host-mode multi-auth

Why it fails: This command sets the authentication host mode to allow multiple hosts to authenticate independently on the same port. It does not control VLAN assignment upon server failure and does not provide guest VLAN functionality. It is unrelated to the requirement of fallback VLAN when the RADIUS server is unreachable.

authentication event fail action authorize vlan 100

Why it fails: This command authorizes the port into VLAN 100 when authentication fails, such as when a user provides incorrect credentials. It does not handle the case where the RADIUS server is unreachable; that scenario requires the 'server dead' action. Using this command would not provide the guest VLAN fallback when the server is down.

authentication violation restrict

Why it fails: This command configures the switch to restrict the port when an authentication violation occurs, such as when a new MAC address appears on a port that has already been authenticated. It does not assign a guest VLAN when the RADIUS server is dead. It is used for security violation handling, not for server unavailability fallback.

The next-hop 192.168.1.1 is not reachable from R1 due to a routing issue.

Why it fails: The debug output confirms R1 successfully forwards packets to 192.168.1.1, proving the next-hop is reachable from R1; the failure occurs at R2, which drops traffic from 10.10.10.0/24 per its configured policy. This option is tempting because a missing route to the next-hop is a common PBR failure cause, and it would be correct if R1’s ‘debug ip packet’ showed no ARP reply or ICMP unreachable for 192.168.1.1, indicating a Layer 3 reachability problem.

The route-map on R1 is missing a 'set ip next-hop verify-availability' command, causing it to forward traffic to an unreachable next-hop.

Why it fails: The firewall replacement changed the next-hop reachability, but R1 already forwards successfully to 192.168.1.1, so verify-availability would not alter the drop. That command tracks next-hop liveness via ICMP or object tracking, and would be correct where a PBR next-hop could silently fail without a routing-table entry.

The VLAN interface on R1 has an ACL that is blocking traffic from 10.10.10.0/24.

Why it fails: The debug output confirms packets reach 192.168.1.1, proving R1’s VLAN interface has no ACL blocking the source subnet; an ACL would drop packets before they leave R1, contradicting the debug evidence. This option is tempting because ACLs are commonly used to filter traffic from specific VLANs at the ingress interface, and in a scenario where packets never appear in debug output, an ACL would be the correct root cause.

DHCP snooping has detected a rogue DHCP server on GigabitEthernet0/1.

Why it fails: The binding table lists legitimate client MAC-to-IP leases learned on trusted ports; it contains no record of DHCPOFFER or DHCPACK messages from an unauthorised server. Rogue-server detection requires DHCP snooping to log a server-originated frame arriving on an untrusted port, which this output does not show.

DHCP snooping is not functioning because the bindings are not trusted.

Why it fails: Bindings are populated precisely because snooping is working; the trust state applies to ports, not to individual bindings, so entries appearing here is normal operation. Trusted ports are configured on uplinks toward the legitimate DHCP server or relay, not on client-facing access ports.

DHCP snooping has a conflict because two clients are on the same interface.

Why it fails: Multiple MAC addresses on one interface is expected when a downstream switch or wireless access point connects through that port; snooping tracks each client independently. A conflict would require duplicate IP-to-MAC mappings, which the three distinct addresses and leases do not exhibit.

The session is misconfigured because the source must be a port, not a VLAN.

Why it fails: A remote destination session legitimately sources traffic from an RSPAN VLAN, so the configuration is valid; the source is not required to be a physical port. The misconception arises because local SPAN sessions do specify source ports or VLANs directly, making port-based sourcing the familiar pattern, yet RSPAN deliberately transports tagged traffic across the network via a dedicated VLAN.

The session is misconfigured because the destination port must have ingress enabled.

Why it fails: Ingress disabling is expected on an RSPAN destination port, so this is not a misconfiguration. The destination port must not forward normal traffic back into the network; ingress stays disabled by design. Enabling ingress would be relevant only for a local SPAN destination where you want the port to accept traffic.

The session is misconfigured because the RSPAN VLAN must be the same as the source VLAN.

Why it fails: The output shows a valid remote destination session, so no VLAN-matching rule is broken; RSPAN source and destination VLANs are independent, with traffic carried over the dedicated RSPAN VLAN. This option tempts engineers who conflate RSPAN with local SPAN, where source and destination ports share the same VLAN.

All devices are in ACTIVE state, indicating stable tracking.

Why it fails: The database shows three entries with differing states: two ACTIVE and one VERIFY, so claiming all are ACTIVE misreads the output. It is tempting because ACTIVE entries dominate and suggest healthy tracking, but the VERIFY row indicates a binding still being validated rather than stable.

Device tracking is disabled, and the database is empty.

Why it fails: The database clearly contains three populated entries with MAC addresses, IPv6 addresses and policies, so tracking is running. It is tempting because an empty database would explain a lack of output, but here the presence of ACTIVE and VERIFY rows proves device tracking is enabled and learning bindings.

Device tracking only tracks IPv4 addresses.

Why it fails: Device tracking maintains both IPv4 and IPv6 bindings; the output lists IPv6 addresses such as 2001:db8::1, confirming IPv6 tracking. It is tempting because the command is often associated with IPv4 snooping, but the ipv6 keyword and displayed IPv6 addresses directly contradict an IPv4-only claim.

The session is misconfigured because ERSPAN cannot use VLANs as source.

Why it fails: ERSPAN source sessions can monitor VLANs, including both directions, so using VLANs 10-20 as the source is valid. The claim is tempting because ERSPAN encapsulates traffic in GRE, but that encapsulation concerns the destination, not whether VLANs can be monitored.

The session is misconfigured because the ERSPAN ID must be less than 100.

Why it fails: ERSPAN IDs are 10-bit fields, so values up to 1023 are valid; 200 is accepted and the session is not misconfigured on that basis. The claim is tempting because ERSPAN IDs are often written as small numbers, but the range genuinely permits 1 through 1023.

The session is misconfigured because the destination IP must be on the same subnet.

Why it fails: ERSPAN tunnels monitored traffic in GRE to the destination IP, which is routed and need not share a subnet with the source. The claim is tempting because local SPAN destinations are interfaces, but ERSPAN's whole purpose is crossing Layer 3 boundaries.

Voice traffic uses a different CoS value, which SPAN ignores.

Why it fails: SPAN replicates frames verbatim regardless of Layer 2 CoS bits, so differing CoS values cannot cause voice packets to be omitted from the mirror. It is tempting because CoS is how voice gets prioritised, and would matter when diagnosing QoS queueing on the monitored link rather than capture completeness.

The voice VLAN is configured as a native VLAN, which SPAN does not capture.

Why it fails: SPAN sources are defined by VLAN, interface or port-channel; a native VLAN designation does not exclude that VLAN from a VLAN-based source, so voice traffic on it is still mirrored. The option is tempting because native VLAN tagging behaviour causes genuine capture confusion, and would apply when a trunk's untagged frames are missing.

The switch has a security ACL that blocks voice traffic from being mirrored.

Why it fails: ACLs filter forwarded traffic, not the SPAN copy; mirrored packets bypass egress and ingress ACL enforcement, so a security ACL cannot selectively strip voice frames. It is tempting because ACLs plausibly explain missing traffic, and would be correct if the monitoring destination port itself were administratively blocked.