Nos kernels anteriores a 3.6, você poderia ter sido atingido pelo ENOBUFS para o tráfego IPv4 / v6 regular, quando o net.ipv4.route.max_size ou net.ipv6.route.max_size limite foi deplorado, de acordo .
Começando com o kernel 3.6, o cache de roteamento foi removido e net.ipv4.route.max_size perdeu sua influência na quantidade de entradas dst. Então, geralmente, isso não seria mais possível.
No entanto, você ainda pode encontrar esse erro, como eu, ao usar o IPSec. Depois de certa quantidade de túneis IPSec criados, não consegui fazer ping no host remoto:
# ping 10.100.0.1
connect: No buffer space available
ping do iputils cria um descritor de arquivo de teste e usa o connect () nele, para ligar o dst ip. Quando isso acontece, a entrada do cache dst para o AF fornecido é criada pelo kernel, e xfrm4 dst cache limite de entradas já foi depleated no meu caso. Este limite é controlado pela configuração sysctl:
xfrm4_gc_thresh - INTEGER
The threshold at which we will start garbage collecting for IPv4
destination cache entries. At twice this value the system will
refuse new allocations.
Eu encontrei isso usando o kernel 3.10.59, onde o limite padrão é muito baixo - 1024. A partir do kernel 3.10.83, este limite foi aumentado para 32768, e seria muito mais difícil de acertar .
Então, eu publiquei:
# sysctl net.ipv4.xfrm4_gc_thresh=32768
e isso fez a coisa por mim.
Caminho aproximado no kernel para o meu caso com IPSec:
ip4_datagram_connect() -> ip_route_connect() -> ip_route_output_flow() ->
xfrm_lookup() -> xfrm_resolve_and_create_bundle() ->
... -> xfrm_alloc_dst() -> dst_alloc() with xfrm4_dst_ops, where gc is set.