Linux dejó caer paquetes UDP

Solución de problemas de caída de paquetes UDP

C05348A3-9AB8-42C9-A6E0-81DB3AC59FEB
           

Esta imagen es uno de los mejores resúmenes de todas las herramientas de solución de problemas de Linux que he visto:

linux_observability_tools .

Una vez tuve que solucionar un problema con paquetes UDP más grandes que MTU que se descartaban entre hosts en diferentes subredes. Se necesitaban pruebas sólidas para que el proveedor de la nube admitiera que había un problema.

Primero, usé el siguiente comando para probar paquetes fragmentados:

iperf -s -p 7870 -u
------------------------------------------------------------
Server listening on UDP port 7870
Receiving 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.1 port 7870 connected with 192.168.1.1 port 45467
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec   494 KBytes   402 Kbits/sec   0.021 ms    0/  344 (0%)
[  4] local 192.168.1.1 port 7870 connected with 192.168.8.8 port 43130
[  4]  0.0-10.1 sec   494 KBytes   402 Kbits/sec   0.023 ms    0/  344 (0%)
[  3] local 192.168.1.1 port 7870 connected with 192.168.8.8 port 47294
[  3]  0.0-10.1 sec   494 KBytes   402 Kbits/sec   0.048 ms    0/  344 (0%)

Luego ejecuté una prueba desde un host "bueno" enviando una solicitud UDP más grande que la MTU permitida:

iperf -c host1 -u -p 7870 -l 3832
------------------------------------------------------------
Client connecting to sd6pstg-35b5, UDP port 7870
Sending 3832 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.8.8 port 47294 connected with 192.168.1.1 port 7870
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  1.26 MBytes  1.05 Mbits/sec
[  3] Sent 344 datagrams
[  3] Server Report:
[  3]  0.0-10.1 sec   494 KBytes   402 Kbits/sec   0.048 ms    0/  344 (0%)

Ejecutaron la misma prueba en un host "malo":

iperf -c host1 -u -p 7870 -l 3832
------------------------------------------------------------
Client connecting to sd6pstg-35b5, UDP port 7870
Sending 3832 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.9.9 port 38406 connected with 192.168.1.1 port 7870
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec  1.26 MBytes  1.05 Mbits/sec
[  3] Sent 344 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.
sysctl -a |grep udp

Detalles adicionales sobre ese comando:
https://iperf.fr/iperf-doc.php#tuningudp



sudo ifconfig eth0 mtu 800
ip route flush cache
 
ping -s 1520 -M dont -i 0.8 192.168.1.1
tcpdump -vv -i eth0 host 192.168.1.1 and udp -n

El siguiente artículo también fue muy útil: ¿Linux tiene un equivalente de Windows PMTU Blackhole Router Discovery? para activar tcp_mtu_probing:

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing 
Possible values
0: disabled
1: enabled when black hole detected
2: always enabled 
 
tracepath -n 192.168.1.1
1?: [LOCALHOST]                                         pmtu 1464
1:  169.254.154.42                                        1.429ms 
1:  169.254.154.42                                        1.058ms 
2:  169.254.32.144                                        2.134ms 
3:  169.254.32.19                                         1.034ms 
4:  no reply
 
tcpdump -nnvvXSs 1514 -i eth0
nn = don't resolve host names or port names
vv = verbosity level (can be v, vv, or vvv)
X = Payload. Shows packets contents in both ASCII and HEX. If you need the ethernet header us XX instead of just X
S = prints absolute sequence numbers
s = allows you to set snaplen (in this case 1514) so we capture the whole packet.
 
 
 
cat /proc/sys/net/ipv4/ip_default_ttl
64
sudo sysctl net.ipv4.ip_default_ttl=129
Comentarios publicados: 0

Tagged with:
troubleshooting performance linux