> Mark Leonard wrote : > Your processing time for 5k IPs should be measured in seconds (ie: less than > one) rather than minutes on any modern core.
I agree. I am surprised by the minutes thing as well. > Based on your pseudocode (sort -n | uniq) I get the impression that you're > using BASH which isn't ideal for performing this sort of operation at high > speed. Even with bash it does not take minutes. I used a bash sort in the first version of the CBBC and it was quite fast. Was not very elegant, but worked fine. Fetch all sources into the same file, then bash sort removing duplicates. My current limitation now is the injection into ExaBGP and because I still display the prefixes in the console. Kinda, its in debug mode. > On the flip side, I think an extra 100k routes isn't that much unless you're > suffering from hardware routing table limitations. In my world the cost of a > false positive match would far outweigh the cost of upgrading hardware. YMMV. The problem here is that there still are plenty of routers out there that have a 1 million route limit and that the growth of the routing table is predictable enough that the year to upgrade is 2023. By adding 100K prefixes, you advance the upgrade year into 2021. Does not look good to request the capex 2 years earlier than previously predicted. I am curious to see how many prefixes aggregation saves. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
