Hello! On Tue, Oct 15, 2019 at 12:46 PM Saku Ytti <saku@ytti.fi> wrote:
On Mon, 14 Oct 2019 at 09:30, Vincent Bernat <bernat@luffy.cx> wrote:
How much performance impact should we expect with uRPF?
Depends on the platform, but often it's 2nd lookup. So potentially 50% decrease in performance. Some platforms it means FIB duplication. And ultimately it doesn't really offer anything over ACL, which is, in comparison, much cheaper feature. I would encourage people to toolise this, then the ACL generation is no cost or complexity. And you can use ACL for many BGP customers too, as you create 'perfect' prefix-list for customer, you can reference to same prefix-list in ACL, without actually needing customer to announce that prefix, as it's entirely valid to originate traffic from allowable prefix without advertising the prefix (to you).
This has the potential to brake things, because it requires symmetry and perfect IRR accuracy. Just because the prefix would be rejected by BGP does not mean there is not a legitimate announcement for it in the DFZ (which is the exact difference between uRPF loose mode and the ACL approach). For BGP customers where I control the announced IP space (it's mine, the customer has a private ASN and the only reason for BGP is so he can multi-home to different nodes of my network), sure. For real "IP Transit" where the customers may itself have multiple downstream ASNs, there is no guarantee that everyone in the chain will update the IRR records 24 - 48 hours before actually sourcing traffic from a new prefix (or enabling that new downstream as-path). Some other transit may just allow prefixes "manually" (for example, because of LOA's or inetnum objects, as opposed to route objects), so *a valid announcement is in the DFZ*, you are just not accepting it on your customers BGP session. In fact, maybe my downstream customer just wants to send traffic to my network, but not receive any, so I don't actually have to include that customer in my AS-macro (an exotic use-case for sure, just trying to point out that there will always be asymmetry). Routing, BGP and the IRR data is asymmetric by definition and neither real-time nor 100% accurate. That's not a problem for BGP and strict ingress prefix-lists, but it is a problem for ingress ACL'ing, because the latter effectively blackholes traffic, while uRPF loose mode does not (if there is a announcement for it in the DFZ). So I don't think ACL's can replace uRPF loose mode in the DFZ and frankly I find this proposal to be a bit dangerous. If my transit provider would do this without telling me, I'm turning up a new transit customer with an incomplete IRR record, causing an immediate partial outage for them, I would be *very* surprised (along with some other emotions). cheers, lukas