¿Por qué he visto "Invalid argument" durante un acceso a un ECS de Linux?
Síntomas
- Cuando un ECS de Linux envía una solicitud a un servidor de la misma subred, el servidor ha recibido la solicitud pero no devuelve una respuesta. Cuando el servidor hace ping al cliente, aparece el mensaje "sendmsg: Invalid argument" (Argumento no válido).
64 bytes from 192.168.0.54: icmp_seq=120 ttl=64 time=0.064 ms 64 bytes from 192.168.0.54: icmp_seq=122 ttl=64 time=0.071 ms ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
- "Neighbor table overflow" se muestra en el archivo de log /var/log/messages o en la salida del comando dmesg de un ECS de Linux.
[21208.317370] neighbour: ndisc_cache: neighbor table overflow! [21208.317425] neighbour: ndisc_cache: neighbor table overflow! [21208.317473] neighbour: ndisc_cache: neighbor table overflow! [21208.317501] neighbour: ndisc_cache: neighbor table overflow!
Causa raíz
La tabla Neighbour hace referencia a la caché ARP. Cuando la tabla Neighbour se desborda, la tabla ARP está llena y rechazará las conexiones.
Puede ejecutar el siguiente comando para comprobar el tamaño máximo de la tabla de caché ARP:
# cat /proc/sys/net/ipv4/neigh/default/gc_thresh3
/proc/sys/net/ipv4/neigh/default/gc_thresh1 /proc/sys/net/ipv4/neigh/default/gc_thresh2 /proc/sys/net/ipv4/neigh/default/gc_thresh3
- gc_thresh1: El número mínimo de entradas que se deben mantener en la caché ARP. El recolector de basura no se ejecutará si hay menos de este número de entradas en la caché.
- gc_thresh2: El número máximo suave de entradas que se deben mantener en la caché ARP. El recolector de basura permitirá que el número de entradas exceda esto durante 5 segundos antes de que se realice la recolección.
- gc_thresh3: El número máximo de entradas a conservar en la caché ARP. El recolector de basura siempre se ejecutará si hay más de este número de entradas en la caché.
Para verificar el número real de entradas ARP IPv4, ejecute el siguiente comando:
# ip -4 neigh show nud all | wc -l
Solución
- Asegúrese de que el número de servidores en una subred es menor que el valor default.gc_thresh3.
- Ajuste de parámetros: cambie gc_thresh3 a un valor mucho mayor que el número de servidores en el mismo segmento de red de VPC, y asegúrese de que el valor gc_thresh3 es mayor que el valor gc_thresh2 y el valor gc_thresh2 es mayor que el valor gc_thresh1.
Por ejemplo, si una subred tiene una máscara de 20 bits, la red puede alojar un máximo de 4,096 servidores. El valor default.gc_thresh3 de este segmento de red debe ser un valor mucho mayor que 4,096.
Efectivo temporal:# sysctl -w net.ipv4.neigh.default.gc_thresh1=2048 # sysctl -w net.ipv4.neigh.default.gc_thresh2=4096 # sysctl -w net.ipv4.neigh.default.gc_thresh3=8192
Efectivo siempre:
Agregue el siguiente contenido al archivo /etc/sysctl.conf:net.ipv4.neigh.default.gc_thresh1 = 2048 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh3 = 8192
Agregue la configuración de IPv6 si es necesario:net.ipv6.neigh.default.gc_thresh1 = 2048 net.ipv6.neigh.default.gc_thresh2 = 4096 net.ipv6.neigh.default.gc_thresh3 = 8192