<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 10, 2022, at 6:37 PM, Matthew Petach <<a href="mailto:mpetach@netflight.com" class="">mpetach@netflight.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 10, 2022 at 8:44 AM Mark Tinka <<a href="mailto:mark@tinka.africa" class="">mark@tinka.africa</a>> 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 class="">
<br class="">
> Hello,<br class="">
><br class="">
> We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has <br class="">
> 24x100G, but only 2.2mln route (FIB) memory entries. In a near future <br class="">
> it will be not enough - so we're thinking to deny all /24s to save the <br class="">
> memory. What do you think about that approach - I know it could <br class="">
> provide some misbehavior. But theoretically every filtered /24 could <br class="">
> be routed via smaller prefix /23 /22 /21 or etc. But of course it <br class="">
> could be a situation when denied /24 will not be covered by any <br class="">
> smaller prefix.<br class="">
<br class="">
I wouldn't bank on that.<br class="">
<br class="">
I am confident I have seen /24's with no covering route, more so for PI <br class="">
space from RIR's that may only be able to allocate a /24 and nothing <br class="">
shorter.<br class="">
<br class="">
It would be one heck of an experiment, though :-).<br class="">
<br class="">
Mark.<br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I may or may not have done something like this at $PREVIOUS_DAY_JOB.</div><div class=""><br class=""></div><div class="">We (might have) discovered some interesting brokenness on the Internet in doing so; </div><div class="">in one case, a peer was sending a /20 across exchange peering sessions with us, </div><div class="">along with some more specific /24s. After filtering out the /24s, traffic rightly flowed </div><div class="">to the covering /20. Peer reached out in an outraged huff; the /24s were being </div><div class="">advertised from non-backbone-connected remote sites in their network, that suddenly </div><div class="">couldn't fetch content from us anymore. Traceroutes from our side followed the /20 </div><div class="">back to their "core", and then died. They explained the /24s were being advertised </div><div class="">from remote sites without backbone connections to the site advertising the /20, and </div><div class="">we needed to stop sending traffic to the /20, and send it directly to the /24 instead.</div><div class="">We demurred, and let them know we were correctly following the information in the </div><div class="">routing table. </div></div></div></div></blockquote><div><br class=""></div><div>We encountered similar behavior, but not from a network desegregating their own address space like this. Rather, it was a network (actually a network services vendor) who had a PA /24 from a colo provider that they were no longer interconnected with. We had to filter /24s on transit (our network does not resell transit) due to issues with spanslogic inefficiency on Nexus 7k. </div><div><br class=""></div><div>When trying to turn up a demo with this vendor, connections were not establishing. We found that they had an older PA /24 in the FIB but we were following a /20 or some such route to their old upstream/colo. We ended up doing a bunch of work to find other such “possibly disconnected /24s” based mainly on origin ASN, and put in exceptions to our filtering until we could complete some hardware upgrades.</div><div><br class=""></div><div>In situations like this, we of course did have functioning default routes from our upstream — but that doesn’t help since the /20 from a peer was attracting and blackholing the traffic. As IPv4 continues to desegregate and get resold and otherwise optimized, I imagine this will become more common. Not a problem for a multi-homed stub network with multiple default routes coming from upstream, unless they have peering and don’t micromanage it with this in mind.</div><div><br class=""></div><div>Ryan</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">They became even more huffy, insisting that we were breaking the internet by not </div><div class="">following the correct routing for the more-specific /24s which were no longer present </div><div class="">in our tables. No amount of trying to explain to them that they should not advertise </div><div class="">an aggregate route if no connectivity to the more specific constituents existed seemed </div><div class="">to get the point across. In their eyes, advertising the /24s meant that everyone should </div><div class="">follow the more specific route to the final destination directly.</div><div class=""><br class=""></div><div class="">So, even seeing a 'covering route' in the table is no guarantee that you won't create </div><div class="">subtle and not-so-subtle breakage when filtering out more specifics to save table space. ^_^;</div></div></div></div></blockquote><div><br class=""></div>+1 </div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Having (possibly) done this once in the past, I'd strongly recommend looking for a </div><div class="">different solution--or at least be willing to arm your front-end response team with </div><div class="">suitable "No, *you* broke the Internet" asbestos suits before running a git commit </div><div class="">to push your changes out to all the affected devices in your network. ;)</div><div class=""><br class=""></div><div class="">Matt</div><div class=""><br class=""></div><div class=""> </div></div></div>
</div></blockquote></div><br class=""></body></html>