We deploy urpf strict on all customer end-host and broadband circuits. In this scenario urpf = ingress acl I don't have to think about.

We deploy urpf loose on all customer multihomed DIA circuits. I dont this makes sense - ingress packet acl would be more sane.

Any flavour of urpf on upstream transit or peering would be challenging. Ingress packet acl dropping source = own+customer prefix might make sense depending on your AS topology.

You might argue that ingress packet acl would be operationally simpler on customer and upstream, as you could cover all scenarios.

On Thu, Oct 15, 2020 at 10:05 AM Saku Ytti <saku@ytti.fi> wrote:

On Thu, 15 Oct 2020 at 15:14, <adamv0025@netconsultings.com> wrote:

> Yes one should absolutely do that, but...
> But considering to become a good netizen what is more work?
> a) Testing and the enabling uRPF on every customer facing box or setting up precise ACLs on every customer facing port, and then maintaining all that?
> b) Gathering all your PAs (potentially PIs) (hint: show bgp nei x.x.x.x advertised routes) crafting an ACL and apply it on several peering/transit links?
> One of them is couple of weeks work and one is an afternoon job.

I am not fan of uRPF, expensive for what it does. But I don't view it
as an alternative here, I view it as either adding an ACE on all
egresses on egress direction or adding ACE on the ingress where
customer is on ingress direction.

To me these options seem equally complex but the latter one seems superior.

--
++ytti