Strict uRPF breaks asymmetric traffic on a dual-homed VPRN
VPRN 200 serves a logistics customer. CE-A at the main site is dual-homed by eBGP in AS 65100 to PE-1 and PE-2, advertising 10.20.0.0/16. PE-1 and PE-2 are iBGP peers in AS 65000. An inbound route policy on PE-1 sets local-preference 200 on routes received from CE-A; PE-2 has no such policy, so its locally received eBGP copy keeps the default local-preference 100 while the iBGP copy from PE-1 arrives with 200. CE-A balances its outbound traffic roughly 50/50 across the two eBGP links. The security baseline requires uRPF strict on all customer-facing VPRN SAPs, and it was enabled on both PEs last week. Since then about half of CE-A's outbound sessions to remote sites fail, while inbound connections to CE-A work. The uRPF drop counter on PE-2's SAP rises steadily and PE-1's does not. show router 200 route-table on PE-2 shows 10.20.0.0/16 with next-hop PE-1.
1. Explain the drop and why it is asymmetric and roughly 50%.
Read the worked answer
Strict uRPF asks: would this router send a packet back to the source out of the interface it just arrived on? If not, drop.
- CE-A balances outbound traffic 50/50 over its two eBGP links, so roughly half of CE-A's packets arrive on PE-2's SAP.
- On PE-2, the best route to 10.20.0.0/16 is the iBGP copy from PE-1 (local-preference 200), not the directly received eBGP copy (local-preference 100). The FIB therefore points 10.20.0.0/16 at PE-1, not at the SAP.
- Every packet sourced from 10.20.0.0/16 that arrives on PE-2's SAP fails the check and is dropped. The same packets on PE-1 pass, because PE-1's best path is the SAP.
- That produces ~50% loss, only for CE-A-originated traffic, and only on PE-2's counter. Inbound connections work because their return traffic is sourced elsewhere.
- Nothing is being spoofed: the source is legitimate. The security feature is behaving as designed against an asymmetry the local-preference policy created.
2. Weigh the options to fix it - loose uRPF, removing uRPF on the SAP, correcting the local-preference asymmetry, or applying uRPF only on WAN-facing interfaces. Recommend one and justify it against the security baseline.
Read the worked answer
- Remove uRPF on the SAP: restores service, violates the baseline and leaves the customer-facing interface with no anti-spoofing. Not acceptable as a steady state.
- Loose uRPF: checks only that the source is reachable somewhere in the VPRN. It still blocks unallocated and unknown sources, which is the common spoofing case, and it tolerates this asymmetry. It is weaker than strict, so it needs a documented exception against the baseline.
- Fix the local-preference asymmetry: apply the same inbound policy on both PEs, or stop the PE-1 copy from being preferred over PE-2's local route. Then PE-2's FIB points at the SAP and strict uRPF passes. This also removes the forwarding detour through PE-1, which is a performance problem in its own right. The caution is that it changes the customer's path selection, so it needs the customer's agreement and a maintenance window.
- Strict only on WAN-facing interfaces, loose on customer SAPs: pragmatic, but the customer SAP is precisely where spoofed sources enter.
Recommendation: correct the policy asymmetry as the root cause and keep strict uRPF on the CE SAPs. Where asymmetry is genuinely unavoidable, use loose uRPF with a documented, reviewed exception. Treat 'one PE has an inbound policy the other lacks' as a configuration-drift finding in its own right, because it caused the outage.
3. What residual exposure remains after the fix, and what would you monitor to catch a recurrence?
Read the worked answer
Residual exposure: uRPF - even strict - validates reachability, not ownership. A customer can still spoof another address inside 10.20.0.0/16, or another VPRN's space if that space is reachable from this VRF. Close that with an inbound prefix filter on the eBGP sessions (permit only the customer's registered prefixes), a bogon and private-space deny, and max-prefix limits.
Monitoring:
- Alarm on uRPF drop counters per SAP by rate, not just total, so a policy change is caught in minutes rather than by the helpdesk.
- Track BGP best-path changes for customer prefixes and alert when the best path for a directly connected prefix is not the SAP - that is the precondition for this failure mode.
- Configuration compliance: compare inbound route policies between PE pairs for the same VPRN and raise a ticket on any mismatch.
- After the change, re-test with a deliberately spoofed source to prove invalid sources are still dropped while the legitimate asymmetric case passes.