La red de Angel

Anteriormente, he mostrado varios playbooks sencillos con Ansible para realizar comandos del tipo show para mostrar configuración de los routers y switches.  Ahora os mostraré como ejecutar comandos CLI en multiples dispositivos Cisco IOS con la ayuda del módulo de Ansible llamado cisco.ios.ios_config. Básicamente con este módulo lo que conseguiremos es entrar en modo de configuración global dentro de un router o un switch (lo mismo a hacer un conf t ) y luego ejecutariamos los comandos de configuración de Cisco.   Para entenderlo mejoren el siguiente ejemplo, ejecutariamos los siguientes comandos CLI: Router#conf t Router(config)# snmp-server host 192.168.1.50 version 2c <communitystring> Router(config)# snmp-server host 192.168.1.50 version 2c <communitystring> Router(config)# snmp-server host 192.168.1.50 version 2c <communitystring> Router(config)# end Router#copy run start (enter) Para hacer lo mismo en Ansible y a su vez ejecutarlo en multiples dispositivos (

Como habéis podido observar, soy muy fan de Ansible ya que es una herramienta de network automation muy fácil de aprender y no requiere saber mucho de programación en Python para poder usarlo. Sin embargo, me he dado cuenta que Ansible tiene sus limitaciones ya que cuando ejecutamos un playbook como por ejemplo cuando queremos ejecutar show ip int brief en multiples routers y switches Cisco es un proceso un tanto lento ya que realiza cada conexión SSH secuencialmente y no a la vez con lo que imaginaros que si tenemos que gestionar cientos o miles de dispositivos de red la cantidad de segundos y minutos que tendriamos que esperar para obtener el output de nuestro playbook. Para ello, existe un nueva herramienta de automatización de redes llamada Nornir que se supone que es una especie de evolución de Ansible (hay que gente que le llama Ansible 2.0) pero que está creado puramente en Python y soluciona alguno de los problemas or limitaciones de Ansible. Algunas de estas mejoras son l

1r paso. Editamos el inventory file de Ansible llamado "hosts" donde definiremos las IPs/Hosts de los Routers/Switches que queramos realizar el backup.  root@angel-pc:/etc/ansible# nano hosts [devices] 192.168.1.10 192.168.1.20 [devices:vars] ansible_python_interpreter=/usr/bin/python3 ansible_connection=network_cli ansible_network_os=ios ansible_ssh_user=usuario_ssh ansible_ssh_pass=password_ssh 2o paso. Creamos un nuevo script donde aplicaremos el siguiento código:  root@angel-pc:/etc/ansible# nano sh_run_backup.yml --- - hosts: all gather_facts: false # Ejecutamos el comando 'show run' en el dispositivo Cisco IOS tasks: - name: Backup IOS device running config cisco.ios.ios_command: commands: show run # Registramos el output del comando 'sh run' y lo guardamos en una variable llamada 'var'    register: print_output - debug: var=print_output.stdout_lines # Exportamos el output de la variable var, lo convertimos en lenguaje JS

Esta semana he experimentado un caso curioso con el protocolo RDP. Mi compañero que trabaja para el equipo de Sistemas me comentó que habian usuarios que al conectarse a un servidor en concreto mediante el protocolo RDP habian reportado que cada ciertos minutos la sessión RDP se quedaba "colgado" (o freezed ) por un par de minutos y eso frustraba mucho al usuario que no no podía trabajar. Hicimos troubleshooting intentando replicar este problema intentado conectarnos desde redes distintas y al final sacamos la siguiente conclusión: Caso 1. La conectividad RDP desde la red A hacia el servidor funcionaba bien Caso 2. La conectividad RDP desde la red B hacia el servidor funcionabal mal (como he dicho antes se quedaba colgado cada X tiempo) Que diferencia habia entre estas dos situaciones? En el caso 1 , permitiamos el trafico RDP (TCP/3389) desde la red A hacia el servidor. En el caso 2 permitiamos todo el trafico (todos los puertos TCP/UDP del 1 al 65535) desde la red B