Introducción
Maple Hall utiliza ahora dos conmutadores de software unidos por un cable compartido. Los grupos locales de visitantes y personal ya son correctos. Debes transportar ambos por el enlace y trasladar un dispositivo reasignado al grupo del personal sin romper los dispositivos existentes.
Completa el primer laboratorio o conoce su flujo de puertos de acceso: leer el plan, eliminar una pertenencia exacta, añadir PVID y salida sin etiquetas, y observar servicios/ARP reales. Se requieren conocimientos básicos de MAC/IP y subredes. Esta escena independiente no depende de la VM anterior.
Switch A y Switch B son consolas persistentes distintas para espacios de nombres separados de una instancia, con un núcleo compartido. Client Checks observa terminales; LAN Groups muestra estado actual y solicitudes reales. Solo se pueden modificar pertenencia VLAN/PVID/etiquetado de los dos puertos uplink y del puerto ticket de Switch B. Conserva direcciones, otros puertos, servicios, puentes y firewalls. Los 45 minutos son una estimación del autor, sin prueba piloto con principiantes.
Completa el enlace etiquetado
En este paso distinguirás un grupo local funcional de una ruta compartida incompleta y después completarás ambos extremos. Abre LAN Groups y Open device plan. Visitantes usa VLAN 10; personal VLAN 20. Los servidores locales están en Switch A; los remotos y ticket, en Switch B. La dirección /24 preparada de cada terminal ya coincide con su grupo previsto.
Cambia a Client Checks. Usa primero las dos rutas locales funcionales con el ayudante del primer laboratorio:
python3 /opt/labex/lan-groups/checks.py request visitor local
python3 /opt/labex/lan-groups/checks.py request staff local
Lee todo el programa y las instrucciones. Omite ahora local para apuntar al servidor del mismo grupo al otro lado del enlace. Se espera un tiempo agotado porque el enlace no permite ninguna VLAN. El ayudante devuelve un estado distinto de cero e informa del tiempo agotado. Es intencionado aquí; continúa con el siguiente comando:
python3 /opt/labex/lan-groups/checks.py request visitor
Cambia a Switch A y consulta sus pertenencias reales:
bridge vlan show
Cambia a Switch B y consulta ese conmutador independiente:
bridge vlan show
Ambas consolas empiezan en /home/labex/project/lan-groups, pero actúan en espacios de nombres distintos. Lee el nombre de la pestaña antes de modificar nada. Una fila uplink vacía o ausente indica que no hay grupos permitidos, no que el terminal esté desenchufado. Ambos grupos locales pueden funcionar aunque la ruta compartida esté incompleta.
El terminal ticket ya tiene la dirección del personal 10.60.20.31/24, pero su puerto aún muestra VLAN de visitantes 10. Este desajuste deliberado se resolverá después del enlace. No lo repares cambiando su IP.
Permite los grupos en ambos extremos
Ahora transportarás dos grupos por el mismo enlace. Un enlace etiquetado incorpora un identificador VLAN IEEE 802.1Q a cada trama Ethernet para que el siguiente conmutador reconozca su grupo. Los terminales ordinarios siguen recibiendo tramas sin etiquetas. Ambos extremos deben permitir los mismos grupos.
Empieza en Switch A. Añade las pertenencias de visitantes y personal a uplink. Se omiten intencionadamente pvid y untagged: el enlace transporta tramas etiquetadas y no tiene un grupo nativo sin etiquetas:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
Cambia a Switch B y configura su extremo:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
bridge vlan show dev uplink
Debes ver las VLAN 10 y 20, sin indicadores PVID ni Egress Untagged. Vuelve a Switch A y consulta también ese extremo:
bridge vlan show dev uplink
Cambia a Client Checks y prueba ambas rutas remotas:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Captura cada grupo en los terminales reales y en ambos extremos del enlace:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Lee uplink-a y uplink-b: las líneas de visitantes contienen 802.1Q y vlan 10; las del personal, vlan 20. El servidor remoto del mismo grupo recibe ARP sin etiqueta VLAN y el del otro grupo recibe cero coincidencias. Así se demuestra etiquetado real en la ruta compartida y entrega sin etiquetas a sus extremos.
En este punto ticket todavía recibe difusiones de visitantes y no del personal porque su puerto conserva la pertenencia anterior. Es normal hasta el próximo paso. Si un servidor remoto no recibe su grupo, compara las dos tablas del enlace antes de repetir; configurar solo un extremo no basta. Si añades una VLAN errónea, elimina solo esa fila mediante bridge vlan del dev uplink vid ... en la pestaña correcta y añade la pertenencia prevista.
Asigna el dispositivo reasignado a su grupo previsto
En este paso terminarás la reasignación de ticket conservando ambos grupos remotos. Empieza en Switch B. Consulta primero el puerto exacto actual:
bridge vlan show dev ticket
Su VLAN antigua de visitantes es 10, aunque la dirección preparada y la finalidad ya pertenecen al personal. Elimina esa pertenencia y configura PVID del personal y salida sin etiquetas:
bridge vlan del dev ticket vid 10
bridge vlan add dev ticket vid 20 pvid untagged
bridge vlan show dev ticket
Debes ver únicamente 20 PVID Egress Untagged. Dirección IP y pertenencia VLAN son capas distintas; este trabajo no necesita reasignar direcciones.
Cambia a Client Checks y usa el servicio real del personal desde el terminal reasignado:
python3 /opt/labex/lan-groups/checks.py request ticket
Repite las dos solicitudes remotas originales:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Captura de nuevo ambos grupos:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Ahora ticket recibe difusiones del personal y cero de visitantes. Deben seguir siendo visibles las dos copias etiquetadas del enlace y todos los terminales del mismo grupo. Detener un servicio no supera las pruebas positivas, y distintas subredes no ocultan una fuga ARP.
Abre LAN Groups, recarga y solicita el servicio en todas las tarjetas, incluidas las dos referencias y ticket. Lee cada recurso completo. Abre la pertenencia actual y compara ambos extremos y ticket con el plan. Si modificaste otro puerto de acceso, restaura solo su pertenencia original según el plan, con el patrón enseñado de eliminación/adición; no reinicies la VM ni elimines el puente.
La evaluación lee la configuración y envía sondeos de lectura acotados, sin repararla. El aprendizaje de vecinos y de MAC a puertos en la FDB (Forwarding Database), así como los registros normales de acceso, pueden cambiar naturalmente. Son grupos cableados temporales de una instancia con núcleo compartido, sin enrutamiento entre VLAN ni persistencia tras reinicio.
Lee la respuesta completa bajo cada botón. Las etiquetas describen el plan; las solicitudes correctas y las tablas actuales muestran el resultado real.
Resumen
Has distinguido éxito local de una ruta completa entre conmutadores, permitido ambas VLAN etiquetadas en los dos extremos y corregido un puerto reasignado. Las capturas 802.1Q reales, las capturas sin etiquetas en terminales, las respuestas completas y las referencias conservadas demuestran el resultado. El desafío cambia los ID VLAN y combina las mismas operaciones.
