Ethernet y el modelo de capas

01 · Un salto de escala

De los buses a las redes de paquetes

Los buses de los temas anteriores (UART, SPI, I²C, RS-485, CAN) comparten una característica: un solo medio, un solo diseño de extremo a extremo. Quien arma el sistema elige los cables, las velocidades y el formato de los mensajes, y todo se diseña junto. Una red de datos como Internet es lo contrario: la forman millones de equipos de miles de fabricantes, con cables de cobre, fibras y radio, que cambian con los años. Para que eso funcione se necesitan cuatro ideas, y las tres primeras ya las vimos en pequeño:

• Direcciones. Cada equipo tiene una identidad; el mensaje dice a quién va (como las direcciones de I²C o Modbus).
• Tramas con detección de errores. Los datos viajan en paquetes con encabezado y un código de verificación (como el CRC de CAN o de Modbus).
• Acceso compartido. Hay que decidir quién transmite cuando varios quieren hablar (como el arbitraje de CAN o el sondeo de Modbus).
• Capas. Cada función se resuelve en un nivel con una interfaz clara hacia el de arriba y el de abajo. Es la idea nueva de este tema.

Ethernet nació en los años setenta en Xerox como una forma de conectar computadoras de una oficina con un cable coaxial compartido, y se normalizó como IEEE 802.3. Hoy casi no queda nada del cable original: usa pares trenzados o fibra, conmutadores en lugar de un medio compartido y velocidades de 10 Mbit/s a cientos de Gbit/s. Pero conservó lo esencial: el formato de la trama y las direcciones, y por eso un equipo de 1990 y uno actual todavía pueden entenderse.

02 · Un problema, varios niveles

El modelo de capas y la encapsulación

Enviar un dato por una red implica resolver muchos problemas a la vez: qué voltajes representan los bits, cómo se delimita un mensaje, cómo se llega a un equipo de otra red, cómo se recupera un mensaje perdido, qué significa el contenido. Los modelos de capas separan esas tareas. Hay dos de uso común:

• El modelo OSI (de ISO) tiene siete capas: física, enlace, red, transporte, sesión, presentación y aplicación. Es útil como vocabulario: se habla de «capa 2» (enlace) y «capa 3» (red).
• El modelo TCP/IP es el que describe Internet real y tiene cuatro o cinco capas: aplicación, transporte, internet, enlace y, si se separa, física. Es el que vamos a usar.

Los buses del curso viven casi todos en las capas física y de enlace: UART, SPI, I²C y RS-485 definen (cada uno a su manera) las señales y la forma de delimitar mensajes; CAN agrega direcciones, errores y arbitraje; Modbus RTU es una capa de aplicación sobre RS-485. Lo que las redes de paquetes agregan son las capas superiores, que permiten llegar a equipos que no están en el mismo cable.

El mecanismo central es la encapsulación. Cuando una aplicación envía datos, cada capa los trata como una carga opaca a la que agrega su propio encabezado (y a veces un cierre). El de transporte agrega los puertos; el de internet, las direcciones IP; el de enlace, las direcciones MAC y el FCS. En el destino ocurre lo inverso: cada capa lee su encabezado, lo quita y entrega el resto a la de arriba. Cada capa solo conversa con su par del otro extremo, sin preocuparse por lo que hacen las demás. Por eso se puede mandar el mismo mensaje HTTP por Ethernet, por Wi-Fi o por una línea celular sin cambiarlo.

El costo es una sobrecarga de encabezados. Con TCP sobre IPv4 y Ethernet (sin opciones) son 20 + 20 + 14 + 4 = 58 bytes por trama. Para un mensaje de unos pocos bytes (el dato típico de un sensor) la sobrecarga domina; es un buen motivo para agrupar datos (sección 09).

03 · Del cable a los bits

El medio físico: cobre y fibra

Casi todas las redes locales actuales usan cable de par trenzado sin blindaje (UTP) de cuatro pares con conector RJ45 de ocho contactos. Ya vimos por qué el par trenzado y la señal diferencial rechazan el ruido (tema 23); Ethernet de par trenzado usa lo mismo, con transformadores de aislamiento en cada puerto que además separan eléctricamente los equipos. Las variantes más comunes:

El límite de 100 m por tramo de cobre (90 m de cable fijo más los cables de conexión de cada extremo) vale para todas las variantes de par trenzado. Si hace falta más, se pone un conmutador intermedio, que regenera la señal, o fibra óptica, que además es inmune a las interferencias eléctricas y aísla totalmente los dos extremos (útil entre edificios o junto a motores y hornos).

En un conector RJ45, con la norma de colores T568B, los pines 1 y 2 forman el par que transmite en 10 y 100 Mbit/s y los pines 3 y 6 el que recibe; los pares de los pines 4-5 y 7-8 quedan sin uso hasta 100 Mbit/s y se emplean en gigabit. Un equipo transmite por 1-2 y escucha por 3-6, de modo que al conectar dos equipos iguales entre sí hacía falta un cable «cruzado». Hoy casi todos los puertos hacen Auto-MDI-X (detectan y corrigen el cruce) y negociación automática: los dos extremos se ponen de acuerdo en velocidad y modo dúplex con unos pulsos que intercambian al conectarse.

El enlace también aprovecha el cable para llevar energía: PoE (Power over Ethernet, IEEE 802.3af/at) alimenta cámaras, puntos de acceso y sensores con hasta unos 15 W o 30 W por el mismo cable de datos, lo que simplifica instalar un dispositivo en un lugar sin tomacorriente. Y para sistemas embebidos y automotrices existe Ethernet de un solo par (single-pair Ethernet: 100BASE-T1, 10BASE-T1L y 10BASE-T1S), que usa un par trenzado y distancias de decenas de metros hasta un kilómetro según la variante, y compite con CAN y con los buses industriales.

04 · Quién es quién en la red local

Direcciones MAC

Cada interfaz Ethernet tiene una dirección MAC (Media Access Control) de 48 bits, que se escribe como seis bytes en hexadecimal: DE:AD:BE:EF:FE:ED. Es la dirección de la capa de enlace: sirve para entregar una trama a un equipo del mismo segmento de red. Se reparte así:

• Los tres primeros bytes son el OUI (Organizationally Unique Identifier): un número que el IEEE asigna a cada fabricante.
• Los tres últimos los asigna el fabricante a cada interfaz que produce.

Dos bits del primer byte tienen significado propio:

• El bit menos significativo (I/G, individual/grupo): 0 es una dirección unicast (un solo equipo); 1 es de multicast (un grupo). Una dirección con todos los bits en 1, FF:FF:FF:FF:FF:FF, es la de difusión (broadcast): la reciben todos los equipos del segmento.
• El siguiente bit (U/L, universal/local): 0 es una dirección asignada por el fabricante; 1 es una dirección administrada localmente, elegida a mano o por software.

Por ejemplo, B8:27:EB:… tiene el primer byte 10111000: unicast y universal. DE:AD:BE:EF:FE:ED (el valor que usan muchos ejemplos de Arduino) tiene el primer byte 11011110: unicast y local, porque no pertenece a ningún fabricante. 01:00:5E:… es multicast IPv4. 33:33:… es multicast IPv6.

Las direcciones MAC se usan en el mismo segmento, y no atraviesan routers: cuando una trama cruza de una red a otra, el router le cambia la MAC de origen y de destino (la IP, en cambio, viaja intacta; es el tema 30). Dos cosas prácticas. Primero, dos equipos con la misma MAC en la misma red generan fallas intermitentes y difíciles de ver: si se usan direcciones locales en prototipos (el clásico DE:AD:BE:EF:FE:ED) hay que cambiar el último byte en cada placa. Segundo, la MAC no es un secreto ni una garantía de identidad: muchos sistemas permiten cambiarla.

05 · El formato del mensaje

La trama Ethernet

La trama que se usa en casi todas las redes es la de Ethernet II. Sus campos, en el orden en que viajan:

• Preámbulo (7 bytes) y delimitador de inicio, SFD (1 byte). Siete bytes 10101010 y un octavo 10101011. Sirven para que el receptor se sincronice con el reloj del emisor y sepa dónde empieza la trama (como el SOF de CAN). No cuentan como parte de la trama.
• Dirección MAC de destino (6 bytes). Va primero para que un conmutador pueda decidir enseguida por dónde reenviar.
• Dirección MAC de origen (6 bytes).
• Tipo (2 bytes). Dice qué protocolo de la capa superior viaja en los datos: 0x0800 para IPv4, 0x0806 para ARP, 0x86DD para IPv6. El valor 0x88B5 está reservado para pruebas y protocolos propios. (En la variante IEEE 802.3 original este campo era el largo de los datos; los valores desde 1536, o 0x0600, se interpretan como tipo.)
• Datos (de 46 a 1500 bytes). La carga útil. El máximo de 1500 bytes es el MTU (Maximum Transmission Unit). Si hay menos de 46 bytes se rellenan con ceros: el receptor usa los campos de capas superiores para saber cuántos son reales.
• FCS (4 bytes). Una secuencia de verificación: un CRC de 32 bits (sección siguiente).
• Separación entre tramas, IFG (12 bytes). Un silencio de 96 tiempos de bit entre una trama y la siguiente.

La trama propiamente dicha, de la dirección de destino al FCS, mide entre 64 y 1518 bytes (14 de encabezado, de 46 a 1500 de datos y 4 de FCS). Si el equipo usa etiquetas VLAN (IEEE 802.1Q) se intercalan 4 bytes más después de la dirección de origen, y el máximo pasa a 1522 bytes; es la forma de separar redes lógicas dentro de un mismo conmutador. Hay también «tramas gigantes» (jumbo frames) de hasta unos 9000 bytes en redes de centros de datos, que no son estándar y no se usan en redes comunes.

Observá el parecido con la trama CAN del tema 27: delimitador de inicio, identificación de destino, tipo/longitud, datos y CRC. La diferencia es de escala: en CAN el identificador dice qué contiene el mensaje y los datos son de hasta 8 bytes; en Ethernet las direcciones identifican equipos y los datos son hasta 1500 bytes, que contienen a su vez un paquete de la capa superior con su propio encabezado.

06 · Descartar lo dañado

Detección de errores: el FCS

El FCS (Frame Check Sequence) es un CRC de 32 bits calculado sobre todos los campos desde el destino hasta los datos (con el relleno incluido). Es el mismo cálculo que vimos con CRC-15 en CAN y CRC-16 en Modbus, con otro polinomio: 0x04C11DB7, que es el que usan también ZIP, PNG y otros formatos. En la forma que se programa habitualmente (bit a bit, con el bit menos significativo primero), el polinomio aparece reflejado como 0xEDB88320, el registro arranca en 0xFFFFFFFF y el resultado se invierte al final.

El emisor calcula el CRC y lo agrega al final, y el receptor recalcula el CRC de lo recibido y lo compara con el FCS. Una propiedad útil de los CRC: si se calcula el CRC de la trama completa incluyendo el FCS, siempre da una constante (0x2144DF1C en esta forma de cálculo) cuando no hay errores. Los bytes del FCS viajan con el menos significativo primero.

Lo que Ethernet hace con una trama dañada es simple: la descarta en silencio. No hay confirmación ni reintento en esta capa; el equipo emisor ni se entera. Si la aplicación necesita que el dato llegue, la recuperación la hace una capa superior (TCP, tema 31, retransmite lo que no se confirma). Es una diferencia importante con CAN, donde la propia trama lleva un ACK y el emisor reintenta solo. Un CRC de 32 bits detecta todos los errores de una ráfaga de hasta 32 bits y deja pasar uno entre unos cuatro mil millones de los demás.

Los conmutadores y las placas de red llevan contadores de errores (tramas con FCS incorrecto, tramas demasiado cortas o largas, colisiones tardías) que son la mejor herramienta de diagnóstico de un enlace dañado: un conector mal crimpado o un cable cerca de un motor se ve como un contador de errores de CRC que sube.

07 · Cuando todos comparten el cable

Medio compartido y CSMA/CD

La Ethernet original, de cable coaxial y después de concentradores (hubs), era un medio compartido: lo que transmitía un equipo lo recibían todos, igual que en RS-485 o CAN. El método de acceso era CSMA/CD (Carrier Sense Multiple Access with Collision Detection):

1. Escuchar antes de hablar (carrier sense): un equipo con una trama para enviar espera a que el cable esté libre.
2. Transmitir y vigilar (collision detection): mientras transmite, compara lo que envía con lo que lee. Si difieren, otro equipo habló a la vez: hubo una colisión.
3. Avisar y esperar: el equipo envía una señal de interferencia (jam) para que todos descarten la trama, y reintenta tras una espera aleatoria que crece exponencialmente con cada colisión consecutiva (backoff exponencial binario: entre 0 y 2^k − 1 intervalos, con k creciendo hasta 10, y se rinde tras 16 intentos).

A diferencia del arbitraje de CAN (tema 27), que resuelve la colisión sin perder la trama ganadora, en Ethernet las dos tramas se destruyen y hay que repetirlas. Cuantos más equipos y más tráfico, más colisiones y menos rendimiento útil.

De ahí viene la trama mínima de 64 bytes. Para detectar una colisión, el emisor tiene que seguir transmitiendo mientras la señal del otro extremo llega y vuelve. El tiempo de ida y vuelta máximo de la red original se fijó en 512 tiempos de bit (el slot time: 51,2 µs a 10 Mbit/s), que son justamente 64 bytes. Una trama más corta podría terminar de enviarse antes de que el emisor se entere de que chocó. Por eso se rellena la carga útil hasta 46 bytes.

Hoy CSMA/CD casi no se usa: en los enlaces dúplex completo (full duplex) entre un equipo y un conmutador hay un par para cada sentido (o, en gigabit, cancelación de eco en los mismos pares), así que no hay medio compartido ni colisiones. El modo medio dúplex (half duplex) subsiste solo como compatibilidad. Los equipos se ponen de acuerdo en el modo con la negociación automática; si uno queda en dúplex completo y el otro en medio dúplex (una «discordancia de dúplex», por ejemplo cuando se fuerza manualmente un solo lado) aparecen colisiones tardías y una velocidad pésima, que es una causa clásica de redes «lentas».

08 · Una red sin colisiones

Conmutadores

Un concentrador (hub) es un repetidor: lo que entra por un puerto sale por todos los demás. Un conmutador (switch) entiende las tramas: lee la dirección de destino y envía la trama solo por el puerto donde está ese equipo. Para saber dónde está cada equipo, mantiene una tabla de direcciones MAC que construye solo, observando el tráfico:

1. Aprende. Cuando llega una trama por un puerto, anota en la tabla que la dirección de origen está en ese puerto.
2. Reenvía. Busca la dirección de destino en la tabla. Si la conoce, envía la trama solo por ese puerto (y si es el mismo por el que llegó, la descarta).
3. Inunda. Si el destino es desconocido, o es de difusión o multicast, envía la trama por todos los puertos menos el de entrada.
4. Olvida. Las entradas que no se renuevan caducan (por omisión suelen ser unos 5 minutos), para adaptarse cuando un equipo se mueve.

Las consecuencias son grandes. Cada puerto de un conmutador es un dominio de colisión propio (con dúplex completo, ya sin colisiones), así que varias conversaciones pueden ocurrir a la vez a toda velocidad: un conmutador de 8 puertos de 1 Gbit/s puede mover hasta 8 Gbit/s en total. En cambio, la difusión sigue llegando a todos: el conjunto de equipos que se alcanzan por difusión es un dominio de difusión, y solo un router (tema 30) lo separa de otros.

Algunos conceptos más, útiles cuando se trabaja con conmutadores:

• Almacenar y reenviar (store-and-forward): el conmutador recibe la trama completa, verifica el FCS y recién entonces la reenvía; así no propaga tramas dañadas, a costa de una pequeña latencia. Algunos equipos reenvían apenas leen el destino (cut-through) para reducir la latencia.
• Bucles. Si hay dos caminos entre conmutadores, una trama de difusión puede girar para siempre y saturar la red (una «tormenta de difusión»). El protocolo Spanning Tree (STP) detecta los bucles y bloquea los enlaces redundantes. Los conmutadores no administrables tienen que conectarse sin bucles.
• VLAN. Un conmutador administrable puede dividir sus puertos en redes lógicas separadas, cada una con su dominio de difusión.
• Espejado de puertos (port mirroring): copia el tráfico de un puerto a otro, donde se conecta un analizador. Con un conmutador no se puede «espiar» una conversación ajena sin esto, a diferencia de lo que pasaba con el hub.

Para que una MAC se asocie con una dirección IP (la «dirección de la red») se usa el protocolo ARP: el equipo pregunta por difusión «¿quién tiene la IP 192.168.1.10?» y el dueño responde con su MAC. Lo veremos con las direcciones IP en el tema siguiente.

09 · Cuánto sirve realmente

Eficiencia y rendimiento

Cada trama ocupa en el cable más bytes que los de la trama: hay que sumar el preámbulo con el SFD (8 bytes) y la separación entre tramas (12 bytes). Los bytes que ocupa una trama en el cable son entonces 8 + 14 + máx(46, n) + 4 + 12, con n bytes de datos. Eso fija el rendimiento máximo:

Dos conclusiones. Primero, el rendimiento máximo de datos en Ethernet de 100 Mbit/s con tramas completas es de unos 97,5 Mbit/s, y con tramas pequeñas baja muchísimo. Segundo, y más importante para un diseñador de sistemas embebidos: enviar muchos mensajes de pocos bytes es muy ineficiente. Un sensor que manda un dato de 4 bytes en una trama TCP/IP ocupa 4 + 58 = 62 bytes de trama, rellenados a 64, y 84 en el cable: menos del 5 % es dato. Cuando hay muchos sensores conviene agrupar varias lecturas en un solo mensaje, o usar protocolos de aplicación livianos (tema 32).

Además, la velocidad de la línea no es el rendimiento de la aplicación: los encabezados de IP y TCP restan otros 40 bytes de cada trama, y TCP agrega confirmaciones y retransmisiones. En un enlace de 100 Mbit/s, una transferencia TCP grande suele alcanzar unos 94 Mbit/s de datos, y en un microcontrolador pequeño el límite lo pone casi siempre el procesador o el SPI del módulo Ethernet, no el cable.

10 · Con el microcontrolador

Con el microcontrolador

Hay tres maneras de poner un microcontrolador en una red Ethernet. Los módulos con un chip W5500 (o W5100) agregan Ethernet a cualquier placa con SPI: el chip contiene el controlador MAC, el PHY y toda la pila TCP/IP en hardware (ocho conexiones simultáneas), por lo que el microcontrolador solo envía y recibe datos de aplicación. Algunos microcontroladores traen un controlador MAC integrado, y solo necesitan un chip PHY externo; es el caso del ESP32 clásico (con un PHY como el LAN8720) y de placas de desarrollo que ya lo traen. Y los módulos tipo ENC28J60 (SPI) dejan la pila TCP/IP en software. Para el curso usamos el W5500 en el tema 33.

El primer programa inicializa un módulo W5500 con la biblioteca Ethernet de Arduino, muestra su MAC y vigila el estado del enlace físico. (Pedir una dirección IP por DHCP es el tema 30; acá solo comprobamos que el chip y el cable funcionan.)

#include <SPI.h>
#include <Ethernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };    // dirección local: cambiar el último byte en cada placa
const int PIN_CS = 10;                                  // chip select del módulo W5500

void setup() {
    Serial.begin(115200);
    Ethernet.init(PIN_CS);
    Ethernet.begin(mac, IPAddress(192, 168, 1, 50));    // IP fija de ejemplo: ajustarla a tu red
    Serial.print("MAC ");
    for (int i = 0; i < 6; i++) { if (mac[i] < 16) Serial.print('0'); Serial.print(mac[i], HEX); if (i < 5) Serial.print(':'); }
    Serial.println();
    switch (Ethernet.hardwareStatus()) {
        case EthernetNoHardware: Serial.println("No se encontró el chip: revisá el cableado SPI y el CS"); while (true) delay(1000);
        case EthernetW5500:      Serial.println("Chip W5500 detectado"); break;
        default:                 Serial.println("Chip Ethernet detectado"); break;
    }
}

void loop() {
    static EthernetLinkStatus anterior = Unknown;
    EthernetLinkStatus estado = Ethernet.linkStatus();
    if (estado != anterior) {
        anterior = estado;
        Serial.println(estado == LinkON ? "Enlace activo (hay un equipo del otro lado)" : estado == LinkOFF ? "Sin enlace: cable desconectado o equipo apagado" : "Estado del enlace desconocido");
    }
    delay(200);
}

Al enchufar y desenchufar el cable, el programa informa el cambio: es el mismo pulso de negociación que enciende los indicadores luminosos del conector. El segundo programa no depende de ninguna biblioteca: arma una trama Ethernet a mano, con relleno y FCS, para que se vea que no hay nada misterioso en ella. Lo podés correr en cualquier Arduino, y el resultado se verifica con el modelo de Python de la sección siguiente (si el FCS coincide, tu CRC-32 está bien):

#include <string.h>

uint32_t crc32(const uint8_t *datos, size_t n) {
    uint32_t crc = 0xFFFFFFFF;
    for (size_t i = 0; i < n; i++) {
        crc ^= datos[i];
        for (int b = 0; b < 8; b++) crc = (crc & 1) ? (crc >> 1) ^ 0xEDB88320UL : crc >> 1;
    }
    return ~crc;
}

// Arma destino + origen + tipo + datos (con relleno) + FCS. Devuelve el largo de la trama.
size_t armarTrama(uint8_t *trama, const uint8_t *destino, const uint8_t *origen, uint16_t tipo, const uint8_t *datos, size_t n) {
    size_t largoDatos = n < 46 ? 46 : n;
    memcpy(trama, destino, 6);
    memcpy(trama + 6, origen, 6);
    trama[12] = tipo >> 8;
    trama[13] = tipo & 0xFF;
    memcpy(trama + 14, datos, n);
    memset(trama + 14 + n, 0, largoDatos - n);           // relleno con ceros hasta 46 bytes
    size_t largo = 14 + largoDatos;
    uint32_t fcs = crc32(trama, largo);
    trama[largo]     = fcs & 0xFF;                       // el byte menos significativo sale primero
    trama[largo + 1] = (fcs >> 8) & 0xFF;
    trama[largo + 2] = (fcs >> 16) & 0xFF;
    trama[largo + 3] = fcs >> 24;
    return largo + 4;
}

void setup() {
    Serial.begin(115200);
    const uint8_t texto[] = "123456789";
    Serial.print("CRC-32 de prueba: 0x"); Serial.println(crc32(texto, 9), HEX);    // debe dar CBF43926

    const uint8_t destino[6] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
    const uint8_t origen[6]  = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
    const uint8_t datos[4]   = { 'H', 'o', 'l', 'a' };
    uint8_t trama[1518];
    size_t largo = armarTrama(trama, destino, origen, 0x88B5, datos, sizeof(datos));
    Serial.print("Trama de "); Serial.print(largo); Serial.println(" bytes:");
    for (size_t i = 0; i < largo; i++) { if (trama[i] < 16) Serial.print('0'); Serial.print(trama[i], HEX); Serial.print(i % 16 == 15 ? '\n' : ' '); }
    Serial.println();
}

void loop() {}

Debe imprimir CBF43926 y una trama de 64 bytes cuyos últimos cuatro son 98 D3 25 55 (el FCS 0x5525D398, con el byte menos significativo primero). Una placa con controlador MAC de verdad hace todo esto en hardware: el preámbulo, el relleno, el FCS y la verificación de las tramas que recibe.

11 · Analogía con programación

Ethernet en Python

Armar una trama, calcular su FCS, describir una dirección MAC, medir la eficiencia, calcular la encapsulación y simular el aprendizaje de un conmutador caben en pocas líneas. El modelo siguiente implementa el CRC-32 a mano y lo contrasta con el de la biblioteca zlib (que es el mismo algoritmo), arma la trama del programa anterior, y recorre una secuencia de envíos en un conmutador de cuatro puertos.

import zlib


def mac_bytes(texto):
    limpio = texto.replace(":", "").replace("-", "")
    return bytes.fromhex(limpio)


def describir_mac(texto):
    mac = mac_bytes(texto)
    if mac == b"\xff" * 6:
        tipo = "difusión"
    else:
        tipo = "multicast" if mac[0] & 1 else "unicast"
    admin = "local" if mac[0] & 2 else "universal"
    return tipo, admin, mac[:3].hex(":").upper()


def crc32(datos):
    crc = 0xFFFFFFFF
    for b in datos:
        crc ^= b
        for _ in range(8):
            crc = (crc >> 1) ^ 0xEDB88320 if crc & 1 else crc >> 1
    return crc ^ 0xFFFFFFFF


def armar_trama(destino, origen, tipo, datos):
    datos = datos + bytes(max(0, 46 - len(datos)))            # relleno hasta la trama mínima
    cuerpo = mac_bytes(destino) + mac_bytes(origen) + tipo.to_bytes(2, "big") + datos
    fcs = crc32(cuerpo)
    return cuerpo + fcs.to_bytes(4, "little"), fcs           # el FCS sale con el byte menos significativo primero


def bytes_en_el_cable(n):
    return 8 + 14 + max(46, n) + 4 + 12                      # preámbulo + encabezado + datos + FCS + separación


def encapsular(n, tcp=True):
    l4 = 20 if tcp else 8
    paquete = n + l4 + 20
    return 14 + max(46, paquete) + 4


class Conmutador:
    def __init__(self):
        self.tabla = {}

    def recibir(self, origen, puerto, destino):
        self.tabla[origen] = puerto                          # aprende la dirección de origen
        if destino in self.tabla and destino != "difusión":
            return [self.tabla[destino]]
        return [p for p in (1, 2, 3, 4) if p != puerto]       # destino desconocido o difusión: inunda


print("CRC-32 de '123456789':", f"{crc32(b'123456789'):#010x}", "| zlib:", f"{zlib.crc32(b'123456789'):#010x}")
trama, fcs = armar_trama("FF:FF:FF:FF:FF:FF", "DE:AD:BE:EF:FE:ED", 0x88B5, b"Hola")
print(f"Trama con 'Hola': {len(trama)} bytes, FCS {fcs:#010x}, coincide con zlib: {fcs == zlib.crc32(trama[:-4])}")
print("  FCS en el cable:", trama[-4:].hex(" ").upper())
print("  el CRC de la trama completa (con FCS) da el residuo constante:", f"{zlib.crc32(trama):#010x}")
for texto in ("FF:FF:FF:FF:FF:FF", "DE:AD:BE:EF:FE:ED", "01:00:5E:00:00:FB", "B8:27:EB:12:34:56"):
    print(texto, "->", describir_mac(texto))

for n in (1, 46, 512, 1500):
    on = bytes_en_el_cable(n)
    print(f"{n} bytes de datos: {on} bytes en el cable, eficiencia {n / on * 100:.1f} %, a 100 Mbit/s {100e6 / 8 / on:,.0f} tramas/s")
print(f"Trama mínima a 1 Gbit/s: {1e9 / 8 / bytes_en_el_cable(1):,.0f} tramas por segundo")

print("Encapsulado de 100 bytes: TCP", encapsular(100), "bytes, UDP", encapsular(100, False), "bytes; de 1 byte con TCP:", encapsular(1))
print("Segmentos TCP para 10000 bytes de aplicación (MSS 1460):", -(-10000 // 1460))

sw = Conmutador()
for origen, puerto, destino in (("A", 1, "B"), ("B", 2, "A"), ("C", 3, "A"), ("A", 1, "difusión"), ("D", 4, "C")):
    print(f"{origen} -> {destino}: sale por los puertos", sw.recibir(origen, puerto, destino))
print("Tabla final:", sw.tabla)

Resultado: el CRC-32 de «123456789» es 0xcbf43926 con la implementación propia y con zlib. La trama de difusión con «Hola» mide 64 bytes y su FCS es 0x5525d398, que sale en el cable como 98 D3 25 55; coincide con el de zlib, y el CRC de la trama completa da el residuo constante 0x2144df1c. La dirección FF:FF:FF:FF:FF:FF es de difusión, DE:AD:BE:EF:FE:ED es unicast y local, 01:00:5E:00:00:FB es multicast y universal, y B8:27:EB:12:34:56 es unicast y universal. Con 1, 46, 512 y 1500 bytes de datos, la trama ocupa 84, 84, 550 y 1538 bytes en el cable, con eficiencias de 1,2 %, 54,8 %, 93,1 % y 97,5 %; a 100 Mbit/s caben 148 810, 148 810, 22 727 y 8127 tramas por segundo (cifras redondeadas; el laboratorio trunca a 148 809), y a 1 Gbit/s la trama mínima da 1 488 095. Con 100 bytes de datos, la trama mide 158 bytes con TCP y 146 con UDP; con 1 byte con TCP mide 64; y 10 000 bytes de aplicación necesitan 7 segmentos TCP. En el conmutador, A→B se inunda por los puertos 2, 3 y 4, B→A sale por el 1, C→A por el 1, la difusión de A por 2, 3 y 4, y D→C por el 3; la tabla final es A = 1, B = 2, C = 3 y D = 4.

Observá que el FCS de la trama coincide con el de zlib y que el CRC de la trama completa da el residuo constante. También que el conmutador solo inunda cuando no conoce el destino: tras la primera conversación, el tráfico entre A y B ya no llega a C ni a D.

12 · Exploración interactiva

Laboratorio: MAC, tramas, eficiencia, conmutador y capas

El laboratorio tiene cinco herramientas. La primera analiza una dirección MAC. La segunda arma una trama Ethernet con relleno y FCS. La tercera calcula la eficiencia y el rendimiento según el tamaño de los datos. La cuarta simula un conmutador que aprende direcciones, frente a un concentrador. La quinta muestra cómo se encapsulan los datos de una aplicación en TCP o UDP, IP y Ethernet.

En la herramienta 1, el bit I/G es el menos significativo del primer byte y el U/L el siguiente. En la 2, el FCS se calcula sobre destino, origen, tipo y datos (con relleno), y el tiempo incluye el preámbulo y la separación. En la 3, la eficiencia considera solo Ethernet. En la 4, el equipo A está en el puerto 1, el B en el 2, el C en el 3 y el D en el 4, y la tabla empieza vacía. En la 5 se supone IPv4 y TCP sin opciones, con un MTU de 1500.

Recorrido guiado

1. Con la dirección inicial DE:AD:BE:EF:FE:ED: primer byte 11011110, bit I/G = 0 (unicast) y bit U/L = 1 (administrada localmente). Probá FF:FF:FF:FF:FF:FF (difusión), 01:00:5E:00:00:FB (multicast universal) y B8:27:EB:12:34:56 (unicast universal).
2. En la herramienta 2, con los valores iniciales (difusión, origen DE:AD:BE:EF:FE:ED, tipo 0x88B5 y datos 48 6F 6C 61, «Hola»): 4 bytes de datos + 42 de relleno = 46, trama de 64 bytes, FCS 0x5525D398 (en el cable 98 D3 25 55), 84 bytes en el cable y 6,72 µs a 100 Mbit/s. A 10 Mbit/s son 67,2 µs; a 1 Gbit/s, 0,67 µs.
3. Cambiá un solo bit de los datos (por ejemplo 48 por 49): el FCS cambia por completo. Es lo que el receptor detecta. Con 46 o más bytes de datos desaparece el relleno.
4. En la herramienta 3, con los valores iniciales (100 bytes, 100 Mbit/s): 138 bytes en el cable, eficiencia 72,5 %, 90 579 tramas por segundo y 72,46 Mbit/s de datos. Con 1500: 1538 bytes, 97,5 %, 8127 tramas por segundo. Con 1: 84 bytes (con 45 de relleno), 1,2 % y 148 809 tramas por segundo. Con 1 Gbit/s y 1 byte, 1 488 095 tramas por segundo.
5. En la herramienta 4, con la secuencia inicial A>B B>A C>A A>* en un conmutador: A>B inunda (B es desconocido) y aprende A; B>A sale solo por el puerto 1; C>A, también solo por el 1; A>* es difusión y se inunda. Son 8 copias (3 + 1 + 1 + 3), con la tabla A = puerto 1, B = puerto 2 y C = puerto 3. Con el concentrador, 12 copias: cada trama llega a todos.
6. Probá A>B B>A A>B B>A: solo la primera se inunda. Con A>C A>D, ambos destinos desconocidos: las dos se inundan.
7. En la herramienta 5, con los valores iniciales (100 bytes con TCP): paquete de 140 bytes (100 + 20 + 20), trama de 158 bytes y 58 bytes de sobrecarga (36,7 % de la trama). Con UDP: 146 bytes. Con 1 byte y TCP: el paquete (41 bytes) se rellena hasta 46 y la trama mide 64 bytes.
8. Con 10000 bytes de datos y TCP: 7 segmentos de hasta 1460 bytes cada uno (MSS = 1500 − 20 − 20). Con UDP y 2000 bytes: no cabe en una trama, y IP tendría que fragmentar el datagrama.

13 · Un procedimiento

Diagnóstico de un enlace Ethernet

Cuando un equipo no se comunica por Ethernet, se revisa de abajo hacia arriba, igual que las capas:

1. Capa física. ¿Está encendido el indicador de enlace (link) en ambos extremos? Si no, revisá el cable (continuidad de los 8 hilos o al menos de los pares 1-2 y 3-6), el conector y que el otro extremo esté alimentado. Un cable «de teléfono» de 4 hilos no sirve.
2. Velocidad y dúplex. Mirá en qué modo negoció cada lado. Un lado a 100 Mbit/s dúplex completo y el otro en medio dúplex es la causa típica de una red lenta. Dejá la negociación automática en ambos.
3. Contadores de errores. Errores de CRC, tramas cortas o colisiones tardías que suben indican cable defectuoso, conector mal armado, longitud excesiva o interferencia.
4. Capa de enlace. ¿Aparece la MAC del equipo en la tabla del conmutador? ¿Hay MAC duplicadas? ¿Hay un bucle o una tormenta de difusión (todos los indicadores parpadeando sin parar)?
5. Capas superiores. Con el enlace sano, recién ahí vale la pena mirar la IP, la máscara y las rutas (tema 30).

14 · Comprensión

Confusiones frecuentes

15 · Práctica guiada

Predecí antes de comprobar

1. Una dirección MAC

¿Qué tipo de dirección es 33:33:00:00:00:01?

2. Trama mínima

Se envían 10 bytes de datos. ¿Cuántos bytes de relleno se agregan, cuánto mide la trama, cuántos bytes ocupa en el cable y cuánto dura a 100 Mbit/s?

3. Eficiencia

Se envían 200 bytes de datos por trama. ¿Qué eficiencia tiene y cuántas tramas por segundo caben a 1 Gbit/s?

4. Encapsulación

Un dispositivo envía 1000 bytes de datos por TCP sobre IPv4 y Ethernet. ¿Cuánto mide la trama y qué porcentaje es sobrecarga? ¿Y con UDP?

5. Un conmutador

Un conmutador con la tabla vacía recibe, en este orden: A→B (A en el puerto 1), B→A (B en el puerto 2) y C→A (C en el puerto 3). ¿Cuántas tramas se inundan y cómo queda la tabla?

6. Una trama dañada

Un bit de una trama se invierte por ruido en el cable. ¿Qué pasa en cada capa?

7. Un tramo de 120 metros

Hay que conectar un sensor a 120 m del conmutador con cable UTP categoría 6. ¿Qué opciones hay?

16 · Síntesis

Ideas para recordar

¿Listo para el siguiente tema?

Antes de avanzar, calculá cuántos bytes ocupa en el cable una trama con 300 bytes de datos (338) y su eficiencia (88,8 %); decidí qué hace un conmutador con una trama cuyo destino no está en su tabla (la inunda por todos los puertos menos el de entrada); y explicá por qué una trama Ethernet con un bit dañado no llega a la aplicación pero Ethernet no la reenvía (el FCS no coincide, se descarta, y la recuperación la hace TCP u otra capa superior). Si podés justificar las tres respuestas, tenés los fundamentos de Ethernet.

En el próximo tema subimos una capa: IP, direcciones y puertos. Cómo se direcciona un equipo en una red de redes, qué hacen la máscara y la puerta de enlace, y cómo obtienen sus direcciones los dispositivos con DHCP y DNS.