Una sola VLAN, DHCP agotado y errores CRC que se confunden con falta de ancho de banda
Una planta corporativa de tres niveles aloja a 180 empleados y 260 dispositivos con dirección: 150 laptops, 120 teléfonos VoIP, 40 cámaras IP y 6 puntos de acceso. Todo vive en la VLAN 10 con 192.168.10.0/24; el servidor DHCP entrega el rango .100–.200 con concesiones de ocho días y el resto se asigna manualmente «para que no se mueva». Cada mañana varios usuarios reciben «no se pudo obtener una dirección IP» y hay reportes recurrentes de conflicto de IP. A las 11:00 las videollamadas se pixelan y en el switch de acceso del segundo piso los contadores del puerto del AP muestran errores FCS/CRC que crecen ~200 por hora. El servidor de archivos tiene un solo enlace de 1 GbE y su respaldo nocturno (22:00–02:00) coincide con el turno de guardia, que reporta lentitud al abrir expedientes. La dirección pide «más ancho de banda» y «cambiar los AP por unos de mayor categoría».
1. Dimensiona el direccionamiento actual y propón un plan que elimine los conflictos y el agotamiento, justificando cada decisión.
Read the worked answer
El /24 no alcanza. 192.168.10.0/24 ofrece 254 direcciones utilizables y hay 260 dispositivos, sin contar crecimiento ni invitados. Peor aún: el pool DHCP (.100–.200, 101 direcciones) convive con asignaciones manuales dentro del mismo rango, de modo que un equipo estático puede caer en una dirección que el DHCP ya entregó a otro; de ahí los conflictos. Con concesiones de ocho días, un portátil que se va el viernes retiene su dirección hasta el miércoles siguiente, y el pool se agota los lunes por la mañana.
Plan propuesto (segmentación, no solo ampliación):
- Datos cableados: 192.168.10.0/25 (126 hosts).
- Voz: 192.168.11.0/24 (120 teléfonos con margen; la voz no debe compartir dominio de difusión con datos).
- Cámaras IP: 192.168.12.0/26 (62).
- Invitados: 192.168.13.0/25 con aislamiento de clientes y salida solo a Internet.
- Gestión de red: 192.168.14.0/28.
Esto exige enrutamiento inter-VLAN en el switch core y DHCP relay (
ip helper-address) donde esté el servidor.
Complementos imprescindibles: reservas DHCP por MAC para teléfonos, cámaras e impresoras; pool y rango estático declarados en subredes distintas; concesión de 8–12 h en inalámbrico e invitados y 8 días solo en cableado; DHCP snooping, Dynamic ARP Inspection y port security para que un usuario no pueda responder por una IP ajena. Ampliar a /23 sin segmentar arregla el conteo pero mantiene un único dominio de difusión con voz y datos, y no resuelve los conflictos.
2. A las 11:00 hay pixelación en videollamadas y errores FCS/CRC crecientes en el puerto del AP. ¿Cómo distingues la causa y qué haces antes de comprar AP nuevos?
Read the worked answer
Los CRC/FCS son capa 1, no falta de ancho de banda. Un contador de FCS/CRC que crece indica tramas que llegan corruptas al switch: cable dañado, conector mal ponchado, exceso de longitud, interferencia electromagnética o problema de PoE/transceptor. El switch descarta la trama; las capas superiores retransmiten y el aire se llena de repeticiones, lo que se percibe como pixelación. Comprar AP de mayor categoría no corrige un enlace físico defectuoso: solo mueve el problema.
Secuencia de diagnóstico:
- Comparar contadores en dos lecturas separadas 10 minutos; si crecen, aislar el enlace.
- Sustituir el patch cord y el latiguillo del AP; probar el cable con certificador. En radios largos, verificar que no se supere el límite de 100 m.
- Revisar velocidad y dúplex negociados en ambos extremos; un desajuste produce errores y colisiones.
- Solo con la capa 1 limpia, medir ocupación de canal, interferencia cocanal y densidad de clientes por AP con un survey; ahí sí se decide si hace falta otro AP o reubicarlo.
Sobre el horario: que ocurra a las 11:00 no prueba causalidad de tráfico; puede coincidir con el pico de uso, pero un enlace con errores empeora precisamente cuando hay más tráfico. Verificación del arreglo: contadores de error en cero durante 24 h y prueba de latencia/jitter contra el borde antes de declarar resuelto. Si tras corregir la capa 1 persiste, entonces se evalúa QoS para VoIP (priorizar EF/voz y marcar el resto) y no antes.
3. El respaldo nocturno satura el único enlace de 1 GbE del servidor de archivos y afecta al turno de guardia. Cuantifica y elige la solución.
Read the worked answer
Cuantificación. 1 GbE = 1,000 Mbps ≈ 125 MB/s teóricos; en la práctica, con TCP y disco, ~110 MB/s sostenidos. En una ventana de 4 h (14,400 s) el techo teórico es ~1.8 TB; si el respaldo mueve, por ejemplo, 600 GB, necesita 600,000/14,400 ≈ 42 MB/s de media, es decir, ~33% del enlace. El problema no es el promedio: los respaldos son ráfagas que llenan la cola del enlace y del disco, y la latencia de las peticiones pequeñas (abrir un expediente) se dispara mucho antes de saturar el ancho de banda. Por eso la guardia percibe lentitud con el enlace «al 40%».
Opciones, de menor a mayor coste:
- Limitar la tasa del respaldo a ~40 MB/s con QoS o
rsync --bwlimit, y priorizar el tráfico interactivo con una cola de baja latencia. Coste cero, efecto inmediato. - Cambiar a respaldo incremental/diferencial y espaciar el completo: reduce el volumen, no solo la velocidad.
- Mover la ventana fuera del turno de guardia, si la operación lo permite.
- Enlace dedicado (segunda NIC en VLAN de respaldo o 10 GbE): resuelve de raíz pero requiere presupuesto y cambios de cableado.
Recomendación: 1 y 2 de inmediato, medir latencia p95 de apertura de expedientes antes y después; 4 solo si la medición muestra que el enlace sigue siendo el límite.