[HN Gopher] Improving Network Performance with Linux Flowtables
___________________________________________________________________
Improving Network Performance with Linux Flowtables
Author : furkansahin
Score : 86 points
Date : 2024-03-04 17:05 UTC (5 hours ago)
(HTM) web link (www.ubicloud.com)
(TXT) w3m dump (www.ubicloud.com)
| guerby wrote:
| Another article about flowtables:
|
| https://firewalld.org/2023/05/nftables-flowtable
|
| Documentation:
|
| https://wiki.nftables.org/wiki-nftables/index.php/Flowtables
| dboreham wrote:
| Nicely written article, and now I know about Ubicloud.
| tux1968 wrote:
| A little more info:
|
| https://www.kernel.org/doc/Documentation/networking/nf_flowt...
| furkansahin wrote:
| Hello from the author, here! I wanted to explain that we use
| Nftables for NATing, Firewall Rules and some spoofing avoidance
| tasks at the moment. Enabling Flowtables benefit the full
| networking stack for any connections. Give it a try!
|
| Also, happy to answer if there are any questions.
| binkHN wrote:
| If more performance is better, why isn't this the default in the
| Linux networking stack? What are the drawbacks of using this and
| are there security implications?
| furkansahin wrote:
| There are a couple of important points to consider when using
| Flowtables. Depending on the traffic characteristics,
| Flowtables may also drop the network performance. It also
| depends on the amount of rules and their configuration. For
| example, if we had much much more rules in nftables file for so
| many different operations (think of it like adding a new rule
| per IP address), Flowtables would hurt the performance in
| Ubicloud. They go hand in hand with how the overall network is
| configured. In our case at Ubicloud, it helps us, but we have a
| fairly simple Nftables definition as you can see a big part of
| it here
| https://github.com/ubicloud/ubicloud/blob/main/prog/vnet/upd...
| chatmasta wrote:
| I wonder if there are any security implications to consider,
| particularly in a multi-tenant environment, when caching
| routing information for the "same" connection.
| furkansahin wrote:
| In this case, no. The reason is, we setup separate network
| namespaces per VM and the flowtables are also created
| separately per namespace.
| fdr wrote:
| I think history is at least a part of this. The software flow
| table implementation (which ubicloud demonstrates here, full
| disclosure, I work there) offers some speedup, but the motive
| appears closely coupled with hardware flow table offloading:
| https://lwn.net/Articles/738214/
| nolist_policy wrote:
| nftables is very flexible and flowtables won't work
| (transparently) in all configurations.
|
| For example sending packets from a single connection over
| multiple links round-robin. The cache will remember only one
| link and route all packets over that link.
|
| And packets in offloaded connections will bypass nftables
| rate/bandwidth limits and counters.
| rany_ wrote:
| > In Ubicloud's case, enabling flowtables just took seven lines
| of code!
|
| Could have been six lines by combining these two lines:
| ip protocol tcp counter flow offload @ubi_flowtable ip
| protocol udp counter flow offload @ubi_flowtable
|
| into: meta l4proto { tcp, udp } flow offload
| @ubi_flowtable
|
| Also, their changes only work for IPv4. The above would work for
| both IPv4 and IPv6.
| fdr wrote:
| That's a good one. Ubicloud has decent IPv6 support as we use
| it for our underlay network (in fact...for a while, as a
| prototype, it only supported IP6), but we missed a trick here.
|
| https://github.com/ubicloud/ubicloud/pull/1322
| rany_ wrote:
| You're most welcome, happy to help!
| darksim905 wrote:
| Showing the netfilter _with_ the OSI layer on the left, after all
| these years is absolutely clutch and as an educator, I 'm
| thankful the author made such a thing. It's beautiful.
|
| I feel like from an abstraction standpoint, a lot of these
| concepts get lost when you transition to Windows and in either
| direction, these pre/post chains never quite made sense to me on
| the surface. Though, I'm positive it's because I'm not a
| developer or sysadmin in linux daily. I imagine there's some
| fascinating stuff you can do.
| chatmasta wrote:
| This diagram [0] from Wikipedia has always been my favorite way
| of understanding the flow of a packet through the kernel.
|
| [0]
| https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilte...
| throwawaaarrgh wrote:
| > an opensource alternative to AWS
|
| Just putting out there that OpenStack is open source, already
| exists, very feature complete, and there are even hosting
| providers that will give you your own OpenStack control plane and
| only bill you for the resources you use. Only one provider in the
| US, but several in Europe.
|
| No need to deploy and manage your own clusters on bare metal.
| They do it all for you and just give you an API, same as AWS. Way
| better than managing your own stack. The fact that more providers
| aren't doing this kind of blows my mind. But they probably prefer
| the proprietary walled garden, easier to keep customers from
| moving.
| einpoklum wrote:
| Should I really read about these tables, or will the Linux kernel
| replace them with yet another set of tables in a few years, with
| almost-but-not-quite-the-same semantics, a different command-line
| tool, different column order etc. ?
|
| -- disgruntled user
___________________________________________________________________
(page generated 2024-03-04 23:00 UTC)