URPF on small BGP-enabled customers?

Fri Jun 3 13:30:19 UTC 2005

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..

Internet
christopher.morrow at mci.com@merit.edu - 03/06/2005 14:21

Sent by:    owner-nanog at merit.edu

To:    will

cc:    nanog

Subject:    Re: URPF on small BGP-enabled customers?

not speaking on behalf of sprint... but

On Fri, 3 Jun 2005 will at 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

This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.

BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.