1 votes

Linux MTU et UDP

Quelqu'un peut-il m'expliquer ce comportement ? J'ai quelques VMS (centos) fonctionnant sur un fournisseur de nuage. L'interface est définie sur le standard 1500 MTU.

pining avec de gros paquets ICMP fonctionnent bien :

# ping -s 1600 10.132.6.3
PING 10.132.6.3 (10.132.6.3) 1600(1628) bytes of data.
1608 bytes from 10.132.6.3: icmp_seq=1 ttl=64 time=1.16 ms
1608 bytes from 10.132.6.3: icmp_seq=2 ttl=64 time=1.09 ms
1608 bytes from 10.132.6.3: icmp_seq=3 ttl=64 time=1.04 ms
^C
--- 10.132.6.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2207ms
rtt min/avg/max/mdev = 1.044/1.101/1.168/0.063 ms

Il semble donc que quelque chose fragmente le trafic ICMP.

Mais un trafic UDP important n'y parvient pas :

]# nping --udp -p 111 -data-length 1600 10.132.6.3
WARNING: Payload exceeds maximum recommended payload (1400)

Starting Nping 0.5.51 ( http://nmap.org/nping ) at 2015-08-10 18:06 EDT
sendto in send_ip_packet_sd: sendto(3, packet, 1628, 0, 10.132.40.29, 16)   => Message too long
Offending packet: UDP 10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499   iplen=1628
SENT (0.0082s) UDP 10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499 iplen=1628
sendto in send_ip_packet_sd: sendto(3, packet, 1628, 0, 10.132.40.29, 16) => Message too long
Offending packet: UDP 10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499  iplen=1628
SENT (1.0086s) UDP10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499  iplen=1628
sendto in send_ip_packet_sd: sendto(3, packet, 1628, 0, 10.132.40.29, 16) => Message too long
Offending packet: UDP 10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499 iplen=1628
SENT (2.0097s) UDP 10.132.6.3:53 > 10.132.40.29:111 ttl=64 id=17499 iplen=1628

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 3 (4.884KB) | Rcvd: 0 (0B) | Lost: 3 (100.00%)
Tx time: 2.34513s | Tx bytes/s: 2082.61 | Tx pkts/s: 1.28
Rx time: 2.34513s | Rx bytes/s: 0.00 | Rx pkts/s: 0.00
Nping done: 1 IP address pinged in 2.35 seconds

Comment expliquer que le trafic UDP ne soit pas fragmenté ?

2voto

Dan Pritts Points 3091

El sendto L'erreur vient de nping qui le reçoit en retour de la bibliothèque de sockets du système d'exploitation (c'est-à-dire localement, et non pas depuis un endroit du réseau). Ainsi, nping essaie juste d'envoyer des paquets UDP de 1600 octets, mais le système d'exploitation ne peut pas les envoyer.

En revanche, si vous utilisez l'option --mtu option pour nping il fragmentera les paquets. Apparemment, il ne tient pas compte de l'en-tête IP dans son MTU, car la valeur maximale que je peux définir pour le MTU est de 1480.

nping --udp -p 111 -data-length 1600 --mtu 1480 some-host
WARNING: Payload exceeds maximum recommended payload (1400)

Starting Nping 0.5.51 ( http://nmap.org/nping ) at 2015-08-11 10:29 EDT
SENT (0.0056s) UDP 192.168.1.40:53 > 192.168.1.14:111 ttl=64 id=58221 iplen=1628
RCVD (0.0068s) ICMP 192.168.1.14 > 192.168.1.40 Destination host 192.168.1.14 administratively prohibited (type=3/code=10) ttl=64 id=33478 iplen=576

PAR CONTRE, ping doit fragmenter les paquets avant de les donner à l'OS.

Une bonne technique pour enquêter sur ce genre de choses est d'utiliser tcpdump pour renifler ce qui se passe réellement sur le réseau.

tcpdump -s0 -w /tmp/tcpdump.out host 192.168.1.1

vous pouvez ensuite télécharger tcpdump.out et inspecter son contenu avec wireshark.

Si vous omettez -s0, il ne capturera que les 64 premiers octets (je pense) de chaque paquet. Dans ce cas, c'est suffisant.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X