Cómo manejas tu tiempo? Cómo das balance a tu trabajo, hobbies, tu vida personal.. etc… con el paso de los años vas aprendiendo a gestionar mejor tu tiempo, aunque creo nunca es suficiente. Ha sido el caso para mi toda esta pandemia y hoy por fin hago esta entrada para tratar de retomar las publicaciones; tengo tiempo ahora? No realmente pero creo que he logrado gestionarlo mejor, ahora preparándome para mi CCIE buscaré atacar ciertos temas de routing y switching a un nivel con el que me siento confortable y que seguro podrá ayudar a alguien más tratando de comprender una tecnología… nos vemos en la siguiente publicación.
Durante la semana me topé con un caso bonito, de esos donde el partner tiene dudas sobre la utilización de la tecnología pero también el tiempo encima para entregar un despliegue de cerca de 1000 sucursales… SI! ESCALACIÓN!!!!
Para muchas personas, SD-WAN es crear túneles IPSEC fácil y rápido, y lo es… obvio no lo es todo… pero una de las cosas inherentes de Cisco SD-WAN es la cantidad impresionante de «cosas» que puedes hacer.
Cuál es el caso de uso? El cliente final tiene al menos tres tipos de sitios WAN en su ambiente; Centros de datos (A), Sucursales Tipo B y Sucursales Tipo C. Qué tenemos que realizar para lograr un Hub and Spoke entre Tipo C y Centros de Datos, restringiendo conectividad entre Tipo C, contar con la capacidad de comunicarse con los Tipo B, pero teniendo al Centro de Datos como punto de interconexión (si, sin túneles entre B <> C)… y a su vez los Tipo B y los Centros de Datos puedan realizar una malla (full mesh)…
Y ahora, cómo le hacemos? En el siguiente video revisamos una de las formas más simples de atacar este requerimiento.
No olvides suscribirte, eso me ayuda a seguir subiendo contenido! Espero sea de ayuda.
Como saben, la finalidad de este espacio es compartir experiencias dentro de este bonito campo en donde abunda la tecnología, cientos de cursos sobre cada una de ellas (o parte de ellas) y certificaciones… esta ocasión les quiero platicar sobre DevNet Associate (CCNA) y mi experiencia con la misma.
¿Soy un candidato para la certificación?
Tu primera impresión podrá ser, ¿realmente debería intentar esta certificación, aunque no he «programado» en mi vida? La respuesta es, ADELANTE. Cualquier persona puede iniciar este camino, recuerda que un CCNA es el primer paso en un track de certificación que va aumentando su dificultad conforme avanzas (CCNP, CCIE, etc.), DevNet Associate es un CCNA y como tal busca sentar las bases del mundo de programabilidad / desarrollo de software / automatización que es posible llevarse acabo con el portafolio de soluciones de Cisco. Entonces, la respuesta es, anímate, comienza tu estudio.
¿En qué me ayuda la certificación?
Conocer sobre estos temas y certificarte pone en marcha lo que yo llamo un refresh para ti como ingeniero en redes, ¿por qué? ¿ te habías preguntado cuántas tareas puedes automatizar y ganar mucha agilidad en tu día a día? Como leí durante mi preparación para el examen, «Si tienes que repetir la tarea muchas veces, automatízalo»… claro, automatizar puede llevar algunas horas, días o semanas, aprender un lenguaje de programación, quizá un engine de base de datos y conjuntar los distintos elementos para lograr que lo que hacías manualmente y transaccional, ahora pueda ejecutarse por medio de un script, en segundos y con mayor flexibilidad. A esto le llamo refresh, aprender cosas nuevas que agregan valor a todo lo que ya sabes.
¿Y cómo me preparo para combatir este pequeño monstruo?
Material suficiente existe en google para poder salir avante de esta certificación. Personalmente usé Digital Library de Cisco ( digital-learning.cisco.com ) si buscan por DEVASC (with labs) pueden encontrar un excelente material que te guía por el contenido necesario e incluye labs para poder salir exitoso en el DEVNET Associate.
Temas puntuales que les recomiendo estudiar: Linux, creo que todos debemos tener bases de Linux (por ello esperen un tutorial con comandos básicos)… uso de Postman… bash scripting… y obviamente interacción con APIs de portafolio Enterprise Networks de Cisco (particularmente XE, DNA Center, Meraki)… para mayor guía pueden entrar a recursos como http://developer.cisco.com (esto es un MUST)…
Ah, recuerda que las certificaciones no son un adorno, en este caso específico de DEVNET, busquemos casos en donde podemos aplicarlo, de esto se trata facilitarnos la vida en nuestro día a día (trabajo, vida personal, o por qué no, ayudando a nuestra comunidad como mis amigos super cracks https://www.itsitio.com/us/cisco-mexico-desarrolla-aplicativo-frente-covid-19/ )
Para no seguir mareándolos, les deseo mucho éxito en este journey, cualquier duda o comentario, o ayuda que necesiten pueden dejar aquí su solicitud y en medida de lo posible les brindo apoyo.
Como menciono en el video, existen dos Sistemas Operativos con los cuales se puede hacer ZTP, uno de ellos XE SDWAN.
Si no queremos usar las templates por default del vManage, es simple crear las nuestras para hacer que nuestro enrutador se firme con los controladores, y posteriorment configurar según lo requerido.
Primero ingresamos a nuestro vManage
Vista vManage
Nos aseguramos que el dispositivo que queremos aprovisionar se encuentre en el inventario, sincronizar en caso de que no se encuentre.
Ahora podemos observar que el dispositivo está disponible en nuestro inventario (último en nuestra lista)
Ahora configuraremos una template para el dispositivo.
Y aquí viene lo interesante, primero agregamos una descripción y nombre a la template, no sin antes elegir el modelo que usaremos.
Recuerda que los enrutadores establecen la comunicación con los controladores por la VPN 0, entonces, en la pestaña de Transport & Management VPN, tenemos que configurar nuestra VPN 0 y nuestra interface que usaremos para el ZTP.
Primero crearemos la VPN 0 – aquella que habrá de contener todos nuestros transportes WAN.
Coloca un nombre y una descripción. La VPN 0 está por default, es opcional colocar un «Name» en Basic Configuration, es prácticamente una descripción.
Por buena práctica, siempre coloco un DNS, recuerda que tienen que resolver devicehelper.cisco.com , y si el DNS que nos provee el carrier tiene algún problema, nuestro ZTP no funcionará en ese instante. Más vale prevenir. Con esto es suficiente por ahora.
Ahora, vamos a configurar la interface que nos dará salida al mundo externo y a los controladores, por supuesto.
Para este punto lo primero que tenemos que hacer es encender la interface. Cambia la variable a global para predeterminar el encendido de la misma.
Ahora coloca la información respectiva de la interface, en un enrutador con XE cualquier interface routed/L3 puede usarse para aprovisionamiento de cero toque. En mi caso, un 1111X-8P, tiene la interface GigabitEthernet0/0/0 y GigabitEthernet0/0/1. Yo usaré la GigabitEthernet0/0/0.
Indicamos más abajo que el equipo tiene direccionamiento dinámico.
Y en Tunnel, la configuración más importante, nuestra interface será utilizada para establecer conexiones de control y túneles seguros -IPSEC- hacia otros enrutadores, por lo que debe tener asignado un TLOC (Transport Locator), para ello vamos a configurarla como Tunnel Interface, asignándole un Color y Encapsulación, bien pudieramos dejarlo con el color «Default», pero en este caso colocaré color Biz-Internet
Ahora estamos listos, nuestra template ha sufrido las siguientes modificaciones.
Nuestro enrutador pudiera estar ya instalado en las premisas del sitio remoto donde va a operar, o en camino quizá. Nosotros como administradores tenemos que enviar la tempalte de configuración, para que una vez el equipo tome IP por DHCP, se reporte con el servicio PnP y encuentre sus controladores, le sea entregada la configuración correspondiente.
Hasta acá seguimos viendo solo dos dispositivos en nuestro vManage.
Si tuvieramos acceso por consola al equipo, y vemos esto, la magia está sucediendo.
Nuestro equipo ya está aprovisionado
De aquí en adelante podemos gestionar su configuración y comportamiento remotamente, la ventaja que nos da un ZTP real.
En esta ocasión solo configuramos que el equipo se refleje en nuestro vManage, pero bien pudimos crear la configuración completa que refleje lo que hoy en día tenemos en ese sitio remoto que estamos migrando a SD-WAN.
Aquí puedes ver una breve demostración del procedimiento anterior (es un equipo distinto pero el fin es el mismo)
En esta ocasión, platicaremos brevemente cuáles son los componentes base de la arquitectura Cisco SD-WAN antes de dar paso a un análisis a fondo de cómo opera la solución.
https://youtu.be/KUhAuRZGb9w
Espero que les sea de utilidad y puedan visitar este espacio en las siguientes sesiones.
A lo largo de los años en campos como telecomunicaciones y/o redes, hemos vivido diferentes transiciones de una tecnología a otra, aunque los pilares que soportan la operación de las Redes Definidas por Software no son necesariamente nuevos, la transición hacia estos approaches ha sido gradual, en algunos países más rápida que en otros.
Las redes definidas por software permiten separar los diferentes planos (roles) que por muchos años han estado contenidos en una misma entidad o elemento de red (router, switch,etc); en lugar de tener todos estos roles dentro de la misma arquitectura, el componente queda exclusivamente a cargo del plano de datos, mientras que el plano de control puede ser virtualizado y colocado ya sea en nubes públicas o en un punto centralizado en el Centro de Datos.
¿Y por qué ha tomado tanta relevancia? Algunas de las razones son los beneficios o pilares en los que se sustenta, un punto centralizado de control y/o gestión que nos permite ganar agilidad al ejecutar diferentes tareas de configuración, monitoreo y diagnóstico de fallas; analíticos; automatización y programabilidad; entre otras cosas.
En resumen, las Redes Definidas por Software busca facilitar al staff de TI las tareas que vienen desempeñando hace tiempo y entregar al cliente final nuevos valores agregados que antes era imposible obtener o simplemente muy difícil.
