<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you taking the stance of "if you don't send us the prefix, then<br>we don't accept the traffic"? <br></blockquote><div><br></div><div>If you were one of my upstreams, and you implemented that, you would very quickly no longer be one of my upstreams. </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello -<br>
<br>
I'm are currently working on getting BCP38 filtering in place for our BGP <br>
customers. My current plan is to use the Juniper uRPF feature to filter out <br>
spoofed traffic based on the routing table. The mentality would be: "If you <br>
don't send us the prefix, then we don't accept the traffic". This has raised <br>
some issues amongst our network engineers regarding multi-homed customers.<br>
<br>
One of the issues raised was if a multi-homed BGP customer revoked a prefix from <br>
one of their peerings, but continued sending us traffic on the link then we <br>
would drop the traffic.<br>
<br>
I would like to hear what others are doing for BCP38 deployments for BGP <br>
customers. Are you taking the stance of "if you don't send us the prefix, then <br>
we don't accept the traffic"? Are you putting in some kind of fall back filter <br>
in based on something like IRR data?<br>
<br>
Thanks!<br>
<br>
-- <br>
Charles Rumford (he/his/him)<br>
Network Engineer | Deft<br>
1-312-268-9342 | <a href="mailto:charlesr@deft.com" target="_blank">charlesr@deft.com</a><br>
<a href="http://deft.com" rel="noreferrer" target="_blank">deft.com</a><br>
</blockquote></div>