Strict uRPF versus asymmetric ISP routing
A university has a 10 Gbps primary ISP link and a 1 Gbps backup ISP link. The border Nokia 7750 SR runs eBGP with both ISPs and receives about 1,200 prefixes. The security team enables strict uRPF on both customer-facing and ISP-facing interfaces to block spoofed source addresses. Within minutes, about 8% of inbound connections to the public web server fail. The web server sends responses via the primary link because BGP local preference prefers ISP-A. Some clients reach the server through ISP-B because of a more specific route advertised by ISP-B. The backup link carries 200 Mbps of inbound traffic at peak. The university wants to keep anti-spoofing and avoid dropping legitimate asymmetric traffic. There is no NAT at the border.
1. Why did strict uRPF drop legitimate traffic? Walk through the source-address check.
Read the worked answer
Strict uRPF on an ISP-facing interface checks that the packet's source address is reachable through the same interface on which it arrived. A client coming through ISP-B may have a route back via ISP-A because ISP-A is preferred by BGP. The source check therefore fails, even though the client is legitimate. The web server's response path is not the issue; the check is on the inbound source. The 8% failure rate is consistent with the fraction of clients whose traffic reaches the university via the backup ISP.
2. Recommend an anti-spoofing policy that preserves the backup link. Compare loose uRPF, strict uRPF, and ACLs.
Read the worked answer
Use loose uRPF on ISP-facing interfaces: the source must exist in the global routing table, but not necessarily via the ingress interface. Keep strict uRPF on single-homed customer interfaces where the topology is unambiguous. Add ingress ACLs to drop RFC1918, bogon, multicast, and the university's own prefixes from outside. Loose uRPF does not stop spoofing of routable addresses, so combine it with BGP RTBH and flow telemetry. Do not enable strict uRPF on ISP-B while it carries asymmetric traffic.
3. How would you validate and monitor the new policy?
Read the worked answer
Validate in a lab with a spoofed source from a prefix reachable only via ISP-A and send it through ISP-B; loose uRPF should pass it, strict should drop it. Check interface uRPF counters before and after. Monitor NetFlow for source addresses that fail the check and alert on spikes. Periodically compare the uRPF pass list with the BGP table.