[81289] in North American Network Operators' Group
Re: URPF on small BGP-enabled customers?
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Fri Jun 3 10:28:36 2005
In-Reply-To: <OF8DB168B0.EB9943DD-ON80257015.0049ED55@bnpparibas.com>
Cc: "Patrick W. Gilmore" <patrick@ianai.net>
From: "Patrick W. Gilmore" <patrick@ianai.net>
Date: Fri, 3 Jun 2005 10:06:00 -0400
To: nanog@merit.edu
Errors-To: owner-nanog@merit.edu
On Jun 3, 2005, at 9:30 AM, christian.macnevin@uk.bnpparibas.com wrote:
> At an old transit provider I was at, we had a pig of a time dealing
> with
> uRPF. It doesn't like asymmetric routing at all, which is
> commonplace when
> you've got customers homed at exchange points for one.
>
> I imagine the simplest and most foolproof way around directly
> connected
> providers blackholing your traffic is announcing more specific
> prefixes
> down the one you're currently favourint, and just the aggregates
> for same
> into the second. Good luck if you've only got a bunch of non-
> contiguous
> /24s..
<disclaimer> Not uRPG guru </disclaimer>
Why would that work? If I see a /16 from my customer and a /19 from
a peer, I will still pick the /19, and strict uRPF should drop any
packets from that /19 coming the customer interface, right?
Not to mention the Really Bad Things associated with deaggregation.
Perhaps a simpler way is to announce your entire allocation and put
no-export on things you want to come in your other provider? ^1239$
will still pick those routes, but no one else will see them.
Although sprint is a _VERY_ large network when you include
downstreams, their own AS is rather tiny compared to the whole Internet.
--
TTFN,
patrick
