North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: URPF on small BGP-enabled customers?
not speaking on behalf of sprint... but On Fri, 3 Jun 2005 [email protected] 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