URPF on small BGP-enabled customers?
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. This is new to me, but I haven't bought any new transit in the past 18 months -- is this common practice on multihomed BGP customers now? I could force things to work by always advertising all my prefixes out to them with the obvious downside of living in fear of my outbound traffic being dropped if I ever need to withdraw any of them. 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...) 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. Am I missing something obvious here? -- -Will :: AD6XL Orton :: http://www.loopfree.net/
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
will@loopfree.net wrote:
This is new to me, but I haven't bought any new transit in the past 18 months -- is this common practice on multihomed BGP customers now? I could force things to work by always advertising all my prefixes out to them with the obvious downside of living in fear of my outbound traffic being dropped if I ever need to withdraw any of them.
I (a network much, much smaller than Sprint) do uRPF on all ports, but also inform BGP customers (nine-page handoff documentation) that they are uRPFed. However, in conjunction with community support for adjusting localpref, we set a sufficient weight on the announcement so that the edge node sees the customer link as preferred even if the rest of our network doesn't, and therefore the uRPF check passes. I don't think advertising more-specifics through other connections would actually work, as the Sprint edge router would still want to reach the more-specifics through the Sprint network, rather than the customer link. It's all a matter of what the FIB says. pt
Pete Templin wrote:
will@loopfree.net wrote:
This is new to me, but I haven't bought any new transit in the past 18 months -- is this common practice on multihomed BGP customers now? I could force things to work by always advertising all my prefixes out to them with the obvious downside of living in fear of my outbound traffic being dropped if I ever need to withdraw any of them.
I (a network much, much smaller than Sprint) do uRPF on all ports, but also inform BGP customers (nine-page handoff documentation) that they are uRPFed. However, in conjunction with community support for adjusting localpref, we set a sufficient weight on the announcement so that the edge node sees the customer link as preferred even if the rest of our network doesn't, and therefore the uRPF check passes.
This sounds like the better approach. Although this is still not strictly what the customer want, because all peers of the same edge will prefer the edges path.
I don't think advertising more-specifics through other connections would actually work, as the Sprint edge router would still want to reach the more-specifics through the Sprint network, rather than the customer link. It's all a matter of what the FIB says.
pt
Am I missing something obvious here?
Try announcing the remainder of yopur prefixes with either a couple prepends, or see if SprintLink supports the use of communities to control advertisement (you want SprintLink to prefer the paths they learn from you in case it's strict uRPF, but not pass those announcements along to preserve your current inbound policy as much as possible). That will (in theory) let you advertise all your prefixes to SprintLink with minimal change to traffic flow, and if your dropped-traffic problem goes away then you'll have a good supporting argument in favor of the explanation that uRPF is in effect. Stephen
participants (5)
-
Christopher L. Morrow -
Joe Maimon -
Pete Templin -
Stephen Stuart -
will＠loopfree.net