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@01D8FE60.27B812C0]Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=athomp...@merlin.mb.ca> From: NANOG <nanog-bounces+athompson=merlin.mb...@nanog.org> On Behalf Of Mike Hammett Sent: November 8, 2022 2:29 PM To: William Herrin <b...@herrin.us> Cc: nanog@nanog.org; Grant Taylor <gtay...@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" <b...@herrin.us<mailto:b...@herrin.us>> To: "Grant Taylor" <gtay...@tnetconsulting.net<mailto:gtay...@tnetconsulting.net>> Cc: nanog@nanog.org<mailto:nanog@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@nanog.org<mailto:nanog@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/
