In the referenced message, Eric Gauthier said: <snip>
Another limitation that we've found with uRPF is that it doesn't live well with multihomed systems (i.e. a host with two NIC's - each on a different subnet) because of the way most OS'es handle their default gateways. For anyone who is interested in our experience, drop me a note off list. If you have a solution for this multihoming problem, PLEASE email me off-list.
Eric :)
Most Cisco boxes have 3 related modes of uRPF: 1) pure RPF, if forwarding path back to source doesn't go via interface packet received from, then dump. I believe, but am not positive, that it will handle equal-cost-multipath ok in situations where that exists. 2) acl exceptions, if source matches the acl, allow the packet 3) not-so-pure RPF, if there is _any_ forwarding path back to the source via _any_ interface, then accept. for single-homed customers, simple uRPF for multihomed customers, acl exceptions based upon their registered IRR-policy, since the customer should already be registering in the IRR you have a list of all networks reachable via the customer, regardless of the actual real-time announcements or policy applications (prepending, localpref tweaks, etc) for peers that are clued-in, again acl exceptions based upon the peers registered policy for non-clued peers, accept based upon any available forwarding path [hopefully, by the 100th time you beat on the peer about spoofed crud coming from them, they'll get religion and register, since you'll have less overall spoofing to track down, you can devote it to slapping them around more] you should also in/egress filter known bogons at all borders, like src/dst in rfc1918 src/dst in class e src in class d (not dest, however) etc