BCP38 For BGP Customers

Tue Nov 22 16:49:56 UTC 2022

We’ve seen Juniper EX9ks implement uRPF in such a way that if I have two (load-balanced) BGP connections to the EX9k, and uRPF is turned on facing me, I immediately experience ~50% outbound packet loss.
Methinks the EX9ks apply uRPF a little too close to the hardware and ignore the RIB.
-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image002.png at 01D8FE60.27B812C0]Chat with me on Teams<https://teams.microsoft.com/l/chat/0/[email protected]>

From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> On Behalf Of Mike Hammett
Sent: November 8, 2022 2:29 PM
To: William Herrin <bill at herrin.us>
Cc: nanog at nanog.org; Grant Taylor <gtaylor at tnetconsulting.net>
Subject: Re: BCP38 For BGP Customers

"Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address."

FIB or RIB?

I knew of uRPF as available over an interface, per the routing table, not best path available. Or is that implementation dependent?

-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

________________________________
From: "William Herrin" <bill at herrin.us<mailto:bill at herrin.us>>
To: "Grant Taylor" <gtaylor at tnetconsulting.net<mailto:gtaylor at tnetconsulting.net>>
Cc: nanog at nanog.org<mailto:nanog at nanog.org>
Sent: Tuesday, November 8, 2022 2:01:49 PM
Subject: Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>> wrote:
> Maybe it's the lack of caffeine, but would someone please remind /
> enlighten me as to why uRPF is a bad idea on downstream interfaces?

Hi Grant,

Two words: asymmetric routing.

If the downstream network is architected in such a way that there's
more than one path in and out of their network then there's no way to
guarantee that any particular router believes the forward path to that
network goes to a particular next hop. It can currently map to any
next hop that goes in the direction of one of the valid paths. That
routing is completely independent of how next hops are selected in the
other direction. Packets can travel in one path and out another.

Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address. When it's possible for the forward route to point a different
direction than the one from which valid packets are received, that is
the wrong thing to do. In fact, it breaks the network.

Useful automated reverse path filtering can ONLY be used when there is
exactly ONE valid path to which and from which packets can be
received. This is where strict mode uRPF actually works.

> N.B. Maybe I'm thinking more a varient of uRPF wherein if I have a route
> to the source from the interface in question.  Thus not uRPF-strict
> (active route) nor uRPF-loose (route on any interface).

Even if a particular router happens to have RIB entries for all the
valid paths to a host (a sketchy proposition at best), only one such
entry will be stored in the FIB where uRPF looks to make its filtering
decision.

As for loose mode, it's basically useless in a BCP38 discussion. Loose
mode only filters bogons. It doesn't prevent impersonation of any IP
address currently routed in the system and doesn't do anything at all
on a router with a default route.

Regards,
Bill Herrin

--
For hire. https://bill.herrin.us/resume/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221122/bf39d4c9/attachment.html>