Redes on Cisco Redes

Segurança – Exploração de Protocolos Autenticação – Dicas – Parte 3

Mon, 26 Oct 2020 00:00:00 +0000

Olá Pessoal,

Como vocês vem acompanhando nossos posts sobre o detalhamento de segurança na perspectivia inicial de um ambiente WI-FI, onde inicialmente trouxe a menção sobre a captura de pacotes usando ” air-crack “, em nosso segundo post foi explicado quais os pacotes são trafegados por esse ambiente, então espero nesse post falar um pouco sobre as metodologias que podem ser agregadas a esses ambientes.

Metodologias

Vale lembrar que as características mencionadas aqui, não necessariamente são aplicadas a somente ao ambiente de WIFI ou vice-versa, pois as soluções são intercambiavéis entre elas depedendo da característica de cada aplicação/solução.

Como estamos fazendo as tratativas em relação a conectividade e captura de pacotes via WIFI, então vou mencionar os tipos de criptografia, ou seja, os protocolos de segurança disponivéis para ser configurado.

WEP ( Wired Equivalent Privacy ): O protocolo foi desenvolvido em 1999, no entanto, existem diversos problemas de segurança conhecidos no WEP, bem como é fácil de ser quebrada a chave, baseando-se no tipo de ” hash ” que é executado. O protocolo foi oficialmente abandonado em 2004 pela WI-FI Alliance.
WPA ( WI-FI Protected Access ): Ele iniciou-se justamente com a idéia de melhorar o protocolo que usava-se na época ( WEP ), ou seja, ele foi lançado 1 ano antes de o WEP ser abandonado.

Na maioria dos casos WPA utiliza-se de uma chave pré-compartilhada ( PSK -> Pre-Share Key ) que por sua vez é adicionado em conjunto com TKIP ( Temporal Key Integrity Protocol ) e AES ( Advanced Encryption Standard ).

Lembrando que esse protocolo também é muito vulnerável, e ameaça maior é feita através do WPS ( WI-FI Protected Setup )

WPA2: Como devem imaginar ele é uma evolução de seu antecessor e a principal menção foi devido a ter adicionado um ítem importante que é a utilização do AES, bem como ela havia sido liberada pelo governo americano. Mas novamente, ainda existe um risco em relação a utilização do WPS que torna-se a sua rede mais vulnerável.

Dentro desse protocolo teremos também as mesmas menções citadas acimas, onde pode ser agregado com TKIP ou AES. Sempre o recomendado é você trabalhar com AES, pois o TKIP já foi excluido do WIFI Alliance, mas infelizmente alguns hardware ainda não suportam a utilização de criptografia AES, o que acarretá a você a trabalhar ainda com o TKIP.

Isso deve-se até porque a metodologia de processamento sendo usada para o AES é maior, e por muitas situaçõe se observar o equipamento, o mesmo pode deixar seu acesso mais lento.

WPA2 Enterprise: Neste modelo como podem imaginar estará mais relacionado algumas metodologias de autenticação diferenciada, que é especificamente se autenticar através de recursos externos ( RADIUS ) associados ao seu protocolo 802.1x. A ideia ainda não é se aprofundar neste paramêtro, porém ele acaba utilizando-se do EAP e normalmente iremos visualizar mais em ambientes corporativos, pois a implementação é mais complicada e nem todos os equipamentos suportam o 802.1x, dado na equação de visualizar em ambientes residencias.
WPA3: De fato é o novo protocolo liberado pela WIFI Alliance em 2018, e atualmente o mais seguro ( a principio – rs ). Como já alertado, hoje ainda muitos equipamentos não estão preparados para esse novo protocolo, bem como os endpoints para aceitar essa metodoliga de criptografia, mas acredito que mais 2 anos todos já vão estar utilizando esse protocolo.

Basicamente a ideia dele é proteger do famoso ataque de dicionário implementando a inovação sobre a troca de chaves. No WPA2 como vimos no post anterior utilizava-se de 4 vias entre o cliente e o AP para autenticar ( 4-way handshake authentication ), onde no WPA3 as senhas são mais difíceis de quebrar, pois o invasor precisa interagir diretamente com seu WI-FI para descobrir a senha, ficando mais doloroso o processo.

No WPA2 depois de capturado o trafego você poderia ficar executando o ataque dicionário por varios dias, semanas e meses, com isso conseguiria ver de forma clara seus dados. Entretanto, o WPA3 suporta o ” forward secrecy “, o que significa que se um atacante capturar quaisquer dados criptografados de sua máquina e depois aprender sua senha mais tarde, eles não serão capazes de decodificar os dados antigos que capturaram. Obviamente, eles só serão capazes de decodificar os dados recém-capturados, pois como mencionando acima precisa ser interagido diretamente.

Obs: Vale lembrar que baseado em todos esses modelos, de fato ainda não estamos totalmente resgardados em alguma dessas metodologias, pois as chaves podem ser capturadas, ou seja, a recomendação é sempre que use senhas fortes utilizando no mínimo 12 caracteres e sempre mesclar números, letras maiúsculas e minúscula, caracteres especiais.

Segue um dado que trafegou pela Internet, comparando a quantidade de caracteres X tempo. Infelizmente, não sei de onde veio esses dados, porém acredito que é interessante para pensar em suas metodologias de senhas.

Proteção

Após visualizar todos os protocolos acima, talvez você me pergunte estou confuso e temos muita ” sopa de letrinhas “, e de fato temos, e podem acreditar temos milhares ainda associadas a esses parâmetros.

Como podemos ter diferentes públicos lendo nosso BLOG, como usuários residencias e também de ambientes corporativos, vou tentar elencar da forma que vejo mais víavel para cada público, pois isso deve-se também sobre as questões de configurações que muita das vezes não é algo prático para o usuario final.

Residencial

Acredito que você pode observar em seu modem/router/WIFI para habilitar o protocolo nessa sequência e lembrando sempre sobre a criação da senha, pois ela é um dos principais fatores desse processo. Segue abaixo:

– WPA2+AES(PSK)
– WPA+AES(PSK)
– WPA2+TKIP(PSK)
– WPA+TKIP(PSK)
– WEP -> nunca 🙂
– Rede Aberta -> acredito que não existe a necessidade

Corporativo

Neste quesito podemos exigir um pouco mais pensando em sua infra-estrutura, bem como, pode solicitar serviços adicionais para autenticação. Segue abaixo:

– WPA2 Enterprise
– WPA2+AES(PSK)
– WPA3 ( analise para crescimento futuro )
– Rede Aberta -> Utilização de soluções NAC ( Network Access Control ), onde podemos explorar posteriormente.

Conclusão

Espero que vocês tenham gostado desses ítens adicionais, e possam ter explicado um pouco mais esses termos.

Caso você deseje mais informações sobre esses formatos, deixe seu comentário que podemos explorar mais esse conteúdo.

Agora vou deixar uma tarefa para vocês nesse post. Sobre qual tema vocês gostariam que fosse a parte 4 dessa série. Deixe sua dica que vou analisar e preparar o conteúdo.

Abs,
Rodrigo

Meraki – Analisar Gráficos Meraki Insight – Parte 3

Thu, 01 Oct 2020 00:00:00 +0000

Olá Pessoal,

De fato, já faz um tempo que trouxemos as informações relacionadas ao Meraki Insight, mas como sempre na correria acabo não conseguindo publicar todos os conteúdos ” on-time ” para vocês.

Mas, uma hora ele chega e acredito que possa ajudar todos vocês a entender um pouco a mais sobre as funcionalidades e a tecnologia. Enfim, depois demonstrar sobre as facilidades de configurações das aplicações que foram detalhadas em nosso post anterior, hoje venho aqui para explicar um pouco sobre os resultados que a solução vai nos trazer.

Detalhamento

Após mencionar sobre as diferentes formas de habilitar o serviço, digo em relação a utilização do ” Smart Threshold ” ou via os valores padrões, vamos sempre ter as segregações dos 3 componentes ( LAN, WAN, Aplicação ), com isso podemos observar através dos gráficos o que esta impactando a performance da minha aplicação.

Baseado-se nesse conceito, iremos ter as análises sendo populadas em nosso portal, e vale lembrar que as aplicações ou status de cada elemento irá ser definido com o status ” RED ” quando a performance ficar <80%.

Talvez venha a pergunta, posso alterar esse valor? Não, esse valor não pode ser alterado, ou seja, mesmo que você tenha uma aplicação WEB personalizada que irá monitorar seu servidor web, sempre irá seguir essa política.

Visualização da Organização

Neste meu caso vou observar toda minha organização, e dentro das ultimas duas horas, na qual observo apenas um alarme relacionado ao meu dropbox.

Entretanto, já temos que isso está relacionado com a aplicação, porém vamos observar todos os status na sequência.

Consolidação da LAN

Neste gráfico sempre iremos observar as caracteristicas internas de sua rede,

Como podem observar, consigo validar quantos clientes internos estão utilizando essa aplicação e se de alguma forma estão sendo impactados em relação ao serviço especificamente nesta aplicação.

Logo abaixo, podemos observar nos graficos se algo esta sendo impactado correlacionando ” GoodPut “, ” Loss “, ” Latency ” versus seu pior cliente interno.

Se observar no número ” 1 ” podemos observar sobre o meu cliente e através do número ” 2 ” poderiamos ver em relação a perca comparado o meu ” end point ” versus o serviço.

No gráfico abaixo podemos consolidar a latência e verificar quais os clientes estão utilizando essa aplicação, bem como quanto de solicitações estão sendo/foram requisitadas para este serviço.

Esses dados de fato não vão trazer a causa raiz do problema, pois podem existir outros fatores que estão impactando esses clientes, entretanto são dados que podem oferecer uma linha de raciocionio para iniciar as investigações posteriores através de outros ítens dentro de sua infra-estrutura, como se conectado ao WIFI qual seria o problema? Poderiamos avaliar no Wireless Health?

Consolidação da WAN

Nesses gráficos teremos a capacidade de avaliar a nossa conexão externa ( Internet ) entretanto com a visibilidade mais apurada para aplicação específica que estamos trabalhando neste momento.

Desta forma, logo abaixo como mencionado anteriormente teremos um resumo sobre componentes presentes nessa conexão e já poderíamos avaliar se temos impacto via nosso link.

Nesse caso, visualizamos que existe um período que de fato foi onde tivemos algumas oscilações relacionando ” goodput ” e ” loss “.

Abaixo verifico o que eu acho mais interessante, que é a latência, mas as questões de quais servidores de fato meu link WAN está buscando para essa aplicação, relacionando isso em perca, latência e quantidade de solicitações para os servidores na nuvem.

Obs.: Vale ressaltar que devido a estar trabalhando com o ” Smart Threshold ” esses servidores estariam relacionados a serem os mais próximos de onde estão conectado seu MX, mas sempre observe que muito serviço em cloud pode estar fazendo ” anycast ” ou dependendo da aplicação utilizando ” CDN “.

Para finalizar temos a menção resumida para todos os meus links, porém nesse caso tenho ativo um link de internet, mas se tivermos a conexão de mais circuitos podemos ter as estatisticas por link e atrelar isso também as menções sobre os recursos possiveis para atuar minha solução de SDWAN.

Consolidação da Aplicação

Enfim, chegamos no ítem relacionado aplicação que irá trazer mais valor no sentido de identificar os domínios e IPs que podem estar impactando em usa performance.

Logo abaixo, visualizo os gráficos que por sua vez vão definir qual é o tempo de resposta que estou tendo entre o MX e aplicação que esta hospedada na nuvem.

Nessa linha do tempo, consigo avaliar especificamente o tempo/latência dedicado para este período e validar com o impacto observado ou reclamação recebida através de seu usuário.

Logo abaixo a relação dos IPs que estão hospedando esse serviço, onde acabei deixando um filtro relacionado com a quantidade de solicitação.

Desta forma, podemos comparar rapidamente através da resolução desse endereço ( FQDN ) que temos o ponto em comum com o endereço IP versus a resolução do nome e a partir desse momento temos a confirmação que o impactante ou a baixa performance está relacionado a este serviço.

Conclusão

Podemos observar que de fato temos muito mais dados para trabalhar nos eventos de baixa performance, para assim comparar com nossa linha de base.

Porém, vale ressaltar que a partir do momento que você avaliou que sua aplicação está com baixa performance o troubleshooting juntamente como o provedor do serviço pode ser mais doloroso.

Entretanto, você terá muito mais dado para concretizar do problema que você esta enfrentando e assim encurtar o caminho, pois terá informações especificas do dominio, IPs, periodo, etc.

Em nosso próximo post vou configurar uma aplicação que de fato ainda não existe no portal especificamente e assim posso responder talvez mais um questionamento sobre esse ponto para vocês.

Fique ligado e deixe seu comentário para avaliar o que vocês estão achando dessas informações.

Abs,
Rodrigo

Segurança – Analise de WIFI – Entendimento via Air-Crack

Mon, 03 Aug 2020 00:00:00 +0000

Olá Pessoal,

Como vocês sabem nosso BLOG acaba tendo uma diversidade de conteúdo e nem sempre seguimos uma linha, adicionando apenas conteúdo específico daquela tecnologia ou dedicado aquele fabricante.

Meu objetivo aqui é sempre compartilhar um pouco daquilo que eu estudo, aprendo, bem como ítens que preciso pesquisar e obviamente aprender, pois como sabem também leciono. Devido a isso, sempre precisamos encontrar maneiras para explicar conteúdo específicos ou até de criar laboratórios para explicar determinado funcionamento dentro de nosso ambiente.

Desta forma, hoje iremos ter um conteúdo totalmente diferente que é explicar um pouco sobre Wireless, utilizando algumas análises de ferramentas que ouviamos falar bastante em nosso meio. As ferramentas mencionadas, podem ser utilizadas para critérios de avaliação de segurança em sua infra, ou pode ser utilizada por pessoas mal-intecionadas para usufruir desse descuidado dos usuários em ambientes compartilhados.

Vale lembrar!!! O que iremos detalhar tem a intenção disseminar ítens para conhecimento no âmbito para entendimento do funcionamento da tecnologia, e correção de falhas para seu ambiente. Todo ato mal intencionado é por conta e risco de cada usuario e não temos nenhuma responsabilidade.

Para conhecimento a ferramenta que iremos utilizar será AirCrack-ng.

Talvez muito de vocês vão perguntar. Porque você não fez isso usando o Kali Linux? Porquê precisamos usar uma ferramenta de PenTest para aprender?

A ideia aqui é explorar os caminhos, pois essas bibliotecas não são exclusivas da distribuição Kali Linux, e sim pode ser instalada qualquer distribuição ( inclusive Windows ). Não necessariamente é uma ferramenta de pentest, mas sim algo que você possa entender o que de fato está ocorrendo em sua conectividade WIFI.

Instalação

Neste exemplo, vou executar a instalação “default” dos pacotes através disponibilização feita pela distribuição instalada na máquina virtual (XUBUNTU-18.04). Desta forma segue abaixo:

Podemos observar a versão instalada:

root@ubuntu:/home/rodrigo# aircrack-ng --help

Aircrack-ng 1.2 rc4 - (C) 2006-2015 Thomas d'Otreppe
http://www.aircrack-ng.org

usage: aircrack-ng [options] <.cap / .ivs file(s)>

Obviamente a melhor forma seria adicionar o repositório, porém algumas pessoas não gostam devido a não ter homologação da distribuição em seus respositórios. Entretanto, para que você possa sempre obter a última atualização do código, pode ser executado conforme abaixo. Caso tenha interesse de ler mais sobre esse desenvolvimento, recomendo olhar a documentação.

$curl -s https://packagecloud.io/install/repositories/aircrack-ng/git/script.deb.sh | sudo bash

root@ubuntu:/home/rodrigo# aircrack-ng --help

Aircrack-ng 1.6 rev cd77600 - (C) 2006-2020 Thomas d'Otreppe
https://www.aircrack-ng.org

usage: aircrack-ng [options] <input file(s)>

Funcionalidades

Após consolidação da instalação podemos observar algumas formas de avaliar os comandos disponivéis através dessa biblioteca, e para nosso exemplo iremos utilizar:

airmon-ng: Processo para consolidação sobre se nossa porta ( conectividade ) WIFI irá monitorar o tráfego, ou seja, trazer a concepção de que estou trabalhando em ” Monitor Mode ” ou ” Managed Mode “.
airodump-ng: Processo para capturar os pacotes que estão sendo escutados pela sua conectividade WIFI, em modo de ” Monitor Mode “.
aireplay-ng: Processo para gerar tráfego na rede, tendo o propósito de capturar pacotes de “deauthentication” para usufruir deles com intenção da visualização dos pacotes.
aircrack-ng: Processo para executar “brute-force” nos dados capturados e avaliar a segurança da conectividade.

Inicialização dos comandos

Para que você consiga monitorar através de sua conexão WIFI, já mencionado acima terá que iniciar sua placa ou USB em modo ” Monitor “, para validar é interessante executar as validações:

$ sudo airmon-ng check

Caso seja necessário você pode matar o processo para iniciar em modo monitor

$ sudo airmon-ng check kill

Consolidar iniciando

$ ip a ( para capturar o nome definido da placa )

$ sudo airmon-ng start wlan0

A nomenclatura wlan0 pode modificar validando o que de fato o seu SO ( Sistema Operacional ) identificou para essa conectividade WIFI. Baseado em seu output, você precisa nesse momento fazer a referência conforme evidenciado, na qual em meu caso ele definiu para **wlan0mon**

PS.: Pode ser que seu USB não suporte a menção para atuar como “monitor”, portanto terá que avaliar um novo dispositivo ou pesquisar sobre o device.

Capturar os BSSID co-relacionado com os APs próximos, e mapear o nome do SSID.

$ sudo airodump-ng wlan0mon

Para que possamos acelerar o processo de captura podemos forçar a DE-AUTH dos endpoints, mas faça com cautela pois isso pode impactar a rede e também existe a forma de captura de seu MAC-Address.

$ sudo aireplay-ng --deauth 1000 -a [ MAC AP Destino ] -c [ MAC Endpoint Destino ] wlan0mon --ignore-negative-one

Proximo passo é começar a capturar dados para obter o handshake entre o AP e o host ( usuario ). Observe para validar em qual canal esta operando essa comunicação.

$ sudo airodump-ng -c [ canal ] --bssid [ MAC AP Destino ] -w [ nome do arquivo salva a captura.pcap ] wlan0mon --ignore-negative-one

PS.: Depois de rodar por algum tempo devemos observar se iremos obter algo no sentido de **WPA handshake: BSSID**, ou seja, caso isso ocorra você já conseguiu obter a captura do pacote que esta contido o handshake de autenticação.

Outro lembrete que caso queira visualizar outras formas/combinações, é possivel também utilizar sempre o comando de ” help ” de cada comando para lembrar o que de fato você tem necessidade para visualizar.

E agora?

Obviamente sempre irá ter a pergunta. E agora o que faço com isso?

Na verdade temos um caminhão de informação capturada que irei explicar em outros post, pois vamos analisar através do Wireshark, mas de fato temos agora os dados e precisamos unicamente tentar fazer um ” brute-force “. Mas para isso existe milhões de opções para esse caso, e os mais tradicionais são as ” Word Lists “.

A mais conhecida seria chamada de ” John the Ripper “, onde tem listas com milhões de combinações.

Você pode fazer um teste criando uma lista rapida apenas para validar e entender o funcionamento, porém novamente, não temos a intenção aqui de trazer risco para vocês, então fique claro que isso fica a critério de cada usuario.

Para efetuar brute force, segue o exemplo:

$ aircrack-ng -w Downloads/teste.txt -b [ MAC AP Destino ] pacote_capturado.pcap

Esse processo pode demorar horas ou segundos, variando em relação ao tamanho de sua ” Word List “, ou a complexidade da senha criada. Lembrete, pode ser que depois de rodar horas você ainda não consiga obter a senha, pois não existe a senha no seu arquivo de teste. 🙂

Conclusão

Neste caso apenas quis compartilhar os ítens que foi pesquisado e também para alavancar novos conteúdos em relação essa tecnologia.

Como mencionado vou trazer nos post posteriores uma explicação sobre esses pacotes capturados, como eles são trafegados em nosso ambiente e também algumas dicas de como se prevenir para melhorar sua segurança.

Espero que tenha gostado e postem seus comentários abaixo se gostaram, se é valido explorarmos esse mundo.

Abs,
Rodrigo

BLOG – Juniper – Treinamentos Free e Vouchers

Thu, 09 Jan 2020 00:00:00 +0000

Olá Pessoal,

Acabei esquecendo e quando fui verificar eu ainda não havia publicado essa informação aqui para vocês sobre os treinamentos Juniper.

Eu posso dizer para vocês que esse programa está ajudando muita gente adquirir conhecimentos básicos e de alguma forma oferecendo oportunidades para os profissionais crescerem em sua carreira, adquirindo certificação e de alguma forma agregando conteúdo técnico para sua carreira.

A Juniper já vem fazendo esse programa acredito há 2 anos ( se eu tiver errado me corrigam ), onde ela esta oferecendo treinamentos online com Voucher Free ( obtendo pontuação mínima no teste online ) para executar 5 provas. Após obter os vouchers é necessário fazer agendamento da prova através do parceiro VUE ( como da Cisco ) e executar sua prova.

As certificações Juniper deste nível, para qual eles estão oferecendo os treinamentos tem uma validade de 3 anos e segue um modelo parecido com o da Cisco. Podemos comparar esse nível de certificação dentro da pirâmide conhecida da Cisco como sendo o nível de CCNA, ou seja, certificações de entrada para qualquer carreira que você deseja seguir dentro do mundo de Juniper.

Eu já obtive duas certificações ( Cloud e Design ) neste programa, e posso atestar que funciona perfeitamento o processo, porém vale lembrar que o treinamento como a prova são feitas em Inglês. Se pensarmos dentro de nosso mundo de TI, isso não deve ser mais novidades.

Também gostaria de adicionar que não somente fazendo o treinamento você irá estar apto para executar a prova, ou seja, vai exigir um esforço para pesquisar sobre o assunto, ler documentações, fazer alguns laboratórios, etc.

Enfim, vamos logo ao que interessa, De fato de tempos em tempos vocês precisam ficar consultando se existem turmas abertas para se inscrever, mas sempre existe alguma delas na lista, portanto se isso está dentro de seu objetivo de conhecimento e crescimentos profissional/pessoal fique atento. Segue abaixo:

- Junos: https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10175
- Design:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10908
- Cloud:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10483
- Dev-Ops:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=11060
- Segurança:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=11398

Se deseja entender um pouco mais sobre as certificações e torres de tecnologia da Juniper, recomendo observar esse link.

Qualquer dúvida deixe seus comentários.

Abs,
Rodrigo

Cisco Meraki – Visualização de Log – Syslog

Mon, 29 Oct 2018 00:00:00 +0000

Olá pessoal,

Voltando a falar mais um pouco sobre Meraki, hoje venho aqui para mostrar novamente mais uma facilidade que pode ser habilitada rapidamente em seu ” Dashboard ” chamado de Syslog.

Não sei se todos já utilizaram o ” Log ” oferecido diretamente pela ferramenta, mas em algumas situações o que é demonstrado não consolida muito baseando no problema que você queira investigar, devido a ter pequenas informações sobre alguns eventos que estão ocorrendo na rede.

Desta forma, temos um protocolo que ajuda-nos não somente neste caso, mas devemos pensar em utilizar em outros casos para obter as informações mais concretas. Vocês podem perguntar, qual protocolo seria? A resposta é o Syslog.

O syslog é um protocolo padrão que trabalha na porta 514 ( TCP/UPD ), com intuito de enviar as notificações ( message logging ) para algum ponto ( destino ) e posteriormente para que você consiga analisar com maior criticidade os alarmes detectados. Devido caracteristica desse produto você pode definir para um host local dentro da sua estrutura ( mais comum ) ou até em algum serviço de cloud, entretanto você irá definir via IP esse serviço que seria o seu destino, no qual ele terá que responder através de um DNS e ao mesmo tempo não devemos esquecer-se sobre a segurança desse serviço por estar sendo carregado através de um ambiente público, ou até mesmo você pode pensar na utilização de cloud mas sendo uma privada ( IaaS ).

Existem outras explicações sobre o protocolo e seu funcionamento, entretanto não vou detalhar neste post, se vocês desejarem posso fazer um post explicando somente o Syslog, para isso deixe seu comentário que planejo o post.

Voltando ao nosso portal Meraki devemos seguir através deste menu Network Wide -> General -> Reporting para habilitar o serviço, conforme figura abaixo:

Vocês podem observar que temos vários filtros que podemos habilitar e vale lembrar que tendo esse serviço habilitado ele irá ” logar ” o inventário que está todo dentro de sua organização na portal Meraki, portanto dependendo de sua estrutura isso pode gerar uma massa muito grande de log se trabalhar com todos esses eventos.

Em nosso exemplo eu habilitei todos para demonstrar para vocês alguns tipos de alarmes, que podem ser validados abaixo:

Neste exemplo temos o inicio do meu log sendo salvo em meu servidor Syslog, posteriormente coloquei uma messagem relacionado a captura da URL que meu dispositivo estava executando e para finalizar apenas uma notificação de Wireless que está relacionado associação de meu dispositivo ao meu SSID. Vale ressaltar que isso está baseado na linha do tempo, correspondendo ao primeiro IP do device que está enviando essa messagem de Syslog.

Em nosso próximo post irei explicar sobre como habilitar o SNMP e os ítens para fazer essa validação.

Espero que vocês tenham gostado da dica. 🙂

Abs,
Rodrigo

Packet Tracer Atualizado – Versão 7.2

Wed, 05 Sep 2018 00:00:00 +0000

Olá Pessoal,

Acredito que essa notícia já é um pouco antiga, pois a Cisco já havia anunciado, porém estou atrasado para atualizar em nosso BLOG devido a diversos fatores. Mas como eu brinco “ tarda mas não falha“, eu fico sempre no dever de principalmente divulgar aos alunos que necessitam dessa nova versão e por algum motivo ainda não havia obtido essa atualização.

Vocês podem observar que em nossa sessão de Arquivos eu atualizei com a nova versão do Packet Tracer 7.2, para qual está populado para Windows e Linux. Para aqueles que desejam ter o usuário para que não fique aparecendo a mensagem de problemas para salva eu recomendo ler meu post sobre “ Usuario Guest “.

Enjoy it!!! 😀

Abs,
Rodrigo

Ansible – Gerenciando erros na playbook

Wed, 04 Jul 2018 00:00:00 +0000

Olá Pessoal,

Hoje venho aqui para trazer mais um ítem para que possamos agregar em nossas implementações de Ansible, e como vocês vêem observando nós temos algumas alternativas para identificar quando houve um erro com o device, ou de alguma forma que executamos algum erro no módulo que estamos escrevendo por falta de um parâmetro, erro na digitação, caminho da pasta apresentada erronêamente, etc.

Pois bem, nós temos algumas formas de contornar esses alarmes, ou demostrar quais equipamentos estão sendo ignorados, para que possamos continuar com a execução do restante de nossa playbook. Para que possamos iniciar, gostaria primeiramente de apresentar a primeira opção que com certeza vai acontecer, é o fato de termos algum problema no preenchimento da planilha ( .csv ), que por sua vez está atrelado a falta de algum valor em alguma coluna desse arquivo.

Desta forma, para testarmos eu acabei excluindo apenas um valor relacionado à coluna do router R1 e R4, com isso podemos apresentar as metodologias para fazer essa tratativa de erros através de termos que são agregados a sua playbook. A forma que podemos trabalhar é de fato trazendo a função ” ignore_errors “, “ fail ” e ” any_errors_fatal “. Se desejar, recomendo também consultar a documentação do Ansible sobre ” Error handling “.

Abaixo vocês vão observar alteração que fiz no arquivo que popula todas as minhas variáveis do ( .csv ) e abaixo a menção sobre o “ ignore_errors ” classificado como “ yes “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  ignore_errors: yes
  tags:
    - always

Após a inserção desse recurso o que iremos fazer é executar nossa playbook e observar o comportamento na execução do código. Como esperado verifico que o status para os dois roteadores está mostrando como ” ignoring “, ou seja, ele acaba excluindo meu erro e continua execução dos meu outros roteadores, ou melhor dizendo, dos meus hosts já populados em nosso arquivo.\

Se obervamos, vamos analisar os erros posteriores da minha playbook, porque é devido as variavéis que deveriam ter sido capturadas anteriormente, porém sem o recurso de ” ignore_errors ” não vemos a mensagem de “ ignoring “, que por consequência vamos observar na finalização que temos nosso contador demostrando como “ failed=1 ” capturados nessa task ( TEMPLATE 881 ).

Então, para que também seja executado nessa task é necessario adicionar ” ignore_errors ” e agora vamos observar novamente a mensagem e automaticamente temos nosso contador “ failed ” zerado.

Caso você tenha necessidade pode-se usar o recurso de ” any_errors_fatal ” como sendo ” True “, que por sua vez, vai demonstrar o erro e popular em nosso contador.

Talvez vocês estejam pensando em que momento poderia utilizar esses métodos, ou seja, um ítem para pensarmos rápido seria em situações que nossos equipamentos populados no inventário estejam ” unreachable ” que por sua vez vai parar toda execução de sua playbook.

Outro ponto interessante, para que possamos armazenar os logs das execuções de nossa playbook, seria habilitar dentro do arquivo ” ansible.cfg ” um caminho para nossos logs, pois em algumas circunstâncias não vamos estar sempre presentes para analisar naquele momento o erro que ocorreu, ou seja, você vai observar os futuros problemas através desse arquivo.

Para isso devemos editar nosso arquivo e adicionar o caminho através do “ log_path ” conforme pode observar abaixo:

Após isso podemos consultar nosso arquivo populado em nosso diretorio e todas as informações salvas baseado em um timestamp.

Obs.: Nesse parâmetro precisamos ficar esperto com o tamanho desse arquivo se for uma task muito longa e com muitos hosts, bem como para ter um significado maior teríamos que popular “ verbose ” no comando ad-hoc do Ansible.

Bom pessoal, espero que tenham gostado dessas dicas e espero alguns comentários e idéias para compartilharmos.

Abs,
Rodrigo

Ansible – Script baseado na família do equipamento – parte 5

Mon, 02 Jul 2018 00:00:00 +0000

Olá Pessoal,

Já faz um tempo que não adiciono nada em relação a este tema, então vamos trazer mais opções para que vocês possam observar essas idéias e possam adaptar ou criar dentro de seus ambientes que trabalham no dia a dia.

Neste detalhamento vou atrelar aos códigos que já estavamos desenvolvendo nos posts anteriores que trazia o conceito de trabalhar com ( .csv ) e scripts Jinja2, bem como respondendo o que eu havia perguntando no post anterior de nossa série.

Pois bem, nesse primeiro momento vamos fazer a nossa tratativa para selecionar o equipamento através de uma funcionalidade básica, que por sua vez vai depender de alguns parâmetros ” ad-hoc ” no momento de execução de nossa playbook. Eu quis dizer básico, pois vamos adicionar ” tags ” que de alguma forma será identificada manualmente pela inserção do desenvolvedor do código.

Dentro do ambiente Ansible essas ” tags ” são tratadas inerente ao comando ou ação que você esta executando em sua “ task “, ou seja, essas marcações vão ser interpretadas a partir do momento que ela é definida na execução de sua ” playbook “. Portanto, se a ” tag ” estiver identificada aquela task será executada e obviamente se você estiver incluindo “ sub tasks “, “ roles ” as mesmas ações de suas “ tags ” precisam ser identificadas no ambiente. Essa é uma maneira mais rápida e prática identificar as ações que devem ser executadas em sua playbook, porém dependendo de sua demanda outros caminhos e soluções precisam ser analisadas. Para maiores detalhes recomendo observar documentação tags em Ansible.

Na versão 2.4 e 2.5 já temos algumas nomenclaturas adicionadas para que você consiga anexar em sua lógica de execução, e assim facilitar em algumas metodologias. Nesses parâmetros podemos definir ” always “, ” tagged “, “ untagged ” e ” never “. Outro ponto que podemos declarar em algumas situações é através do ” –skip-tags “, na qual eu reforço aqui, que devemos usar através de comandos ” ad-hoc “, como já explicado nesse post sobre esse recurso.

Com isso mapeado, nesse caso vou trazer um exemplo para que possamos gerar scripts distintos para uma plataforma Cisco 881 e outra plataforma Cisco 1941. Venho ressaltar que no script do 1941 estou apenas anexando o nome do router para validação e declarando para identificar que de fato rodamos o template correto via automação. PS.: Esse script não tem muito sentido olhando na visão de router, mas vou testar a lógica.

Primeiramente analisando meu código eu tenho tasks que precisam ser executadas independentemente da plataforma, ou seja, estou utilizando a tag ” always “.

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml
    tags:
      - always

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined
    tags:
      - always

  - name: EXECUTE JINJA2
    include_role:
      name: script_jinja2
    tags:
      - always

Como mencionando preciso adicionar nas minhas “ roles ” que também precisam identicar em que situação iremos rodas essas tarefas. Neste meu caso popular as varíaveis são essenciais, portanto vamos também adicionar a tag ” always “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  tags:
    - always

Enfim, chegamos no ponto onde vou definir minhas variaveis distintas e obviamente meu template ” script ” distinto. Nesse caso eu criei um arquivo adicional chamado de ” script_1941.j2 ” para emular minha plataforma e avaliar se estou populando corretamente via “ tags “. Após esse detalhamento adicionei mais uma tarefa para separar essas demandas.

---
- name: TEMPLATE 881
  template:
    src: ./template/script.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router881

- name: TEMPLATE 1941
  template:
    src: ./template/script_1941.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router1941

Agora podemos executar e analisar quais templates estão sendo gerados utilizando via comando ” ad-hoc “. Para isso vamos seguir desta forma chamando como –tags “router1941” .

Agora vamos observar a criação dos templates com suas caracteristicas dessa seleção de “ tag “.

Quando usado por exemplo um –skip-tags “router1941” você pode observar que rodamos outra “ tag “, portanto excluindo toda tarefa relacionada a essa demanda. Se pensarmos, podemos também utilizar a tag ” router881 ” que terá a mesma execução.

Enfim, mais uma vez podemos verificar a diversidade que podemos atender baseando em sua demanda. Em nosso próximo post essa escolha será automatica na qual irei validar no router real que plataforma estamos trabalhando e após isso farei a entrega do template correto ao equipamento. Reforçando que esse códigos estão todos disponivéis no meu Github.

Espero que vocês tenham gostado e falta apenas provar para vocês a questão levantada no post anterior sobre as validações de erros. 😉

Abs,
Rodrigo

Ansible – Loop com Validação de Variáveis – Parte 4

Thu, 26 Apr 2018 00:00:00 +0000

Olá Pessoal,

Esse post acabou surgindo depois de discussões em nosso foruns, mais especificamente no Telegram, onde eu já havia feito essa alteração mas acabei não detalhando em nosso BLOG, sobre essa possível alteração e de que forma poderia ser feito dentro de nossa estrutura de playbook para o Ansible.

Como já mencionado em nossos posts, inúmeras ideias podem surgir baseado na necessidade de seu ambiente e lógicas para cada tipo de configuração, portanto explorar as ideias são sempre bem vindas. Enfim, o que gostaria de agregar aqui nesse post seria sobre uma hipótese de precisarmos fazer uma validação de algum ID de loopback para que possamos amarrar a nossa base externa.

Pensando nesse item e respondendo ao questionamento, é possivel. Com isso iremos fazer atualização em nosso arquivo de teste ( .csv ) definindo variáveis ( x e y ) para popular em nosso exemplo de amarração com loopback ID ( 12 e 13 ).

inventory_hostname,DHCP,dhcp_exclude1_start,dhcp_exclude1_end,dhcp_network,dhcp_netmask,dhcp_gateway,new_hostname,id_loopback,ip_loopback,mask_loopback,ip_loopback_x,mask_loopback_x,ip_loopback_y,mask_loopback_y
R1,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R1_floor1,10,10.10.10.1,255.255.255.255,2.2.2.2,255.255.255.255,
R2,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R2_floor1,10,10.10.10.1,255.255.255.255,3.3.3.3,255.255.255.255,5,5
R3,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R3_floor1,10,10.10.10.1,255.255.255.255,1,2,5.5.5.5,255.255.255.255
R4,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R4_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R31,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R31_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R32,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R32_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R5,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R5_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R6,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R6_floor1,10,10.10.10.1,255.255.255.255,1,1,5.5.5.5,255.255.255.255

Obs.: Vocês podem achar que estou louco

, mas na verdade estou somente jogando valores ficticios nas variaveis definidas como IP Address de loopback, para que possamos de fato validar automação, então não se espante com esses IPs.

Para comparar os IDs ( 12 e 13 ) adicionei eles em nosso arquivo ( /group_vars/all.yml ).

---
vars_from_csv: "{{ vars_dict }}"

cisco_881_l2_interfaces:
  - FastEthernet0
  - FastEthernet1
  - FastEthernet2
  - FastEthernet3

loopback_id:
  - 5
  - 6
  - 7
  - 10
  - 11
  - 12
  - 13

Com isso agora já preparei minha base ( .csv ) e minha variáveis para que agora eu possa montar minha condição obviamente dentro de meu arquivo Jinja2, usando as condições de ” if, elif e else “. Segue alteração de nosso jinja template.

!
{% for loopback in loopback_id %}
{% if loopback == 12 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_x }} {{ vars_from_csv.mask_loopback_x }}
  no shutdown
!
{% elif loopback == 13 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_y }} {{ vars_from_csv.mask_loopback_y }}
  no shutdown
!
{% else %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback }} {{ vars_from_csv.mask_loopback }}
  no shutdown
!
{% endif %}
{% endfor %}
!

Vocês podem observar que estou criando condições de se coincidir com o ID escrevo isso, caso contrario coincidir com o IDy escrevo aquilo e por fim execute isso.

Dentro desse contexto estou comparando meu ID com o valor quero propagar em meu script e obviamente exportar para meu futuro device. 😉

Agora como desafio e ideias que vocês podem adicionar em nossos comentários, vocês já imaginaram de que forma também eu poderia agregar se eu consolidar o script comparando familias de equipamentos ( 881, 1941, etc ) para após isso montar meu template? E se em meu arquivo de base externa ( .csv ) eu não tiver com uma variável preenchida o que irá acontecer? Posso remediar?

Aguardo os comentários e claro depois de nossas discussões coloco meus exemplos/ideias para esses problemas.

Abs,
Rodrigo

Ansible – Instalar SSH usando processo de automação

Thu, 21 Dec 2017 00:00:00 +0000

Olá Pessoal,

Já faz um bom tempo que não escrevo aqui no BLOG, mas tudo isso é devido outras tarefas que estão tomando também um certo tempo ( recertificação CCIE, estudos DevOps, projetos particulares, aulas, treinamentos, etc ). Enfim, hoje venho aqui trazer uma situação real que acredito que diversos leitores de nosso canal podem vivenciar em sua infra-estrutura e de alguma forma já fizeram esse questionamento quando começei aqui explicar sobre Ansible 💡 . Você pode conferir nossos posts sobre Ansible aqui.

De fato, vocês observaram que a todo momento o que implementamos usando essa ferramenta foi utilizando o processo de acesso remoto a nossos equipamentos, é claro, executando as operações necessarias via CLI. Mas qual é esse acesso remoto? **SSH.

Pois bem, se observarmos todos os módulos para Networking os acessos aos equipamentos é feito pela biblioteca ” Paramiko “, e antes da versão 2.4 do Ansible não tinhamos nenhum módulo para utilizarmos os acessos via Telnet. Devido a isso, foi criado na versão 2.4.0 um módulo para que pudessemos avaliar os equipamentos ou executar algum comando ( CLI ) pelo acesso via Telnet. Esse módulo você pode conferir através desse link ( Telnet no Ansible ).

Baseado nesses fatos, a ideia é acessar os equipamento via telnet, implementar script para habilitar o SSH, e após essa configuração toda a nossa infra-estrutura já estaria apta para utilizar-se de uma metodologia de maior segurança para acesso remoto aos equipamentos e pronto para trabalharmos com qualquer outro módulo disponível dentro da estrutura do Ansible. O que posso dizer é, mais ou menos!!!

Como estamos pensando em automação vamos pontuar os ítens para que isso seja efetivo:

Acessar o equipamento via telnet.
Verificar se o equipamento tem o ssh habilitado.
Qual a versão implementada do SSH.
Caso negativo, devemos instalar o script para acesso via SSH e importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.
Caso positivo, devemos importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.

As dificuldades encontradas com o módulo telnet do Ansible é de fato capturar alguns logs ( utilizar pipe ) e fazer as tratativas dos outputs para obter somente o necessário, então o desafio foi encontrar biblioteca para usarmos nesta demanda. Depois de avaliar diferentes caminhos/testes e pedir ajuda à grupo discussão no SLACK Networktocode ( onde indico para todos com intuito adquirir experiências com essas pessoas, e claro, de uma comunidade que de fato ajuda muito nas dúvidas e idéias para desenvolvermos nossas soluções ), verifiquei poderíamos trabalhar com a biblioteca ” ntc-ansible “, pois ela já oferece o acesso via telnet e temos diversos outputs ” show commands ” formatados JSON ” JavaScript Object Notation “, onde a comunidade executou via TextFSM, trazendo assim esse ” array ” para ficar de fato mais pratico a consulta de nossos outputs. Mas, nossa vida não é fácil, pois esse comando que é necessario em minha playbook não tinhamos pronto, porém não foi impactante devido a conseguir executar os filtros e capturar o output essencial do comando.

Para nossa estrutura de arquivos e pastas eu desenvolvi desta forma.

Vocês podem observar que temos uma estrutura de ” roles “, ” templates ” e ” output ” onde a principal pasta para corresponder a nossa playbook estaria dentro de roles, desta forma podemos fazer nossas validações ” conditionals ” na playbook e trabalhar baseado nos outputs/status para as execuções das tarefas posteriores. Nosso arquivo raiz para iniciar implementação estaria em ” ssh_config.yaml “.

---
- name: INSTALL SSH IN CISCO DEVICES
  hosts: routers-client
  gather_facts: no
  connection: local
  vars:
    template_dir: /home/rodrigo/Documents/ansible/ntc-ansible/ntc-templates/templates/

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: INCLUDE SSH ENABLE ROLE
    include_role:
      name: ensure_ssh_enabled

  - name: INCLUDE SSH KEY ON THE PATH .ssh/known_hosts
    include_role:
      name: get_ssh_key

Como podem observar a primeira validação é garantir se temos implementado o SSH, e caso negativo, iremos fazer a implementação de nosso script. Dentro da estrutura de roles podemos ter diversos arquivos denominados com o mesmo nome, porém ele sempre irá buscar o arquivo main.yaml que é a base de nossa role.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | include SSH Enabled - version 2
  register: ssh_telnet

- name: ENABLE SSH IF REQUIRED
  include_tasks: enable_ssh.yaml
  when: "ssh_telnet.results.0.response.0 != 'SSH Enabled - version 2.0'"

Para ficar mais claro vocês podem observar no debug ( via ah-hoc command ” -vvv ” ) output sendo demostrado com valor essencial para validar via condição ( when ) de qualquer coisa que seja diferente de versão 2 , então ele irá chamar nossa próxima task para implementar nosso script.

PS.: Nessa execução o valor é o mesmo comparado portando ele esta executando o ” skipping “

Em nossa próxima task temos novamente o acesso sendo executado via telnet e a implementação dos comandos necessário para subirmos o protocolo SSH, liberando assim esse equipamento para seus devidos fins.

---
- name: INSTALL SSH TEMPLATE
  ntc_config_command:
      connection: telnet
      platform: cisco_ios
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
      commands_file: "/home/rodrigo/Documents/ansible/IWAN Project/ssh_installation_by_telnet/template/ssh_configuration.txt"

Após toda essa validação e configuração ( se necessario ) nós precisamos fazer com que nosso host tenha essa chave inserida em seu arquivo de controle ( ~/.ssh/known_hosts ) para que ele não faça essa pergunta chata quando for acessar pela primeira vez seu equipamento.

Para isso, iremos ter nossa próxima role para trazer essas validações e inserções dentro do arquivo necessário. Após chamar role ” get_ssh_key ” iremos novamente ter nosso arquivo main.yaml sendo executado e nele iremos tratar as informações.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | begin ^ssh-rsa
  register: ssh_key

- name: Save output in variable related inline command
  set_fact: myvar="{{ ssh_key.results.0.response.0 }}"
  when: ssh_key is defined

- name: Replace space inside myvar
  set_fact:
    clean: "{{ myvar.replace('\n','') }}"
  when: ssh_key is defined

- name: ADD KEY INSIDE LOCALHOST OF SSH CONNECTION
  lineinfile:
    path: ~/.ssh/fake_hosts
    state: present
    line: "{{ inventory_hostname }} {{ clean }}"
    insertafter: EOF
  when: ssh_key is defined

Um dos problemas enfrentados nesse tópico foi justamente a comparação da chave existente com o fato de possívelmente eu já ter essa chave inserida em seu arquivo de hosts, portanto dependendo de sua infra-estrutura essas informações poderiam ficar duplicadas e também a cada execução ele salvar a mesma chave em seu arquivo. Para validação no arquivo temos um módulo muito interessante chamado ” lineinfile ” que de fato ele pesquisa no arquivo se temos essa informação, caso negativo, ele insere o que foi solicitado. Como dito o problema sobre a inserção toda vez que executava a playbook ficava atrelado algum espaço ( \n ) que ele tinha do output ficando interpretável para o modulo lineinfile, com isso precisou ser feito um ” replace ” desses espaços para que pudesse comparar minha variável com o arquivo.

PS.: Vocês vão observar que criei um arquivo ” fake_hosts ” justamente para que você não fique testando dentro de seu arquivo de produção e de alguma forma possa impactar aquilo que esta funcionado, portanto criei o arquivo para você validar os seus passos e analisar se esta sendo executado da maneira correta, pois no momento de rodar talvez em cima de 100, 300 devices o rollback pode ficar complicado. ( rsrs )

Vamos partir do principio que não temos nada instalado em nosso equipamento e a configuração que será implementado é conforme abaixo.

!
username ssh privilege 15 password 0 sshansible
!
ip domain-name cisco.com
!
crypto key generate rsa modulus 2048
!
ip ssh version 2
ip ssh source-interface g3
ip ssh time-out 5
!
line vty 0 4
 login local
 transport input all
!

Abaixo você pode conferir que removi toda a configuração de ssh e deletei no meu arquivo de teste para garantir que não temos nada populado.

Com isso, em nosso próximo output você poderá observar que de fato não consigo fazer nenhum acesso SSH, e após execução de nossa playbook ( capturando duas changes ) temos de fato implementado nosso script e chave inserida. O erro mencionado abaixo em meu detalhamento refere-se ao fato de eu não ter salvo nossa chave SSH no arquivo correto, devido ao que foi comentando logo acima.

Para garantir podemos acessar nosso equipamento e consolidar as informações relacionados ao script implementado, bem como, adicionei um novo usuario.

Validando nosso arquivo ” fake_hosts ” para garantir que temos a mesma chave inserida no arquivo e comparado ao nosso equipamento.\

Vale lembrar que, o foi adicionado em nosso arquivo de ” known_hosts ” é o hostname, portanto se você acessa seus equipamentos pelo nome ele terá essa menção adicionado no arquivo, porém se o DNS não resolver esse nome você terá que acessar pelo endereço IP e que nesse caso não é a mesma informação que populamos em nosso arquivo de “ known_hosts “, sendo assim ele irá questionar para adicionar sua chave.

Logo abaixo, coloco alguns exemplo para garantir o correto funcionamento, colocando hipóteses de alguns itens que podemos obter durante a implementação que diversos hosts.

Nesse caso foi removido apenas ” no ip ssh version 2 ” para que possamos implementar o script, mas não inserir chaves duplicadas em nosso arquivo.

Declaro que esse post ficou bem grande, porém quis demonstrar todas as possibilidades colocando os outputs e anuências que foram vivenciadas até o desenvolvimento dessa automação.

Espero que vocês tenham gostado e de fato ajude de alguma forma a solucionar problemas vivenciados em seu dia a dia. Fique a vontade de compartilhar esse artigo e de colocar mais sugestões ou melhorias para essa estrutura.

Esses códigos estão disponivéis também no meu Github. 😛

Abs,
Rodrigo

Packet Tracer Atualizado – Versão 7.1

Wed, 25 Oct 2017 00:00:00 +0000

](/wp-content/uploads/2016/11/Packet_tracer_Screen.png)Olá Pessoal,

Acredito que essa notícia já é antiga, porém estou atrasado para atualizar em nosso BLOG, principalmente aos alunos que necessitam dessa nova versão e por algum motivo ainda não havia obtido essa atualização.

Vocês podem observar que em nossa sessão de Arquivos eu atualizei com a nova versão do Packet Tracer 7.1, para qual está populado para Windows e Linux. Para termos como histórico segue as informações anunciadas nesta nova versão:

Correção de Bugs
Atualização das Versões do IOS nos Dispositivos (v15.4.3, 15.5.3 e 15.6.3)
Novos Dispositivos Wireless (WLC 2504 e AP 3702 Aironet)
Novos Dispositivos (Switch 3650, Router 4321)
Protocolo MQTT (Message Queue Telemetry Transport)
Suporte a SFP/SFP+
Módulo HWIC-1GE-SFP

Abs,
Rodrigo

Ansible – Rodar um Grupo de seu Inventário

Mon, 21 Aug 2017 00:00:00 +0000

Olá Pessoal,

Detalhando um pouco mais sobre nossa estrutura do Ansible, gostaria de trazer hoje algumas facilidades que podemos executar através de um recurso chamado ” Ad-Hoc commands “, onde caracteriza que podemos passar variáveis, limitar host, executar module, etc, através de nossa própria execução do playbook.

Neste exemplo, o que vou trazer de dica é que, a partir do momento que temos um lista grande hosts ( inventário ) em algum determinado momento acredito que, não queremos obter as informações de todos que estão presentes nesta lista, por isso podemos trazer limitações de quais hosts iremos executar nossas task. Como podem observar abaixo, fiz alteração em nosso arquivo de ( hosts ) adicionando mais equipamentos e trazendo grupos distintos de equipamentos ( routers e switches ). Para maiores detalhes dos comandos ad-hoc veja no site da documentação.

Vale lembrar que, em nossa simulação até o momento não temos esses equipamentos adicionais, foi mais pela questão demonstrar sobre quais os grupos, equipamentos estamos trazendo nesse post.

[routers]
R1 ansible_host=192.168.0.19
R33 ansible_host=192.168.0.21

[switches]
SW1 ansible_host=192.168.0.20

Devido a termos as segmentações de equipamentos fiz alteração em nosso arquivo abaixo, chamando na função ” hosts ” ambos os grupos, mas isso não é um ítem obrigatório, pois iremos chamar nossas funções via parâmetro na execução de nossa playbook.

---
- name: Acesso remoto aos equipamentos
  hosts: routers, switches
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Obtain commands
    include: commands_variance.yaml

Após essa alteração vamos executar nosso playbook, porém iremos adicionar um comando adicional ( –limit “routers” ), que por sua vez irá executar nossas tarefas em todos os routers definidos anteriormente. Segue em detalhe em nosso quadro azul.

Após essa menção detalho que estamos agora chamando nosso próximo grupo.

Logo abaixo faço uma pequena alteração, chamando agora especificamente um hosts que está dentro de um grupo de equipamentos, fazendo com que eu possa executar as tasks sem executar as tarefas em qualquer outro equipamentos que esteja em nossa lista de inventário.

Espero que vocês tenham gostado.

Abs,
Rodrigo

Atualização nos valores de prova da Cisco

Thu, 09 Feb 2017 00:00:00 +0000

Olá Pessoal,

Acredito que para muitos isso não será uma noticia boa, pois hoje foi anunciado pela Cisco os novos valores das provas que estão sendo cobrados a partir de hoje ( 09/02/2017 ).

Para a maioria dos ” tracks ” tivemos uma atualização em torno de U$50,00, ou seja, é mais um motivo para que todos se dediquem cada vez mais nos estudos, para que você consiga alcançar sua certificação em sua primeira tentativa, com isso seu ” bolso ” não sofrerá tanto impacto.

Como evidência para que vocês vejam:


Certification	Preço antigo ( U$ )	Preço Novo ( U$ )
CCNA R&S	295,00	325,00
CCNA Security	250,00	300,00
CCNP	250,00	300,00
CCIE Written	400,00	450,00

Para consulta de outras certificações verifique no site da VUE – Certificação Cisco.

Dentro desse parâmetro vocês imaginavam que os valores iriam subir? O que acharam desse aumento? Deixe seus comentários. 😉

Abs,
Rodrigo

Pesquisa sobre IPv6

Thu, 19 May 2016 00:00:00 +0000

Olá Pessoal,

Conversando com diversas pessoas, percebo que a ideia sobre IPv6 ainda é grande misterio, na qual todos ainda tem muitas dúvidas sobre como esse assunto vai efetivamente progredir e se temos a propria necessidade de ter essas implementações em ambientes de LAN e consequentemente em WAN.

Resolvi fazer uma pesquisa para capturarmos essas informações e posteriomente trabalhar elas de uma forma para ir guiando o que é a real necessidade. É um questionario simples na qual você não irá gastar mais de 5 minutos, depois com essas informações vou postar os resultados e desta forma vamos trabalhar para divulgar mais informações especificas. Segue o form abaixo:

Loading…

Nesse projeto pretendemos caminhar juntos com um amigo que está iniciando seu BLOG que será dedicado a IPv6. No momento seu site esta em construção, mas segue o link.

Abs,
Rodrigo

Senac – Road Show TI 2016

Mon, 02 May 2016 00:00:00 +0000

Olá Pessoal,

Todo ano o Senac promove um road show entre as unidades participantes deste evento, onde cada cidade acaba abordando algum conteúdo para explanar durante os dias propostos. Neste ano a unidade de Campinas irá ter palestras sobre Fotografia, Adobe, Animação Gráfica e Redes ( Cisco ).

Para esse último tópico eu estarei presente para palestrar falando sobre ” Carreiras e Certificações Cisco “. No segundo dia criamos uma abordagem diferente, onde exclusivamente faremos um workshop com demonstração prática em nossos laboratórios, fazendo assim com que as pessoas vejam como de fato funcionam as coisas e que também isso seja um ” pontapé ” inicial para futuros profissionais certificados dentro de nosso mercado de trabalho.

Para participar desse evento é obrigatório o cadastro através do link, para que sua vaga seja garantida. Não fique fora dessa, venha participar!!!

Abs,
Rodrigo

Telegram – Grupo Cisco Redes

Mon, 02 May 2016 00:00:00 +0000

Olá Pessoal,

Conforme mencionando anteriormente, estamos trazendo cada vez mais novidades para nosso BLOG e estava trabalhando para que cada vez mais a facilidade de divulgação de informação e a interação com o comunidade seja cada vez mais prática, onde possamos nos aproveitar das tecnologias que nos rodeia, desta forma venho aqui falar um pouco sobre o Telegram ( isso concorrente do What’s up).

Essa ferramenta consegue nos oferecer algumas facilidades de interação e integração com outras tecnologias, onde a forma de propagação desse meio seja muitas vezes de forma mais efetiva, ou seja, sempre caindo nas questões de mobilidade. Esse app é dedicado para plataforma mobile, onde até o presente momento não teremos nenhuma interação via web-browser, e vale ressaltar é um app ” free “.

Nos aqui do BLOG temos um canal criado no Telegram, que através dele podemos nos comunicar rapidamente dentro de nossa comunidade, bem como receber as ultimas atualizações que são postadas em nosso BLOG.

Nosso canal de criação é visulizado através desse link, entretanto para que você faça parte dessa comunidade você precisa instalar o app em seu mobile, fazer a pesquisa por ciscoredes, e associar ou nosso canal @ciscoredes.

Aproveitando oportunidade devido alguns problemas judiciais ( não vamos entrar na questão ) sobre o What’s Up, essa ferramenta é muito grandioso, onde oferece diversos recursos adicionais onde não temos implementado em seu concorrente.

Entre para nosso canal e vamos desfrutar desse meio de comunicação.

Abs,
Rodrigo

SLACK – Forum

Wed, 27 Apr 2016 00:00:00 +0000

Olá Pessoal,

Anteriormente nos estavamos utilizando nosso Forum atraves do phpbb3, entretanto como vocês viram em meu post anterior tive alguns problemas e como havia trazido essa nova ferramenta já anunciada em nossa fan page, gostaria novamente agora de mencionar em nosso BLOG sobre o SLACK.

A idéia é utilizar ela para que possamos discutir juntos, assim sendo como um grupo por sala, onde todos podem ir acompanhando os debates e conforme a necessidade de assuntos vou criando novas salas para segmentarmos o conteúdo.

Essa ferramenta é possivel utilizar também nos aparelhos móveis ( Android e iOS ), sendo assim podemos atender dentro das necessidades de mobilidade para acesso e discussão.

Segue uma tela via desktop e via Android:

Para acessar a ferramenta acesse através do link SLACK ou através de nosso widget.

Abs,
Rodrigo

Cisco Live Magazine – Edição 18 – 2016

Mon, 25 Apr 2016 00:00:00 +0000

Olá Pessoal,

Segue mais uma edição da revista Cisco Live, na qual temos tópicos para falar sobre Big Data, estudos sobre crescimento da rede móvel, etc.

Veja os principais tópicos:

» ESPECIAL EDUCAÇÃO: O processo e os primeiros resultados da digitalização do ensino e da infraestrutura de serviços em escolas, universidades e institutos de pesquisas.

» A REINVENÇÃO DA TELEFONIA MÓVEL: Telcos encontram na virtualização das redes uma alternativa para garantir os investimentos.

» CAMINHO SEM VOLTA: Evento internacional mostra que varejo já se convenceu da importância de ter o Big Data e o Analytics como aliados.

Segue abaixo a edição completa da revista.

Abs,
Rodrigo