EL RELLENO ETHERNET, EN RESUMEN
¿Por qué un mensaje corto puede aparecer como una trama más larga?
Ethernet puede añadir relleno antes del FCS para cumplir el formato mínimo de la trama MAC. El relleno queda fuera de un paquete IPv4 y no debe convertirse en datos de la aplicación. El software de captura puede observar el procesamiento antes del relleno o recibir un registro sin el FCS, por lo que su longitud mostrada por sí sola no demuestra una transmisión de tamaño insuficiente. Verifique el punto de observación y la convención de longitud.
Construir la trama externa
El relleno cumple el formato externo; no añade significado a la aplicación.
Ubicar el observador
El software puede ver una etapa distinta de la del enlace físico.
Respetar el límite interno
Para IPv4, use la longitud total de IP en lugar de tratar el relleno como datos.
Verificar el recuento
Indique qué cabeceras, etiquetas y bytes de FCS incluye la longitud.
Verificar la captura
Registre la dirección, las descargas de offload, la longitud retenida y la configuración de FCS.
Verificar el analizador
Confirme que la longitud de la capa superior define el contenido válido de la aplicación.
Lista de verificación de selección y comprobación — ampliar
| Comprobación | Qué confirmar | Cómo verificar |
|---|---|---|
| Convención de trama | Cabeceras, etiquetas y FCS | Documente el inicio y el final exactos del recuento. |
| Punto de observación | Antes de la NIC, el cable o el receptor | Conserve la configuración de la interfaz y de la recolección. |
| Integridad de la captura | Longitud original frente a longitud retenida | Compruebe el truncamiento y los límites de recolección. |
| Límite del protocolo | IP válido u otra longitud de protocolo | Inspeccione la longitud especificada y el comportamiento del analizador. |
| Evidencia de fallo | Contadores, dirección y tiempo | Correlacione el tráfico conocido en ambos extremos. |
Ejemplos conceptuales, no a escala, no son mediciones ni afirmaciones sobre la implementación de un producto concreto.
Un PLC envía un mensaje de estado corto, pero el contenido transmitido por Ethernet es más largo. Una captura muestra 60 bytes, mientras que la documentación describe una trama mínima de 64 bytes. No concluya de inmediato que un switch eliminó cuatro bytes. El mensaje de la aplicación, la encapsulación Ethernet y la captura de software son capas de observación diferentes. Colocar el relleno en el lugar correcto explica la aparente contradicción.
Separar el mensaje, el paquete IP y la trama Ethernet
A una aplicación le interesa un estado, un comando o una medición, pero la transmisión necesita información que el equipamiento de red pueda reconocer. Piense en el mensaje como una nota, en el paquete IP como su sobre y en la trama Ethernet como el embalaje externo para este enlace. La analogía explica las capas, no tres cajas físicas: el cable transporta una secuencia continua de bits.
En el ejemplo habitual de Ethernet sin etiquetas que se usa aquí, la trama MAC va desde la dirección de destino hasta la secuencia de verificación de trama, o FCS. Una dirección MAC identifica a un emisor o destinatario en el enlace; el FCS ayuda al receptor a comprobar errores de transmisión. El preámbulo precede a la trama, y el intervalo entre tramas es tiempo inactivo entre transmisiones. Ninguno de los dos forma parte de este recuento de 64 bytes.
El mínimo se aplica a la trama MAC externa, no a la longitud de cada instrucción del PLC. Al leer documentación o capturas, establezca primero dónde empieza y termina el recuento. Mezclar datos de la aplicación, cabeceras y el FCS puede hacer que una encapsulación normal parezca contenido adicional de la aplicación.
Añadir el relleno antes de formar la secuencia de verificación de trama
Si el contenido de la capa superior proporcionado es demasiado corto, el procesamiento de transmisión Ethernet añade relleno después de ese contenido y antes del FCS. Es como el material de protección: ocupa espacio sin añadir palabras a la nota. Que una operación concreta la realice el software, un controlador o el hardware depende de la interfaz de red o de la implementación embebida.
Considere un ejemplo deliberadamente acotado: una cabecera Ethernet sin etiquetas de 14 bytes transporta un paquete IPv4 de 28 bytes. Ese paquete de IP puede constar de una cabecera IPv4 normal y una cabecera UDP, sin carga útil de aplicación UDP. Añadir 18 bytes de relleno y un FCS de cuatro bytes produce una trama MAC de 64 bytes. Esto ilustra la estructura; no es una medición de un dispositivo FCTEL.
El relleno se incluye en el contenido protegido por la suma de verificación Ethernet. No puede modificarse arbitrariamente una vez formado el FCS. El receptor verifica la trama recibida, no solo el mensaje de aplicación. No se necesita ningún cálculo de CRC para entender la secuencia: formar el contenido de trama requerido y luego generar su valor de verificación correspondiente.
El relleno no debe convertirse en datos de aplicación adicionales
Para IPv4, el campo de longitud total en la cabecera IP define la longitud del paquete IP, incluida su cabecera y datos pero excluyendo el relleno Ethernet externo. El receptor pasa la porción IP hacia arriba para su posterior interpretación. La RFC 894 separa explícitamente el relleno del paquete IP y especifica relleno de cero bytes cuando es necesario para la encapsulación que describe.
Un analizador de capa superior no debe tratar todos los bytes Ethernet capturados restantes como contenido de aplicación. Debe validar la longitud y los límites de su protocolo en lugar de añadir el empaquetado externo a un comando. Tampoco debe eliminar simplemente todos los ceros finales: un cero puede ser un dato válido. El protocolo, no la apariencia visual de un byte, determina el límite.
Otros protocolos de capa dos necesitan sus propias reglas de encapsulación; la longitud total de IPv4 no puede aplicarse mecánicamente a todos los protocolos. El relleno no debe transportar instrucciones de control privadas ni memoria no inicializada. El hábito práctico es verificar por separado el límite de la trama externa y el límite del mensaje interno.
Por qué el software puede mostrar 60 bytes o incluso menos
El software de captura no necesariamente recibe la representación completa del cable. Muchas interfaces verifican el FCS entrante sin entregar esos cuatro bytes al sistema operativo. Por lo tanto, el software puede registrar 60 bytes correspondientes a una trama MAC completa de 64 bytes en el cable. La documentación de Wireshark destaca esta distinción: una longitud mostrada de solo 60 no establece por sí misma una transmisión de tamaño insuficiente.
Una captura del lado de transmisión puede observar otro punto, antes de que el hardware añada el relleno y el FCS. Su registro puede ser más corto que 60 bytes aunque el hardware produzca posteriormente una trama transmitida válida. Una pantalla del emisor, una pantalla del receptor y una observación del enlace físico son puntos de vista diferentes. Comparar solo dos longitudes mostradas no puede probar que el equipo entre ellos eliminó contenido.
También distinga la longitud original de la longitud capturada. Un colector puede retener solo el comienzo de cada trama, por lo que no necesariamente se guarda cada byte original. Verifique la configuración de captura, la entrega de FCS, la dirección y el comportamiento de offload, y luego compare la evidencia de los pares. Probar la representación física del cable requiere un método de prueba adecuado con condiciones de adquisición declaradas.
El procesamiento de VLAN no implica un número fijo de relleno
Los bytes de relleno de 18 pertenecen solo al ejemplo anterior. Diferentes longitudes de contenido, el etiquetado y el procesamiento de encapsulación cambian la cantidad necesaria. Una etiqueta VLAN ocupa parte de la región de cabecera; no la cuente dos veces cuando ya está incluida. El tamaño mínimo de trama y la unidad máxima de transmisión, o MTU, también son conceptos diferentes.
Un switch recibe tramas, identifica los destinos de reenvío y forma la salida adecuada en el siguiente enlace. El equipo que añade o elimina etiquetas debe mantener los requisitos de salida. El documento de solución de problemas de Cisco referenciado ilustra un caso específico de plataforma en el que eliminar una etiqueta requiere rellenar de nuevo. Ayuda a explicar un límite de procesamiento, no una implementación interna universal para todos los switches.
El relleno normal de un mensaje corto completo no es una falla. Una trama realmente de tamaño insuficiente, una transmisión anómala causada por un enlace dañado y un registro de captura acortado durante la recolección requieren investigaciones diferentes. Los nombres y condiciones de los contadores de puerto varían según el equipo. Correlacionar los contadores con los tiempos y direcciones de captura es más útil que reemplazar un switch solo porque un registro parece corto.
Aplique la distinción a una conexión de switch industrial
La página publicada del switch Fast Ethernet de cinco puertos mini DIN-rail FCTEL enumera cinco puertos eléctricos Ethernet y adaptación 10/100M. Esto proporciona una base de producto real para un escenario de conexión de PLC y HMI. No establece capacidades de captura, espejo de puertos, control especial de relleno ni umbrales de error particulares. Verifique la configuración seleccionada con su propia documentación.
Si un terminal envía repetidamente mensajes de estado cortos mientras otro transfiere un archivo más grande, los recuentos de bytes de aplicación por sí solos no describen la carga del puerto. Cada trama también consume oportunidades de encapsulación y transmisión, incluido el espaciado requerido. Muchos mensajes pequeños pueden consumir recursos de procesamiento y de enlace. Comience con observaciones de la tasa de tramas, el tráfico real y el ciclo de la aplicación en lugar de exigir fórmulas complejas.
Si una aplicación transportada de forma transparente parece ganar bytes finales, primero verifique los límites del protocolo y el analizador. Compare lo que observan el origen, cualquier convertidor y el destino. No trate automáticamente el relleno Ethernet como parte de un mensaje serie, ni cambie los modos del equipo solo para eliminar el relleno. Establezca primero la capa afectada.
Use tres preguntas para acotar una investigación de campo
Primero, identifique el punto de observación: antes de la transmisión del origen, después de la recepción del par o una copia proporcionada por un switch. Segundo, documente la convención de longitud: cabeceras incluidas, disponibilidad de FCS y si se retuvo una trama completa. Tercero, correlacione las longitudes de protocolo, la carga útil y los contadores de error para el mismo tráfico de aplicación. Una sola captura de pantalla que muestre 60 bytes es insuficiente.
Para comparar, use un mensaje corto conocido en un entorno de prueba aislado o en una ventana de mantenimiento aprobada. Conserve las capturas originales y los parámetros de adquisición de ambos extremos. Confirme que la aplicación extrae solo su contenido válido y que las comunicaciones ordinarias continúan. Dicha prueba valida esa configuración y esa ruta; la visualización de una herramienta no define todas las interfaces y switches.
Por último, observe si la anomalía sigue a un puerto, un cable o un método de captura. Conserve la evidencia sin procesar en lugar de solo capturas de pantalla anotadas. El principio es simple: la trama externa tiene un formato mínimo, la aplicación interna tiene su propio límite de longitud y el software de captura registra una etapa del procesamiento. Mantener esos tres aspectos separados ayuda a localizar una falla real.
Fuentes y evidencia del producto
Wireshark: Ethernet; IETF RFC 894, abril de 1984; Documento de solución de problemas de relleno de Cisco, actualizado en julio de 16, 2021. Los mecanismos generales no transfieren comandos específicos de plataforma ni conclusiones sobre defectos a otros equipos. Evidencia del producto: Switch Fast Ethernet de cinco puertos mini para riel DIN FCTEL, página en chino. Verifique la versión seleccionada. Las ilustraciones son conceptos genéricos elaborados con asistencia de IA.
Traducido del artículo técnico en chino: Leer el artículo original en chino.
Preguntas prácticas comunes
¿Es una captura de 60 bytes una trama corta no válida?
No necesariamente. Una captura común omite el FCS de cuatro bytes. Verifique el punto de observación, la longitud original y la longitud capturada.
¿Se convierte el relleno en un nuevo comando del PLC?
No debería. Un analizador debe usar la longitud del protocolo de capa superior en lugar de tratar el relleno externo como datos de aplicación adicionales.
¿Todo mensaje corto necesita bytes de relleno de 18?
No. Los dieciocho bytes se aplican solo al ejemplo sin etiqueta de este artículo; el contenido original y la encapsulación determinan el relleno real.
Alcance y lecturas adicionales
Conceptos genéricos de relleno Ethernet y captura, no mediciones ni comportamiento garantizado específico de un modelo.
Guía relacionada sobre CRC y FCS · Guía relacionada sobre preámbulo y espacio entre tramas
