Re: URPF on small BGP-enabled customers?
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.
christian.macnevin@uk.bnpparibas.com wrote:
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.
This is why I say there should be a feature that will work like a dynamic ACL but is fed from BGP. All the prefixes you learn from customer A via BGP are put into an automatic ACL, default is deny. Then you apply this dynamic ACL to the interface the customer is connected to. Of course it still doesn't work if you send traffic from prefixes you don't announce but for 70-80% of the cases it's a big step forward in automation. This also gets rid of any differences between ACL on the forwarding plane and on the routing protocol plane. All prefix filters are defined in BGP configuration. Forwarding layer follows and never gets out of sync again. Random example syntax: router bgp 65500 neighbor 192.168.2.2 remote-as 65501 neighbor 192.168.2.2 dynamic ACL 10001 receive #put received prefixes here neighbor 192.168.2.2 prefix-list CUST65501 ... #usual stuff #only this one is controlled ip prefix-list extended CUST65501 permit ip 172.16.0.0/16 any permit ip 10.0.0.0/8 any #ACL on interface follows BGP received prefixes interface f0/0/0 ip access-group 10001 in #same as in BGP neighbor config And Voila! Problem automagically solved. -- Andre
On Jun 3, 2005, at 9:30 AM, christian.macnevin@uk.bnpparibas.com wrote:
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..
<disclaimer> Not uRPG guru </disclaimer> Why would that work? If I see a /16 from my customer and a /19 from a peer, I will still pick the /19, and strict uRPF should drop any packets from that /19 coming the customer interface, right? Not to mention the Really Bad Things associated with deaggregation. Perhaps a simpler way is to announce your entire allocation and put no-export on things you want to come in your other provider? ^1239$ will still pick those routes, but no one else will see them. Although sprint is a _VERY_ large network when you include downstreams, their own AS is rather tiny compared to the whole Internet. -- TTFN, patrick
On Fri, 3 Jun 2005, Patrick W. Gilmore wrote:
Perhaps a simpler way is to announce your entire allocation and put no-export on things you want to come in your other provider? ^1239$
or perhaps 'no-advertise' and send the same length prefixes everywhere... this IS headed down the 1000 ways to config bgp though :(
On Jun 3, 2005, at 10:52 AM, Christopher L. Morrow wrote:
On Fri, 3 Jun 2005, Patrick W. Gilmore wrote:
Perhaps a simpler way is to announce your entire allocation and put no-export on things you want to come in your other provider? ^1239$
or perhaps 'no-advertise' and send the same length prefixes everywhere... this IS headed down the 1000 ways to config bgp though :(
It is. Although, after reading the thread (here & on c-nsp) and thinking about it, I have a hypothesis: Sprint configures inbound source IP filters based on BGP filters. This could be automated easily. (BGP Tech: "What prefixes are you going to announce to us?" type-type-type.... System pushes prefix and IP ACLs.) Sound reasonable? Anyone from Sprint care to confirm? So even if you do not plan to announce all prefixes to Sprint, give them all prefixes so you can announce them, and the IP ACLs will be built properly. -- TTFN, patrick
participants (4)
-
Andre Oppermann -
christian.macnevin＠uk.bnpparibas.com -
Christopher L. Morrow -
Patrick W. Gilmore