MSS y MTU

¡PARTICIPEMOS!

Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor suscríbete

NUESTROS CURSOS Foros MSS y MTU

  • Este debate tiene 8 respuestas, 2 mensajes y ha sido actualizado por última vez el hace 1 año por AlvaroM.
Viendo 9 entradas - de la 1 a la 9 (de un total de 9)
  • Autor
    Entradas
  • #29133
    AdminNG
    Superadministrador
    #33342
    Abel Quispe Fernandez
    Participante

    Buenas noches, tengo la siguiente consulta:
    En mi servicio de internet, se supone que se trabaja a nivel de ethernet con MTU 1500 sin embargo cuando realizo un PING hacia la 8.8.8.8 con MTU 1500 no se concreta pero cuando pongo en MTU 1472 si son satisfactoria las pruebas.

    C:\Users\ABELQ>ping -l 1500 8.8.8.8

    Haciendo ping a 8.8.8.8 con 1500 bytes de datos:
    Tiempo de espera agotado para esta solicitud.
    Tiempo de espera agotado para esta solicitud.
    Tiempo de espera agotado para esta solicitud.
    Tiempo de espera agotado para esta solicitud.

    Estadísticas de ping para 8.8.8.8:
    Paquetes: enviados = 4, recibidos = 0, perdidos = 4
    (100% perdidos),

    C:\Users\ABELQ>ping -l 1472 8.8.8.8

    Haciendo ping a 8.8.8.8 con 1472 bytes de datos:
    Respuesta desde 8.8.8.8: bytes=68 (enviados 1472) tiempo=41ms TTL=53
    Respuesta desde 8.8.8.8: bytes=68 (enviados 1472) tiempo=43ms TTL=53
    Respuesta desde 8.8.8.8: bytes=68 (enviados 1472) tiempo=41ms TTL=53
    Respuesta desde 8.8.8.8: bytes=68 (enviados 1472) tiempo=44ms TTL=53

    Estadísticas de ping para 8.8.8.8:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
    Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 41ms, Máximo = 44ms, Media = 42ms

    C:\Users\ABELQ>netsh interface ip show subinterfaces

    MTU MediaSenseState Bytes de entrada Bytes de salida Interfaz
    ———- ————— ———— ———— ————-
    4294967295 1 0 531006 Loopback Pseudo-Interface 1
    1500 1 37659768211 1499309250 Ethernet
    1500 5 0 0 Wi-Fi
    1500 5 0 0 Conexión de red Bluetooth
    1500 5 0 0 Conexión de área local* 1
    1500 5 0 0 Ethernet 2

    **¿Me podrías indicar a que se debe este comportamiento? Quedo atento a tu respuesta 🙂

    #33344
    AlvaroM
    Superadministrador

    Buenos días Abel!

    Bienvenido nuevamente; en este caso cuando tú haces un ping de tamaño 1500, estás diciendo que quieres que la porción de datos sea de 1500 BYTES, ahí no estas contando los headers; por lo tanto como tu MTU de Ethernet es de 1500 por defecto (contando headers), ese tu paquete no podrá ser enviado sin ser fragmentado. En tu caso tienes lo siguiente: 1500 bytes de datos + 20 bytes header IP + 8 bytes header ICMP = 1528 bytes lo cual significa que el paquete debe ser fragmentado. El hecho que NO funcione el ping es porque seguramente no se permite fragmentación en tu conexión.

    El ping de 1472 funciona porque de nuevo estas diciendo que quieres enviar 1472 de DATOS, ahí debes sumarle 20 bytes del header IP y 8 bytes del header ICMP lo que da como resultado los 1500 bytes que sí puedes enviar por tu conexión.

    Espero que quede claro.

    Atento a tus comentarios.

    Saludos! =)

    #33348
    Abel Quispe Fernandez
    Participante

    Entiendo que seria : 1500 – 20 – 8 = 1472 bytes. Pero te estas olvidando del header TCP que compone 20 bytes. Entonces quedaria de la siguiente forma: 1500 – 20 -8 – 20 = 1452 bytes que se podria enviar, pero estoy enviando mas de lo permitido ya que el paquete no se esta fragmentando. Quedo atentos a tu respuesta 🙂

    Otra consulta adicional:

    Si en un router reconfiguro una interfaz para que aumente el MTU y la interfaz del otro extremos se deja en MTU 1500, entonces solo se podria enviar paquete con un maximo de 1500 bytes sin fragmentar? y para enviar mas se deberia setear ambos extremos?

    #33350
    AlvaroM
    Superadministrador

    Hola Abel, creo que te estas confundiendo ya que por defecto un mensaje ICMP no lleva ni header TCP ni UDP. Por lo tanto la afirmación se mantiene de 1472 bytes + 20 bytes header IP + 8 bytes header ICMP que da como resultado los 1500 bytes que sí puedes enviar por tu conexión.

    Respecto a tu segunda consulta, si envías paquetes de más tamaño que el MTU de la otra interface, la otra interface no lo podrá recibir ya que maneja un MTU menor; para enviar paquetes de más tamaño, la interface receptora debe tener tú mismo tamaño de MTU. Por otro lado, si envías un paquete más grande que el MTU de tu propia interface, ahí recién ocurre la fragmentación.

    Atento a cualquier otra consulta/comentario.

    Saludos! =)

    #33372
    Abel Quispe Fernandez
    Participante

    Gracias, todo muy claro 🙂 Sin duda no me cansare de decirlo, usted es el mejor profesor! Saludos des Peru.

    #33440
    AlvaroM
    Superadministrador

    De nada Abel, y muchas gracias por tu gentil comentario.

    =)

    #35119
    Abel Quispe Fernandez
    Participante

    Buenas noches,

    Continuando con las consultas tengo las siguientes:

    1. Actualmente administro router de cliente corporativos con salida a internet, he estado haciendo pruebas con pesos de MTU y me doy con la sorpresa que cuando pongo en »SIZE» 1500 el PING si progresa por lo que me genera confusión cuando dijiste estas afirmaciones:

    »El ping de 1472 funciona porque de nuevo estas diciendo que quieres enviar 1472 de DATOS, ahí debes sumarle 20 bytes del header IP y 8 bytes del header ICMP lo que da como resultado los 1500 bytes que sí puedes enviar por tu conexión.»
    »la afirmación se mantiene de 1472 bytes + 20 bytes header IP + 8 bytes header ICMP que da como resultado los 1500 bytes que sí puedes enviar por tu conexión.»

    En teoría solo me debería permitir realizar un PING son un peso de 1472. En mis pruebas puse »df-bit» para no permitir la fragmentacion.

    rLAD_DIAMANTE#show int Gi0/0/0
    GigabitEthernet0/0/0 is up, line protocol is up
    MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
    Keepalive not supported
    Full Duplex, 100Mbps, link type is force-up, media type is RJ45
    output flow-control is on, input flow-control is on

    rLAD_DIAMANTE#ping X.X.X.X size 1500 df-bit
    Type escape sequence to abort.
    Sending 5, 1500-byte ICMP Echos to X.X.X.X , timeout is 2 seconds:
    Packet sent with the DF bit set
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
    rLAD_DIAMANTE#ping X.X.X.X size 1501 df-bit
    Type escape sequence to abort.
    Sending 5, 1501-byte ICMP Echos to X.X.X.X , timeout is 2 seconds:
    Packet sent with the DF bit set
    …..
    Success rate is 0 percent (0/5)

    3. Para el funcionamiento de una aplicación influye el tamaño de MTU que se debe enviar? Por ejemplo streaming, aplicacion OBS, amazon primer, etc

    4. Cuando se realiza un PING, el paquete no debería tener un header ETH y trailer? Porque solo descuentas el header IP ?

    #35120
    AlvaroM
    Superadministrador

    Hola Abel,

    Lo que pasa, es que esos mensajes ICMP son generados de diferente manera de acuerdo al sistema operativo, cuando utilizas Windows o Linux y generas esos ICMP con 1500 bytes, realmente se introducen 1500 bytes de datos a los paquetes (puedes verificarlo con Wireshark), sin embargo con Cisco IOS, si tu generas un mensaje ICMP de 1500 bytes, en realidad esos 1500 bytes de datos ya toman en cuenta a los headers existentes, por lo tanto realmente estas enviando solo 1472 bytes de datos, si generas un ping de 1501 bytes, en realidad estas generando un ping con 1473 bytes de datos, así que sumando los otros headers, ya sobrepasas los 1500 bytes y por ende necesitas fragmentar la información. Este comportamiento varía si tenemos IOS-XR, IOS, Windows, Linux, etc. La única forma de estar seguro es haciendo pruebas y analizando la cantidad real de datos que se introduce a tus tramas. Así que en resumen, todo lo mencionado anteriormente se mantiene =)

    Respecto a tu tercera consulta, analicemos un poco… qué ocurre si utilizas por ejemplo un jumbo frame donde el payload por ejemplo ya sea de 8960 bytes (vs 1460 tradicional), qué ganaste con eso?… ganaste eficiencia en la comunicación, ya que estas utilizando menos headers y mayor tráfico de datos en tu red, además que el CPU debe trabajar menos para la creación de tramas; por el otro lado si envías datos con MTU más pequeños qué es lo que estas provocando?… que mayor tráfico de control (headers) sea añadido, restando el espacio para el tráfico de datos, además que el CPU trabajara más en la creación de las tramas, sin embargo también ganas en reducción de latencia ya que las tramas se enviaran más rápido. Un incremento de MTU tiene utilidad cuando quieras transportar grandes cantidades de información entre dispositivos. Respecto a otras aplicaciones, habría que analizar qué protocolo de transporte utilizan, y como es el comportamiento de la generación de datos a nivel aplicativo, ya que por ejemplo en telefonía, aunque tengas un MTU de 1500 bytes, nunca los llenaras ya que se trata de generar la menor latencia posible enviando datos de manera muy rápida, esto significa que se generan tramas de tamaño pequeño todo el tiempo. De todas formas, hacia Internet no podrás habilitar un MTU más grande que 1500 ya que los routers de Internet no están configurados para ello, si envías tramas con MTU más grandes, esas serán descartadas por los routers del ISP; puede servirte en tu red Interna, pero no hacía afuera.

    Respecto a tu última pregunta, obviamente la trama tiene headers de capa 2, sin embargo cuando se habla de MTU no se toma en cuenta a estos headers/trailers. =)

    Atento a tus comentarios.

    Saludos!

Viendo 9 entradas - de la 1 a la 9 (de un total de 9)
  • Debes estar registrado para responder a este debate.