hardMultiple Choice
300-410 Practice Question: An engineer configures unicast Reverse Path…
An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface. Traffic from a legitimate source IP is being dropped. The network has asymmetric routing. Which is the most likely explanation?
⚠ Common exam trap
Cisco often tests the distinction between strict and loose uRPF modes, and the trap here is that candidates assume any uRPF drop means the source is unreachable, when in fact asymmetric routing causes strict mode to drop legitimate traffic that would pass in loose mode.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The router receives the packet on an interface that is not the best return path to the source IP, causing strict uRPF to drop it.
Strict uRPF verifies that the source IP of an incoming packet is reachable via the exact interface on which the packet arrived. In asymmetric routing, the return path to the source may use a different interface, causing the router to see the incoming interface as not matching the best return path in the FIB. This mismatch triggers a drop, even though the source IP is legitimate and reachable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The router receives the packet on an interface that is not the best return path to the source IP, causing strict uRPF to drop it.
Why this is correct
Strict uRPF performs a two-part check: first, the source IP must exist in the FIB, and second, the inbound interface must be the exact interface used to reach the source IP. When traffic arrives on an interface that is not the best return path (e.g., due to asymmetric routing with equal-cost paths or policy-based routing), the router sees the source as unreachable via that interface and silently drops the packet. Even though the source is legitimate and routable, strict mode is intolerant of any interface mismatch, making this the correct explanation for the drop.
- ✗
The source IP is not in the routing table at all.
Why it's wrong here
If the source IP were truly absent from the routing table, uRPF in either strict or loose mode would drop the packet because neither mode allows forwarding when no route exists to the source. However, the question explicitly states the source is legitimate, meaning a valid route is present in the FIB. The cause is not a missing route but rather a mismatch between the incoming interface and the best reverse path, which is a distinct failure that only strict uRPF enforces.
- ✗
The uRPF configuration is missing the 'allow-default' option.
Why it's wrong here
The 'allow-default' option tells uRPF to accept the default route as a valid reverse path when checking the source IP. It is useful in scenarios where the only route to a source is the default route (e.g., DHCP-addressable users), but it does not waive the interface-match requirement in strict mode. Even if allow-default were present, a packet arriving on a non-preferred interface would still be dropped because the default route points out a different interface, so its absence is not the reason for this specific drop.
- ✗
The router is using loose mode instead of strict mode.
Why it's wrong here
Loose mode (configured with 'reachable-via any') only verifies that the source IP is present somewhere in the routing table, regardless of the interface on which the packet arrives. If the router were in loose mode, the packet would pass since the source is legitimate and routable; it would not be dropped for arriving on a non-best interface. The fact that the traffic is being dropped indicates strict mode is active, so suggesting loose mode is the cause is backwards.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
Courseiva writes every 300-410 question from scratch — 1,401 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 300-410 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 300-410 exam.