Cox AS22773 uPRF issue - please contact off list
If there's anyone on here with Cox engineering that can assist with a uPRF strict issue (we're multihomed), please contact me offlist. Thanks, Evan [cid:ca13917c-8f83-46c4-80da-06b0c0d7e178] Evan S. Weiner Managing Member , Hosted Backbone, LLC d: (804) 549-4899<tel:(804)%20549-4899> | m: (804) 677-9544<tel:(804)%20677-9544> e: eweiner@hostedbackbone.net<mailto:eweiner@hostedbackbone.net> | w: www.hostedbackbone.net<https://www.hostedbackbone.net/>
strict urpf should only ever be enabled by providers when PA space is assigned, and typically thats on a static routed assignment, never a bgp session and typically never on a bgp session / peer with a customer that is multihomed, etc. In other words I would tend to say Im not going to ever buy transit from you if you run strict uRPF on my ports. + Jon Larsen: CTO Richweb, Inc. + Richweb.com: Cloud/Route/Switch/MSP Experts since 1995 + GnuPG Public Key: http://jlarsen.richweb.com/jlarsen.gpg + Business: (804) 368-0421 x 101; Mobile: (804) 747-8592
Hi. if you're a customer, using only my PA space, and multihomed: I'll do BGP with you -- you can be AS64512. I'll do strict uRPF with a fail-filter allowing all my PA space sourced by you. Is there a problem with that? Frank On 12/4/2025 7:23 AM, C. Jon Larsen via NANOG wrote:
strict urpf should only ever be enabled by providers when PA space is assigned, and typically thats on a static routed assignment, never a bgp session and typically never on a bgp session / peer with a customer that is multihomed, etc.
In other words I would tend to say Im not going to ever buy transit from you if you run strict uRPF on my ports.
+ Jon Larsen: CTO Richweb, Inc. + Richweb.com: Cloud/Route/Switch/MSP Experts since 1995 + GnuPG Public Key: http://jlarsen.richweb.com/jlarsen.gpg + Business: (804) 368-0421 x 101; Mobile: (804) 747-8592
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/ nanog@lists.nanog.org/message/HOLPB2PBSMHY57IQP6WGEVVYTNXVOFXU/
On Thu, 4 Dec 2025 at 06:24, C. Jon Larsen via NANOG <nanog@lists.nanog.org> wrote:
strict urpf should only ever be enabled by providers when PA space is assigned, and typically thats on a static routed assignment, never a bgp session and typically never on a bgp session / peer with a customer that is multihomed, etc.
There is a variant of strict with feasible paths, basically RIB instead of FIB. However uRPF is expensive, and if you do have BGP, you hopefully have prefix-lists, then you might just as well use those prefix-lists as an ACL, which are usually zero or near zero cost. -- ++ytti
On Wed, Dec 3, 2025 at 8:32 PM Frank Habicht via NANOG <nanog@lists.nanog.org> wrote:
if you're a customer, using only my PA space, and multihomed: I'll do BGP with you -- you can be AS64512. I'll do strict uRPF with a fail-filter allowing all my PA space sourced by you.
Is there a problem with that?
Most likely, yes there is. I can drop my announcement without dropping the BGP session. There are lots of reasons to do so. If you're doing strict URPF, you'll start blackholeing packets I send to you on the link based on the routes you're still sending to me, even though they're from the address space you assigned to me. URPF will show the return route transiting the other link. It's even more dicey if the multihoming isn't two links with you but rather a link with you and another with someone else. Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Wed, Dec 3, 2025 at 8:32 PM Frank Habicht via NANOG <nanog@lists.nanog.org> wrote:
if you're a customer, using only my PA space, and multihomed: I'll do BGP with you -- you can be AS64512. I'll do strict uRPF with a fail-filter allowing all my PA space sourced by you.
Is there a problem with that?
Most likely, yes there is.
I can drop my announcement without dropping the BGP session. There are lots of reasons to do so. agreed. If you're doing strict URPF, you'll start blackholeing packets I send to you on the link based on the routes you're still sending to me, even though they're from the address space you assigned to me. my "with a fail-filter allowing" above meant
On 12/4/2025 4:19 PM, William Herrin wrote: the $J-speak "rpf-check fail-filter <filter>" - which will allow this.
URPF will show the return route transiting the other link.
It's even more dicey if the multihoming isn't two links with you but rather a link with you and another with someone else.
my "using only my PA space" condition should still prevent undesired discards of packets on my part. Frank
participants (5)
-
C. Jon Larsen -
Evan S. Weiner -
Frank Habicht -
Saku Ytti -
William Herrin