Strict uRPF on a Dual-Homed Edge Drops Inbound Traffic
A regional company edge router R1 is dual-homed to two providers. The public prefix 198.51.100.0/24 is advertised to both ISPs over eBGP, and the internal network is 10.50.0.0/16. ISP-A terminates on GigabitEthernet0/0 (203.0.113.2/30) and carries most inbound traffic; ISP-B terminates on GigabitEthernet0/1 (192.0.2.2/30) and is preferred by several APAC networks because the path from there is three AS hops shorter. Outbound AS-path prepending to ISP-B makes ISP-A the best return path for most of the Internet. A default route is received from both providers.
During a hardening exercise ip verify unicast source reachable-via rx was enabled on both provider-facing interfaces. Since then roughly 30 percent of inbound HTTPS and SMTP sessions from APAC clients fail at the TCP handshake, while European and North American clients are unaffected. No routing changes were made in the same window. The firewall and servers show the SYNs never arriving, and ISP-B reports no drops or filtering on its side.
1. Explain the mechanism behind the failures and describe how you would confirm the diagnosis on R1 without disrupting production traffic.
Read the worked answer
ip verify unicast source reachable-via rx is strict unicast RPF. For every packet arriving on an interface, the router looks up the source address in the FIB and requires the resolved egress interface to be the same interface the packet arrived on. Packets from APAC clients arrive on GigabitEthernet0/1, but R1's best path back to those source prefixes is via ISP-A on GigabitEthernet0/0, because that is what BGP selected. The check fails and the packet is dropped before any NAT or firewall processing. European and North American clients arrive on GigabitEthernet0/0, where the return path does match, so they succeed.
Confirm it without changing anything. Pick an affected source address from a failed session and run show ip cef <source> and show ip route <source>; both should resolve out GigabitEthernet0/0. Run show ip interface GigabitEthernet0/1 to see the uRPF mode and any drop counters, and show ip traffic to see the unicast RPF drop counter incrementing while you reproduce the failure. A packet capture on the inside interface will show nothing reaching the LAN, and show ip nat translations will show no entry created for the failed flow, which proves the drop is before translation. There is no syslog by default for uRPF drops, so counters are the only evidence.
2. Which remediation do you choose, and what are the security trade-offs compared with leaving strict mode in place?
Read the worked answer
The requirement is to accept legitimate asymmetric inbound traffic on ISP-B without turning the edge into an open door. The blunt option is loose mode, ip verify unicast source reachable-via any, on GigabitEthernet0/1 only, keeping strict mode on GigabitEthernet0/0. Loose mode only checks that the source is routable at all, so any spoofed source covered by the default route passes; that is a significant weakening, but it is applied to a single interface where asymmetry is by design.
The better option is ACL-based uRPF: ip verify unicast source reachable-via rx 120 on GigabitEthernet0/1 with an extended ACL that permits only the source prefixes legitimately reachable through ISP-B and denies everything else. You build the permit list from the APAC prefixes actually seen in the BGP table via ISP-B, refreshed on a schedule; a stale list silently blackholes new customers, so pair it with logging on the deny. This keeps strict checking for everything not explicitly exempted.
Do not try to fix this by changing BGP so the return path matches inbound, because you do not control which path remote networks choose toward your /24. allow-default would not help here either, since the FIB already has a more specific path out GigabitEthernet0/0. Verify with the same counters after the change.
3. With the uRPF exception in place, how do you keep the control plane protected, and why is that not redundant with uRPF?
Read the worked answer
uRPF protects against spoofed sources; it does nothing about a legitimate but excessive volume of packets destined to the router itself. Once GigabitEthernet0/1 accepts a broader source range, the router becomes a more attractive target for transit and for protocol floods, so control-plane policing is still needed.
Build a CoPP policy applied under control-plane with service-policy input. Classify first: BGP (TCP 179) from the two known peer addresses, SSH and SNMP from the NOC subnets, ICMP echo, IGP hellos, and NTP. Give each a committed rate with a conform-action of transmit and an exceed-action of transmit with a lower DSCP or drop for the noisy classes, and put everything else into a class-default policer set low with drop. The exceptions must be matched before the default or the peers themselves will be dropped.
Remember the scope: CoPP only sees traffic that is punted to the CPU, so forwarded transit traffic never hits it, and it is not a substitute for interface ACLs. Verify with show policy-map control-plane counters and show control-plane host open-ports to confirm nothing legitimate is being dropped, and roll it out in monitor mode first if the platform supports it, since a mis-ordered CoPP policy can lock you out of the router exactly as effectively as a bad uRPF rule.