Router R1 Cannot Reach R3 Practice Questions

The EtherChannel is using PAgP.

Why it fails: The EtherChannel is using PAgP. The output clearly shows the EtherChannel protocol as LACP (Link Aggregation Control Protocol, IEEE 802.3ad), not PAgP (Port Aggregation Protocol, Cisco proprietary). In the 'show etherchannel summary' output, the 'Protocol' column would list LACP, confirming that PAgP is not in use. PAgP and LACP are mutually exclusive, so this option is factually incorrect.

Port Gi0/3 is bundled in the channel.

Why it fails: Port Gi0/3 is bundled in the channel. In 'show etherchannel summary', each member port is assigned a flag: 'P' means the port is bundled and actively participating in the channel, while 'D' means the port is down or administratively down. Gi0/3 shows the flag 'D', not 'P', so it is not part of the active EtherChannel bundle. Only ports with the 'P' flag are actively forwarding traffic.

The port-channel is a Layer 3 interface.

Why it fails: The port-channel is a Layer 3 interface. The output identifies the port-channel's layer type via a flag on the logical interface: 'S' signifies a Layer 2 port-channel, whereas 'R' would denote a Layer 3 routed port-channel. Since the flag shown is 'S', the EtherChannel is operating at Layer 2, making this statement incorrect. A Layer 3 port-channel would require an 'R' flag and an IP address configured on the logical interface.

The VRF is missing the route-target export command.

Why it fails: The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.

The PE router is not running a routing protocol with the CE router.

Why it fails: PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.

The MPLS LDP is not enabled on the PE-CE link.

Why it fails: MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.

The AS-path contains the local AS number.

Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.

BGP synchronization is enabled.

Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.

The maximum-prefix limit has been exceeded.

Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.

The physical interface is configured with 'no ip address'.

Why it fails: The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.

The default route is pointing to the wrong next-hop IP.

Why it fails: A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.

The ISP's gateway is not responding to ICMP.

Why it fails: While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.

The interface is configured as an access port.

Why it fails: The show interfaces trunk output explicitly lists the Administrative Mode as 'trunk' and the Operational Mode as 'trunk', which directly contradicts the assertion that the interface is configured as an access port. An access port would have an administrative mode of 'static access' or 'dynamic auto' and would not appear in the trunk output. Therefore, this conclusion is unsupported by the command output.

The native VLAN is tagged with 802.1Q.

Why it fails: Actually, native VLAN tagging is enabled, meaning the native VLAN is tagged, but the statement is ambiguous. However, the correct interpretation is that native VLAN tagging is enabled, but the question asks what can be concluded. Option B is more directly supported.

All VLANs except 2-1001 are pruned.

Why it fails: The line 'Pruning VLANs Enabled: 2-1001' indicates that VLANs 2 through 1001 are eligible for pruning, meaning the switch may remove them from the trunk for load balancing if the neighbor does not use them. It does not state that these VLANs are actually being pruned, nor does it imply that all other VLANs are pruned. The phrasing 'except 2-1001 are pruned' inverts the correct meaning, confusing eligibility with active pruning.

Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping

Why it fails: This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.

Apply a service policy that uses a priority queue for voice only

Why it fails: Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.

Increase the number of queues to eight

Why it fails: Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.

The RP is not configured as the DR on its segment.

Why it fails: The Designated Router (DR) on a segment is responsible only for sending PIM register messages on behalf of a directly connected source, not for selecting the tree used by other routers. The RP's DR status on its own segment has no bearing on whether last-hop routers use the SPT or the shared tree. In this scenario, the issue is purely a tree-switching delay, not any DR misconfiguration on the RP's link.

The multicast source is using a different group address.

Why it fails: If the source were sending to a different group address, the last-hop router wouldn't receive those packets at all—they'd be dropped because the router has no group state for that other group. The fact that traffic is flowing at all, albeit via the RP, proves the group address is correctly matched. This option incorrectly conflates the tree type with group addressing; the group address is consistent, and the actual problem is the absence of an SPT switchover.

The last-hop router has a higher metric to the source than to the RP.

Why it fails: The SPT switchover in PIM-SM is triggered by the first packet arriving at the last-hop router, or by the spt-threshold configuration—not by any comparison of unicast metrics to the source versus the RP. Even if the metric to the source is higher, PIM defaults to switching to the SPT anyway, and a higher metric would only delay the switch if a policy like spt-threshold were in place. Thus, a metric difference alone cannot explain why the traffic remains on the shared tree.

All IP SLA operations are active.

Why it fails: The asterisk (*) in the output of `show ip sla` is the indicator that an operation is actively running, and it appears exclusively next to operation ID 4. Every other operation listed lacks this marker, which means they are either configured but not scheduled, or they are in an inactive or stopped state. Therefore, interpreting all operations as active is a misreading of the state column and would be incorrect for this output.

IP SLA operation 3 has failed.

Why it fails: Operation 3 is reported with a status of 'Success', which is the direct opposite of a failed state. In IP SLA output, a failed operation would display a status such as 'Timeout', 'Over threshold', or a non-zero return code. Since the output explicitly shows 'Success' for operation 3, it has not failed; it is operating normally and generating expected results.

IP SLA operation 1 has the highest round-trip time.

Why it fails: The 'Last' column in IP SLA output records the most recent round-trip time (RTT) measurement, and operation 1 shows a value of 1, which is the lowest number among the listed operations. Assuming this is a common unit like seconds or milliseconds, a value of 1 cannot be the highest RTT. Furthermore, the 'Last' column may reflect a different metric depending on the operation type, but in no reasonable interpretation does operation 1 represent the highest round-trip time.

Both neighbors are using MD5 authentication.

Why it fails: The EIGRP neighbor table command output (show ip eigrp neighbors) does not include any authentication-related fields, such as the key ID or hash algorithm, because authentication is configured under the EIGRP process or interface, not displayed in the neighbor adjacency table. A stable neighbor relationship can exist with or without authentication, and this output offers no evidence to determine whether MD5 or any other authentication method is in use. Therefore, the statement about MD5 authentication is unsupported by the provided data.

Neighbor 192.168.1.2 has a higher metric than 10.1.1.2.

Why it fails: The EIGRP neighbor table lists neighbor IP addresses along with hold time, uptime, SRTT, RTO, queue count, and sequence number, but it does not display metric values for routes learned from those neighbors. Metrics are stored and shown in the EIGRP topology table (show ip eigrp topology), which contains the composite metric and vector metrics for each route. Without topology table output, there is no basis to claim that 192.168.1.2 has a higher metric than 10.1.1.2.

Router R1 is using EIGRP named mode.

Why it fails: The header 'EIGRP-IPv4 Neighbors for AS(100)' is the format used for classic EIGRP configuration, which is created with the 'router eigrp 100' global configuration command. In named mode (EIGRP named configuration), the output includes VRF and address-family context, such as 'EIGRP-IPv4 Neighbors for VRF(NAME)' or 'EIGRP-IPv4 Neighbors for AS(100) VRF(NAME)' when using address-family configuration. The absence of a VRF or address-family label in the header indicates the router is running classic EIGRP mode, not named mode.

30 seconds

Why it fails: The 30-second value is the default OSPF HelloInterval for NBMA (Non-Broadcast Multi-Access) networks such as Frame Relay, ATM, and X.25, where multicast Hello delivery is not natively supported. Ethernet, by contrast, natively supports multicast/broadcast, so OSPF uses the faster 10-second HelloInterval as its default. A 30-second hello would not be the default on Ethernet, and a neighbor using the default dead interval of 40 seconds would be declared down almost immediately because the dead interval is only four times the default 10-second hello, not four times 30 seconds.

5 seconds

Why it fails: A 5-second hello interval is the default for OSPF on NBMA (Non-Broadcast Multi-Access) networks, not for Ethernet. On an Ethernet broadcast multi-access link, the default hello interval is 10 seconds. This option is tempting because 5 seconds is the default for OSPF point-to-point and NBMA interfaces, so it is correct for those specific network types, but the stem explicitly specifies an Ethernet link.

40 seconds

Why it fails: The 40-second value is not a hello interval at all — it is the default OSPF RouterDeadInterval on broadcast and point-to-point networks, including Ethernet. This dead interval is four times the HelloInterval (4 × 10 seconds = 40 seconds) and represents how long a router waits without receiving a Hello packet before declaring its neighbor down. Since the question specifically asks for the hello interval, this option is incorrect, even though 40 seconds is the related default dead timer for the same interface type.

Telnet from 10.0.0.0/8 is denied.

Why it fails: Entry 10 permits Telnet from 10.0.0.0/8.

SSH from 172.16.0.0/16 is denied.

Why it fails: Entry 30 permits SSH from 172.16.0.0/16.

All traffic is permitted.

Why it fails: Telnet and SSH from unauthorized sources are denied.

The OSPF adjacency between PE1 and CE1 is down.

Why it fails: An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.

The VRF forwarding table on PE1 is full.

Why it fails: A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.

MPLS LDP is not enabled on the PE1-CE1 link.

Why it fails: LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

VRF CUSTOMER-A is not using BGP for routing

Why it fails: This statement is incorrect because the routing table for VRF CUSTOMER-A explicitly includes a BGP entry. The 'B' code in the output is standard for Border Gateway Protocol routes, and the presence of this entry with a valid next-hop (192.168.1.2) proves BGP is operational for this VRF. BGP is often configured under 'router bgp' with an address-family ipv4 (or ipv6) vrf CUSTOMER-A to enable per-VRF route exchange. Therefore, claiming BGP is not used contradicts the direct evidence from the show ip route vrf output.

The default route is learned via BGP

Why it fails: The gateway of last resort being 10.0.1.1 does not mean the default route was learned via BGP. A default route in the routing table is shown as 0.0.0.0/0, and its source can be static configuration, connected, or a dynamic protocol such as OSPF or EIGRP. The BGP entry for 10.0.2.0/24 is a distinct, non-default prefix, and there is no indication in the output that a BGP-learned default route exists. It is equally plausible the default route is a static route pointed to 10.0.1.1 originating from the service provider or local configuration.

GigabitEthernet0/0.100 is not associated with VRF CUSTOMER-A

Why it fails: This is incorrect because the directly connected route for GigabitEthernet0/0.100 appears within the VRF CUSTOMER-A routing table. If the subinterface had not been associated with the VRF, its connected network would reside in the global routing table instead. A subinterface is placed into a VRF by issuing the 'vrf forwarding CUSTOMER-A' command under the interface configuration, which tags all subsequently learned routes on that interface with the VRF instance. Therefore, the presence of that interface's connected routes in the VRF table is definitive proof of association.