How Does uRPF Strict Mode Handle Asymmetric Return Traffic on R1?
Refer to the exhibit. R1 is multihomed to ISP1 and ISP2. uRPF strict mode has been configured on both interfaces uplinked to the ISPs. Traffic destined to the Internet over ISP1 returns to R1 via ISP2 and is immediately dropped. Which configuration changes address this issue and allow return traffic from the other ISP? - 
Community Votes
62% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests whether you know strict uRPF needs the allow-default keyword when the only route back to a source is a default route; the trap is choosing the plain rx command (A) or the interface that never sees the return traffic.
uRPF strict mode drops R1's asymmetric return traffic because the only reverse path to the Internet source is the default route learned from the providers. This page confirms that adding allow-default to the ISP2 uplink (option B) restores the return path while keeping the anti-spoofing check in place.
Choosing A: re-applying ip verify unicast source reachable-via rx on fastethernet 0/1 without allow-default. The drop stays in place because sources reachable only through the provider's default route still fail the strict uRPF check on a multihomed edge.
Community Discussion (10 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Strict uRPF on R1 demands that a packet's source be reachable through the very interface the packet arrived on, so a multihomed router with asymmetric routing is a classic failure case. R1 receives only default routes from ISP1 and ISP2, meaning the source address of Internet return traffic arriving on the ISP2 uplink (FastEthernet 0/1) matches nothing more specific than 0.0.0.0/0. Option B adds ip verify unicast source reachable-via rx allow-default on that interface, which lets the check accept the default route as a valid reverse path, so the return traffic is forwarded instead of being dropped by the FIB lookup. Security is still enforced for spoofed sources that have no route at all, and the interface that was actually dropping packets is the one that is changed.Why the Other Options Are Wrong
Option A applies the same strict check on fastethernet 0/1 but omits allow-default, so packets whose only return path is the default route continue to fail uRPF and are discarded — nothing about the symptom changes. Options C and D move the command to fastethernet 0/0, which is the uplink associated with the outbound (ISP1) direction in this scenario, so the interface that is actually dropping the asymmetric return traffic is untouched; even D, which does include allow-default, targets the wrong port. The only combination that both enables allow-default and lands on the ingress interface carrying the unwanted traffic is B, which is why the answer key and the majority of learners converge on it.Community Comment Notes
Most voters defend B on the default-route argument: tubirubs notes that "allow-default is configured when the return of traffic is over on default route", assuming the ISPs hand R1 default routes rather than full tables. 21bc749 reaches the same conclusion from the topology itself, pointing out that an Internet connection "means a default route, which means allow-default", and 0d2257b adds that this is a multihomed ISP link where both paths lead to the Internet. Pietjeplukgeluk dissents in favor of A, arguing the question does not give enough information to justify allow-default, while bk989 concedes that both A and B can work if the default route specifically points out fastethernet 0/1. That caveat is real: strict uRPF passes when the reverse path's exit interface matches the ingress interface, but on a multihomed design that alignment is not guaranteed, so allow-default remains the durable fix.Exam Strategy
When a uRPF question describes traffic leaving through one ISP and returning through another, first identify the ingress interface where the drop occurs and ask whether R1 has a specific route back to the source. If the only path is a default route, the answer must include allow-default on that ingress interface; options that keep the plain rx check, or that reconfigure the interface on the outbound path, never remove the drop.
Frequently Asked Questions
Why isn't plain "ip verify unicast source reachable-via rx" enough on the ISP2 interface?
Without allow-default, strict uRPF drops any packet whose only matching route is the default route learned from the providers, so the asymmetric return traffic from ISP2 still fails the check.
When would option A (plain rx on f0/1) still work?
Only if the default route's exit interface happens to be fastethernet 0/1 itself, making the reverse path match the ingress interface. On a multihomed edge that alignment isn't guaranteed, so allow-default (B) is the reliable fix.
Related Analysis
Practice All 300-410 Questions
Access 159 questions with complete answers and detailed explanations.
View Full 300-410 Practice Test →