Re: Force10 Gear - Opinions

[Mark Tinka <mtinka () globaltransit net>]

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.

Attachment: signature.asc
Description: This is a digitally signed message part.