[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Force10 Gear - Opinions
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080904/598f5dd2/attachment.bin>
- Follow-Ups:
- uRPF
- From: jrhett at netconsonance.com (Jo Rhett)