El año pasado celebré mis 20 años de certificación CCIE. Nadie me organizó una fiesta, no hubo desfile de teletipos, diablos, si no hubiera rescatado el correo electrónico de mi carpeta de correo no deseado no me habría enterado de que había ocurrido. Así que celebré contento que ya no tengo que pagar $80 cada 2 años a Cisco, y luego me descargué un logotipo CCIE Lifetime Emeritus para ponerlo en mi Página de LinkedIn (Qué elegante, ¿eh?). Obtener esa certificación me abrió un montón de puertas en mi carrera, y estoy muy agradecida. Pero ahora ya no tengo que volver a certificarme, ni pagar cuotas, ni hacer nada en realidad, y por todo eso también estoy agradecido.
Ser un experto en redes cuando había una demanda insaciable de conocimientos de élite en redes fue ciertamente divertido. Trabajé en un montón de sitios interesantes, viajé por todo el mundo en clase turista, hice grandes amigos y, lo más importante, ayudé a mucha gente buena.
Las redes han cambiado drásticamente en los últimos 20 años, y me siento como un dinosaurio cuando veo una nueva topología de enrutamiento por segmentos o intento comprender los entresijos de la última tecnología de enrutamiento por segmentos. ASIC que todos los chicos guays están usando. Pero cuanto más ha cambiado, más se ha mantenido igual. Seguimos utilizando CLI, syslog y SNMP. Eso debería hacer reflexionar a todo el mundo, la mayoría de las redes aún se gestionan con protocolos y herramientas creados en los años 70.
- Descargo de responsabilidad: Un párrafo de marketing -
Recientemente he estado trabajando en algo de tecnología que está diseñado para capacitar a los equipos de DevOps para construir y operar redes de centros de datos y de borde con sus herramientas preferidas, a saber, Kubernetes y el amplio mundo del software Cloud Native. Eliminará este nuevo y emocionante enfoque de las redes la necesidad de CCIEs? Es poco probable. Pero no necesito hacer nada en absoluto para lograrlo, sucederá por sí solo.
- Marketing final -
Esta serie de posts describirá brevemente algunas cosas de mi vida en la CLI. En primer lugar, permítanme ser claro, voy a estar hablando de expertos en redes como "CCIEs". Si eres un JNCIE o simplemente alguien que se ha ganado su propia insignia de honor personal viviendo el mismo tipo de estilo de vida, este post ES para ti. No me gusta la religión de los proveedores de redes, pero CCIE es el título más corto que puedo utilizar para describir a la flor y nata de los expertos en redes.
Ignorando por un momento la amplia variedad de actividades relacionadas con proyectos que llenan la mayor parte del día (bostezo), un CCIE hace básicamente 3 cosas:
- Rompe la red
- Arregla la red
- Realiza movimientos, adiciones y cambios
(¡espero que no los tres todos los días!)
El episodio en el que rompe la red
Definitivamente he roto redes. Si eres un CCIE durante algún tiempo, también lo has hecho. No pasa nada por asentir ahora mismo, todos lo hemos hecho. A veces no ha sido culpa nuestra, a veces sí. Con el tiempo, estas experiencias dolorosas se transforman en lecciones de las que aprendemos, como una cicatriz. Algunas personas tienen MUCHAS cicatrices. Éstas son algunas de las mías.
Una vez saqué del aire toda una importante oficina de noticias porque configuré mal un mapa de rutas para intentar distribuir el tráfico a través de dos enlaces de ancho de banda desigual. Los propietarios de la empresa eran tacaños y compraron un enlace de 5 MB y un enlace "de reserva" de 1 MB. En algún momento decidieron que querían usar el enlace de reserva para cierto tipo de tráfico, así que me pidieron que distribuyera los paquetes a través del enlace de 1MB. En redes, cada bit cuenta, y un rango IP que no se alinee con la máscara de bits puede traerte un mundo de dolor. En mi caso causó que todo el tráfico en el enlace de 5MB fuera hacia el enlace de 1MB. 5MB > 1MB obviamente y el enlace se saturó en un segundo y voila, adiós oficina de noticias de D.C. Lección: No dejes que la dirección te obligue a poner en riesgo un sistema importante porque son baratos. Redundancia significa IGUAL COSTE.
En otra ocasión causé un gran contratiempo en un gran sitio web de comercio electrónico con mis primeros intentos de automatización. Yo estaba usando PERL (sí, soy así de viejo) para conectarse a un Cisco 5k a través de telnet (SSH no era compatible con el 5k) para recoger algunos telemetría básica de un comando show. Si el script no podía conectarse simplemente reintentaba de nuevo hasta que la conexión se establecía, porque ¿quién necesita estrangulamiento de conexión de todos modos? El 5k fue construido antes de que nadie se preocupara por la seguridad, así que si golpeabas la vty mgmt con 10 intentos de conexión seguidos muy rápidamente causabas que el dispositivo tuviera un kernel panic. Que alegría. Naturalmente, este switch de acceso al campus estaba conectado al núcleo a través de L2, y el núcleo también estaba conectado a la parte frontal del sitio de comercio electrónico. Spanning Tree puede ser una cosa realmente molesta cuando esta haciendo su trabajo. Ha habido muchas veces en las que he maldecido el nombre de Radia Perlman mientras la red estaba caída (Lo siento Radia, no tengo forma de contar todas las veces que tu invento me ha salvado el culo mágicamente). Lección: Nunca pruebe algo nuevo, por inofensivo que parezca, en producción.
Esto último es lo que algunos denominan "suceso generador de currículum".
También he estropeado cosas bastante simples, como desenchufar un cable y volverlo a enchufar. A veces, si estás trabajando en un armario de cableado abarrotado, el cable entra en el siguiente puerto a la derecha, que por supuesto está en una VLAN diferente. Y ese cable no iba al escritorio de un usuario, sólo tenía que ir a un servidor de Microsoft Exchange, y aquí vamos de nuevo, adiós oficina de prensa extranjera. Las organizaciones de noticias no necesitan acceso al correo electrónico 24/7 ¿verdad? Lección: No dejes que nadie te obligue a correr un riesgo personal por su mala planificación. Lección 2: No enchufes/desenchufes los cables si no puedes verlos fácilmente.
Si este post parece una sesión de terapia freudiana, lo siento, pero en 20 años tienes la oportunidad de meter la pata hasta el fondo. Demonios, sólo han sido 3 errores, ¡imagina lo largo que podría ser en teoría este post! Hay que reconocer que estos errores ocurrieron en una época diferente, y algunas de estas empresas eran respetadas por la soltura (léase rapidez) con la que gestionaban sus redes.
¿Qué tienen en común todos estos sucesos? Aparte de tener que pasarme el resto del día escondido en uno de los armarios de cableado, en cada situación me enfrentaba a un entorno creado por otra persona. En el CLI, o mirando a un lío de cableado, era como si estuviera viajando en el tiempo para ver las decisiones exactas de diseño y el pensamiento de alguien años antes que yo. No estoy culpando a otra persona, ciertamente cometí los errores, pero ninguna de estas redes fueron creadas por mí. Son lo que los ingenieros de redes llaman copos de nieve. Cada uno de ellos es individualizado y único, con un conjunto único de comportamientos y problemas. Los CCIE odian los copos de nieve de los demás.
Regalo de cumpleaños para un CCIE
Pero el trabajo en red tiene que ver con el orden, la organización y el determinismo. Las redes se parecen mucho a los Legos. Todo el mundo sabe utilizar los Legos. Se sienten de una manera determinada en la mano y encajan con un clic específico que permite saber si la conexión es correcta. Los Legos se interconectan de maneras muy definidas, pero las opciones de conectividad son tan amplias que puedes apilarlos en un número infinito de configuraciones.
A los CCIE no les gusta coger el conjunto de problemas de otra persona porque nunca hay suficiente documentación para que se sientan cómodos. Pero con los Legos no hace falta documentación. Los ladrillos son piezas bien definidas que se interconectan de una manera muy prescrita. Y cuando construyes un juego grande, el manual te muestra exactamente cómo montarlo para conseguir el resultado anunciado en la portada de la caja. Así que no le compres al CCIE de tu vida un copo de nieve por su cumpleaños.
Muchas empresas de redes venden Legos. Algunas todavía quieren que utilices la CLI para montar sus Legos. ¿Le parece que esto es muy de Lego? Nosotros (todos en la industria de las redes) tenemos que hacer un trabajo mucho mejor para ofrecer una experiencia más amigable y de consumo para los constructores de redes. Tenemos que producir bloques de construcción pulidos, perfectamente ajustados y funcionales para que más gente pueda montarlos, moverlos, cambiarlos e interconectarlos con el resto de nuestra ciudad de Lego. Tenemos que ofrecer mejores productos, con más inteligencia incorporada, para que los usuarios finales obtengan resultados más deterministas.
Y, con suerte, muchos menos incidentes de ingenieros inocentes rompiendo la red.
P.D. La próxima vez hablaré de cosas que hice y que me salvaron el día. Yippee
Josh Saul ha sido pionero en soluciones de red de código abierto durante más de 25 años. Como arquitecto, construyó redes centrales para GE, Pfizer y NBC Universal. Como ingeniero en Cisco, Josh asesoró a clientes del sector financiero de Fortune 100 y evangelizó nuevas tecnologías entre los clientes. Más recientemente, Josh dirigió equipos de marketing y productos en VMware (adquirida por Broadcom), Cumulus Networks (adquirida por Nvidia) y Apstra (adquirida por Juniper). Josh vive en Nueva York con sus dos hijos y es un ávido submarinista.