Ethernet, switching, ARP y dominios locales

El enlace local decide qué llega al siguiente salto

Cuando una aplicación envía una petición a una dirección IPv4, no empieza hablando con una dirección MAC remota. Primero, la pila decide si el destino está en la red conectada o si necesita un gateway; después debe entregar el datagrama al vecino correcto mediante el enlace local. En ese tramo intervienen Ethernet, la resolución de direcciones y el switching. Confundir estas decisiones produce diagnósticos imprecisos: una tabla ARP correcta no prueba que un switch esté reenviando, una trama visible no demuestra que el proceso remoto haya recibido datos y un fallo de ping no identifica por sí solo una causa.

Este capítulo reconstruye esa cadena. Ethernet define una forma de transportar una unidad de capa de red en una trama; ARP (Address Resolution Protocol) relaciona una dirección IPv4 con una dirección de enlace cuando la pila necesita un vecino; un switch aprende y consulta asociaciones entre direcciones MAC (Media Access Control) y puertos; y un dominio local delimita dónde se propagan esas tramas. El valor profesional no está en memorizar nombres, sino en ubicar la primera transición que deja de cumplir su contrato y en pedir la evidencia que separa causas alternativas.

De un destino IPv4 a una trama

ARP no enruta ni autentica.

Una dirección IPv4 identifica un destino en la capa de red; una dirección MAC identifica una interfaz de enlace en el dominio donde se entrega una trama. No son dos nombres para el mismo objeto. La pila compara la dirección destino con la máscara de la interfaz. Si el resultado indica que el destino pertenece a la red conectada, el host intenta entregarlo directamente. Si no, selecciona un gateway de esa red y entrega la trama a la MAC del siguiente salto. El datagrama conserva como destino la IPv4 final, mientras que la trama usa la MAC del vecino inmediato.

La decisión anterior ocurre antes de ARP. ARP no calcula rutas, no traduce nombres DNS (Domain Name System), no autentica a un host y no decide qué servicio escucha en un puerto. Sólo ayuda a obtener la dirección de enlace necesaria para una entrega local, normalmente a partir de una IPv4. Si el destino es remoto, ARP resuelve la IPv4 del gateway, no la MAC del servidor remoto. Esta distinción explica por qué un cambio de gateway puede alterar la trama sin cambiar el destino IPv4 que observa el transporte.

El proceso de salida puede expresarse así:

1. La aplicación entrega datos al transporte y éste forma su unidad.
2. IP selecciona una interfaz y un siguiente salto según sus rutas y la configuración local.
3. Si falta la asociación de enlace para ese siguiente salto, el host inicia resolución ARP o utiliza una entrada ya aprendida.
4. IP entrega el datagrama a la interfaz de enlace.
5. Ethernet construye una trama con dirección MAC origen, dirección MAC destino, un campo EtherType y los datos; el medio o el switch transporta esa trama dentro del dominio local.

El orden importa para el diagnóstico. Una entrada ARP incompleta puede impedir la emisión de la trama; una trama emitida puede ser descartada por una política del switch; una trama que llega al host puede contener un datagrama que IP rechaza; y un datagrama aceptado puede no producir una respuesta de la aplicación. La misma observación —«no hay respuesta»— es compatible con varios puntos de fallo.

Qué garantiza Ethernet y qué deja fuera

Ethernet es una tecnología de enlace, no un protocolo de autorización. En el encapsulado clásico descrito por RFC 894, el campo de tipo identifica que los datos contienen un datagrama IP y el campo de datos transporta esa unidad. El tamaño máximo de la carga de IP depende de la variante y configuración del enlace; el valor histórico de 1500 octetos para Ethernet no debe convertirse en una afirmación universal sobre cualquier red o equipo actual. Una trama puede llevar padding para alcanzar el tamaño mínimo, y ese padding no pertenece al datagrama IP.

La trama tiene un alcance de enlace. Sus direcciones se interpretan por los participantes del dominio local y pueden cambiar en cada salto de capa 3. Por eso una captura que muestra una MAC destino no prueba quién es el dueño administrativo de una IPv4, quién autorizó el envío ni qué contenido acabará procesando un servicio. Ethernet entrega una unidad al vecino según sus reglas; las propiedades de identidad, confidencialidad e integridad extremo a extremo requieren mecanismos adicionales y un alcance distinto.

El campo EtherType tampoco es una etiqueta de confianza. Indica cómo interpretar los datos que siguen dentro del enlace. La validez de una trama se contrasta con su formato, tamaño, verificación y estado de la interfaz, pero incluso una trama bien formada puede proceder de un principal no autorizado o transportar una petición que la capa superior rechazará. El profesional debe separar observación de inferencia: «la interfaz recibió una trama con EtherType IPv4» es más preciso que «el servidor recibió la solicitud».

El switch: aprendizaje, búsqueda y flooding

Compartir un switch no equivale a compartir subred.

Un switch de capa 2 mantiene una base de datos de reenvío, a menudo llamada FDB (Forwarding Database). Aprende la dirección MAC de origen de las tramas que recibe en cada puerto. Cuando debe reenviar una trama, busca la MAC destino junto con el contexto de VLAN cuando aplica. Si encuentra una entrada válida asociada con otro puerto del mismo dominio, transmite hacia ese puerto. Si no la encuentra, suele inundar la trama a los puertos pertinentes excepto el de entrada; una trama broadcast se propaga por el dominio que la admite. La inundación es un comportamiento de entrega, no evidencia de que todos los receptores acepten el contenido.

Una entrada aprendida puede caducar o desplazarse si la misma MAC aparece en otro puerto. El switch no descubre por sí solo la legitimidad del propietario: aprende de las tramas observadas y aplica las políticas configuradas. La FDB puede contener entradas dinámicas, estáticas o locales, y un equipo físico puede hacer switching en hardware mientras una representación equivalente se ve en un bridge de software. Por eso conviene registrar modelo, versión, VLAN, puerto, hora y origen de la observación antes de atribuir un movimiento de MAC a una intrusión.

La VLAN (Virtual Local Area Network) añade contexto al dominio de switching. Dos puertos en el mismo equipo físico pueden pertenecer a dominios lógicos distintos y no compartir broadcast ni FDB efectiva. Un enlace trunk puede transportar etiquetas de varias VLAN entre equipos; un puerto de acceso puede presentar tráfico sin etiqueta al dispositivo final. El hecho de compartir chasis o cableado no demuestra pertenencia al mismo dominio local. La pregunta correcta es: ¿qué clasificación de VLAN y qué política de reenvío aplicó el equipo a esa trama?

Hay tres resultados que suelen mezclarse:

• Unicast conocido: la MAC destino aparece en el contexto correcto y la trama se dirige al puerto asociado.
• Unicast desconocido: no hay asociación vigente; el switch inunda dentro del dominio autorizado y aprende si luego ve respuestas.
• Broadcast o multicast: la política de la VLAN determina los puertos que reciben la trama; no se trata de una búsqueda unicast.

Un switch no es necesariamente un firewall. Puede filtrar, aislar puertos, limitar MAC o aplicar controles de VLAN, pero el comportamiento depende de la configuración y del modelo. Llamar «segmentación» a cualquier switching oculta si existe una frontera de confianza real. Para sostener un claim de aislamiento hace falta demostrar qué tráfico se permite, dónde se bloquea y qué rutas laterales quedan abiertas por trunks, gestión, dispositivos auxiliares o protocolos de descubrimiento.

ARP como transacción de vecino

ARP define una solicitud y una respuesta para asociar una dirección de protocolo, aquí IPv4, con una dirección de hardware de enlace. El emisor que necesita una asociación construye una solicitud con la IPv4 buscada y la envía normalmente como broadcast de enlace. Los receptores comparan la dirección objetivo con sus propias direcciones; el dueño responde con la asociación que conoce. El emisor almacena el resultado en su caché durante un tiempo dependiente de la implementación y vuelve a resolver cuando la entrada expira o se invalida.

La solicitud revela un aspecto esencial del dominio local: el broadcast sólo llega a los participantes que el enlace y la VLAN incluyen. Un router no reenvía un broadcast ARP ordinario entre redes. Si un host remoto no responde, puede ser porque el destino está detrás de un gateway y la pila nunca debía preguntarle directamente, porque el broadcast no llegó al puerto, porque la IPv4 no está configurada allí o porque la respuesta se perdió o fue rechazada. Un estado INCOMPLETE o equivalente es evidencia de que la resolución no concluyó, no prueba de que el equipo remoto esté apagado.

ARP no lleva autenticación criptográfica incorporada. Una respuesta puede ser aceptada según reglas de la pila y de controles locales aunque el emisor no haya validado una autoridad externa. Por ello un atacante con posición adecuada podría intentar asociar una IPv4 legítima con otra MAC; la posibilidad concreta depende del segmento, de las políticas de inspección y de la implementación. No es correcto afirmar que «ARP es vulnerable» sin fijar el mecanismo, la topología y el impacto: la propiedad relevante puede ser integridad de la resolución, disponibilidad del vecino, confidencialidad del tráfico o suplantación de una decisión de routing.

Las variantes operativas importan. Un host puede anunciar una dirección para detectar conflictos; RFC 5227 define procedimientos de detección de conflictos de IPv4. Un gateway puede responder mediante Proxy ARP en ciertos diseños; RFC 1027 documenta esa técnica histórica. Una entrada estática o una inspección de DHCP puede reducir cambios no autorizados, pero introduce dependencia de configuración y ciclo de mantenimiento. Cada control modifica un supuesto y debe evaluarse junto con fallos, cambios de interfaz y recuperación.

Caso conductor: Northstar en un dominio local

Supongamos una red sintética de Northstar Systems con un cliente C, un servidor S y un gateway G. C tiene IPv4 10.40.8.21/24; S tiene 10.40.8.15/24; G tiene 10.40.8.1/24. C intenta conectar con S. Como ambas direcciones coinciden en la red conectada, C busca la MAC de S mediante ARP. Si la caché contiene una asociación coherente, emite una trama unicast a esa MAC. El switch aprende la MAC de C por el puerto de entrada y consulta la de S. Si no la conoce, inunda la primera trama unicast; cuando S responde, el switch aprende su puerto y las siguientes tramas son dirigidas.

Ahora cambiamos sólo la máscara de C a /25 y mantenemos S en la parte superior de la red. C puede concluir que S no es local y enviar el datagrama a G; ARP resolverá la MAC de G. Si G no tiene una ruta o política hacia S, el síntoma será distinto del de una resolución ARP fallida, aunque el usuario sólo vea un timeout. Si una captura en C muestra solicitudes ARP para G, afirmar que «S no responde a ARP» sería una inferencia incorrecta: C no le preguntó a S.

Otro estado posible es una entrada ARP que cambia entre dos MAC. Eso puede deberse a una interfaz legítimamente reubicada, alta disponibilidad, una máquina virtual que migra o una suplantación. El dato discriminante no es un único paquete, sino la correlación entre tabla ARP, FDB del switch, cambios de puerto, inventario y tiempo. La investigación debe preservar ambos modelos hasta obtener una observación que los separe.

Dominios locales como fronteras de visibilidad

Un dominio de broadcast es el conjunto de interfaces al que un broadcast de enlace puede propagarse bajo una determinada configuración. No equivale siempre a una LAN física ni a una subred correctamente configurada. Un dominio puede extenderse por varios switches y una VLAN, o reducirse por aislamiento de puertos y controles de bridge. ARP depende de esta frontera para descubrir vecinos. IP, en cambio, puede tratar como conectadas direcciones que luego no logran atravesar el enlace; la coincidencia de máscara no garantiza entrega.

El dominio también limita la visibilidad de la evidencia. Un observador en el puerto de C ve solicitudes y respuestas de C, pero no necesariamente las tramas entre S y otro vecino. Un puerto espejo puede omitir tramas por saturación, por selección de VLAN o por límites de hardware. Una captura en el host puede ver una copia después de offloading o filtrado, mientras el switch tomó decisiones sobre una trama anterior. Los registros del equipo de red pueden indicar reenvío y descarte, pero no sustituyen la evidencia del socket o de la aplicación.

La expansión del dominio tiene trade-offs. Facilita descubrimiento y movilidad, pero aumenta broadcast, dependencia de políticas comunes y alcance de un error de capa 2. Reducirlo puede mejorar aislamiento y diagnósticos, pero requiere routing, configuración de gateway y controles de acceso adicionales. Ninguna topología es segura por su etiqueta. El claim debe especificar qué flujo debe cruzar la frontera, qué broadcast es esperado, qué principal administra la configuración y qué comportamiento se considera fallo.

Diagnóstico por capas sin saltos lógicos

Una captura parcial no demuestra apagado ni llegada a la aplicación.

Ante «C no llega a S», empieza por una ventana y un estado conocidos. Conserva la dirección IPv4, máscara, interfaz elegida, tabla de rutas, estado de vecino y VLAN. Luego pregunta, en orden:

1. ¿La pila clasifica S como local o selecciona G?
2. ¿Existe una asociación de enlace para el siguiente salto? Si no, ¿se emitió y recibió la solicitud ARP?
3. ¿La interfaz formó la trama esperada con MAC y EtherType correctos?
4. ¿El switch aprendió las MAC en puertos y VLAN previstas? ¿La trama fue dirigida, inundada o descartada?
5. ¿La interfaz de S recibió la trama y entregó el datagrama a IP?
6. ¿El transporte y la aplicación aceptaron la unidad y generaron respuesta?

Cada pregunta requiere una fuente distinta. La tabla de rutas explica una elección local; la caché ARP explica una asociación vista por el host; la FDB explica un reenvío observado por el switch; una captura de interfaz muestra sólo lo que ese punto recibió o pudo entregar al capturador; los logs del servicio muestran una decisión de aplicación si existe correlación temporal y de identidad. Un ping negativo puede ser compatible con un filtro ICMP (Internet Control Message Protocol), un servicio no escuchando o una ruta rota. Sirve como prueba, pero no como diagnóstico completo.

La prueba negativa debe cambiar una sola variable relevante. Por ejemplo, repetir hacia otro vecino de la misma VLAN ayuda a separar un problema de interfaz local de uno específico de S. Repetir desde otro puerto de acceso puede separar un problema de C de una política de VLAN. Capturar en C y en S con relojes correlacionados puede distinguir «no salió», «salió y se perdió» y «llegó pero no fue aceptado». Si no se observa una trama en C, sólo se puede afirmar que ese punto no la registró dentro de la ventana y configuración dadas.

Errores frecuentes y límites

Confundir MAC final y MAC del gateway. Para un destino remoto, la trama inicial tiene como destino la MAC del siguiente salto. Revisar la MAC del servidor no explica la primera entrega. El remedio es escribir juntos el destino IPv4 final y el vecino de enlace.

Suponer que ARP resuelve nombres. DNS produce una dirección IP; ARP resuelve un vecino de enlace para esa dirección según la decisión local. Una consulta DNS exitosa no prueba conectividad, y una entrada ARP no prueba que el nombre sea correcto.

Tratar el switch como barrera de seguridad. Aprendizaje y forwarding reducen tráfico innecesario, pero no sustituyen una política de autorización. VLAN, port security o ACL (Access Control List) deben evaluarse con su configuración efectiva, excepciones y rutas de gestión.

Concluir que una MAC cambiante es un ataque. Movimiento, virtualización y alta disponibilidad son explicaciones legítimas. Hace falta correlación de tiempo, puertos, inventario y configuración antes de atribuir intención.

Concluir que no hay red porque ping falla. ICMP puede estar bloqueado mientras TCP o el servicio funcionan. La prueba debe vincularse al objetivo: resolución ARP, entrega IP, puerto, operación de aplicación o disponibilidad.

Interpretar una captura como visión total. El punto, filtro, offloading, espejo y ventana temporal limitan la conclusión. Documentar la interfaz y el filtro forma parte de la evidencia.

Uso profesional: seguridad, defensa e ingeniería

En un assessment autorizado, el objetivo es demostrar una propiedad dentro del alcance, no enumerar comandos. Para un problema de ARP, define si buscas integridad de la asociación, disponibilidad de vecinos o posibilidad de redirección. Obtén la mínima evidencia necesaria: configuración, tablas, capturas y logs. Detén la actividad si aparece un activo no autorizado o un riesgo de interrupción. Un hallazgo necesita precondición, observación, impacto posible, control existente, incertidumbre y una prueba de regresión.

Desde defensa, una alerta de cambio de MAC o de ráfaga ARP es una hipótesis. El contexto debe incluir host, VLAN, puerto, tiempo y mantenimiento esperado. Un control positivo puede ser una reubicación aprobada; un control negativo, una asociación no autorizada que no debe propagarse. La ausencia de alertas no demuestra ausencia de manipulación si el punto de captura o el sensor no cubre el dominio. La detección debe indicar qué queda invisible.

Desde security engineering, convierte el mecanismo en contratos verificables: el direccionamiento define cuándo se espera ARP; la política de VLAN define el dominio; el switch debe tener una fuente de verdad para sus entradas estáticas; el host debe reaccionar de forma controlada ante conflicto o fallo; y la restauración debe poder comprobarse. El control debe tener owner, versión, expiración de excepciones y una prueba que compare estado esperado, trama observada y resultado de aplicación. La simplicidad operativa es parte del diseño: un aislamiento que nadie puede mantener acaba siendo una configuración nominal.

Síntesis

Ethernet transporta datagramas en tramas dentro de un enlace; el switch usa el contexto de dominio y sus asociaciones para decidir hacia qué puerto reenviar; ARP permite que un host relacione una IPv4 del siguiente salto con una MAC; y la máscara y las rutas determinan si el destino se considera local o remoto. Son mecanismos relacionados, pero no intercambiables.

La conclusión profesional conserva la cadena: destino IP final, siguiente salto, asociación ARP, trama, VLAN y decisión del switch, recepción del host y procesamiento superior. Cada tramo tiene límites y evidencia propia. Un broadcast no cruza automáticamente un router; una MAC no autentica un principal; una FDB no prueba que la aplicación esté disponible; una captura parcial no demuestra ausencia global. Cuando el diagnóstico separa esos hechos de sus inferencias, puede elegir la siguiente observación que realmente reduzca incertidumbre.

Fuentes de referencia

La operación de ARP y su formato se especifican en RFC 826. El encapsulado de datagramas IP en Ethernet se describe, con alcance histórico y específico, en RFC 894. Para la decisión de red conectada o gateway, consulta RFC 1122; para bridges y VLAN, la ficha normativa de IEEE 802.1Q-2022 delimita el alcance del estándar.

Comprobación de conocimiento

1. Un cliente y un servidor tienen direcciones IPv4 que la máscara del cliente considera remotas. ¿Qué dirección debe resolver ARP y por qué no la MAC del servidor?
2. Explica la diferencia entre unicast conocido, unicast desconocido y broadcast en un switch, incluyendo qué puede aprender el equipo después de una respuesta.
3. Una entrada ARP cambia de una MAC a otra en pocos segundos. Formula dos explicaciones legítimas y una hipótesis adversaria; indica qué evidencia las discriminaría.
4. ¿Qué puede y qué no puede demostrar una captura tomada sólo en el puerto del cliente sobre la entrega en el servidor?
5. Un ping falla pero una conexión TCP a la aplicación funciona. ¿Qué inferencia queda descartada y qué mecanismo sigue siendo compatible?
6. Critica la frase «están en el mismo switch, así que comparten dominio local». Incluye VLAN, trunks y políticas de puerto en tu respuesta.
7. En Northstar, el cliente emite ARP para el gateway, pero el servicio remoto no registra tráfico. Diseña una secuencia de observaciones que distinga máscara incorrecta, descarte de switching y rechazo en el host.
8. Formula un claim acotado sobre la integridad de la resolución ARP en una VLAN. Declara alcance, evidencia, condiciones y una limitación que impida convertirlo en una garantía universal.

Problema de transferencia

Una organización observa que algunos clientes pierden conexión después de una migración de máquinas virtuales. En una captura aparece una solicitud ARP y, poco después, la misma IPv4 asociada con otra MAC. El switch muestra que la MAC se aprendió en un puerto distinto; el servicio remoto no presenta errores consistentes. Redacta un análisis que separe observación, inferencia e impacto posible. Incluye las comprobaciones de VLAN, FDB, inventario de virtualización, configuración de gateway, reloj y logs del host. Propón un control temporal y un retest que no dependa de asumir que el cambio es malicioso. Explica qué parte seguiría sin demostrarse aunque la conectividad se restaurase.