Re: URPF on small BGP-enabled customers?

["Christopher L. Morrow" <christopher.morrow () mci com>]

not speaking on behalf of sprint... but

On Fri, 3 Jun 2005 will () loopfree net wrote:

> I am in the process of turning up a new transit connection with SprintLink. My
> network is a multi-homed stub AS and I only announce 5 prefixes. Having the bright
> idea to incrementally move some traffic onto the new line I didn't announce all 5
> immediately and I localpref'd ^1239$ to get some outbound traffic moving -- and the
> result is of course that they drop any of my outbound traffic sourced from prefixes
> I'm not announcing yet. This really smells like URPF but of course nobody at Sprint
> has even confirmed that they are actually dropping packets.

They might not, or the person in tech support might not know what you are
asking about... if its part of the 'standard config template' chances are
high there are LOTS of folks who don't know what it is or does :(

> If they're paranoid enough to manually filter my BGP announcements it's not much
> more work to manually filter my source addresses too (nevermind the fact that I
> already do it myself, but...)

the want to avoid manually filtering source addresses is exactly why uRPF
was brought into existence (one of the reasons atleast). It's lower
impact, on some cards/chassis/os's, than actual filters and certainly
lower management headache to maintain. Keep in mind that sprint has
probably a few hundred interfaces on that one router, with a few thousand
routers (atleast, again I'm not a sprint person) with similar interface
counts... managing acls on a hundred thousand interfaces (non-standard
acls) isn't a simple task.

> I'm working through the SprintLink noc/support process but I'm surprised this
> hasn't happened to any of their other customers before now.

perhaps other customers just announce their /24 to each provider and don't
care about traffic engineering? or they atleat announce the depref'd
routes incase of failure?

> Am I missing something obvious here?

probably not