<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 10, 2022 at 8:44 AM Mark Tinka <mark@tinka.africa> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 10/10/22 16:58, Edvinas Kairys wrote:<br>
<br>
> Hello,<br>
><br>
> We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has <br>
> 24x100G, but only 2.2mln route (FIB) memory entries. In a near future <br>
> it will be not enough - so we're thinking to deny all /24s to save the <br>
> memory. What do you think about that approach - I know it could <br>
> provide some misbehavior. But theoretically every filtered /24 could <br>
> be routed via smaller prefix /23 /22 /21 or etc. But of course it <br>
> could be a situation when denied /24 will not be covered by any <br>
> smaller prefix.<br>
<br>
I wouldn't bank on that.<br>
<br>
I am confident I have seen /24's with no covering route, more so for PI <br>
space from RIR's that may only be able to allocate a /24 and nothing <br>
shorter.<br>
<br>
It would be one heck of an experiment, though :-).<br>
<br>
Mark.<br></blockquote><div><br></div><div><br></div><div>I may or may not have done something like this at $PREVIOUS_DAY_JOB.</div><div><br></div><div>We (might have) discovered some interesting brokenness on the Internet in doing so; </div><div>in one case, a peer was sending a /20 across exchange peering sessions with us, </div><div>along with some more specific /24s.  After filtering out the /24s, traffic rightly flowed </div><div>to the covering /20.  Peer reached out in an outraged huff; the /24s were being </div><div>advertised from non-backbone-connected remote sites in their network, that suddenly </div><div>couldn't fetch content from us anymore.  Traceroutes from our side followed the /20 </div><div>back to their "core", and then died.  They explained the /24s were being advertised </div><div>from remote sites without backbone connections to the site advertising the /20, and </div><div>we needed to stop sending traffic to the /20, and send it directly to the /24 instead.</div><div>We demurred, and let them know we were correctly following the information in the </div><div>routing table. </div><div>They became even more huffy, insisting that we were breaking the internet by not </div><div>following the correct routing for the more-specific /24s which were no longer present </div><div>in our tables.  No amount of trying to explain to them that they should not advertise </div><div>an aggregate route if no connectivity to the more specific constituents existed seemed </div><div>to get the point across.  In their eyes, advertising the /24s meant that everyone should </div><div>follow the more specific route to the final destination directly.</div><div><br></div><div>So, even seeing a 'covering route' in the table is no guarantee that you won't create </div><div>subtle and not-so-subtle breakage when filtering out more specifics to save table space.   ^_^;</div><div><br></div><div>Having (possibly) done this once in the past, I'd strongly recommend looking for a </div><div>different solution--or at least be willing to arm your front-end response team with </div><div>suitable "No, *you* broke the Internet" asbestos suits before running a git commit </div><div>to push your changes out to all the affected devices in your network.   ;)</div><div><br></div><div>Matt</div><div><br></div><div> </div></div></div>