<?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: 64000 Chassis - capture traffic on BPEthX interface in Hyperscale Firewall (Maestro)</title>
    <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/240237#M3175</link>
    <description>&lt;P&gt;Good day!&lt;/P&gt;&lt;P&gt;I have written an email to our customer as soon as I saw the SK. It was not accepted as a valid explanation.&lt;/P&gt;&lt;P&gt;On the bright side, I was able to capture all packets on a BPEthX interface on our test chassis. The next step will be to gather another set of pcaps from BPEthX and then look for malformed packets in wireshark. The concern is that the chassis itself may calculates the length field wrong, and I need to disprove it.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 03 Feb 2025 06:09:15 GMT</pubDate>
    <dc:creator>Gennady</dc:creator>
    <dc:date>2025-02-03T06:09:15Z</dc:date>
    <item>
      <title>64000 Chassis - capture traffic on BPEthX interface</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/232319#M3172</link>
      <description>&lt;P&gt;Hi, everyone!&lt;/P&gt;&lt;P&gt;We have a strange problem in a customer environment. There are rx_length_errors constantly increasing on BPEth0 and BPEth1 interfaces. We can see that there are no rx_undersize or rx_oversize in the output of ethtool -S BPEthX.&lt;/P&gt;&lt;P&gt;#ethtool -S BPEth1 | grep 'port.rx_undersize\|port.rx_oversize\|port.rx_length_erro&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; rx_length_errors: 172188&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_length_errors: 172188&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_undersize: 0&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_oversize: 0&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;#ethtool -S BPEth1 | grep 'port.rx_undersize\|port.rx_oversize\|port.rx_length_erro&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; rx_length_errors: 172192&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_length_errors: 172192&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_undersize: 0&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; port.rx_oversize: 0&lt;/P&gt;&lt;P&gt;I have tried to capture traffic on BPEthX interface of our lab Chassis 64000. 99% of traffic is CCP and ARPs. There is no production traffic in tpcdump or cppcap. It looks like SecureXL doing the same thing as with VSX wrpj interfaces.&lt;/P&gt;&lt;P&gt;What is the procedure to capture all frames which are passing via back-plane interfaces?&lt;/P&gt;&lt;P&gt;What may be the reason for the strange rx_length_errors?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 11 Nov 2024 13:32:57 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/232319#M3172</guid>
      <dc:creator>Gennady</dc:creator>
      <dc:date>2024-11-11T13:32:57Z</dc:date>
    </item>
    <item>
      <title>Re: 64000 Chassis - capture traffic on BPEthX interface</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/232381#M3173</link>
      <description>&lt;P&gt;I'd consult with TAC here.&lt;/P&gt;</description>
      <pubDate>Mon, 11 Nov 2024 23:13:50 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/232381#M3173</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2024-11-11T23:13:50Z</dc:date>
    </item>
    <item>
      <title>Re: 64000 Chassis - capture traffic on BPEthX interface</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/240215#M3174</link>
      <description>&lt;P&gt;Believe it or not, this may be related to a bug in the icen driver not properly computing the Length field of the generated Ethernet frame.&amp;nbsp; See here:&amp;nbsp;&lt;A href="https://support.checkpoint.com/results/sk/sk183040" target="_blank" rel="noopener"&gt;&lt;SPAN&gt;sk183040: HealthCheck Point reports "rx_length_errors" for Security Group Members in a Maestro cluster&lt;/SPAN&gt;&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Sat, 01 Feb 2025 23:18:50 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/240215#M3174</guid>
      <dc:creator>Timothy_Hall</dc:creator>
      <dc:date>2025-02-01T23:18:50Z</dc:date>
    </item>
    <item>
      <title>Re: 64000 Chassis - capture traffic on BPEthX interface</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/240237#M3175</link>
      <description>&lt;P&gt;Good day!&lt;/P&gt;&lt;P&gt;I have written an email to our customer as soon as I saw the SK. It was not accepted as a valid explanation.&lt;/P&gt;&lt;P&gt;On the bright side, I was able to capture all packets on a BPEthX interface on our test chassis. The next step will be to gather another set of pcaps from BPEthX and then look for malformed packets in wireshark. The concern is that the chassis itself may calculates the length field wrong, and I need to disprove it.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 03 Feb 2025 06:09:15 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/64000-Chassis-capture-traffic-on-BPEthX-interface/m-p/240237#M3175</guid>
      <dc:creator>Gennady</dc:creator>
      <dc:date>2025-02-03T06:09:15Z</dc:date>
    </item>
  </channel>
</rss>

