Preguntas de entrevista para Ingeniero de Redes

Respuesta modelo

En mi último puesto era el responsable técnico de una red de 145 sedes y unos 3.100 dispositivos, con dos centros de datos activos en Madrid y Zaragoza. Mi ámbito iba desde el diseño y la ingeniería de cambios hasta la operación: yo definía la topología de las sedes nuevas, mantenía las dos sesiones eBGP de salida a Internet y el OSPF interno, ejecutaba las ventanas de cambio y entraba en el retén 24x7 en semanas alternas. El despliegue físico lo hacía un instalador externo, pero la configuración, la validación y la aceptación eran mías. El proyecto más grande que lideré fue la migración de MPLS a SD-WAN de esas 145 sedes en once meses.

Respuesta modelo

Primero acoto: si le pasa a un usuario, a una planta o a toda la sede, si es contra una aplicación o contra todas, y desde cuándo. Después subo por capas. En la capa física y de enlace miro errores, descartes y negociación del puerto de acceso y del uplink, porque un CRC creciente o un dúplex mal negociado explican la mitad de estos casos. En la capa de red compruebo el camino con traceroute y MTR desde el puesto y desde la sede, y miro la latencia y la pérdida en el enlace WAN, además de la saturación en la monitorización. En la capa de transporte reviso si hay retransmisiones o problemas de MTU con una captura en Wireshark. Y antes de cerrar descarto DNS, porque una resolución lenta se percibe siempre como aplicación lenta. Si hasta ahí la red está limpia, lo documento con datos y lo devuelvo al equipo de aplicación con la captura, no con una opinión.

Respuesta modelo

La migración de 145 sedes de MPLS a SD-WAN. Empecé con un inventario real en NetBox, porque el que había estaba desactualizado en un 30 %. Definí un diseño patrón para tres tamaños de sede y lo probé con cinco pilotos durante seis semanas, midiendo latencia, pérdida y comportamiento del respaldo móvil. A partir de ahí montamos oleadas de doce sedes por noche, siempre en martes, con la configuración generada por plantilla Jinja2 y validada automáticamente. Cada oleada tenía criterios de aceptación escritos y un punto de no retorno a las 02:00: si a esa hora no había servicio, se volvía al circuito antiguo, que mantuvimos en paralelo un mes. Tuvimos que aplicar el retroceso dos veces, ambas por problemas de portabilidad del operador y no de configuración. Acabamos en once meses, sin corte superior a veinte minutos y con un ahorro de 268.000 € anuales.

Respuesta modelo

Yo soy el propietario de la conectividad y de la segmentación: diseño las VLAN y las VRF, configuro el cortafuegos como elemento de red (interfaces, zonas, NAT, enrutamiento, túneles IPsec) y me aseguro de que las políticas se apliquen sin romper el tráfico legítimo. El equipo de seguridad define qué debe estar permitido, gestiona el análisis de riesgos, el SIEM y las auditorías. En la práctica trabajamos juntos: ellos piden una microsegmentación entre entornos y yo digo qué es viable con la topología actual, qué requiere cambiar el direccionamiento y qué impacto tiene en el rendimiento. Cuando aparece un incidente de seguridad, yo aporto las capturas, los registros de sesión del cortafuegos y el NetFlow, y ellos hacen el análisis.

Respuesta modelo

Tengo la CCNP Enterprise en vigor y en mayo superé el examen escrito del CCIE; estoy preparando el laboratorio para el año que viene, con unas seis horas semanales en EVE-NG. Sigo las notas de versión de FortiOS y las de NX-OS porque me han mordido bastantes veces, y participo en el grupo de usuarios de redes de Madrid. Lo que más me ha cambiado la forma de trabajar en los dos últimos años ha sido la automatización: pasé de scripts sueltos con Netmiko a playbooks de Ansible con NetBox como fuente de verdad, y ahora estoy con las pruebas automáticas posteriores al cambio.

Respuesta modelo

Sí, y tengo experiencia con ello: llevo cinco años haciendo retén en semanas alternas, con una media de tres incidencias P1 al mes. Lo que sí me gustaría concretar es cómo está organizado aquí: cuántas personas rotan, cómo se compensa la semana de guardia y las horas intervenidas, y si existe un primer nivel que filtre antes de escalar. Con un reparto razonable y procedimientos escritos, la guardia es perfectamente sostenible; sin ellos se convierte en el motivo por el que la gente se va.

OSPF lo uso dentro de mi propio dominio: converge rápido, calcula la ruta más corta según coste y me da la topología interna del campus o del centro de datos, con áreas para acotar el tamaño de la base de datos. BGP lo uso en la frontera, con operadores o entre sistemas autónomos, porque escala a cientos de miles de prefijos, es estable y sobre todo porque me da política: con local preference decido por dónde sale el tráfico, con AS-path prepending y comunidades influyo en por dónde entra, y con prefix-lists controlo exactamente qué anuncio y qué acepto. Un protocolo de estado de enlace no me sirve para eso: no está pensado para expresar preferencias comerciales ni para aguantar tablas de ese tamaño. En una red mediana típica conviven los dos: OSPF interno y eBGP hacia los operadores, con redistribución muy controlada y solo en un sentido.

Sin protección, las tramas de difusión circulan indefinidamente porque la cabecera Ethernet no tiene TTL: se produce una tormenta de difusión, la tabla MAC se inestabiliza porque la misma dirección aparece por puertos distintos, la CPU de los conmutadores se dispara y la sede deja de funcionar entera, no solo el segmento afectado. Lo evito con Spanning Tree, normalmente RSTP o MST, que bloquea el enlace redundante y lo activa si cae el principal. Además fijo el rol de raíz con la prioridad para que no lo tome un conmutador cualquiera, aplico BPDU guard y portfast en los puertos de acceso para que un equipo enchufado por un usuario no se convierta en raíz, y activo storm-control. En el centro de datos he sustituido esta lógica por un fabric VXLAN/EVPN, donde no hay bucles de capa 2 porque el transporte es enrutado y todos los enlaces trabajan a la vez.

Una VLAN separa dominios de difusión en la capa 2: dos VLAN son redes distintas, pero si el mismo router las conoce, sus rutas viven en la misma tabla y pueden comunicarse en cuanto exista una ruta y lo permita el cortafuegos. Una VRF separa en la capa 3: crea tablas de enrutamiento independientes dentro del mismo equipo, de modo que dos VRF pueden usar incluso el mismo direccionamiento sin colisionar y no se hablan salvo que yo lo permita de forma explícita, con fugas de ruta controladas o pasando por el cortafuegos. Uso VLAN para segmentar usuarios, voz, impresoras o cámaras dentro de una sede, y VRF cuando necesito aislamiento fuerte de extremo a extremo: la red de invitados, la red industrial, un entorno de una empresa recién adquirida o el tráfico de gestión.

Ese cuadro apunta casi siempre a la MTU. El ping por defecto usa paquetes pequeños y pasa; en cuanto entra tráfico con paquetes de tamaño completo, la sobrecarga de la cabecera IPsec, y del GRE si lo hay, hace que se supere la MTU del camino. Si el paquete lleva el bit de no fragmentar y algún salto intermedio descarta los mensajes ICMP de tipo 3 código 4, el descubrimiento de MTU del camino se rompe y la sesión se queda muerta. Lo compruebo con pings de tamaño creciente y bit DF activado para encontrar el umbral exacto, y con una captura donde se ve la retransmisión repetida del mismo segmento grande. La solución habitual es ajustar el MSS clamping en la interfaz del túnel, típicamente a 1350 o 1360, fijar la MTU del túnel y asegurarme de que no se está bloqueando el ICMP necesario en el camino.

Empiezo por abajo, aunque tenga la tentación de mirar la configuración. Reviso el estado físico del enlace y los contadores de errores, porque un enlace con pérdida intermitente tira el temporizador de mantenimiento y provoca exactamente ese síntoma. Compruebo los registros para ver quién cierra la sesión y con qué notificación: un mensaje de temporizador expirado apunta a pérdida o a temporizadores dispares, y un mensaje de límite de prefijos superado apunta a que el vecino me está anunciando más prefijos de los que acepto. Miro también si la CPU del equipo se satura al recibir la tabla completa y si hay algún filtro o política de control de plano que esté limitando el tráfico de la sesión. Mientras investigo, aplico dampening o desactivo el vecino si la inestabilidad está afectando al resto de la red, y abro caso con el operador aportando los tiempos exactos y los contadores, no solo la frase de que se cae.

Cambia el patrón de tráfico y, con él, todo lo demás. En el campus el tráfico es fundamentalmente norte-sur, de los usuarios hacia los servicios, así que la jerarquía clásica de acceso, distribución y núcleo funciona bien; lo que manda es la densidad de puertos, el PoE para telefonía, puntos de acceso y cámaras, el control de acceso a puerto con 802.1X, la calidad de la cobertura inalámbrica y la protección contra bucles causados por los propios usuarios. En el centro de datos el tráfico es mayoritariamente este-oeste, entre servidores, así que se impone la topología leaf-spine con VXLAN/EVPN, donde todos los enlaces están activos y la latencia entre cualquier par de nodos es predecible. Ahí importan la sobresuscripción, la convergencia por debajo del segundo, el direccionamiento de la infraestructura, la conexión doble de los servidores y la integración con la virtualización. También cambia la ventana de mantenimiento: en el campus puedo tocar de noche con relativa tranquilidad, y en el centro de datos cualquier cambio afecta a servicios que están dando de comer a toda la empresa.

Es cuando el tráfico de ida sigue un camino y el de vuelta otro distinto. En una red puramente enrutada eso puede ser inocuo, pero si en uno de los dos caminos hay un cortafuegos con inspección de estado, ese cortafuegos ve la respuesta de una conexión cuyo inicio no ha registrado, no encuentra la entrada en su tabla de sesiones y descarta el paquete. El síntoma típico es que unos servicios funcionan y otros no, o que la conexión se establece y muere al poco. Lo he visto sobre todo tras añadir un segundo enlace o al hacer convivir un anillo antiguo con un diseño nuevo. Se corrige haciendo simétrico el camino con métricas o política de enrutamiento, colocando los dos cortafuegos en clúster con sincronización de sesiones, o forzando el retorno por la misma pasarela con NAT de origen cuando no hay otra opción.

Lo primero es dejar de tocar y fijar la hora límite: si a las 03:00 no hay servicio, la sede abre sin red y hay que avisar. Después recupero el acceso por la vía de emergencia, que en nuestro caso es el módulo 5G de gestión o, si no responde, el técnico de guardia del instalador. Con acceso, comparo la configuración actual con la copia previa que siempre saco antes del cambio, en lugar de ir parcheando a ciegas. Si el retroceso ha fallado por hardware o por el operador, escalo de inmediato: caso con el TAC del fabricante y llamada al NOC del operador con el número de circuito en la mano. En paralelo aviso a mi responsable y al centro de atención a usuarios con un mensaje claro para la apertura, y preparo el plan alternativo, que puede ser levantar la sede con el respaldo móvil aunque sea con rendimiento degradado. Al día siguiente escribo el postmortem, sin buscar culpables, y corrijo el procedimiento de retroceso, porque si ha fallado es que no estaba bien probado.

No lo rechazo de plano ni lo hago en silencio: hago que el proceso funcione a su velocidad. Le llamo, entiendo qué necesita de verdad, porque a menudo la petición viene traducida por un tercero y la regla correcta no es la que pide. Abro yo mismo el ticket con la información técnica, lo marco como urgente y busco la aprobación del propietario del servicio y del responsable de seguridad, que en muchas empresas se puede obtener en una hora. Si el riesgo lo justifica, propongo una regla temporal, acotada a origen, destino y puerto, con fecha de caducidad puesta desde el primer momento. Lo que no hago es aplicar un cambio no registrado: sin traza, dentro de seis meses nadie sabrá por qué existe esa regla y será exactamente el agujero que aparezca en la siguiente auditoría.

Construyo el caso con datos antes de discutir. Preparo pruebas repetibles desde el equipo de la sede contra el primer salto del operador y contra un destino externo, con MTR de varias horas y marcas de tiempo, para demostrar dónde empieza la pérdida y descartar mi propia red y el equipo terminal. Reviso los contadores de errores de la interfaz y hago una prueba con iperf3 en ventana controlada. Con eso reabro el caso citando el número de circuito, el compromiso de servicio contratado y las franjas horarias exactas, y pido pruebas por su parte y una intervención presencial si procede. Si el operador no reacciona, escalo por la vía del gestor de cuenta con el histórico documentado, y en paralelo mitigo lo que pueda: pasar el tráfico crítico por el enlace secundario mediante las reglas de SLA del SD-WAN mientras se resuelve. Registro las incidencias reiteradas, porque son las que sostienen la aplicación de penalizaciones en la renovación del contrato.

Digo la verdad sobre el plazo el mismo día, porque el problema no mejora si se calla, y presento una solución en lugar de un no. La sede puede abrir con un enlace móvil 5G en el propio FortiGate y un túnel IPsec contra el centro de datos: sirve para la caja, para el correo y para las aplicaciones de negocio, con QoS que priorice el tráfico crítico y sin vídeo ni copias de seguridad hasta que llegue la fibra. Comunico con claridad las limitaciones de ancho de banda y latencia para que nadie descubra el día de la apertura que ciertas cosas no van. En paralelo tramito el alta definitiva, exijo fecha comprometida por escrito y, si el plazo es crítico, pido oferta a un segundo operador con infraestructura propia en esa dirección. Cuando llegue la fibra, se conmuta en ventana nocturna y el 5G se queda como respaldo, que es lo que debe ser.

Durante el incidente, servicio primero: le pido la configuración que aplicó, restauro desde la copia previa y dejo el análisis para después. Cuando el servicio está restablecido, hablo con él a solas y sin dramatismo, porque quien acaba de provocar una caída ya está bastante castigado. En el postmortem describo el hecho sin nombres, y lo enfoco al proceso: si una persona con dos meses en el puesto ha podido tocar producción sin ventana ni revisión, el fallo es del control, no solo suyo. De ahí suelen salir dos acciones concretas: revisión obligatoria por un segundo par de ojos para los cambios en conmutadores de acceso durante los primeros seis meses, y un procedimiento escrito con la copia de configuración previa como paso obligatorio. Es la manera de que el equipo siga avisando de sus errores en lugar de esconderlos.