An interview question asks: What is uRPF, and how do strict and loose mode differ? The useful answer explains both the source-address lookup and the legitimate traffic that the wrong setting can drop.
Short answer: Unicast Reverse Path Forwarding is a source-address validation mechanism. Strict uRPF checks whether the packet arrived on an interface that the reverse-path lookup would use to reach its source; loose uRPF checks whether an acceptable route to that source exists, without requiring the incoming interface to match.[1]
Strict vs loose uRPF: the comparison
RFC 3704 describes strict RPF, feasible-path RPF, loose RPF, and loose RPF that ignores default routes as distinct approaches to ingress filtering.[1]
| Question | Strict uRPF | Loose uRPF |
|---|---|---|
| Which packet address is checked? | Source address | Source address |
| What must the lookup establish? | A reverse path through the receiving interface | An acceptable route to the source |
| Must the receiving interface match? | Yes, under the strict reverse-path test | No |
| Can ordinary asymmetric routing cause rejection? | Yes | Not just because interfaces differ |
| Does passing prove that the sender owns the source address? | No | No |
| What about a default route? | Check the implementation and configuration | Explicitly check whether defaults count; there is a separate ignore-default variant |
The table summarizes the filtering models and their limitations, not universal hardware defaults.[1]
Memory aid: strict asks “could I send back through this interface?”; loose asks “do I have an acceptable route back at all?”[1]
Packet flow: look up the source, not the destination
In strict mode, the source address is looked up in the Forwarding Information Base (FIB), and the receiving interface is compared with the reverse forwarding path.[1]
Use this conceptual decision tree when explaining the feature:
Packet arrives on interface A
|
+-- Read the packet's SOURCE address
|
+-- Look up the source using the applicable RPF lookup rules
|
+-- No acceptable route? --> Fail the uRPF check
|
+-- Acceptable route exists
|
+-- Loose mode --> Pass the uRPF check
|
+-- Strict mode --> Does the reverse path accept A?
Yes: pass No: fail
This is an explanatory model, not a hardware pipeline specification or executed router trace. Default routes, route eligibility, and alternate-path support need to be checked against the actual implementation; RFC 3704 explicitly discusses implementation differences and feasible-path variants.[1]
Passing a source-validation check is not proof of sender identity: a router away from the source can establish that a claimed source is plausible within a prefix, not authenticate the originating host.[1]
Why strict uRPF can break asymmetric routing
Consider a fictional router with two WAN interfaces. All addresses below are documentation examples, not a production design.
Incoming packet:
source 198.51.100.25
destination 192.0.2.10
ingress WAN-B
Relevant reverse lookup:
198.51.100.0/24 --> WAN-A
Assume a single usable reverse path, no special exceptions, and an ordinary usable route to the source. Strict uRPF rejects this packet because the reverse interface is WAN-A but the receiving interface is WAN-B; loose uRPF accepts it because the route exists.[1]
The packet could be completely legitimate. RFC 3704 warns that strict RPF can reject valid traffic under asymmetry and that missing legitimate prefixes in the filtering router's FIB can also cause rejection.[1]
For an interview, distinguish “this source is invalid” from “this source failed the locally configured reverse-path test.” They are not interchangeable conclusions.[1]
Worked decision table
The following fictional cases apply the same basic model; “pass” means only that the uRPF check passes, not that every other forwarding or security check succeeds.
| Incoming interface | Acceptable reverse route | Strict result | Loose result |
|---|---|---|---|
| WAN-A | Source prefix via WAN-A | Pass | Pass |
| WAN-B | Source prefix via WAN-A | Fail | Pass |
| WAN-B | Source prefix via WAN-B | Pass | Pass |
| WAN-A | No route to the source | Fail | Fail |
These decisions follow the strict and loose definitions in RFC 3704.[1]
The default-route trap in loose mode
Do not answer “loose uRPF accepts anything as long as the router has a default route” without a qualification. RFC 3704 distinguishes loose RPF from loose RPF ignoring default routes, and describes differences in how implementations handle a default.[1]
If the default is accepted as sufficient reachability, the filter can lose its ability to reject otherwise unrouted source addresses; ignoring the default preserves an explicit-route presence check.[1]
This creates a useful interview follow-up:
A branch has only a default route toward its provider. Should you enable loose uRPF with defaults excluded on that uplink?
Not blindly: legitimate remote sources may have no explicit matching route, so excluding the only available default can cause them to fail the source check.[1]
Recommended pre-change questions: Which routes count? Is the default accepted? Which forwarding context is checked? What happens during failover? Write down the answers before enabling enforcement.
Where should strict or loose mode be used?
Strict RPF is a strong candidate at an edge where the expected source prefixes are reachable through the receiving interface and the routing behavior supports that assumption.[1]
Loose RPF avoids the interface-match constraint, but is a weaker anti-spoofing control: a forged source belonging to somebody else's routed address space can still pass.[1]
Feasible-path RPF expands validation to eligible alternate paths rather than considering only the single best path; it can address some asymmetric scenarios, but depends on the relevant route advertisements reaching the validating router.[1]
My recommended design checklist is:
- Predictable single-homed customer edge: evaluate strict mode and test withdrawals, reconvergence, and management reachability.
- Asymmetric or multihomed boundary: evaluate source-prefix ACLs or supported feasible-path validation before settling for loose mode.
- Default-only routing: test explicit-route and default-route behavior separately.
- Loose mode chosen: document the residual risk; do not describe it as complete source-prefix authorization.
RFC 3704 treats ingress access lists as another source-validation option and recommends considering the security tradeoffs when using more relaxed RPF approaches.[1]
Troubleshooting checklist: valid traffic drops after enabling uRPF
Use this as a proposed workflow, not a claim that a router lab was executed:
- Capture one failing example. Record source, destination, actual incoming interface, timestamp, and routing context.
- Confirm the configured check. Identify strict, loose, or alternate-path behavior and any default-route or exception settings.
- Look up the source. Inspect the relevant forwarding entry, not just the destination route or the existence of a BGP advertisement.
- Compare interfaces. For strict mode, compare the packet's incoming interface with the reverse lookup result.
- Correlate evidence. Check platform-specific uRPF drop counters before and after a small controlled test. Do not diagnose uRPF solely because ping fails.
- Check routing changes. Repeat while the preferred uplink changes and while a source-prefix route is withdrawn.
- Choose the smallest justified correction. Fix missing intended routes or an unsuitable validation policy; do not disable all source validation as the default response.
The source/FIB comparison and routing-change checks follow from the failure modes described in RFC 3704.[1]
Suggested evidence worksheet:
Packet source:
Receiving interface and routing context:
Configured uRPF mode:
Default-route treatment:
Matching source route and reverse interface(s):
uRPF counter change during controlled test:
Expected result during normal operation:
Expected result after WAN failover:
Rollback condition:
Common interview pitfalls
- Looking up the destination. The reverse-path validation described here uses the source address.[1]
- Calling every strict-mode drop spoofing. Asymmetry or an incomplete routing view can also reject legitimate traffic.[1]
- Saying loose mode stops all spoofing. A forged address from another routed prefix may pass.[1]
- Ignoring default-route policy. “A route exists” is incomplete unless you know which routes the implementation accepts.[1]
- Assuming every alternate route counts. Feasible-path validation is a distinct capability with routing-information requirements; do not assume a backup advertisement automatically satisfies a strict check.[1]
- Treating source validation as authentication. A plausible source prefix is not proof of the originating host's identity.[1]
A concise interview answer
“uRPF validates the source address of an incoming packet against routing information. Strict mode requires the receiving interface to match the reverse path; loose mode requires an acceptable route to the source but does not require the same interface.”[1]
“Strict mode can reject legitimate asymmetric traffic. Loose mode is more tolerant of that asymmetry, but can still accept spoofed addresses from routed prefixes, so I would check the default-route behavior, routing visibility, and failover cases before deployment.”[1]
Summary and related reading
Strict checks source reachability plus direction; loose checks source reachability without that directional requirement. Neither should be selected without understanding the available routes and the limitations of source validation.[1]
For the surrounding concepts, continue with:
- Administrative Distance vs Metric vs Longest Prefix Match
- ACL Basics: Standard vs Extended and Implicit Deny
- DHCP Snooping vs DAI vs IP Source Guard
Preparing for a network engineering interview? Draw the two-WAN example, predict both mode results, then explain why accepting a routed source is not the same as authenticating its sender.
Post a Comment