Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
any thoughts?
yhanks,
Ron
Am 17.06.2024 um 11:58:49 Uhr schrieb R C:
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
Depending on the rules (SPI needs much more resources than stateless) and the traffic, there will be an impact. I can feel that effect on the Cisco SPI firewall in my C886va if I use it on links that have high traffic.
If you need a firewall, you need to provide enough resources to run it properly without a performance import.
On 6/17/24 12:43, Marco Moock wrote:
Am 17.06.2024 um 11:58:49 Uhr schrieb R C:
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
Depending on the rules (SPI needs much more resources than stateless) and the traffic, there will be an impact. I can feel that effect on the Cisco SPI firewall in my C886va if I use it on links that have high traffic.
Well, I am talking about firewalld, RHEL8. Regardless of SPI. My reasoning is, a firewall needs to check pretty much every packet a node receives. A node, compute or data node, receives a lot of traffic (That's why Infiniband is used, IB) and a compute node uses a lot of cycles, typicaly one tries to come as close to the number of flops to be used (also threads/ranks and core use). So every incoming packet needs to be done something firewall wise (which takes cycles) so that has an impact on bandwith between nodes. On the other hand machines "running at/close to max" don't have of cycles to spare. So a busy compute node with a lot of traffic mightbe seriously impacted(?). Are there any available metrics, or what would be a good way to 'predict' that?
If you need a firewall, you need to provide enough resources to run it properly without a performance import.
That's the question, enough resources, how do you determine how much resources a compute node would need?
Ron
Am 17.06.2024 um 12:53:31 Uhr schrieb R C:
Well, I am talking about firewalld, RHEL8. Regardless of SPI. My reasoning is, a firewall needs to check pretty much every packet a node receives.
If you do SPI (default in many cases and necessary in many situations), also outgoing packages have to be investigated to be tracked to match the incoming (allow related) packages.
A node, compute or data node, receives a lot of traffic (That's why Infiniband is used, IB) and a compute node uses a lot of cycles, typicaly one tries to come as close to the number of flops to be used (also threads/ranks and core use). So every incoming packet needs to be done something firewall wise (which takes cycles) so that has an impact on bandwith between nodes.
Is has impact on the bandwidth if too less CPU cycles are available.
On the other hand machines "running at/close to max" don't have of cycles to spare. So a busy compute node with a lot of traffic mightbe seriously impacted(?). Are there any available metrics, or what would be a good way to 'predict' that?
Test maximum throughput to many different destinations and measure CPU cycles.
On 6/17/2024 11:53 AM, R C wrote:
Well, I am talking about firewalld, RHEL8. Regardless of SPI. My reasoning is, a firewall needs to check pretty much every packet a node receives.
Realize that firewalld isn't itself the actual firewall, but a management front-end for the kernel code that does the actual packet inspection. You'll want to look at the back end that firewalld uses. On RHEL8, the default back end in the kernel is nftables. (Earlier operating systems used iptables and that's still available on RHEL8.) So start by googling for "nftables performance". The performance section in the nftables wiki might be another good place to start.
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
On 6/20/24 08:45, Eric Garver wrote:
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
I am wondering, if there are some known metrics, or examples so one could create some rough estimates of possible performance loss?
On Fri, Jun 21, 2024 at 11:11:15AM -0600, R C wrote:
On 6/20/24 08:45, Eric Garver wrote:
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
I am wondering, if there are some known metrics, or examples so one could create some rough estimates of possible performance loss?
I'm not exactly sure what you're asking for.
To benchmark your network you could use tools like iperf3 or netperf.
On 6/21/24 12:52, Eric Garver wrote:
On Fri, Jun 21, 2024 at 11:11:15AM -0600, R C wrote:
On 6/20/24 08:45, Eric Garver wrote:
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
https://firewalld.org/2023/05/nftables-flowtableI am wondering, if there are some known metrics, or examples so one could create some rough estimates of possible performance loss?
I'm not exactly sure what you're asking for.
To benchmark your network you could use tools like iperf3 or netperf.
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
I was just wondering if one could roughly calculate/estimate the (theoretical) performance loss
Am Fri, 21 Jun 2024 16:17:01 -0600 schrieb R C cjvijf@gmail.com:
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
Can you track down the reason for that? Is that already related to the firewall (nftables, maybe invoked by firewalld) or to anything other?
Disable firewall and measure again?
On 22. Jun 2024, at 7.25, Marco Moock mm@dorfdsl.de wrote:
Am Fri, 21 Jun 2024 16:17:01 -0600 schrieb R C cjvijf@gmail.com:
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
Can you track down the reason for that? Is that already related to the firewall (nftables, maybe invoked by firewalld) or to anything other? -- _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 6/21/24 22:24, Marco Moock wrote:
Am Fri, 21 Jun 2024 16:17:01 -0600 schrieb R Ccjvijf@gmail.com:
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
Can you track down the reason for that? Is that already related to the firewall (nftables, maybe invoked by firewalld) or to anything other?
yes the differences in performance show up when I run iperf3 with the firewall disabled/stopped versus the firewall running
(on a side note, what would be more 'expensive' for the firewall to implement, a port opened with "|firewall-cmd --add-port=22/tcp" or have a rich rule that does the same thing for a set of source IPs?) |
-- _______________________________________________ firewalld-users mailing list --firewalld-users@lists.fedorahosted.org To unsubscribe send an email tofirewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Am Sat, 22 Jun 2024 06:04:24 -0600 schrieb R C cjvijf@gmail.com:
(on a side note, what would be more 'expensive' for the firewall to implement, a port opened with "|firewall-cmd --add-port=22/tcp" or have a rich rule that does the same thing for a set of source IPs?)
I assume (I haven tested) the rich.rule with the source IPs will need more resources. It needs additional checks for the IP addresses.
On Sat, Jun 22, 2024 at 04:38:23PM +0200, Marco Moock wrote:
Am Sat, 22 Jun 2024 06:04:24 -0600 schrieb R C cjvijf@gmail.com:
(on a side note, what would be more 'expensive' for the firewall to implement, a port opened with "|firewall-cmd --add-port=22/tcp" or have a rich rule that does the same thing for a set of source IPs?)
I assume (I haven tested) the rich.rule with the source IPs will need more resources. It needs additional checks for the IP addresses.
Neither. It's almost certainly not noticeable for a benchmark like iperf3.
Once the connection is established (after the TCP handshake) both of the examples (--add-port and rich rule) follow the _exact_ same packet path. I mentioned earlier in the thread that firewalld short circuits established connections.
The 10% overhead you're seeing is likely due to a combination of connection tracking and the nftables hook. The latter can be completely avoided by using NftablesFlowtable in firewalld.conf.
On Fri, Jun 21, 2024 at 04:17:01PM -0600, R C wrote:
On 6/21/24 12:52, Eric Garver wrote:
On Fri, Jun 21, 2024 at 11:11:15AM -0600, R C wrote:
On 6/20/24 08:45, Eric Garver wrote:
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
https://firewalld.org/2023/05/nftables-flowtableI am wondering, if there are some known metrics, or examples so one could create some rough estimates of possible performance loss?
I'm not exactly sure what you're asking for.
To benchmark your network you could use tools like iperf3 or netperf.
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
I was just wondering if one could roughly calculate/estimate the (theoretical) performance loss
I'm not sure what two things you're comparing.
At any rate, I would expect it to vary widely depending CPU, memory, etc.
On 6/24/24 10:09, Eric Garver wrote:
On Fri, Jun 21, 2024 at 04:17:01PM -0600, R C wrote:
On 6/21/24 12:52, Eric Garver wrote:
On Fri, Jun 21, 2024 at 11:11:15AM -0600, R C wrote:
On 6/20/24 08:45, Eric Garver wrote:
On Mon, Jun 17, 2024 at 11:58:49AM -0600, R C wrote:
Hello,
I was wondering, in high performance environments (high compute loads, high bandwith loads(IB)), is it a concern to run a firewall for network performance reasons? Also, with high compute loads, I heard/read a rumor that a firewall might actually cap traffic?
The actual packet processing uses nftables in the kernel. Established connections are short circuited and thus skip most of the rule set. In other words, it's as fast as rolling your own nftables rule set.
Forwarded traffic can also be accelerated via flowtable. This should offer line rate forwarding.
https://firewalld.org/2023/05/nftables-flowtableI am wondering, if there are some known metrics, or examples so one could create some rough estimates of possible performance loss?
I'm not exactly sure what you're asking for.
To benchmark your network you could use tools like iperf3 or netperf.
I used iperf3, and when not under load, cpu nor bandwidth, it shows a 10% bandwidth loss (over IB)
I was just wondering if one could roughly calculate/estimate the (theoretical) performance loss
I'm not sure what two things you're comparing.
Bandwidth on anIB connection, firewall vs no firewall.
At any rate, I would expect it to vary widely depending CPU, memory, etc.
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
Kenneth Porter -
Marco Moock -
Paavo Leinonen -
R C