<div dir="ltr"><div dir="ltr">On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 19 Dec 2018 at 02:55, Philip Loenneker<br>
<<a href="mailto:Philip.Loenneker@tasmanet.com.au" target="_blank">Philip.Loenneker@tasmanet.com.au</a>> wrote:<br>
<br>
> I had a heck of a time a few years back trying to troubleshoot an issue where an upstream provider had an ACL with an incorrect mask along the lines of 255.252.255.0. That was really interesting to talk about once we discovered it, though it caused some loss of hair beforehand...<br>
<br>
Juniper originally didn't support them even in ACL use-case but were<br>
forced to add later due to customer demand, so people do have<br>
use-cases for them. If we'd still support them in forwarding, I'm sure<br>
someone would come up with solution which depends on it. I am not<br>
advocating we should, I'll rather take my extra PPS out of the HW.<br>
<br>
However there is one quite interesting use-case for discontinuous mask<br>
in ACL. If you have, like you should have, specific block for customer<br>
linknetworks, you can in iACL drop all packets to your side of the<br>
links while still allowing packets to customer side of the links,<br>
making attack surface against your network minimal.</blockquote><div class="gmail_quote"><div><br></div></div><div>And unfortunately is still not supported by IOS-XR for IPv6, which could mean not having a scaleable way on your edge to protect your internal network.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr">Christian<br><br>e-mail/xmpp: <a href="mailto:christian@errxtx.net" target="_blank">christian@errxtx.net</a></div><div dir="ltr">PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318<br></div><div dir="ltr"><div><br></div></div></div></div></div></div>