3 ms·
It annoys me when router vendors (Cisco, looking at you) advertise their throughput as theoretical maximum bi-directional. Almost no real network design can tak
by iigs 17y ago
It annoys me when router vendors (Cisco, looking at you) advertise their throughput as theoretical maximum bi-directional. Almost no real network design can take advantage of that speed. If this router only has 4x10g port (the two left cards), for all intents and purposes it's a 40-50gbit router. That's probably a great deal in the $50-100k range, though, so there's still a place for it.
I feel like I'm telling Larry Wall what is up with Perl or something, but this guy is making route caching sound like something new, when it has been in crappy $4000 workgroup-class layer three switches now for almost a decade. This kind of deflates his "I should know" appeals to authority.
The buffer-alternative algorithm isn't well explained but sounds kind of novel and useful. It would be particularly so if it allows the network operator to manage flows on a per subscriber basis.
One other concern: if this router is cutting power/weight corners by decreasing its ability to calculate new routes ("flows"), it's possible that an ISP would be exposing themselves to a DoS of their network by intruders sending a lot of unique flow requests to the router. An obvious example of this would be several concurrent NMAPs of a large range of IPs.
If it can keep up with the large workloads they claim with only 300w and 3U (or so) of space, it's pretty compelling, all of these issues aside. I'm excited to see it in the real world.
- wmf 17y agoHere's a more technical description: http://packet.cc/files/Flow%20%20Management.pdf http://packet.cc/files/Flow%20%20Management.pdf My take is that flow routing is not necessarily cheaper than doing full routing on every packet, but building a router with virtually no buffers requires tracking flows and interacting with TCP.
- jsn 17y agoI suppose the DoS you mentioned should be relatively easy to prevent. They don't have to cache all flows, just the most hot 20% which consume 80% of bandwidth. Probabilistic caching and/or ruthless pruning of cold flows can probably render the "exploding cache" attack impossible or at least impractical. What bothers me more is routing table updates. I don't see how they can avoid invalidating the whole flow cache on each routing flap. OTOH, rebuilding the said top 20% of flows should be pretty fast, too.