Scenario practice questions

A network engineer is implementing Control Plane Policing (CoPP) on a Cisco IOS XE router to protect against route processor overload. The engineer creates a class map matching OSPF and BGP traffic and a policy map that polices this traffic to 1 Mbps with a burst of 2000 bytes. After applying the policy map to the control plane, the engineer notices that OSPF adjacencies flap intermittently. Which action should the engineer take to resolve the flapping?

Trap 1: Disable OSPF authentication to reduce packet size and processing…

OSPF authentication does not significantly affect packet size or processing overhead in a way that would cause flapping due to CoPP. Disabling authentication would weaken security and not solve the policer dropping packets. The flapping is due to the policer rate, not authentication. The correct fix is to adjust CoPP parameters.

Trap 2: Configure a higher priority queue for OSPF traffic in the policy…

CoPP uses policing, not queuing, to rate-limit traffic. Priority queuing is not a feature of CoPP policy maps. While prioritization could help, the immediate issue is that the policer rate is too low, causing drops. Increasing the policed rate and burst size directly addresses the drops and resolves the flapping.

Trap 3: Apply the policy map to all interfaces instead of the control plane.

CoPP is specifically applied to the control plane to protect the route processor. Applying the policy to interfaces would affect data plane traffic and not protect the control plane. Moreover, it would not address the OSPF flapping caused by the policer dropping legitimate OSPF packets. The correct action is to adjust the policer parameters.

A
Disable OSPF authentication to reduce packet size and processing overhead.
Why it fails: OSPF authentication does not significantly affect packet size or processing overhead in a way that would cause flapping due to CoPP. Disabling authentication would weaken security and not solve the policer dropping packets. The flapping is due to the policer rate, not authentication. The correct fix is to adjust CoPP parameters.
B
Configure a higher priority queue for OSPF traffic in the policy map.
Why it fails: CoPP uses policing, not queuing, to rate-limit traffic. Priority queuing is not a feature of CoPP policy maps. While prioritization could help, the immediate issue is that the policer rate is too low, causing drops. Increasing the policed rate and burst size directly addresses the drops and resolves the flapping.
C
Apply the policy map to all interfaces instead of the control plane.
Why it fails: CoPP is specifically applied to the control plane to protect the route processor. Applying the policy to interfaces would affect data plane traffic and not protect the control plane. Moreover, it would not address the OSPF flapping caused by the policer dropping legitimate OSPF packets. The correct action is to adjust the policer parameters.
D
Increase the policed rate and burst size to accommodate legitimate routing protocol traffic.
Intermittent OSPF adjacency flapping indicates that legitimate OSPF packets are being dropped due to the policer rate being too low. Increasing the rate and burst size allows the routing protocol traffic to pass without being policed, stabilizing the adjacencies. CoPP policies must be tuned to permit normal control plane traffic while still protecting against attacks.

Read the full DHCP explanation →

Question 2easymultiple choice

A network engineer is configuring a Cisco IOS XE router to act as a DHCP server for a subnet. The router must assign IP addresses from the 192.168.100.0/24 pool, but the first 10 addresses and the last address in the range must be excluded from dynamic assignment. Which command accomplishes this requirement?

Trap 1: ip dhcp excluded-address 192.168.100.1 192.168.100.10…

The ip dhcp excluded-address command accepts only a single range or a single address per command. It does not support three separate arguments in one line. To exclude multiple non-contiguous addresses or ranges, multiple commands are required. This syntax is invalid and will be rejected by the router.

Trap 2: ip dhcp excluded-address 192.168.100.1 192.168.100.10 and ip dhcp…

The keyword 'and' is not valid in Cisco IOS configuration syntax. You cannot combine two separate commands with 'and' on a single line. Each exclusion must be configured as a separate command. This option is syntactically incorrect and would cause an error when entered.

Trap 3: ip dhcp excluded-address 192.168.100.1 192.168.100.10

This command excludes only the first 10 addresses (192.168.100.1 through 192.168.100.10) from the DHCP pool. It does not exclude the last address (192.168.100.254), which is also required to be excluded. Therefore, it does not fully meet the requirement of excluding both the first 10 addresses and the last address.

A
ip dhcp excluded-address 192.168.100.1 192.168.100.10 192.168.100.254
Why it fails: The ip dhcp excluded-address command accepts only a single range or a single address per command. It does not support three separate arguments in one line. To exclude multiple non-contiguous addresses or ranges, multiple commands are required. This syntax is invalid and will be rejected by the router.
B
ip dhcp excluded-address 192.168.100.1 192.168.100.10 and ip dhcp excluded-address 192.168.100.254
Why it fails: The keyword 'and' is not valid in Cisco IOS configuration syntax. You cannot combine two separate commands with 'and' on a single line. Each exclusion must be configured as a separate command. This option is syntactically incorrect and would cause an error when entered.
C
Two separate commands: ip dhcp excluded-address 192.168.100.1 192.168.100.10 and ip dhcp excluded-address 192.168.100.254
The ip dhcp excluded-address command can be entered multiple times to exclude different ranges or individual addresses. To exclude the first 10 addresses and the last address, you need two commands: one for the range 192.168.100.1 to 192.168.100.10, and another for the single address 192.168.100.254. This correctly meets all requirements.
D
ip dhcp excluded-address 192.168.100.1 192.168.100.10
Why it fails: This command excludes only the first 10 addresses (192.168.100.1 through 192.168.100.10) from the DHCP pool. It does not exclude the last address (192.168.100.254), which is also required to be excluded. Therefore, it does not fully meet the requirement of excluding both the first 10 addresses and the last address.

Study the full IPv6 explanation →

Question 3mediummultiple choice

A network engineer runs the following command on Router R1:

R1# show ipv6 interface tunnel 0

Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:1

No global unicast address is configured

Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:1 MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfiguration for addresses.

Based on this output, what is a likely problem?

Trap 1: The tunnel interface is down.

The output states Tunnel0 is up and line protocol is up, so the interface is not down. This option tempts engineers who assume a tunnel problem means link failure; checking line protocol status would be the correct diagnostic step when a tunnel genuinely shows down/down.

Trap 2: The MTU is too small for IPv6.

An MTU of 1480 bytes exceeds IPv6's 1280-byte minimum, so it is not too small. This tempts engineers who recall IPv6's larger header and assume fragmentation; reducing MTU is the correct fix when a path drops packets below 1280 bytes.

Trap 3: IPv6 is not enabled on the tunnel.

The output explicitly states IPv6 is enabled and shows a link-local address plus joined multicast groups, so IPv6 is active. This tempts engineers who equate the absence of a global unicast address with IPv6 being disabled; enabling IPv6 is the right action when the interface shows it disabled.

A
The tunnel interface is down.
Why it fails: The output states Tunnel0 is up and line protocol is up, so the interface is not down. This option tempts engineers who assume a tunnel problem means link failure; checking line protocol status would be the correct diagnostic step when a tunnel genuinely shows down/down.
B
The tunnel is not configured with a global IPv6 address, which may prevent routing of IPv6 traffic.
Without a global unicast address, the tunnel interface cannot source or terminate routable IPv6 traffic, so packets arriving from remote tunnel endpoints are dropped. The output explicitly states "No global unicast address is configured", meaning only the link-local FE80:: address exists, which is insufficient for forwarding IPv6 traffic across the tunnel.
C
The MTU is too small for IPv6.
Why it fails: An MTU of 1480 bytes exceeds IPv6's 1280-byte minimum, so it is not too small. This tempts engineers who recall IPv6's larger header and assume fragmentation; reducing MTU is the correct fix when a path drops packets below 1280 bytes.
D
IPv6 is not enabled on the tunnel.
Why it fails: The output explicitly states IPv6 is enabled and shows a link-local address plus joined multicast groups, so IPv6 is active. This tempts engineers who equate the absence of a global unicast address with IPv6 being disabled; enabling IPv6 is the right action when the interface shows it disabled.

Study the full EIGRP explanation →

Question 4hardmultiple choice

An EIGRP network with multiple routers is experiencing frequent stuck-in-active (SIA) events for prefix 10.10.10.0/24. The network topology includes a slow WAN link between R1 and R2. R1's show ip eigrp topology 10.10.10.0/24 shows the route in active state with a query outstanding to R2. R2's show ip eigrp topology shows the same prefix in passive state. The EIGRP timers are default. What is the root cause?

Trap 1: The active timer on R1 is too short for the slow WAN link; it…

The active timer is not the root cause of the SIA; it is only the threshold that triggers the error. R1's timer is set to a default value and is designed to accommodate normal query propagation, so increasing it would merely hide the underlying issue. If R2 is genuinely stuck waiting on a downstream neighbor, a longer timer will not make that neighbor reply faster.

Trap 2: The EIGRP hello timer mismatch between R1 and R2 is causing…

EIGRP hello timers are not negotiated between neighbors; each router independently sends hello packets at its configured interval, and the hold time, not the hello time, determines adjacency loss. Even if R1 and R2 have different hello timers, as long as the hold time is greater than the hello interval, the neighbor relationship remains stable. SIA is caused by query/reply delays, not by hello timer mismatch, so this option does not explain the problem.

Trap 3: The prefix 10.10.10.0/24 is being summarized, causing the query to…

EIGRP summarization affects which routes are advertised and how queries are scoped, but it does not by itself prevent a router from replying to a query. The question states that the specific prefix 10.10.10.0/24 is in active state, meaning the query is for that exact route, not a summary. If a summary were the issue, the active timer would be running for the summary route, not the specific prefix, so this does not align with the troubleshooting scenario.

A
The active timer on R1 is too short for the slow WAN link; it should be increased to accommodate query propagation delays.
Why it fails: The active timer is not the root cause of the SIA; it is only the threshold that triggers the error. R1's timer is set to a default value and is designed to accommodate normal query propagation, so increasing it would merely hide the underlying issue. If R2 is genuinely stuck waiting on a downstream neighbor, a longer timer will not make that neighbor reply faster.
B
R2 has a query outstanding to a neighbor over a slow link, preventing it from replying to R1 within the active timer.
This is the classic SIA cause: R1 sends a query to R2 for the prefix, and R2 must propagate that query to all its neighbors and wait for every reply before it can formulate an answer to R1. If one of R2's downstream neighbors is over a slow or unreliable link and delays its reply, R2's response to R1 is held up beyond R1's active timer. That delay triggers the 'Stuck In Active' condition on R1.
C
The EIGRP hello timer mismatch between R1 and R2 is causing neighbor flapping.
Why it fails: EIGRP hello timers are not negotiated between neighbors; each router independently sends hello packets at its configured interval, and the hold time, not the hello time, determines adjacency loss. Even if R1 and R2 have different hello timers, as long as the hold time is greater than the hello interval, the neighbor relationship remains stable. SIA is caused by query/reply delays, not by hello timer mismatch, so this option does not explain the problem.
D
The prefix 10.10.10.0/24 is being summarized, causing the query to be sent for the summary instead.
Why it fails: EIGRP summarization affects which routes are advertised and how queries are scoped, but it does not by itself prevent a router from replying to a query. The question states that the specific prefix 10.10.10.0/24 is in active state, meaning the query is for that exact route, not a summary. If a summary were the issue, the active timer would be running for the summary route, not the specific prefix, so this does not align with the troubleshooting scenario.

Review the full routing breakdown →

Question 5mediummultiple choice

A network administrator is configuring Unicast Reverse Path Forwarding (uRPF) on a Cisco IOS router to mitigate IP spoofing. The router has two interfaces: GigabitEthernet0/0 connects to the internet, and GigabitEthernet0/1 connects to the internal network. The administrator wants to ensure that packets arriving on GigabitEthernet0/0 are dropped if their source address is not reachable via that interface. However, the administrator also wants to allow asymmetric routing where return traffic may use a different path. Which uRPF mode should be configured on GigabitEthernet0/0?

Trap 1: ip verify unicast source reachable-via rx

The rx keyword enables strict uRPF, which requires that the source address be reachable via the same interface the packet arrived on. This would drop packets in asymmetric routing scenarios because the return path may differ. While it provides strong spoofing protection, it does not meet the requirement to allow asymmetric routing.

Trap 2: ip verify unicast reverse-path

The ip verify unicast reverse-path command is the older syntax for strict uRPF. It is equivalent to reachable-via rx and would therefore not allow asymmetric routing. This command would drop packets if the source is not reachable via the incoming interface, failing the requirement.

Trap 3: ip verify unicast source reachable-via tx

The tx keyword is not a valid option for uRPF. The correct keywords are rx for strict mode and any for loose mode. Using tx would result in a syntax error and not provide any spoofing protection. This option is invalid.

A
ip verify unicast source reachable-via rx
Why it fails: The rx keyword enables strict uRPF, which requires that the source address be reachable via the same interface the packet arrived on. This would drop packets in asymmetric routing scenarios because the return path may differ. While it provides strong spoofing protection, it does not meet the requirement to allow asymmetric routing.
B
ip verify unicast source reachable-via any
The any keyword enables loose uRPF, which checks that the source address is reachable via any interface in the routing table. This allows asymmetric routing because the return path can be different, while still dropping packets with spoofed source addresses that are not in the routing table. This meets the requirement.
C
ip verify unicast reverse-path
Why it fails: The ip verify unicast reverse-path command is the older syntax for strict uRPF. It is equivalent to reachable-via rx and would therefore not allow asymmetric routing. This command would drop packets if the source is not reachable via the incoming interface, failing the requirement.
D
ip verify unicast source reachable-via tx
Why it fails: The tx keyword is not a valid option for uRPF. The correct keywords are rx for strict mode and any for loose mode. Using tx would result in a syntax error and not provide any spoofing protection. This option is invalid.

Open the full VLAN trunking answer →

Question 6hardmultiple choice

A network uses PBR to route traffic from a specific VLAN (10.10.10.0/24) through a firewall (next-hop 192.168.1.1). After a firewall replacement, traffic from this VLAN is being dropped. Router R1 shows: 'show route-map' shows the route-map is applied, 'show ip policy' shows the policy on the VLAN interface, but 'debug ip packet' shows packets being sent to 192.168.1.1 and no response. Router R2 (firewall) shows: 'show ip route 10.10.10.0' returns a route via 192.168.2.1, but the firewall is configured to drop traffic from 10.10.10.0/24. What is the root cause?

Trap 1: The next-hop 192.168.1.1 is not reachable from R1 due to a routing…

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.

Trap 2: The route-map on R1 is missing a 'set ip next-hop…

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.

Trap 3: The VLAN interface on R1 has an ACL that is blocking traffic from…

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.

A
The firewall is configured to drop traffic from the source subnet 10.10.10.0/24. Update the firewall policy to allow this traffic.
The route-map and policy are correctly forwarding packets to 192.168.1.1, but the replacement firewall explicitly drops traffic sourced from 10.10.10.0/24, so no response returns. Amending the firewall policy to permit that source subnet satisfies the connectivity constraint.
B
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.
C
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.
D
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.

Question 7easymultiple choice

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

Trap 1: 10 seconds

The OSPF dead interval on broadcast and point-to-point networks defaults to four times the hello interval, giving 40 seconds, not 10. Ten seconds is tempting because it matches the default hello interval on those network types, which is a separate timer from the dead interval.

Trap 2: 30 seconds

Thirty seconds is not the OSPF broadcast default; the dead interval is four times the 10-second hello, so 40 seconds. Thirty seconds is tempting because it is the default dead interval on NBMA and point-to-multipoint networks, where the hello timer is 30 seconds.

Trap 3: 120 seconds

One hundred and twenty seconds is not the OSPF broadcast default; the dead interval equals four times the 10-second hello, giving 40 seconds. It is tempting because 120 seconds is the default dead interval on NBMA networks configured with a 30-second hello timer.

A
10 seconds
Why it fails: The OSPF dead interval on broadcast and point-to-point networks defaults to four times the hello interval, giving 40 seconds, not 10. Ten seconds is tempting because it matches the default hello interval on those network types, which is a separate timer from the dead interval.
B
30 seconds
Why it fails: Thirty seconds is not the OSPF broadcast default; the dead interval is four times the 10-second hello, so 40 seconds. Thirty seconds is tempting because it is the default dead interval on NBMA and point-to-multipoint networks, where the hello timer is 30 seconds.
C
40 seconds
OSPF derives the dead interval as four times the hello interval. On an Ethernet broadcast network the default hello is 10 seconds, giving a dead interval of 40 seconds, which matches the stem's broadcast media constraint rather than the 120-second non-broadcast default.
D
120 seconds
Why it fails: One hundred and twenty seconds is not the OSPF broadcast default; the dead interval equals four times the 10-second hello, giving 40 seconds. It is tempting because 120 seconds is the default dead interval on NBMA networks configured with a 30-second hello timer.

Question 8hardmultiple choice

A network engineer is troubleshooting a DMVPN Phase 3 network where spoke-to-spoke communication is not working. The hub is configured with ip nhrp redirect, and spokes are configured with ip nhrp shortcut. The routing protocol is OSPF, and the hub is configured with ip nhrp map multicast dynamic. The engineer notices that when a spoke pings another spoke's LAN IP, the first few pings fail, but subsequent pings succeed. However, the engineer wants to eliminate the initial packet loss. Which of the following is the most likely cause of the initial packet loss?

Trap 1: The hub is not configured with no ip next-hop-self for OSPF,…

In DMVPN Phase 3, the hub should not use next-hop-self for OSPF, as that would prevent spokes from learning the correct next hop. However, if next-hop-self were enabled, spokes would always route through the hub, and direct tunnels would never be built. The scenario indicates that direct tunnels are eventually built, so next-hop-self is likely already disabled. The initial packet loss is a normal part of the NHRP resolution process.

Trap 2: The hub is not configured with ip nhrp redirect, so the first…

The scenario states that the hub is configured with ip nhrp redirect. Therefore, this is not the cause. Even if it were, the initial packet loss would be due to the spoke not having a direct tunnel yet, but the hub would still forward the packets. The issue is more about the timing of NHRP resolution and routing convergence.

Trap 3: The spokes are not configured with ip nhrp shortcut, so they cannot…

The scenario states that spokes are configured with ip nhrp shortcut. If they were not, spoke-to-spoke communication would likely fail entirely, not just initially. The fact that subsequent pings succeed indicates that direct tunnels are eventually built, so the shortcut command is present and working.

A
The hub is not configured with no ip next-hop-self for OSPF, causing the spokes to use the hub as the next hop and delaying direct tunnel establishment.
Why it fails: In DMVPN Phase 3, the hub should not use next-hop-self for OSPF, as that would prevent spokes from learning the correct next hop. However, if next-hop-self were enabled, spokes would always route through the hub, and direct tunnels would never be built. The scenario indicates that direct tunnels are eventually built, so next-hop-self is likely already disabled. The initial packet loss is a normal part of the NHRP resolution process.
B
The hub is not configured with ip nhrp redirect, so the first packets are dropped while NHRP resolution occurs.
Why it fails: The scenario states that the hub is configured with ip nhrp redirect. Therefore, this is not the cause. Even if it were, the initial packet loss would be due to the spoke not having a direct tunnel yet, but the hub would still forward the packets. The issue is more about the timing of NHRP resolution and routing convergence.
C
The spokes are not configured with ip nhrp shortcut, so they cannot build direct tunnels.
Why it fails: The scenario states that spokes are configured with ip nhrp shortcut. If they were not, spoke-to-spoke communication would likely fail entirely, not just initially. The fact that subsequent pings succeed indicates that direct tunnels are eventually built, so the shortcut command is present and working.
D
The initial packet loss is expected because the spoke must first send an NHRP resolution request and receive a reply before building the direct tunnel.
In DMVPN Phase 3, when a spoke needs to reach another spoke's network, it initially sends packets to the hub. The hub forwards them and sends an NHRP redirect to the source spoke. The source spoke then sends an NHRP resolution request for the destination spoke's NBMA address, waits for a reply, and then builds a direct tunnel. During this process, the first few packets may be dropped or delayed. This is a normal behavior and not a configuration error.

Review the full routing breakdown →

Question 9easymulti select

Which TWO configuration steps are required to implement Policy-Based Routing (PBR) on a Cisco router? (Choose TWO.)

Trap 1: Configure an access-list to match the traffic.

An access-list is used inside the route-map's match statements, not as a standalone required step. PBR requires defining a route-map with match and set clauses and applying it to the interface, so the ACL alone is insufficient.

Trap 2: Enable CEF globally.

CEF is enabled by default on modern Cisco IOS and is not a PBR configuration step. PBR needs a route-map defining match criteria and set next-hop, plus interface application via 'ip policy route-map'; enabling CEF configures nothing for policy routing.

Trap 3: Use the 'ip local policy route-map' command.

'ip local policy route-map' applies PBR to router-generated traffic only, not to transit traffic being routed through interfaces. Interface-level 'ip policy route-map' is required for forwarded packets, so this command addresses the wrong traffic class.

A
Create a route-map with match and set commands.
PBR requires a route-map defining the match criteria identifying traffic and the set clauses specifying the next-hop or interface. Without this policy definition, the router has no instructions to deviate from destination-based forwarding, so creating the route-map is an essential configuration step before it can be applied.
B
Apply the route-map to an interface using the 'ip policy route-map' command.
A route-map has no effect until attached to an interface's ingress path via the 'ip policy route-map' command. This binding is what activates policy evaluation on received packets, satisfying the stem's requirement for a mandatory PBR configuration step alongside defining the route-map itself.
C
Configure an access-list to match the traffic.
Why it fails: An access-list is used inside the route-map's match statements, not as a standalone required step. PBR requires defining a route-map with match and set clauses and applying it to the interface, so the ACL alone is insufficient.
D
Enable CEF globally.
Why it fails: CEF is enabled by default on modern Cisco IOS and is not a PBR configuration step. PBR needs a route-map defining match criteria and set next-hop, plus interface application via 'ip policy route-map'; enabling CEF configures nothing for policy routing.
E
Use the 'ip local policy route-map' command.
Why it fails: 'ip local policy route-map' applies PBR to router-generated traffic only, not to transit traffic being routed through interfaces. Interface-level 'ip policy route-map' is required for forwarded packets, so this command addresses the wrong traffic class.

Open the full BGP breakdown →

Question 10hardmultiple choice

BGP is used between two ISPs. Router R1 has: neighbor 10.0.0.2 route-map SET-MED in, route-map SET-MED permit 10, set metric 50. Router R2 shows: show ip bgp 172.16.0.0 includes MED 50 but the path is not preferred. What is the root cause?

Trap 1: The MED value is too low to influence path selection.

MED is only compared between paths from the same neighbouring autonomous system; R2 received the route from a different AS, so the value is discarded before best-path selection. It tempts because 50 is numerically low, but MED has no absolute scale — only relative comparison within one AS applies.

Trap 2: The route-map should be applied outbound, not inbound.

MED is compared only between routes from the same neighbouring AS, so setting it inbound on R1 does not influence R2's selection here. Outbound application would be correct when the local router advertises routes to an external peer and must influence that peer's entry path.

Trap 3: The neighbor has a higher local preference overriding MED.

Local preference is exchanged only within an autonomous system via IBGP; R2 receives this route from an external ISP peer, so no local preference value from R1 overrides the MED. Local preference would decide if both paths arrived via IBGP inside one AS.

A
The MED value is too low to influence path selection.
Why it fails: MED is only compared between paths from the same neighbouring autonomous system; R2 received the route from a different AS, so the value is discarded before best-path selection. It tempts because 50 is numerically low, but MED has no absolute scale — only relative comparison within one AS applies.
B
The route-map should be applied outbound, not inbound.
Why it fails: MED is compared only between routes from the same neighbouring AS, so setting it inbound on R1 does not influence R2's selection here. Outbound application would be correct when the local router advertises routes to an external peer and must influence that peer's entry path.
C
MED is only compared when paths are from the same neighboring AS.
BGP compares MED only between paths originating from the same neighbouring autonomous system. R2 received the MED 50 route from a different AS than the competing path, so the attribute is ignored during best-path selection, leaving that route unpreferred despite the lower metric.
D
The neighbor has a higher local preference overriding MED.
Why it fails: Local preference is exchanged only within an autonomous system via IBGP; R2 receives this route from an external ISP peer, so no local preference value from R1 overrides the MED. Local preference would decide if both paths arrived via IBGP inside one AS.

Open the full BGP breakdown →

Question 11hardmultiple choice

An engineer enables unicast RPF (uRPF) in strict mode on an interface. Afterward, some legitimate traffic from a BGP neighbor is dropped. The neighbor has two paths to the router, and traffic may arrive on a different interface than the return path. What is the most likely explanation?

Trap 1: The uRPF 'allow-default' option was not configured, so default…

The allow-default option only affects whether the default route can satisfy the uRPF lookup; it does not explain drops when a specific route to the source exists but points out a different interface. It is tempting because default-route handling is a genuine uRPF nuance, but it is irrelevant to this asymmetric-path scenario.

Trap 2: The neighbor's BGP updates have a source IP that is not in the…

Strict uRPF checks that the source is reachable via the same interface the packet arrived on; asymmetric arrival on the other path fails that check even though the source prefix is present in the routing table. The option is tempting because missing routes do cause drops, but here the route exists via a different interface.

Trap 3: Loose mode should be used instead, but strict mode was configured…

Strict uRPF drops traffic arriving on an interface other than the one the routing table uses to reach the source; switching to loose mode would accept any source present in the table regardless of arrival interface. Loose mode is tempting for multihomed asymmetric designs, but the stem asks for the explanation of the drops, not a remedy.

A
Strict uRPF drops packets if the source IP is not reachable via the receiving interface, which fails in asymmetric routing scenarios.
Strict uRPF checks that the packet's source is reachable through the receiving interface's routing table. With two paths and asymmetric routing, return traffic may use a different interface, so legitimate BGP-sourced packets fail the check and are dropped.
B
The uRPF 'allow-default' option was not configured, so default routes are ignored.
Why it fails: The allow-default option only affects whether the default route can satisfy the uRPF lookup; it does not explain drops when a specific route to the source exists but points out a different interface. It is tempting because default-route handling is a genuine uRPF nuance, but it is irrelevant to this asymmetric-path scenario.
C
The neighbor's BGP updates have a source IP that is not in the routing table.
Why it fails: Strict uRPF checks that the source is reachable via the same interface the packet arrived on; asymmetric arrival on the other path fails that check even though the source prefix is present in the routing table. The option is tempting because missing routes do cause drops, but here the route exists via a different interface.
D
Loose mode should be used instead, but strict mode was configured by mistake.
Why it fails: Strict uRPF drops traffic arriving on an interface other than the one the routing table uses to reach the source; switching to loose mode would accept any source present in the table regardless of arrival interface. Loose mode is tempting for multihomed asymmetric designs, but the stem asks for the explanation of the drops, not a remedy.

Study the full ACL explanation →

Question 12mediummultiple choice

A network engineer is troubleshooting a PBR (Policy-Based Routing) issue on router R5. The engineer configured a route-map to set the next-hop for traffic from a specific source subnet. The route-map is applied to the incoming interface, but traffic from the source subnet is still being forwarded using the regular routing table. The engineer verifies that the ACL matches the traffic correctly. What is the most likely cause?

Trap 1: The route-map is applied outbound instead of inbound on the…

Applying the route-map outbound on the incoming interface means it never evaluates ingress traffic, so local PBR policy is bypassed entirely. It is tempting because outbound PBR is valid for egress interfaces, and would be correct if the requirement were to policy-route traffic leaving the router rather than entering it.

Trap 2: The ACL is using a standard ACL, which cannot match source subnet…

Standard ACLs match source addresses, so they can identify the source subnet; the failure stems from PBR requiring a route-map applied to the incoming interface with 'ip policy route-map', and the ACL merely classifies traffic. It tempts because ACL type affects matching, but standard ACLs suffice for source-based policy.

Trap 3: The route-map has a 'set default interface' command that overrides…

A 'set default interface' only applies when no next-hop is specified; with an explicit next-hop set, it is ignored, so it cannot override the forwarding decision. It is tempting because default-interface commands do steer traffic when next-hop is absent, which would be correct if the route-map lacked a next-hop statement.

A
The route-map is missing a 'set ip next-hop' command, or the next-hop is not reachable.
Policy-based routing only diverts traffic when the route-map both matches via the ACL and executes a set clause. Without a reachable 'set ip next-hop', the route-map permits the packet and normal destination-based forwarding via the routing table continues, exactly as observed.
B
The route-map is applied outbound instead of inbound on the interface.
Why it fails: Applying the route-map outbound on the incoming interface means it never evaluates ingress traffic, so local PBR policy is bypassed entirely. It is tempting because outbound PBR is valid for egress interfaces, and would be correct if the requirement were to policy-route traffic leaving the router rather than entering it.
C
The ACL is using a standard ACL, which cannot match source subnet correctly.
Why it fails: Standard ACLs match source addresses, so they can identify the source subnet; the failure stems from PBR requiring a route-map applied to the incoming interface with 'ip policy route-map', and the ACL merely classifies traffic. It tempts because ACL type affects matching, but standard ACLs suffice for source-based policy.
D
The route-map has a 'set default interface' command that overrides the next-hop.
Why it fails: A 'set default interface' only applies when no next-hop is specified; with an explicit next-hop set, it is ignored, so it cannot override the forwarding decision. It is tempting because default-interface commands do steer traffic when next-hop is absent, which would be correct if the route-map lacked a next-hop statement.

Review the full routing breakdown →

Question 13hardmultiple 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.

The allow-default option permits the default route to satisfy the reverse lookup, which is a loose-mode behaviour; strict mode deliberately omits it. Adding it is tempting because it appears to relax the check. Intermittent failures stem from asymmetric routing, where the reverse path exits a different interface than the one receiving traffic.

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

A missing route for the source address would drop traffic consistently, not intermittently, and strict uRPF already requires a matching route. It is tempting because uRPF is fundamentally a source-address lookup. The actual cause is asymmetric routing: the reverse path points out a different interface, so legitimate return packets fail the check.

Trap 3: The interface has multiple IP addresses.

Strict uRPF checks only the primary address of the receiving interface against the routing table; additional secondary addresses do not alter that lookup, so they cannot explain intermittent drops. Multiple addresses are tempting because they complicate interface configuration. Asymmetric routing itself causes the failure, since return traffic arrives on an interface the FIB would not select.

A
Asymmetric routing causes packets to arrive on an interface that is not the best return path, so uRPF drops them.
Strict uRPF checks that the source address is reachable via the same interface the packet arrived on. With asymmetric routing, return traffic uses a different path, so the incoming interface fails the reverse-path lookup and legitimate packets are dropped, causing intermittent connectivity.
B
The uRPF configuration is missing the 'allow-default' option.
Why it fails: The allow-default option permits the default route to satisfy the reverse lookup, which is a loose-mode behaviour; strict mode deliberately omits it. Adding it is tempting because it appears to relax the check. Intermittent failures stem from asymmetric routing, where the reverse path exits a different interface than the one receiving traffic.
C
The routing table does not have a route for the source IP.
Why it fails: A missing route for the source address would drop traffic consistently, not intermittently, and strict uRPF already requires a matching route. It is tempting because uRPF is fundamentally a source-address lookup. The actual cause is asymmetric routing: the reverse path points out a different interface, so legitimate return packets fail the check.
D
The interface has multiple IP addresses.
Why it fails: Strict uRPF checks only the primary address of the receiving interface against the routing table; additional secondary addresses do not alter that lookup, so they cannot explain intermittent drops. Multiple addresses are tempting because they complicate interface configuration. Asymmetric routing itself causes the failure, since return traffic arrives on an interface the FIB would not select.

Question 14easymultiple choice

In a VRF-Lite scenario with OSPF, what is the default network type on a physical Ethernet interface?

Trap 1: Point-to-point

Ethernet defaults to broadcast network type, so OSPF expects a DR/BDR election and multicasts hellos. Point-to-point applies to serial links or interfaces configured with the ip ospf network point-to-point command, where no DR/BDR election occurs and hellos are unicast.

Trap 2: Non-broadcast

Ethernet defaults to broadcast network type; non-broadcast applies to NBMA media such as Frame Relay or X.25, where neighbours must be statically defined with neighbour statements because multicast hellos cannot reach them. A physical Ethernet interface supports broadcast and multicast natively.

Trap 3: Point-to-multipoint

Ethernet defaults to broadcast, not point-to-multipoint. Point-to-multipoint suits NBMA topologies such as Frame Relay or DMVPN hubs, treating the interface as a collection of point-to-point links without a DR/BDR election, which is unnecessary on a broadcast LAN segment.

A
Point-to-point
Why it fails: Ethernet defaults to broadcast network type, so OSPF expects a DR/BDR election and multicasts hellos. Point-to-point applies to serial links or interfaces configured with the ip ospf network point-to-point command, where no DR/BDR election occurs and hellos are unicast.
B
Broadcast
Physical Ethernet interfaces default to the broadcast network type in OSPF, electing a DR and BDR and using multicast hellos. Point-to-point applies only to serial links or explicit configuration, so no DR election occurs here.
C
Non-broadcast
Why it fails: Ethernet defaults to broadcast network type; non-broadcast applies to NBMA media such as Frame Relay or X.25, where neighbours must be statically defined with neighbour statements because multicast hellos cannot reach them. A physical Ethernet interface supports broadcast and multicast natively.
D
Point-to-multipoint
Why it fails: Ethernet defaults to broadcast, not point-to-multipoint. Point-to-multipoint suits NBMA topologies such as Frame Relay or DMVPN hubs, treating the interface as a collection of point-to-point links without a DR/BDR election, which is unnecessary on a broadcast LAN segment.