Scenario practice questions

A network engineer is troubleshooting an OSPFv2 adjacency issue between two routers connected via a VLAN trunk. R1 and R2 are in different VLANs but are connected through a Layer 2 switch. The engineer has configured 'ip ospf 1 area 0' on the subinterfaces. The adjacency forms but is stuck in INIT state. What is the most likely cause?

Trap 1: The OSPF hello interval is mismatched between the two routers.

A hello interval mismatch would cause the adjacency to not form at all, not to be stuck in INIT.

Trap 2: The subinterfaces are in different VLANs, preventing Layer 2…

If they were in different VLANs, the routers would not receive each other's hellos, so no adjacency would form.

Trap 3: The OSPF network type is set to point-to-point on one side and…

A network type mismatch would cause the adjacency to be stuck in EXSTART or EXCHANGE, not INIT.

A
The routers have the same OSPF router ID.
When a router receives a hello packet with its own router ID, it ignores it, causing the adjacency to stay in INIT.
B
The OSPF hello interval is mismatched between the two routers.
Why wrong: A hello interval mismatch would cause the adjacency to not form at all, not to be stuck in INIT.
C
The subinterfaces are in different VLANs, preventing Layer 2 communication.
Why wrong: If they were in different VLANs, the routers would not receive each other's hellos, so no adjacency would form.
D
The OSPF network type is set to point-to-point on one side and broadcast on the other.
Why wrong: A network type mismatch would cause the adjacency to be stuck in EXSTART or EXCHANGE, not INIT.

Open the full BGP breakdown →

Question 2mediummultiple choice

A network engineer runs the following command on Router R1:

R1# show ip bgp 10.1.1.0/24

BGP routing table entry for 10.1.1.0/24, version 10 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 Local

10.2.2.2 from 10.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 Community: 100:200

Based on this output, what is the problem?

Trap 1: The route 10.1.1.0/24 is learned via an eBGP session and has a…

The route is marked as 'Local', meaning it was redistributed from an IGP, not learned via eBGP.

Trap 2: The community 100:200 is automatically assigned by BGP for all…

Communities are not automatically assigned; they must be configured via route-maps.

Trap 3: The route is not being advertised to any peers because it is not…

The route is marked as best, so it is advertised.

A
The route 10.1.1.0/24 is learned via an eBGP session and has a local preference of 100.
Why wrong: The route is marked as 'Local', meaning it was redistributed from an IGP, not learned via eBGP.
B
The route 10.1.1.0/24 is redistributed from an IGP into BGP, as indicated by the 'Local' path.
The 'Local' path attribute in BGP indicates the route was originated locally via network statement or redistribution from an IGP.
C
The community 100:200 is automatically assigned by BGP for all redistributed routes.
Why wrong: Communities are not automatically assigned; they must be configured via route-maps.
D
The route is not being advertised to any peers because it is not marked as best.
Why wrong: The route is marked as best, so it is advertised.

Open the full BGP breakdown →

Question 3hardmultiple choice

An engineer configures iBGP between two routers in the same AS. The BGP table shows the prefix, but it is not installed in the routing table. The next-hop is reachable via an IGP route. Which is the most likely explanation?

Trap 1: The next-hop-self command is missing on the iBGP peer.

Missing next-hop-self would cause unreachable next-hop, but next-hop is reachable.

Trap 2: The prefix is filtered by an inbound route-map.

Filtered prefix would not appear in BGP table.

Trap 3: The maximum-paths limit is exceeded.

Maximum-paths affects load balancing, not installation.

A
BGP synchronization is enabled, and the prefix is not present in the IGP.
Correct. Synchronization prevents route installation if IGP does not have the prefix.
B
The next-hop-self command is missing on the iBGP peer.
Why wrong: Missing next-hop-self would cause unreachable next-hop, but next-hop is reachable.
C
The prefix is filtered by an inbound route-map.
Why wrong: Filtered prefix would not appear in BGP table.
D
The maximum-paths limit is exceeded.
Why wrong: Maximum-paths affects load balancing, not installation.

Review the full routing breakdown →

Question 4hardmultiple choice

An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface facing the Internet. Legitimate traffic from a customer network is being dropped. The traffic has a source IP that belongs to the customer's prefix, which is reachable via a different interface on the router. Which is the most likely explanation?

Trap 1: The 'ip verify unicast source reachable-via any' command was used…

That would be loose mode, which would not drop the traffic.

Trap 2: The router has a default route pointing out the same interface,…

Default route can cause uRPF to pass traffic that should be dropped.

Trap 3: The 'ip urpf allow-default' command is missing, causing default…

Allow-default affects loose mode, not strict mode.

A
The 'ip verify unicast source reachable-via any' command was used instead of 'rx'.
Why wrong: That would be loose mode, which would not drop the traffic.
B
The router has a default route pointing out the same interface, causing uRPF to pass all traffic.
Why wrong: Default route can cause uRPF to pass traffic that should be dropped.
C
The customer traffic is arriving on an interface where the return path to the source is via a different interface, violating strict uRPF.
Strict uRPF requires symmetric routing; asymmetric routing causes drops.
D
The 'ip urpf allow-default' command is missing, causing default routes to be ignored.
Why wrong: Allow-default affects loose mode, not strict mode.

Read the full VRF explanation →

Question 5hardmultiple choice

A large enterprise network is experiencing intermittent reachability between VRF-A on Router R1 and VRF-B on Router R2. R1 has the following relevant configuration: ip vrf VRF-A, rd 100:1, route-target export 100:1, route-target import 100:2. R2 shows: ip vrf VRF-B, rd 200:2, route-target export 200:2, route-target import 200:1. The link between R1 and R2 is configured with VRF forwarding VRF-A on R1 and VRF forwarding VRF-B on R2. What is the root cause?

Trap 1: The RD values must match for VRF-Lite to work on a direct link.

Incorrect: RD values do not need to match; they are used for route distinguishment, not for route exchange.

Trap 2: The VRFs must have the same name on both routers for direct…

Incorrect: VRF names are local and can differ; connectivity depends on route-target matching.

Trap 3: The interface must be in the same VRF on both ends; route-targets…

Incorrect: In VRF-Lite, route-targets are used for route leaking; if VRFs differ, route-targets must be configured correctly.

A
The route-target import and export values are mismatched between the VRFs, preventing route exchange.
Correct: R1 exports RT 100:1, but R2 imports RT 200:1; R2 exports RT 200:2, but R1 imports RT 100:2. No common RT exists.
B
The RD values must match for VRF-Lite to work on a direct link.
Why wrong: Incorrect: RD values do not need to match; they are used for route distinguishment, not for route exchange.
C
The VRFs must have the same name on both routers for direct connectivity.
Why wrong: Incorrect: VRF names are local and can differ; connectivity depends on route-target matching.
D
The interface must be in the same VRF on both ends; route-targets are irrelevant for VRF-Lite.
Why wrong: Incorrect: In VRF-Lite, route-targets are used for route leaking; if VRFs differ, route-targets must be configured correctly.

Read the full VRF explanation →

Question 6mediummultiple choice

Consider the following configuration: ```

ip vrf CUSTOMER_E

rd 200:1 route-target export 200:1 route-target import 200:1 !

interface GigabitEthernet0/0
 ip vrf forwarding CUSTOMER_E
 ip address 172.16.0.1 255.255.255.0

interface GigabitEthernet0/1
 ip vrf forwarding CUSTOMER_E
 ip address 172.16.1.1 255.255.255.0

``` What is the effect of the route-target commands in this VRF-Lite scenario?

Trap 1: The route-targets enable automatic route redistribution between…

Incorrect. Route-targets alone do not enable redistribution; they are used in MP-BGP for route import/export.

Trap 2: The route-targets cause the VRF to import and export routes from…

Incorrect. Route-targets do not interact with the global table directly.

Trap 3: The configuration will fail because route-targets are not allowed…

Incorrect. Route-targets are allowed but have no effect without MP-BGP.

A
The route-targets enable automatic route redistribution between VRFs.
Why wrong: Incorrect. Route-targets alone do not enable redistribution; they are used in MP-BGP for route import/export.
B
The route-targets are ignored because VRF-Lite does not use MP-BGP.
This is correct. In VRF-Lite, route-targets are not processed unless there is an MP-BGP configuration.
C
The route-targets cause the VRF to import and export routes from the global routing table.
Why wrong: Incorrect. Route-targets do not interact with the global table directly.
D
The configuration will fail because route-targets are not allowed in VRF-Lite.
Why wrong: Incorrect. Route-targets are allowed but have no effect without MP-BGP.

Question 7easymultiple choice

What is the default OSPF dead interval on an Ethernet broadcast network?

Trap 1: 10 seconds

10 seconds is the default hello interval, not the dead interval.

Trap 2: 30 seconds

30 seconds is not a default OSPF timer for broadcast networks.

Trap 3: 120 seconds

120 seconds is the default dead interval on non-broadcast networks (hello 30 seconds).

A
10 seconds
Why wrong: 10 seconds is the default hello interval, not the dead interval.
B
30 seconds
Why wrong: 30 seconds is not a default OSPF timer for broadcast networks.
C
40 seconds
The dead interval is 4 times the hello interval (10 seconds) = 40 seconds.
D
120 seconds
Why wrong: 120 seconds is the default dead interval on non-broadcast networks (hello 30 seconds).

Question 8hardmultiple choice

A VRF-aware network has VRF BLUE on routers R1 and R2. Routes are leaked between VRF BLUE and the global table on R1 using route-replicate. R2 shows: 'show ip route vrf BLUE' includes a route 10.10.10.0/24 learned via OSPF, but 'show ip route' (global) on R1 does not include this route. R1 configuration: ip vrf BLUE, rd 100:1, route-target export 100:1, route-target import 100:1, and 'route-replicate from vrf BLUE to global unicast 10.10.10.0 255.255.255.0'. What is the root cause?

Trap 1: The OSPF route in VRF BLUE has a tag that prevents it from being…

No tag is mentioned; the route-replicate command does not filter by default.

Trap 2: The route 10.10.10.0/24 is not in the VRF BLUE table on R1 because…

The route is in R2's VRF table, but R1 must have it in its VRF table to leak it; the scenario does not specify if R1 has the route.

Trap 3: The route-replicate command requires a route-map to specify the…

The command can use a prefix list or route-map; the example shows a prefix, but the command syntax may be incorrect.

A
The 'route-replicate' command is not configured under the VRF, so it does not take effect; it must be placed under 'ip vrf BLUE'.
The route-replicate command is a subcommand of the VRF configuration; if entered in global configuration mode, it is ignored or causes an error.
B
The OSPF route in VRF BLUE has a tag that prevents it from being leaked.
Why wrong: No tag is mentioned; the route-replicate command does not filter by default.
C
The route 10.10.10.0/24 is not in the VRF BLUE table on R1 because it is learned via R2.
Why wrong: The route is in R2's VRF table, but R1 must have it in its VRF table to leak it; the scenario does not specify if R1 has the route.
D
The route-replicate command requires a route-map to specify the prefix, but none is provided.
Why wrong: The command can use a prefix list or route-map; the example shows a prefix, but the command syntax may be incorrect.

Question 9hardmultiple choice

Management traffic to a router's loopback interface is being dropped. Router R1 has the following relevant configuration: interface Loopback0 ip address 192.168.1.1 255.255.255.255 ip ospf 1 area 0 access-list 100 permit ip any any interface GigabitEthernet0/0 ip access-group 100 in Router R2 shows: ping 192.168.1.1 source 10.1.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) What is the root cause?

Trap 1: The ACL is missing a permit for ICMP; add permit icmp any any.

The ACL permits all IP, so ICMP is included.

Trap 2: The loopback interface is not advertised via OSPF; check routing.

Routing may be fine; ping fails due to filtering, not reachability.

Trap 3: The ACL is applied outbound; change to inbound.

The snippet shows inbound; direction is correct.

A
Control Plane Policing (CoPP) is rate-limiting ICMP traffic to the router.
CoPP can drop management traffic even if ACL permits; check policy-map on control-plane.
B
The ACL is missing a permit for ICMP; add permit icmp any any.
Why wrong: The ACL permits all IP, so ICMP is included.
C
The loopback interface is not advertised via OSPF; check routing.
Why wrong: Routing may be fine; ping fails due to filtering, not reachability.
D
The ACL is applied outbound; change to inbound.
Why wrong: The snippet shows inbound; direction is correct.

Review the full routing breakdown →

Question 10hardmultiple choice

An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface connected to a network with asymmetric routing. Users report intermittent connectivity issues. Which is the most likely explanation?

Trap 1: The uRPF configuration is missing the 'allow-default' option.

Allow-default is for loose mode, not strict.

Trap 2: The routing table does not have a route for the source IP.

If no route, uRPF would drop all packets, not intermittent.

Trap 3: The interface has multiple IP addresses.

Multiple IPs do not cause uRPF issues.

A
Asymmetric routing causes packets to arrive on an interface that is not the best return path, so uRPF drops them.
Correct. Strict mode requires symmetric routing.
B
The uRPF configuration is missing the 'allow-default' option.
Why wrong: Allow-default is for loose mode, not strict.
C
The routing table does not have a route for the source IP.
Why wrong: If no route, uRPF would drop all packets, not intermittent.
D
The interface has multiple IP addresses.
Why wrong: Multiple IPs do not cause uRPF issues.

Question 11hardmultiple choice

An engineer configures BFD on an OSPF link and also applies a distribute-list outbound under the OSPF process. The BFD session is up, but OSPF routes are not being advertised to the neighbor. The engineer verifies that the distribute-list is correctly configured. What is the most likely cause?

Trap 1: The distribute-list is applied outbound, but OSPF distribute-lists…

This is incorrect because although distribute-list outbound does filter routes from being installed in the routing table, it does not prevent LSA advertisement for intra-area and inter-area routes. However, on an ABR, if an 'area range' is configured, the summary LSA can be filtered by the distribute-list, which would prevent advertisement—contradicting the statement that routes are still advertised.

Trap 2: The BFD session is flapping due to a mismatch in the 'bfd interval'…

The BFD session is up per the scenario, so flapping is unlikely. BFD mismatch would cause the session to go down, not just withdraw routes while the session is up.

Trap 3: The distribute-list references an ACL that denies the network, but…

OSPF distribute-lists can reference ACLs to filter specific routes, but ACLs do filter based on network addresses. However, the statement that type 3 LSAs are not affected by ACLs is false; ACLs can match the network in the summary LSA. But the key point is that the distribute-list outbound on an ABR can filter the summary LSA generated by 'area range'.

A
The distribute-list is applied outbound, but OSPF distribute-lists only filter routes in the routing table, not LSAs, so the routes are still advertised.
Why wrong: This is incorrect because although distribute-list outbound does filter routes from being installed in the routing table, it does not prevent LSA advertisement for intra-area and inter-area routes. However, on an ABR, if an 'area range' is configured, the summary LSA can be filtered by the distribute-list, which would prevent advertisement—contradicting the statement that routes are still advertised.
B
The BFD session is flapping due to a mismatch in the 'bfd interval' command, causing OSPF to withdraw routes.
Why wrong: The BFD session is up per the scenario, so flapping is unlikely. BFD mismatch would cause the session to go down, not just withdraw routes while the session is up.
C
The distribute-list references an ACL that denies the network, but OSPF uses type 3 LSAs that are not affected by ACLs.
Why wrong: OSPF distribute-lists can reference ACLs to filter specific routes, but ACLs do filter based on network addresses. However, the statement that type 3 LSAs are not affected by ACLs is false; ACLs can match the network in the summary LSA. But the key point is that the distribute-list outbound on an ABR can filter the summary LSA generated by 'area range'.
D
The 'area range' command is configured on the ABR, summarizing the route, and the distribute-list is filtering the summary.
This is correct. When an ABR has an 'area range' command summarizing a network, it creates a type 3 LSA for that summary. If a distribute-list outbound is applied that denies that summary network, the ABR will not advertise the type 3 LSA to neighbors in other areas. This explains why routes are not being advertised despite the BFD session being up.

Study the full IPv6 explanation →

Question 12mediummultiple choice

A network engineer is troubleshooting a scenario where a router is dropping IPv6 packets that are destined for a server on a directly connected network. The engineer checks the interface and finds that uRPF is enabled in loose mode. The router has a default route pointing to an upstream router. The source address of the packets is 2001:db8:100::1, which is not in the routing table (the router has no route to that prefix). What is the most likely cause of the packet drops?

Trap 1: The uRPF loose mode check fails because the source address is not…

Incorrect because loose mode does not require the same interface; it only requires any route.

Trap 2: The router has an ACL that blocks traffic from that source.

Incorrect because the symptom is specifically related to uRPF, not an ACL.

Trap 3: The uRPF mode should be strict mode to allow the traffic.

Incorrect because strict mode would also drop the packet if the route does not point back to the same interface.

A
The uRPF loose mode check fails because there is no route to the source address in the routing table.
Correct because loose mode requires at least one route to the source address in the FIB; if no route exists, the packet is dropped.
B
The uRPF loose mode check fails because the source address is not reachable via the same interface.
Why wrong: Incorrect because loose mode does not require the same interface; it only requires any route.
C
The router has an ACL that blocks traffic from that source.
Why wrong: Incorrect because the symptom is specifically related to uRPF, not an ACL.
D
The uRPF mode should be strict mode to allow the traffic.
Why wrong: Incorrect because strict mode would also drop the packet if the route does not point back to the same interface.

Question 13mediummultiple choice

A network engineer is troubleshooting an OSPFv2 adjacency issue between two directly connected routers, R1 and R2, both running IOS-XE. The link is a point-to-point Ethernet link. The engineer issues 'show ip ospf neighbor' on R1 and sees no neighbors. 'show ip ospf interface GigabitEthernet0/0' on R1 shows 'Network Type BROADCAST', but the link is actually a point-to-point link. Both routers have 'ip ospf 1 area 0' configured on the interface. What is the most likely cause of the adjacency not forming?

Trap 1: The OSPF network type mismatch between the two routers (one is…

Both show BROADCAST, so no mismatch.

Trap 2: The interface is configured with 'ip ospf passive-interface'.

Passive interface would still allow the router to receive hellos but not send them, but the neighbor list would show the neighbor in INIT state, not absent.

Trap 3: The OSPF process is not enabled globally; 'router ospf 1' is…

If 'ip ospf 1 area 0' is configured on the interface, the process is automatically created if not already present.

A
The OSPF network type mismatch between the two routers (one is BROADCAST, the other is POINT-TO-POINT).
Why wrong: Both show BROADCAST, so no mismatch.
B
The routers have duplicate OSPF router IDs.
Duplicate router IDs prevent OSPF adjacency from forming; each router must have a unique router ID.
C
The interface is configured with 'ip ospf passive-interface'.
Why wrong: Passive interface would still allow the router to receive hellos but not send them, but the neighbor list would show the neighbor in INIT state, not absent.
D
The OSPF process is not enabled globally; 'router ospf 1' is missing.
Why wrong: If 'ip ospf 1 area 0' is configured on the interface, the process is automatically created if not already present.

Review the full subnetting walkthrough →

Question 14hardmultiple choice

A large enterprise network is experiencing intermittent reachability from a specific subnet (10.1.1.0/24) to a critical server (192.168.10.10). Router R1 has PBR configured to forward traffic from 10.1.1.0/24 to next-hop 10.2.2.2, but traffic is also being load-balanced via the routing table to 10.3.3.3. Router R2 shows: 'show ip route 192.168.10.10' returns a route via 10.4.4.4, but 'show ip policy' on R1 shows the route-map is applied. What is the root cause?

Trap 1: The ACL in the route-map is incorrectly matching traffic from…

The ACL is correctly matching the subnet, as evidenced by the symptom. The issue is with next-hop reachability, not ACL matching.

Trap 2: The routing table on R1 has a higher administrative distance for…

PBR overrides the routing table for matched traffic, regardless of administrative distance. The routing table only applies if PBR is not configured or if the route-map does not match.

Trap 3: The next-hop 10.2.2.2 is reachable but the path is congested,…

The symptom is due to unreachability, not congestion. The 'verify-availability' command would still be needed to detect the unreachability.

A
The route-map is missing the 'set ip next-hop verify-availability' command, causing PBR to forward traffic to an unreachable next-hop.
Without 'verify-availability', PBR does not check if the next-hop is reachable. Adding this command ensures PBR only uses the next-hop if it is reachable, falling back to the routing table otherwise.
B
The ACL in the route-map is incorrectly matching traffic from 10.1.1.0/24, causing PBR to be applied to the wrong traffic.
Why wrong: The ACL is correctly matching the subnet, as evidenced by the symptom. The issue is with next-hop reachability, not ACL matching.
C
The routing table on R1 has a higher administrative distance for the route to 192.168.10.10 via 10.3.3.3, causing PBR to be ignored.
Why wrong: PBR overrides the routing table for matched traffic, regardless of administrative distance. The routing table only applies if PBR is not configured or if the route-map does not match.
D
The next-hop 10.2.2.2 is reachable but the path is congested, causing intermittent packet drops.
Why wrong: The symptom is due to unreachability, not congestion. The 'verify-availability' command would still be needed to detect the unreachability.