it-swarm-es.com

Actualización a la red Gigabit: habilitación de tramas gigantes

Me gustaría comenzar a actualizar mi red SOHO a gigabit (desde 10/100) y he escuchado un poco sobre Jumbo Frames.

¿Cuál sería la mejor manera de implementar Jumbo Frames en una red? Por lo que puedo decir, para que funcione correctamente, todos los equipos de red de la red deben admitir Jumbo Frames. ¿Es esto cierto?

Si tengo un equipo específico (por ejemplo, una impresora de red) que no se puede actualizar a GB ethernet, ¿esto me impedirá habilitar Jumbo Frames?

¿Cuáles son algunos de los inconvenientes de habilitar Jumbo Frames?

21
jdiaz

Primero, podría ser mejor explicar qué es ethernet de marco gigante. Ethernet es una tecnología de red de capa 2 y su unidad de datos de protocolo (PDU) es una trama. Como referencia, una L3PDU (capa IP) es un paquete y una L4PDU (tcp/udp) es un segmento.

Una trama ethernet (hay varios tipos de ethernet pero podemos generalizar aquí) consiste en un encabezado (que contiene, entre otras cosas, una MAC de origen, una MAC de destino, una etiqueta 802.1q VLAN, etc) los datos, o paylod, de la trama, y ​​una suma de verificación CRC utilizada para validar la transmisión exitosa de la trama.

La Ethernet original especificaba un tamaño de trama (el valor de los datos en la trama completa, incluido el encabezado y la suma de verificación) como 1500 bytes (o posiblemente 1518, hay que buscarlo). Este número encontró un equilibrio entre la cantidad de datos para enviar a la vez y la probabilidad de que la transmisión falle o colisione y tenga que ser retransmitida. Con la llegada de las LAN rápidas y full duplex, la gente se dio cuenta de que el rendimiento se podía mejorar aumentando el tamaño de la trama de Ethernet. El tamaño tradicional de las tramas gigantes es de 9000 bytes por trama, aunque esto es principalmente una convención.

En una LAN (o VLAN) full duplex sólida como una roca en la que todos los elementos esperan recibir ethernet de trama gigante, en realidad mejora el rendimiento. El problema con este escenario es si introduce un elemento de red o un dispositivo final que no lo espera. En el mejor de los casos, resultará en una degradación del rendimiento ya que los paquetes se pierden porque los dispositivos receptores esperan solo 1518 bytes en una trama.

Ahora a sus preguntas específicas:

¿Cuál sería la mejor manera de implementar Jumbo Frames en una red?

Ésta es una cuestión subjetiva. En mi lugar de trabajo, decidimos implementarlo solo donde sabíamos que teníamos todas las variables bajo control y sabíamos que ayudaría. Para hacer esto, lo implementamos en un vlan "privado" especial al que solo dispositivos específicos podían acceder a través de sus segundas NIC. Específicamente, colocamos el segundo NIC de nuestros servidores de archivos y servidores de aplicaciones en esta nueva VLAN) y luego cambiamos todas las referencias al esquema de IP usado en esta VLAN. Eso nos permite apuntar de manera estrecha (nadie va a conectar una máquina de escritorio a esta VLAN) el área específica que sabemos que se beneficiaría más (los enlaces de datos de mayor utilización en nuestra infraestructura), lo que maximiza la ganancia y minimiza el riesgo.

Más específicamente, en el lado de la red (usando IOS), construimos VLAN dedicadas a los dispositivos de marco gigante, luego agregamos "mtu 9000" a su definición de vlan. Cada interfaz en el switch que usaría esta red se colocó en este vlan usando algo como "switchport access vlan 11". En las máquinas linux (que tienen eth0 conectado a la red estándar y eth1 conectado a la red jumbo frame) agregamos "MTU = 9000" a/etc/sysconfig/network-scripts/ifcfg-eth1. Debido a que nunca enrutamos estos paquetes (es imposible que nada que no esté conectado directamente al marco gigante VLAN para hablar con un NIC en la VLAN del marco gigante)) nunca tuvo que preocuparse por la configuración de un enrutador.

Por lo que puedo decir, para que funcione correctamente, todos los equipos de red de la red deben admitir Jumbo Frames. ¿Es esto cierto?

Sí, bastante. Todos los "clientes" de la red (por lo que me refiero a servidores/escritorios/IPKVM/monitores ambientales IP, etc.) deben hablarlo también o, como se mencionó anteriormente, tendrá muchas máquinas semi-accesibles (harán ping, y cualquier L3 o L4PDU con menos de 1500 bytes tendrá éxito, lo que significa que, por ejemplo, su servidor de correo hará ping y podrá entregar personalmente lo que probablemente será un pequeño mensaje de prueba. Pero cuando intente entregar un mensaje real mail (el que tiene el archivo adjunto de Excel que tiene un tamaño de marco> 1500 bytes) fallará misteriosamente).

Si tengo un equipo específico (por ejemplo, una impresora de red) que no se puede actualizar a GB ethernet, ¿esto me impedirá habilitar Jumbo Frames?

Si ese es el caso, esto es lo que haría (suponiendo que el equipo de red pueda manejar esto):

  • construir dos VLAN, una con marco gigante y otra sin
  • asignar todos sus dispositivos de red a uno u otro vlan
  • en su enrutador y conmutadores, implemente el vlan de marco jumbo y cambie el tamaño del marco en cualquier cliente de red.

Esto significa que ya no tendrá una topología L2 plana en su red. Por ejemplo, si desde su servidor habilitado para jumbo-frame desea imprimir en su impresora de marco no jumbo, los paquetes deberán enrutarse (viajar a través de su enrutador, reescribir los marcos en un tamaño más convencional y luego enviarlos al impresora en la otra VLAN). Esto significa que la comunicación entre sus máquinas jumbo frame y no jumbo frame será un poco más pobre que antes, pero las tasas de transferencia de datos entre todos los dispositivos en el jumbro frame VLAN será mejor. Es realmente solo una llamada de juicio.

¿Cuáles son algunos de los inconvenientes de habilitar Jumbo Frames?

Con suerte cubierto arriba. ¡Buena suerte!

20
jj33

Puede encontrar publicación de Jeff Atwood en Jumbo Frames informativo.

Aspectos destacados de la publicación:

  • 20% de aumento de rendimiento
  • Para que un marco grande permanezca intacto, todos los dispositivos por los que pasa deben admitir ese tamaño de marco
  • Los conmutadores que no admiten Jumbo Frames los eliminarán
11
Jeffrey

Puede usar ping.exe para verificar el tamaño máximo de los paquetes y compararlo con la configuración de Jumbo Frames.

ping -l 4096 -f server

Ajuste el tamaño de paquete usado por -l, y use -f para configurar el indicador DO_ NOT_FRAGMENT. Cuando alcance su tamaño máximo de paquete, obtendrá un "El paquete debe estar fragmentado pero DF set".

Eso le dará una indicación de si Jumbo Frames funciona o no.

5
Frode Lillerud

Sí, todo debe ser compatible con Jumbo Frames: trátelo como si cambiara entre token ring y ethernet. La única diferencia es que algunos dispositivos pueden parecer que todavía funcionan por un corto tiempo o de forma intermitente; esto también puede ser un gran dolor de cabeza si no realiza un seguimiento de qué dispositivos que reconfiguró en una red grande ( es decir, 2 semanas después, recibe un ticket de problema de un usuario con una impresora metida en la parte trasera de su cubículo que "hace un momento" dejó de funcionar). Lo mismo se aplica con cualquier material nuevo: deberá configurar un procedimiento para reconfigurar cualquier dispositivo y computadora nuevos con marcos gigantes, para evitar llamadas de soporte cuando no funcionan después del arranque inicial.

3
David

En Linux, encontré que lo siguiente funciona: si está utilizando vlans etiquetados, configure el mtu para el dispositivo base (por ejemplo, eth1) en el tamaño del marco jumbo. Todos los vlans que admiten marcos jumbo obtienen el mismo mtu, los vlans que no se quedan con el original, por lo general 1500.

En realidad, los vlans que tienen habladores jumbo y conmutación habilitados podrán enviar a la interfaz vlan local incluso si el mtu en ese vlan es más pequeño que el de la interfaz base.

También en Linux, el comando a probar es: ping -s 4096 -M do

-s es el tamaño, -M do dice "no fragmentar". Si excede el mtu local, obtiene un error. Si excede el mtu remoto, no obtiene nada a cambio.

1
AndreasM