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@mci.com@merit.edu - 03/06/2005 14:21 Sent by: owner-nanog@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@loopfree.net wrote:
I am in the process of turning up a new transit connection with
network is a multi-homed stub AS and I only announce 5 prefixes. Having
SprintLink. My 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.
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
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 :( 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.