<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Methinks the EX9ks apply uRPF a little too close to the hardware and ignore the RIB.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">-Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="color:#1F5587">Adam Thompson<o:p></o:p></span></b></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:#1F5587">Consultant, Infrastructure Services<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;color:#1F497D"><img width="220" height="67" style="width:2.2916in;height:.7in" id="Picture_x0020_1" src="cid:image001.png@01D8FE60.27B812C0" alt="MERLIN"></span><span lang="EN-US" style="font-size:9.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:#1F5587">100 - 135 Innovation Drive<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:#1F5587">Winnipeg, MB R3T 6A8<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:#1F5587">(204) 977-6824 or 1-800-430-6404 (MB only)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:#1F5587"><a href="https://www.merlin.mb.ca/"><span style="color:#1F5587">https://www.merlin.mb.ca</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9.0pt;color:black"><img border="0" width="16" height="16" style="width:.1666in;height:.1666in" id="Picture_x0020_2" src="cid:image002.png@01D8FE60.27B812C0"></span><span lang="EN-US" style="font-size:9.0pt;color:#1F5587"><a href="https://teams.microsoft.com/l/chat/0/0?users=athompson@merlin.mb.ca"><span style="color:#1F5587">Chat
with me on Teams</span></a></span><span style="color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org>
<b>On Behalf Of </b>Mike Hammett<br>
<b>Sent:</b> November 8, 2022 2:29 PM<br>
<b>To:</b> William Herrin <bill@herrin.us><br>
<b>Cc:</b> nanog@nanog.org; Grant Taylor <gtaylor@tnetconsulting.net><br>
<b>Subject:</b> Re: BCP38 For BGP Customers<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">"Reverse path filtering literally says don't accept a packet from<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">somewhere that isn't currently the next hop for that packet's source<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">address."<br>
<br>
FIB or RIB?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">I knew of uRPF as available over an interface, per the routing table, not best path available. Or is that implementation dependent?<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><br>
<br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a href="http://www.ics-il.com">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a href="http://www.midwest-ix.com">http://www.midwest-ix.com</a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">
<hr size="2" width="100%" noshade="" style="color:black" align="center">
</span></div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Helvetica",sans-serif;color:black">From:
</span></b><span style="font-size:12.0pt;font-family:"Helvetica",sans-serif;color:black">"William Herrin" <<a href="mailto:bill@herrin.us">bill@herrin.us</a>><br>
<b>To: </b>"Grant Taylor" <<a href="mailto:gtaylor@tnetconsulting.net">gtaylor@tnetconsulting.net</a>><br>
<b>Cc: </b><a href="mailto:nanog@nanog.org">nanog@nanog.org</a><br>
<b>Sent: </b>Tuesday, November 8, 2022 2:01:49 PM<br>
<b>Subject: </b>Re: BCP38 For BGP Customers<br>
<br>
On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br>
> Maybe it's the lack of caffeine, but would someone please remind /<br>
> enlighten me as to why uRPF is a bad idea on downstream interfaces?<br>
<br>
Hi Grant,<br>
<br>
Two words: asymmetric routing.<br>
<br>
If the downstream network is architected in such a way that there's<br>
more than one path in and out of their network then there's no way to<br>
guarantee that any particular router believes the forward path to that<br>
network goes to a particular next hop. It can currently map to any<br>
next hop that goes in the direction of one of the valid paths. That<br>
routing is completely independent of how next hops are selected in the<br>
other direction. Packets can travel in one path and out another.<br>
<br>
Reverse path filtering literally says don't accept a packet from<br>
somewhere that isn't currently the next hop for that packet's source<br>
address. When it's possible for the forward route to point a different<br>
direction than the one from which valid packets are received, that is<br>
the wrong thing to do. In fact, it breaks the network.<br>
<br>
Useful automated reverse path filtering can ONLY be used when there is<br>
exactly ONE valid path to which and from which packets can be<br>
received. This is where strict mode uRPF actually works.<br>
<br>
<br>
> N.B. Maybe I'm thinking more a varient of uRPF wherein if I have a route<br>
> to the source from the interface in question. Thus not uRPF-strict<br>
> (active route) nor uRPF-loose (route on any interface).<br>
<br>
Even if a particular router happens to have RIB entries for all the<br>
valid paths to a host (a sketchy proposition at best), only one such<br>
entry will be stored in the FIB where uRPF looks to make its filtering<br>
decision.<br>
<br>
As for loose mode, it's basically useless in a BCP38 discussion. Loose<br>
mode only filters bogons. It doesn't prevent impersonation of any IP<br>
address currently routed in the system and doesn't do anything at all<br>
on a router with a default route.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
<br>
<br>
-- <br>
For hire. <a href="https://bill.herrin.us/resume/">https://bill.herrin.us/resume/</a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>