Pregunta

Ifconfig 1.2.3.4 MTU 1492

¿Esto establecerá MTU en 1492 para paquetes entrantes y salientes o ambos? Creo que es solo para entrantes

¿Fue útil?

Solución

TLDR: Ambas cosas. Solo transmitirá paquetes con una longitud de carga útil menor o igual a ese tamaño. Del mismo modo, solo aceptará paquetes con una duración de carga útil dentro de su MTU. Si un dispositivo envía un paquete más grande, debe responder con un mensaje ICMP inalcanzable (de gran tamaño).

El nitty arenoso:Sintonizar la MTU para su dispositivo es útil porque otros lúpulos entre usted y su destino pueden encapsular su paquete en otra forma (por ejemplo, una VPN o PPPOE). Esta capa alrededor de su paquete da como resultado un paquete más grande que se envía a lo largo del cable. Si este nuevo paquete más grande excede el tamaño máximo de la capa, entonces el paquete se dividirá en múltiples paquetes (en un mundo perfecto) o se eliminará por completo (en el mundo real).

Como ejemplo práctico, considere tener una computadora conectada sobre Ethernet a un módem ADSL que habla PPPOE a un ISP. Ethernet permite una carga útil de 1500 bytes, de las cuales PPPOE utilizará 8 bytes. Ahora hemos bajado a 1492 bytes que se pueden entregar en un solo paquete a su ISP. Si enviara una carga útil de Ethernet de tamaño completo de 1500 bytes, su enrutador se "fragmentaría" y se dividiría en dos paquetes (uno con una carga útil de 1492 bytes, la otra con una carga útil de 8 bytes).

El problema se produce cuando desea enviar más datos a través de esta conexión, digamos que quería enviar 3000 bytes: su computadora dividiría esto según su MTU, en este caso, dos paquetes de 1500 bytes cada uno, y enviarlos a su Módem ADSL que luego los dividiría para que pueda cumplir su MTU. Ahora sus datos de 3000 bytes se han fragmentado en cuatro paquetes: dos con una carga útil de 1492 bytes y dos con una carga útil de 8 bytes. Obviamente, esto es ineficiente, en realidad solo necesitamos tres paquetes para enviar estos datos. Si su computadora hubiera sido configurada con la MTU correcta para la red, habría enviado esto como tres paquetes en primer lugar (dos paquetes de 1492 bytes y un paquete de 16 bytes).

Para evitar esta ineficiencia, muchas pilas de IP se voltean un poco en el encabezado IP llamado "No fragmentos". En este caso, habríamos enviado nuestro primer paquete de 1500 bytes al módem ADSL y habría rechazado el paquete, respondiendo con un mensaje de control de Internet (ICMP) informándonos que nuestro paquete es demasiado grande. Luego habríamos vuelto a tomar la transmisión con un paquete más pequeño. Esto se llama Path Mtu Discovery. Del mismo modo, una capa a continuación, en la capa TCP, otro factor para evitar la fragmentación es la opción MSS (tamaño de segmento máximo) donde ambos hosts responden con el paquete de tamaño máximo que pueden transferir sin fragmentación. Esto generalmente se calcula a partir de la MTU.

El problema aquí surge cuando los firewalls mal configurados dejan caer todo el tráfico ICMP. Cuando se conecta (digamos) un servidor web, crea una sesión de TCP y envía que está dispuesto a aceptar paquetes TCP en función de su MTU de 1500 bytes (ya que está conectado a través de Ethernet a su enrutador). Si la web extranjera Server quería enviarle muchos datos, dividirían esto en fragmentos que (cuando se combinaban con los encabezados TCP e IP) salieron a cargas útiles de 1500 bytes y se los enviarían. Su ISP recibiría uno de estos y luego intentaría envolverlo en un paquete PPPOE para enviar a su módem ADSL, pero sería demasiado grande para enviar. Por lo tanto, respondería con un ICMP inalcanzable, que (en un mundo perfecto) haría que la computadora remota reduzca su MSS para la conexión y la retransmisión. Sin embargo, si hubiera un firewall roto en el camino, el servidor web extranjero nunca llegaría a este mensaje ICMP y este paquete nunca lo llegaría.

En última instancia, la configuración de su MTU en su dispositivo Ethernet es deseable para enviar los marcos de tamaño correcto a su módem ADSL (para evitar que le pida que se retransmita con un marco más pequeño), pero es fundamental influir en el tamaño de MSS que envía a hosts remotos al construir TCP conexiones.

Otros consejos

ifconfig ... mtu <value> Establece la MTU para las cargas útiles de Layer2 enviadas la interfaz y rechazará las cargas útiles de Lay2 más grandes recibidas en esta interfaz. Tú deber Asegúrese de que su MTU coincida en ambos lados de un enlace Ethernet; tú no debe han coincidente los valores de MTU en cualquier parte del mismo dominio de transmisión de Ethernet. Tenga en cuenta que los encabezados Ethernet no están incluidos en la MTU que está configurando.

También, ifconfig no se ha mantenido en Linux durante años y es viejo y desaprobado; Lamentablemente, las distribuciones de Linux todavía lo incluyen porque tienen miedo de romper los viejos guiones. Esto tiene el efecto muy negativo de alentar a las personas a continuar usándolo. Deberías estar usando el iproute2 Familia de comandos:

[mpenning@hotcoffee ~]$ sudo ip link set mtu 1492 eth0
[mpenning@hotcoffee ~]$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP qlen 1000
    link/ether 00:1e:c9:cd:46:c8 brd ff:ff:ff:ff:ff:ff
[mpenning@hotcoffee ~]$ 

Se pueden eliminar grandes paquetes entrantes en función del tamaño de la interfaz MTU.

Por ejemplo, la MTU 1500 predeterminada en Linux 2.6 CentOS (probado con el controlador Ethernet: el controlador Intel Corporation 80003ES2Lan Gigabit Ethernet (cobre) (Rev 01)) cae paquetes Jumbo> 1504. Los errores aparecen en Ifconfig y hay indicaciones RX_LONG_LENGTY_ERRORS para esto en la salida ETHTOOL -S. El aumento de la MTU indica que los paquetes jumbo deben ser compatibles. El umbral para cuándo dejar caer los paquetes en función de que su tamaño sea demasiado grande parece depender de MTU (-4096, -8192, etc.)

Orín

Es la unidad de transmisión máxima, por lo que definitivamente establece el tamaño máximo de paquete saliente. No estoy seguro de si rechazaré los paquetes entrantes más grandes que la MTU.

No hay duda de que MTU configurada por Ifconfig impacta la fragmentación de TX IP, no tengo más comentarios.

Pero para la dirección RX, encuentro si el parámetro afecta los paquetes IP entrantes, depende. Diferente fabricante se comporta de manera diferente. Probé todos los dispositivos a mano y encontré 3 casos a continuación.

Caso de prueba:

Device0 Eth0 (192.168.225.1, MTU 2000) <-Cable Eth-> Dispositivo1 Eth0 (192.168.225.34, MTU MTU_SIZE)

En Device0 ping 192.168.225.34 -S ICMP_SIZE, verificando cómo MTU_SIZE impacta RX de dispositivo1.

caso 1:

Dispositivo1 = Linux 4.4.0 con Intel I218-LM:

Cuando mtu_size = 1500, ping tiene éxito en icmp_size = 1476, falla en icmp_size = 1477 y arriba. Parece que hay una MTU práctica = 1504 (20B (encabezado IP)+8B (encabezado ICMP)+1476b (datos ICMP)).

Cuando mtu_size = 1490, Ping tiene éxito en icmp_size = 1476, falla en icmp_size = 1477 y superior, se comporta lo mismo que mtu_size = 1500.

Cuando mtu_size = 1501, Ping tiene éxito en ICMP_SIZE = 1476, 1478, 1600, 1900. Parece que el marco Jumbo se enciende una vez que MTU_SIZE está configurado> 1500 y ya no hay una restricción 1504.

Caso 2:

Dispositivo1 = Linux 3.18.31 con Qualcomm Atheros AR8151 V2.0 Gigabit Ethernet:

Cuando mtu_size = 1500, ping tiene éxito en icmp_size = 1476, falla en icmp_size = 1477 y arriba.

Cuando mtu_size = 1490, Ping tiene éxito en icmp_size = 1466, falla en icmp_size = 1467 y arriba.

Cuando mtu_size = 1501, ping tiene éxito en icmp_size = 1477, falla en icmp_size = 1478 y arriba.

Cuando mtu_size = 500, ping tiene éxito en icmp_size = 476, falla en icmp_size = 477 y arriba.

Cuando mtu_size = 1900, Ping tiene éxito en icmp_size = 1876, falla en icmp_size = 1877 y arriba.

Este caso se comporta exactamente como dijo Edward Thomson, excepto que en mi prueba la práctica mtu = mtu_size+4.

Caso 3:

Dispositivo1 = Linux 4.4.50 con Raspberry Pi 2 Módulo B ETH:

Cuando mtu_size = 1500, ping tiene éxito en icmp_size = 1472, falla en icmp_size = 1473 y arriba. Por lo tanto, hay una MTU práctica = 1500 (20B (encabezado IP)+8B (encabezado ICMP)+1472b (datos ICMP)) que trabaja allí.

Cuando mtu_size = 1490, comportes lo mismo que mtu_size = 1500.

Cuando mtu_size = 1501, comporte lo mismo que mtu_size = 1500.

Cuando mtu_size = 2000, comportes lo mismo que mtu_size = 1500.

Cuando mtu_size = 500, comportes lo mismo que mtu_size = 1500.

Este caso se comporta exactamente como dijo Ron Maupin en ¿Por qué la configuración de MTU no entra en vigencia en la dirección de recibir?.

Para resumir todo, en el mundo real, después de establecer Ifconfig mtu,

A veces, los paquetes IP RX se caen cuando exceden 1504, sin importar el valor de MTU que establezca (excepto que el marco Jumbo está habilitado).

A veces, los paquetes IP RX se caen cuando exceden el MTU+4 que se establece en el dispositivo receptor.

A veces, los paquetes IP RX se caen cuando exceden los 1500, sin importar el valor de MTU que establezca.

... ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top