Whitebox Routers Beyond the Datasheet

Fri Apr 12 13:03:49 UTC 2024

I'm looking at the suitability of whitebox routers for high through, low port count, fast BGP performance applications. Power efficiency is important as well. 

What I've kind of come down to (based on little more than spec sheets) are the EdgeCore AGR400 and the UfiSpace S9600-30DX. They can both accommodate at least three directions of 400G for linking to other parts of my network and then have enough 100G or slower ports to connect to transit, peers, and customers as appropriate. Any other suggestions for platforms similar to those would be appreciated. 

They both appear to carry buffers large enough to accommodate buffering differences in port capacities, which is an issue I've seen with boxes more targeted to cloud\datacenter switching. 

What isn't in the spec sheets is BGP-related information. They don't mention how many routes they can hold, just that they have additional TCAM to handle more routes and features. That's wonderful and all, but does it take it from 64k routes to 512k routes, or does it take it from 256k routes up to the millions of routes? Also, BGP convergence isn't listed (nor do I rarely ever see it talked about in such sheets). I know that software-based routers can now load a full table in 30 seconds or less. I know that getting the FIB updated takes a little bit longer. I know that withdrawing a route takes a little bit longer. However, often, that performance is CPU-based. An underpowered CPU may take a minute or more to load that table and may take minutes to handle route churn. Can anyone speak to these routers (or routers like these) ability to handle modern route table activity? 

My deployment locations and philosophies simply won't have me in an environment where I need the density of dozens of 400G\100G ports. That the routers that seem to be more marketed to the use case are designed for. 

----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240412/18bb1916/attachment.html>