UDP buffer overflows?

Home » Asterisk Users » UDP buffer overflows?
Asterisk Users 5 Comments

Hi,

On one of our asterisk systems that is quite busy, we are seeing the
following from ‘netstat -s’:

Udp:
17725210 packets received
36547 packets to unknown port received.
44017 packet receive errors
17101174 packets sent
RcvbufErrors: 44017 <--- this When this number increases, we see SIP errors, and in particular
Qualify packets are lost, and temporarily disable handsets, causing
all sorts of minor chaos.

I have already tuned from the defaults of:

net.core.rmem_max = 131071
net.core.wmem_max = 131071
net.core.rmem_default = 111616
net.core.wmem_default = 111616
net.core.optmem_max = 10240
net.core.netdev_max_backlog = 1000

up to:

net.core.rmem_max = 1048575
net.core.wmem_max = 1048575
net.core.rmem_default = 1048575
net.core.wmem_default = 1048575
net.core.optmem_max = 1048575
net.core.netdev_max_backlog = 10000

with no luck.

Any more suggestions?

Many thanks,
Steve

5 thoughts on - UDP buffer overflows?

  • [snip]

    Additional question – Do I need to restart Asterisk for these settings
    to apply to SIP? I have not done so yet, and further reading suggests
    that this is a per-process buffer and may be assigned when the
    listener is created.

    All pointers gratefully received 🙂
    Steve

  • I had to double check myself in the kernel sources (in
    net/core/sock.c:sock_init_data), but yes you will need to recreate the
    socket for the rmem_default option to take effect.

    I was just about to ask if changing the sysctl changed the frequency
    that you see the error counter increment when I saw your follow on.

    Cheers,
    Shaun

  • Thanks for making the extra effort Shaun 🙂 I will restart Asterisk
    when I get a chance, and re-check.

    Regards,
    Steve

  • False alarm?

    FYI, it seems that the issue is not at-all what we thought.

    It transpires that the unit is an old Asterisk 1.2 system, and that
    the DNS server that the unit had been pointed to had been taken out of
    service. This caused lots of threads to back-up while attempting to
    resolve things, and this dragged down the whole of asterisk, seemingly
    to the point where it was not reading UDP data out of its buffers fast
    enough!

    Thanks,
    Steve