<?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: udp data packets lost at Heavy Forwarder in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477887#M82015</link>
    <description>&lt;P&gt;In addition I suggest to use two Heavy forwarders with a Load balancer to distribute load and be sure of HA features!&lt;BR /&gt;
Bye.&lt;BR /&gt;
Giuseppe&lt;/P&gt;</description>
    <pubDate>Sat, 07 Sep 2019 08:01:34 GMT</pubDate>
    <dc:creator>gcusello</dc:creator>
    <dc:date>2019-09-07T08:01:34Z</dc:date>
    <item>
      <title>udp data packets lost at Heavy Forwarder</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477884#M82012</link>
      <description>&lt;P&gt;I am observing packet loss on Heavy forwarder due to which I am missing the important messages which we are being sent using snmp traps. I have already increased the rmem buffer size to the suggested value for splunk stream app on Splunk docs(which I thought should be more than enough) , but even after that change there are still a lot of packet drops on the HF.&lt;/P&gt;

&lt;P&gt;current stats:&lt;/P&gt;

&lt;P&gt;sysctl net.core.rmem_max&lt;BR /&gt;
net.core.rmem_max = 33554432&lt;/P&gt;

&lt;P&gt;netstats:&lt;BR /&gt;
netstat -suna &lt;/P&gt;

&lt;P&gt;Udp: &lt;BR /&gt;
52071486 packets received &lt;BR /&gt;
21017 packets to unknown port received. &lt;BR /&gt;
3747277 packet receive errors &lt;BR /&gt;
82100 packets sent &lt;BR /&gt;
3747277 receive buffer errors &lt;BR /&gt;
0 send buffer errors &lt;BR /&gt;
UdpLite: &lt;BR /&gt;
IpExt: &lt;BR /&gt;
InNoRoutes: 27 &lt;BR /&gt;
InMcastPkts: 8 &lt;BR /&gt;
InOctets: 31643507863 &lt;BR /&gt;
OutOctets: 6061193400 &lt;BR /&gt;
InMcastOctets: 288 &lt;BR /&gt;
InNoECTPkts: 62078913 &lt;BR /&gt;
InECT0Pkts: 1301&lt;/P&gt;

&lt;P&gt;Any idea, what should be the ideal size for the net.core.rmem_max that can guarantee receive buffer errors reduce to zero.&lt;BR /&gt;
Or this is something which we cannot achieve by increase the buffer size?&lt;/P&gt;</description>
      <pubDate>Wed, 30 Sep 2020 02:09:00 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477884#M82012</guid>
      <dc:creator>splunk4nisha</dc:creator>
      <dc:date>2020-09-30T02:09:00Z</dc:date>
    </item>
    <item>
      <title>Re: udp data packets lost at Heavy Forwarder</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477885#M82013</link>
      <description>&lt;P&gt;Have you tried enabling useACK=true&lt;BR /&gt;
&lt;A href="https://docs.splunk.com/Documentation/Splunk/latest/Admin/Outputsconf"&gt;https://docs.splunk.com/Documentation/Splunk/latest/Admin/Outputsconf&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 06 Sep 2019 19:19:27 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477885#M82013</guid>
      <dc:creator>wgawhh5hbnht</dc:creator>
      <dc:date>2019-09-06T19:19:27Z</dc:date>
    </item>
    <item>
      <title>Re: udp data packets lost at Heavy Forwarder</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477886#M82014</link>
      <description>&lt;P&gt;Based on your HF hardware capacity, set one of the below for the UDP input that you've:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;queueSize = &amp;lt;integer&amp;gt;[KB|MB|GB]
* Maximum size of the in-memory input queue.
* Default: 500KB.

persistentQueueSize = &amp;lt;integer&amp;gt;[KB|MB|GB|TB]
* Maximum size of the persistent queue file.
* Persistent queues can help prevent loss of transient data. For information on
  persistent queues and how the 'queueSize' and 'persistentQueueSize' settings
  interact, search the online documentation for "persistent queues"..
* If you set this to a value other than 0, then 'persistentQueueSize' must
  be larger than either the in-memory queue size (as defined by the 'queueSize'
  setting in inputs.conf or 'maxSize' settings in [queue] stanzas in
  server.conf).
* Default: 0 (no persistent queue).
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Fri, 06 Sep 2019 20:23:33 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477886#M82014</guid>
      <dc:creator>somesoni2</dc:creator>
      <dc:date>2019-09-06T20:23:33Z</dc:date>
    </item>
    <item>
      <title>Re: udp data packets lost at Heavy Forwarder</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477887#M82015</link>
      <description>&lt;P&gt;In addition I suggest to use two Heavy forwarders with a Load balancer to distribute load and be sure of HA features!&lt;BR /&gt;
Bye.&lt;BR /&gt;
Giuseppe&lt;/P&gt;</description>
      <pubDate>Sat, 07 Sep 2019 08:01:34 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/udp-data-packets-lost-at-Heavy-Forwarder/m-p/477887#M82015</guid>
      <dc:creator>gcusello</dc:creator>
      <dc:date>2019-09-07T08:01:34Z</dc:date>
    </item>
  </channel>
</rss>

