On Thursday 04 September 2008 15:47:01 Paul Wall wrote: > uRPF strict as a configuration default, on customers > without possible asymmetry (multihoming, one-way > tunneling, etc) is not a bad default. But when the > customers increase in complexity, the time might come to > relax things some. It's certainly not a be-all-end-all.
Our experience with uRPF has been some unpleasant badness when dealing with a few private peers. Our private peering routers don't hold full routes (naturally), so we had to relax (even) the loose-mode uRPF scheme we had for this because some of our peers were leaking our routes to the Internet. Customer-facing, strict-mode uRPF is standard practice across the board for all customers single-homed to us. Customers for whom we know have multiple connections get loose-mode uRPF. For good measure, each edge router has outbound ACL's on the core-facing interfaces catching RFC 1918 and RFC 3330 junk. On border (transit) routers, we employ loose-mode uRPF with no issues, since these carry a full table. In addition, we catch inbound RFC 1918 and RFC 3330 with ACL's; and just to see how crazy things get, we stick our own prefixes in there since we really shouldn't be seeing them as sources from the wild. It's quite interesting how many matches we log, particularly for own addresses, on transit and peering links. Of course, the RFC 1918 and RFC 3330 are not without increment as well. No filtering in the core. Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.