Ingeniero de redes

Empiezo comprobando lo que resulta más rápido de verificar en lugar de asumir de entrada que es un problema del router. Primero confirmo el alcance: si es un solo usuario, una sola subred, una sola sede o todo, porque eso ya descarta la mayoría de las causas posibles. Reviso el estado de la capa física en el puerto o enlace afectado, luego la capa 2 con un ping a la puerta de enlace predeterminada, y después la capa 3 con un traceroute para ver exactamente dónde se rompe la ruta. Reviso el registro de cambios recientes antes de tocar nada, porque en mi experiencia un cambio hecho en las últimas 24 horas es la causa más a menudo que un fallo de hardware real. Una vez que aíslo el salto o el equipo que falla, reviso sus registros y los contadores de interfaz para detectar errores, pérdidas o problemas de CRC en lugar de adivinar. Voy anotando cada paso, tanto para tener claro lo que realmente he descartado como para que la siguiente persona no repita mi trabajo.

OSPF es mi opción por defecto para el enrutamiento interno dentro de una sola organización, porque converge rápido, gestiona bien los cambios de topología y no requiere la carga de gestión de políticas que exige BGP. Lo uso dentro de un campus o un centro de datos donde todos los routers están bajo una misma administración y el objetivo es simplemente la ruta más corta y eficiente. BGP entra en juego cuando enruto entre sistemas autónomos: conexión con un proveedor de internet, peering con una red asociada, o una WAN multisede donde necesito control por política sobre qué rutas toma el tráfico y no solo la más corta. BGP también me da atributos de ruta como el AS-PATH y la preferencia local para dirigir el tráfico de forma deliberada, algo que OSPF no permite. En la práctica he usado ambos juntos: OSPF internamente, redistribuido con cuidado hacia BGP en el borde, con filtrado de rutas para que un cambio de enrutamiento interno no pueda filtrarse por accidente hacia internet.

Mantengo tres cosas actualizadas en todo momento: un diagrama de topología que refleja la red real en producción, no la del diseño original; un sistema IPAM que rastrea cada subred, VLAN y asignación de dirección para que nadie duplique una dirección; y un registro de cambios ligado a cada despliegue de configuración, incluyendo quién lo hizo, por qué y el plan de reversión. Escribo runbooks para todo lo que ocurre más de una vez, especialmente los pasos de respuesta a incidentes, para que la solución no dependa solo de la memoria de una persona. He visto incidentes que duraron el triple simplemente porque la documentación no coincidía con la realidad, así que trato la actualización de la documentación como parte del cambio en sí, no como una tarea opcional posterior. Comparo el diagrama de topología con la red real cada trimestre para detectar desviaciones antes de que se conviertan en un problema durante un incidente.

Uso plataformas de monitorización con detección de anomalías integrada para detectar patrones de tráfico o picos de latencia que se salen de los valores normales, lo que permite detectar problemas antes de que los usuarios los reporten. Para tareas de configuración repetitivas, como aplicar el mismo cambio de VLAN o ACL en veinte switches, uso playbooks de Ansible y scripts de Python en lugar de hacerlo manualmente, lo que también reduce los incidentes causados por errores de escritura. Donde no delego el control es en cualquier cosa sensible a nivel de seguridad o de cara al cliente: los cambios de reglas de firewall, los cambios de política BGP y todo lo que toque el borde de internet pasan por una revisión manual mía antes de entrar en producción, sin importar la confianza que tenga en la automatización. Trato las herramientas asistidas por IA como buenas para la detección de patrones y la ejecución repetitiva, y mantengo mi propio criterio como el último control sobre cualquier cosa que pudiera tumbar un segmento de la red.

Durante el fallo de un switch núcleo, todo un edificio perdió conectividad, afectando a unos 400 usuarios durante lo que terminó siendo una interrupción de 45 minutos. Confirmé que el fallo estaba aislado a ese switch comprobando que el switch redundante del stack seguía activo pero no pasaba tráfico, lo que apuntaba a un problema de spanning tree y no a un fallo de hardware. Revisé la topología de spanning tree y encontré un valor de prioridad mal configurado tras un cambio hecho el día anterior, lo que había provocado un bucle que los mecanismos de protección del switch intentaban contener sin resolverlo limpiamente. Corregí el valor de prioridad, forcé un recálculo del spanning tree, y confirmé que el tráfico volvía a fluir con normalidad unos seis minutos después de identificar la causa. Después escribí el informe del incidente, añadí un paso de revisión por otro compañero para cualquier cambio de prioridad de spanning tree, y actualicé el runbook para que el siguiente ingeniero reconociera el mismo síntoma más rápido.

Durante un periodo de lentitud intermitente que afectaba a un equipo comercial antes de una llamada importante con un cliente, la directora quería una actualización cada quince minutos y no tenía paciencia para la jerga técnica. Expliqué la situación como un atasco en una carretera concreta entre su oficina e internet, no como toda la red caída, lo que estableció la expectativa correcta de que la mayoría de los sistemas funcionaban bien. Di un cronograma claro: sabemos dónde está la congestión, estamos redirigiendo el tráfico ahora mismo, y esperamos resolverlo en menos de una hora. Evité términos como pérdida de paquetes o MTU y en su lugar describí lo que realmente iban a notar, como páginas que cargan lento frente a páginas que no cargan en absoluto. Cuando se resolvió, lo confirmé con una cifra concreta de antes y después: la latencia bajó de unos 400 milisegundos a menos de 20, así que tuvieron algo concreto en lugar de solo mi palabra de que estaba resuelto.

Me avisaron sobre las 2 de la madrugada por una sesión BGP inestable con nuestro proveedor de internet secundario, que estaba cortando de forma intermitente nuestra ruta de respaldo. Todavía no afectaba a los clientes porque la ruta principal seguía activa, pero una sesión BGP inestable puede escalar rápido si se deja sin atender. Me conecté, revisé la interfaz en busca de errores de capa física, y no encontré nada local, lo que apuntaba a un problema del lado del proveedor. Abrí un ticket con el proveedor con las marcas de tiempo y los contadores de errores exactos, amortigüé la sesión temporalmente para detener el ruido excesivo en los registros, y dejé programado un recordatorio para hacer seguimiento por la mañana si no habían respondido. Documenté toda la secuencia en nuestro canal de incidentes para que el equipo tuviera contexto sin necesidad de despertar a nadie más. Al día siguiente el proveedor confirmó un problema de fibra en su lado, y cerré el tema retirando el amortiguamiento una vez que la sesión se estabilizó.

Una VLAN es una construcción de capa 2: segmenta los dominios de difusión dentro de los switches, de modo que los equipos en VLANs distintas no ven el tráfico de difusión de las demás aunque estén conectados físicamente al mismo switch. Una subred es una construcción de capa 3: una agrupación lógica de direcciones IP que determina cómo se toman las decisiones de enrutamiento. En la práctica, hago corresponder una subred con una VLAN como convención estándar, porque simplifica el diagnóstico: si conozco la VLAN, conozco la subred, y viceversa. La razón para usar ambas juntas en lugar de solo una es que las VLANs aportan aislamiento físico y de difusión a nivel de switch, mientras que las subredes aportan el límite de enrutamiento y control de acceso a nivel de router o firewall. Por ejemplo, podría poner finanzas e ingeniería en VLANs y subredes separadas para aplicar políticas de firewall distintas a cada una sin ninguna ambigüedad sobre a quién pertenece el tráfico.

Diseño en torno a zonas basadas en el nivel de confianza y la función, no en la ubicación física: una DMZ para todo lo expuesto a internet, una zona interna para el tráfico corporativo general, y una zona restringida para sistemas sensibles como finanzas o bases de datos de producción. El tráfico entre zonas tiene que pasar por un firewall, y escribo las reglas sobre una base de denegación por defecto, lo que significa que nada está permitido salvo que sea explícitamente necesario, en lugar de empezar de forma permisiva e intentar cerrarlo después. Cada regla lleva una descripción de quién la pidió y por qué, porque una regla sin documentar es lo más difícil de eliminar de forma segura dos años después. Reviso el conjunto completo de reglas cada trimestre para eliminar lo que ya no se necesita, porque los conjuntos de reglas de firewall tienden a crecer y rara vez se reducen sin un esfuerzo deliberado. Para cualquier segmento nuevo, también pienso en el tráfico este oeste, no solo norte sur, porque muchas brechas reales se propagan lateralmente una vez que están dentro de una sola zona de confianza.

El networking on premise es en gran parte físico: gestiono switches, cables y modos de fallo de hardware reales, y las decisiones de enrutamiento están ligadas a la topología física. En la nube, el networking se define por software: una VPC es una red aislada lógicamente dentro de un proveedor, y el peering de VPC permite que dos VPC se enruten tráfico entre sí de forma privada sin pasar por internet público, pero no es transitivo: emparejar A con B y B con C no permite que A llegue a C sin una conexión de peering directa o una puerta de enlace de tránsito. He usado puertas de enlace de tránsito para conectar varias VPC entre sí en lugar de construir una malla completa de conexiones de peering individuales, algo que se vuelve inmanejable a partir de unas pocas VPC. Para configuraciones híbridas he configurado tanto VPN como conexiones dedicadas como Direct Connect hacia el entorno on premise, y la pregunta de diseño principal es siempre la misma: cuál es el requisito de latencia y fiabilidad, porque una VPN sobre internet está bien para rutas de respaldo pero no para nada sensible a la latencia.