<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Test bandwidth/speed from Gaia VSX in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184373#M33885</link>
    <description>&lt;P&gt;Ultimately, the recommendation for a whole-cluster outage window is because load testing is often disruptive. After all, you're trying to get the system to work as hard as it can to find the weakest point. Even if the cluster itself isn't sourcing or sinking the traffic, there's a risk that it is the weakest point. No matter how many VSs you have, VSX is a single OS running a single kernel, single filesystem, and so on. If you stress test to failure, there's a chance the whole box fails, taking all of its contexts with it.&lt;/P&gt;
&lt;P&gt;Using iperf on the cluster members directly to test performance without involving systems behind the cluster is only marginally more risk.&lt;/P&gt;
&lt;P&gt;As for the curl_cli test, unless you were running it to /dev/null, that is bounded by storage I/O performance. If you're using Check Point branded servers, the storage is probably spinning disks. It's likely to be sequential writes, but there are a million situations which can lead to I/O contention, which would definitely bottleneck downloads via cURL.&lt;/P&gt;</description>
    <pubDate>Tue, 20 Jun 2023 15:46:40 GMT</pubDate>
    <dc:creator>Bob_Zimmerman</dc:creator>
    <dc:date>2023-06-20T15:46:40Z</dc:date>
    <item>
      <title>Test bandwidth/speed from Gaia VSX</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184329#M33876</link>
      <description>&lt;P&gt;I'm trying to test the transfer rate between two firewalls (to test the infrastructure in between). Unfortunately both firewalls are VSX and the 10G interfaces are all attached to the VS1.&lt;/P&gt;&lt;P&gt;In VS0 I would copy a big file to see the speed between the boxes but how do I do that (the speedtest) between the VS1? I cannot make scp directly to a VS 1 using the interface of the VS1.&lt;/P&gt;&lt;P&gt;Or am I wrong and there is a possibility?&lt;/P&gt;&lt;P&gt;best regards&lt;/P&gt;&lt;P&gt;daniel&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 20 Jun 2023 08:55:26 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184329#M33876</guid>
      <dc:creator>Daniel_Fischler</dc:creator>
      <dc:date>2023-06-20T08:55:26Z</dc:date>
    </item>
    <item>
      <title>Re: Test bandwidth/speed from Gaia VSX</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184348#M33879</link>
      <description>&lt;P&gt;Using the Gateway as the source or destination for such tests isn't generally optimal, nor desirable from a SecureXL perspective (Refer&amp;nbsp;&lt;SPAN&gt;sk32578).&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 20 Jun 2023 11:33:05 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184348#M33879</guid>
      <dc:creator>Chris_Atkinson</dc:creator>
      <dc:date>2023-06-20T11:33:05Z</dc:date>
    </item>
    <item>
      <title>Re: Test bandwidth/speed from Gaia VSX</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184370#M33883</link>
      <description>&lt;P&gt;Note that scp is really bad for network link performance testing. Its performance is limited mostly by the cryptographic performance of a single CPU core, so you are extremely unlikely to ever get even 1 gigabit of throughput from it.&lt;/P&gt;
&lt;P&gt;What version of VSX are you running?&lt;/P&gt;
&lt;P&gt;Are these firewalls in production, or is this performance testing before declaring them ready for production use?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;FONT size="7"&gt;If your firewalls are production, only do this in an outage window for the whole VSX cluster.&lt;/FONT&gt;&lt;/P&gt;
&lt;P&gt;If you are running R80.40 or newer, your version of VSX is based on network namespaces, which is a pretty well-understood Linux feature. You can get a statically-linked version of iperf and use standard Linux tools (specifically, &lt;A href="https://www.man7.org/linux/man-pages/man8/ip-netns.8.html" target="_self"&gt;ip netns(8)&lt;/A&gt;) to run it in a particular namespace. First get a list of the namespace names using 'ip netns list' like this:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;[Expert@SomeVsxCluster:0]# ip netns list
CTX00000 (id: 0)
CTX00002 (id: 2)
CTX00003 (id: 3)
CTX00004 (id: 4)
...&lt;/LI-CODE&gt;
&lt;P&gt;Then you use 'ip netns exec &amp;lt;namespace name&amp;gt; &amp;lt;command&amp;gt;' to execute &amp;lt;command&amp;gt; in the specified namespace.&lt;/P&gt;</description>
      <pubDate>Tue, 20 Jun 2023 14:47:30 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184370#M33883</guid>
      <dc:creator>Bob_Zimmerman</dc:creator>
      <dc:date>2023-06-20T14:47:30Z</dc:date>
    </item>
    <item>
      <title>Re: Test bandwidth/speed from Gaia VSX</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184372#M33884</link>
      <description>&lt;P&gt;This is VSX R81.10 and unfortunately this is already in production. I made a short connection test by just downloading a file using curl_cli and I agree: performance is really limited.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks for the information about the namespace feature and especially for the warning&amp;nbsp;8)&lt;/img&gt;&lt;/P&gt;&lt;P&gt;We will forget this idea and will use additional devices to generate traffic &lt;EM&gt;through&lt;/EM&gt; the firewall.&lt;/P&gt;</description>
      <pubDate>Tue, 20 Jun 2023 15:10:04 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184372#M33884</guid>
      <dc:creator>Daniel_Fischler</dc:creator>
      <dc:date>2023-06-20T15:10:04Z</dc:date>
    </item>
    <item>
      <title>Re: Test bandwidth/speed from Gaia VSX</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184373#M33885</link>
      <description>&lt;P&gt;Ultimately, the recommendation for a whole-cluster outage window is because load testing is often disruptive. After all, you're trying to get the system to work as hard as it can to find the weakest point. Even if the cluster itself isn't sourcing or sinking the traffic, there's a risk that it is the weakest point. No matter how many VSs you have, VSX is a single OS running a single kernel, single filesystem, and so on. If you stress test to failure, there's a chance the whole box fails, taking all of its contexts with it.&lt;/P&gt;
&lt;P&gt;Using iperf on the cluster members directly to test performance without involving systems behind the cluster is only marginally more risk.&lt;/P&gt;
&lt;P&gt;As for the curl_cli test, unless you were running it to /dev/null, that is bounded by storage I/O performance. If you're using Check Point branded servers, the storage is probably spinning disks. It's likely to be sequential writes, but there are a million situations which can lead to I/O contention, which would definitely bottleneck downloads via cURL.&lt;/P&gt;</description>
      <pubDate>Tue, 20 Jun 2023 15:46:40 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/Test-bandwidth-speed-from-Gaia-VSX/m-p/184373#M33885</guid>
      <dc:creator>Bob_Zimmerman</dc:creator>
      <dc:date>2023-06-20T15:46:40Z</dc:date>
    </item>
  </channel>
</rss>

