Actualización a la red Gigabit: habilitación de marcos jumbo


21

Me gustaría comenzar a actualizar mi red SOHO a gigabit (de 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 en 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 trucos para habilitar Jumbo Frames?

Respuestas:


20

Primero, podría ser mejor explicar qué es Ethernet de trama 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 de ethernet (hay varios tipos de ethernet pero podemos generalizar aquí) consiste en un encabezado (que contiene, entre otras cosas, un MAC de origen, un MAC de destino, una etiqueta de VLAN 802.1q, 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.

El ethernet original especificó un tamaño de trama (el valor de los datos en toda la trama, incluido el encabezado y la suma de verificación) como 1500 bytes (o posiblemente 1518, tienen que buscarlo). Este número alcanzó un equilibrio entre la cantidad de datos a enviar de una vez y la probabilidad de que la transmisión falle o colisione y tenga que ser retransmitida. Con el advenimiento de LAN rápidas y dúplex completas, las personas se dieron cuenta de que el rendimiento podría mejorarse 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, dará como resultado 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?

Esta es una pregunta subjetiva. En mi lugar de negocios, elegimos implementarlo solo donde sabíamos que teníamos todas las variables bajo control y sabíamos que ayudaría. Para hacerlo, lo implementamos en un vlan especial "privado" al que solo dispositivos específicos podían acceder a través de sus segundas NIC. Específicamente, colocamos la segunda NIC de nuestros servidores de archivos y servidores de aplicaciones en esta nueva VLAN y luego cambiamos todas las referencias al esquema de IP utilizado en esta VLAN. Eso nos permite orientar por poco (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). Esto maximiza la ganancia mientras minimiza el riesgo.

Más específicamente, en el lado de la red (usando IOS), creamos VLAN dedicadas a los dispositivos de trama gigante, luego agregamos "mtu 9000" a su definición de vlan. Cada interfaz en el conmutador que usaría esta red se puso 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 de trama gigante) agregamos "MTU = 9000" a / etc / sysconfig / network-scripts / ifcfg-eth1. Como nunca enrutamos estos paquetes (es imposible que algo que no esté directamente conectado a la VLAN de trama gigante hable con una NIC en la VLAN de trama gigante), nunca tuvimos que preocuparnos por la configuración de un enrutador.

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

Si, mas o menos. Todos los "clientes" de la red (por lo que quiero decir servidores / escritorios / IPKVM / monitores ambientales IP, etc.) también deben hablarlo o, como se mencionó anteriormente, tendrá muchas máquinas semi-accesibles (harán ping, y cualquier L3 o L4PDU que tenga menos de 1500 bytes tendrá éxito, lo que significa, por ejemplo, que su servidor de correo hará ping y podrá entregar personalmente lo que probablemente será un pequeño mensaje de prueba. Pero cuando intenta entregar un mensaje real mail (el que tiene el archivo adjunto de Excel que empuja el tamaño del 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 trama gigante y otra sin
  • asigne todos sus dispositivos de red a un vlan u otro
  • en su enrutador y conmutadores, implemente el vlan de trama gigante y cambie el tamaño de trama 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 marcos jumbo desea imprimir en su impresora de marcos no jumbo, los paquetes deberán ser enrutados (viajar a través de su enrutador, los marcos reescritos en un tamaño más convencional, y luego enviados al impresora en la otra VLAN). Esto significa que la comunicación entre su trama jumbo y las máquinas de trama no jumbo será un poco más pobre que antes, pero las velocidades de transferencia de datos entre todos los dispositivos en la VLAN de trama jumbro serán mejores. Realmente es solo una decisión judicial.

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

Con suerte cubierto arriba. ¡Buena suerte!


¿Es realmente tan malo? En Internet, el descubrimiento de MTU de ruta determinará si algún enrutador a lo largo de la ruta solo puede pasar 500 bytes y ajustar en consecuencia. ¿No debería funcionar en la LAN?
joeforker

1
No funcionará si ambos puntos finales están dentro del mismo dominio de colisión. Esto se debe a que la unidad de envío no puede determinar si la unidad receptora tiene habilitadas las tramas gigantes o no. Si el sistema receptor no ha habilitado las tramas gigantes, el paquete se descartará silenciosamente. Como no hay un enrutador entre ellos, el descubrimiento de MTU de ruta tampoco funcionará. Creo que el descubrimiento de MTU de ruta también puede fallar si la interfaz de salida del último enrutador tiene habilitadas las tramas gigantes y la interfaz de punto final de recepción no.
Flujo

11

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

Aspectos destacados de la publicación:

  • 20% de aumento de rendimiento
  • Para que un marco grande permanezca intacto, cada dispositivo que atraviesa debe admitir ese tamaño de marco
  • Los interruptores que no admiten Jumbo Frames los dejarán caer

5

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 del paquete utilizado por -l, y use -f para establecer el indicador DO_ NOT_FRAGMENT. Cuando alcances tu tamaño máximo de paquete obtendrás un "Paquete que debe estar fragmentado pero configurado DF".

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


3

Sí, todo debe ser compatible con Jumbo Frames: trátelo como un cambio entre token ring y ethernet. La única diferencia es que algunos dispositivos podrían aparecer al trabajo aún por un corto tiempo o de forma intermitente - esto también puede ser un gran dolor de cabeza si no hacer un seguimiento de lo que los dispositivos reconfigurado en una red grande (es decir, 2 semanas más tarde se obtiene una ticket de problema de algún usuario con una impresora rellena en la parte posterior de su cubículo que "justo ahora" 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 funcionen más allá del arranque inicial.


1

En Linux, encontré que lo siguiente funcionaba: si está usando vlans etiquetados, configure el mtu para el dispositivo base (por ejemplo, eth1) en el tamaño de trama gigante. Todos los vlans que admiten marcos jumbo obtienen los mismos mtu, los vlans que no se quedan con el original, generalmente 1500.

En realidad, los vlans que tienen activadores y conmutadores jumbo 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 para probar es: ping -s 4096 -M do

-s es el tamaño, -M do dice "no fragmentar". Si excede el mtu local, obtendrá un error. Si excede los mtu remotos, no recupera nada.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.