Evidencia, no intención
Un bridge transparente no tiene configuración que le diga dónde está nada. Tiene una sola fuente de verdad: las tramas que llegan. IEEE 802.1D §7.8 le entrega al proceso de aprendizaje la dirección MAC origen y crea la entrada sólo si se cumplen cuatro condiciones a la vez: que el puerto de entrada esté en un estado que permita aprender, que la dirección origen «denote una estación concreta, es decir, que no sea una dirección de grupo», que no exista una entrada estática en conflicto, y que quepa en la tabla. 802.1Q 8.7 dice lo mismo con sus palabras —una Individual Address, no una Group Address— y reparte el resto entre 8.6.1 y 8.8.3. La dirección de destino no se le entrega jamás a ese proceso: se usa nada más como clave de consulta.
El motivo no es de estilo. La dirección origen es evidencia: la trama llegó físicamente por ese puerto, así que lo que la mandó se alcanza por ahí. La de destino es una intención, y no dice nada de dónde está el destinatario. Aprender de ella instalaría una entrada apuntando al propio puerto del emisor —justo el equivocado— y crearía un agujero negro. El estándar lo hace estructuralmente imposible en vez de simplemente desaconsejarlo.
El corolario se ve en la hoja: de un broadcast nunca se aprende como destino, y sin embargo el switch aprende un montón del origen de ese mismo broadcast. Un ARP request le enseña al switch dónde está el que pregunta, y nada en absoluto del que es preguntado.
Cuatro resultados, ningún caso especial
Todo lo que un bridge hace con una trama sale de dos reglas. La primera, 802.1D 7.7.1, «Enforcing topology restriction»: un puerto es candidato de transmisión sólo si el puerto de entrada estaba en forwarding, el de salida está en forwarding, el de salida no es el de entrada, y la trama cabe en el MTU del enlace de salida (esta última condición este lab no la modela). La segunda, el filtrado de salida: existiendo entrada para el destino, todo candidato que no sea el puerto de la entrada filtra la trama.
De esas dos salen inundar (sin entrada, o destino de grupo), reenviar (entrada que apunta a otro puerto), filtrar (entrada que apunta al mismo puerto por el que entró, así que ninguno la toma) y descartar (destino reservado, o puerto que no está en forwarding). No existe en ninguna parte una cláusula que diga «si origen y destino comparten puerto, descarta». Ese comportamiento es emergente, y presentarlo como regla sería mentir.
Envejecer, mudarse y quedarse sin sitio
Las entradas no son permanentes. El tiempo de envejecimiento recomendado por defecto son 300 segundos —802.1D tabla 7-4 y 802.1Q 8.7.3 con la tabla 8-9, con un rango de 10 a 1 000 000, y el propio módulo YANG de IEEE 802.1 publica lo mismo—. Recomendado, no obligatorio, y ningún fabricante ofrece el rango entero: Aruba AOS-CX admite de 60 a 3600 y Extreme desde 15. Cisco Catalyst, Juniper, Extreme y Aruba sí traen 300; el Nexus 5600/6000 trae 1800. La información estática queda exenta: «It shall not be automatically removed by any ageing mechanism» (802.1D 7.9, 802.1Q 8.8.1). Y un cambio de topología no acorta el temporizador en un equipo moderno: RSTP vacía lo aprendido en los puertos afectados, y por eso una tabla que se queda en blanco sin motivo aparente suele ser un cambio de topología antes que una avería. (El STP de 1998 sí lo acortaba; ese mecanismo es el que describe la documentación antigua.)
Una dirección vive exactamente en un puerto a la vez. Cuando el switch la ve llegar por otro, borra la fila vieja y escribe la nueva — y si siguen llegando tramas por los dos, sigue reescribiendo y en cada cambio se pierden paquetes. Eso es el MAC flapping, y la causa clásica es un lazo: sin spanning tree la trama inundada vuelve por otro puerto con su dirección origen intacta, así que el switch concluye que el equipo se mudó. Una regla que es correcta en un árbol se vuelve destructiva sin él. Pero no todo flap es un lazo: un cliente Wi-Fi que hace roaming entre dos puntos de acceso que hacen bridge local produce el mismo movimiento, sin daño — con una controladora en medio la dirección vive detrás del puerto de la controladora y no se mueve.
La tabla es finita —el datasheet del Catalyst 9300 dice 32 000 entradas —64 000 en sus modelos de alta escala—, y un Catalyst 9500 High Performance llega a 82 000 sólo con la plantilla SDM Distribution, 32 000 con la que trae de fábrica— y al llenarse las direcciones nuevas no se aprenden y el tráfico hacia ellas se inunda. El switch no ha entrado en ningún «modo hub»: ese modo no existe. Lo que pasa es que todas las consultas fallan, y una consulta fallida ya tiene comportamiento definido. Eso es todo el ataque de desbordamiento de CAM, y todo el motivo de que exista port security: la tabla es un recurso compartido y agotable, y sin cuota por puerto un solo puerto se la puede comer entera. También es reversible, porque el envejecimiento vacía la tabla solo. Cuidado con la conclusión, eso sí: Cisco llama al enrutamiento asimétrico una de las dos causas más comunes de inundación, y al desbordamiento de tabla «posible pero raro» — así que el desbordamiento es la última hipótesis a la que agarrarse, no la primera.
