Automação on Cisco Redes

BLOG – Resumo DevNet Create 2020 – Informações

Tue, 13 Oct 2020 00:00:00 +0000

Olá Pessoal,

Como todos sabem hoje ocorreu o DevNet Create 2020, onde tivemos diversas palestras atendendo as 3 regiões com seus horários distintos e com conteúdo diferenciados, para que de alguma forma pudesse atender os diferentes públicos ( iniciantes à experts ).

Baseado nesses tópicos gostaria de compartilhar algumas informações que foram capturadas durante o evento. Como em todo evento o Keynote sempre traz os principais peers dentro daquele contexto, como ocorreu nos anos anteriores temos também a participação do CEO ( Chuck Robbins ) junto com SVP and GM of Devnet ( Susie Wee ).

Informações

Diversas informações e novidades foram compartilhadas no Keynote, devido a isso resolvi condensar nesse post para ajudar à todos com esses caminhos e possibilidades.

Nesta perspectiva temos diversos Laboratórios adicionais que estão populados no portal, na qual iremos ter mais possiblidades para fazer praticas e utilizar cada vez mais a estrutura de Sandbox. Isso atender para diferentes áreas e sabores, como abaixo:

Após isso temos 3 torres que foram mencionados especificamente, onde cada um pode seguir para avaliar e obviamente agregar os tópicos para cada certificação. Segue as informações:

1. Labs SDWAN: developer.cisco.com/sdwan

Labs Security: developer.cisco.com/security

Labs Datacenter NXOS: developer.cisco.com/nexusapi

Certificações e Estudos

Temos também um resumo sobre todas as certificações e suas respectivas torres de tecnologias relacionadas para cada certificação, e podemos dizer que temos um longo trabalho e muitos estudos que podemos seguir. Isso de fato não é novidades para nós, mas sabemos que sempre precisamos estar se atualizando a cada dia. Sempre gosto de reforçar que de fato você não precisa ser um programador nativo, mas precisa ter alguns caminhos para criar suas facilidades e integrações que podem facilitar em seu dia a dia. Segue abaixo a informação resumida:

Uma outra nova notificação apresentada, esta relacionado com a capacitação dedicada a times ou parceiros queiram obter treinamentos mais direcionados, sendo ofertados pelo DevNet. Esse programa esta relacionado ao DevNet Automation Bootcamp ( cs.co/AutomationBootcamp ) onde é preenchido um formulário baseado em seu interessse. Segue a informação abaixo, bem como um link para obter mais informações ( https://developer.cisco.com/automation-bootcamp/ )

Um outro programa que vai atrelar seria o “ Class of 2020 “, onde esta relacionado a grupos de estudos para obter maiores conhecimentos, obviamente impulsionar seus estudos para suas certificações. Segue o link ( https://developer.cisco.com/classof2020/ )

Desconto nas Certificações

Agora uma das informações publicadas e podem ajudar você, onde já está estudando para sua certificação DevNet e tem planejamento para executar nos próximos meses será fantástico, pois terá um desconto de 25% no agendamento de sua prova. Porém, preste atenção, pois precisa fazer o registro entre o dia 13 à 23, onde o desconto aplicada para quem executar o exame de 26 de Outubro à 6 de Novembro de 2020.

Vale lembrar, que os exames ainda podem ser executados remotamente e todos eles são agendados através do Parceiro VUE. Para isso você deve acessar o website do DevNet ( cs.co/create2020offer ).

Comunidade DevNet

Para finalizar foi apresentado alguns números relacionados a comunidade e ao crescimento.

Conclusão

Enfim, tentei resumir um pouco das informações que capturei neste dia, obviamente mais informações estão sendo populadas no website e outros caminhos para execução desses laboratório, estudos, aprendizagem, etc.

Se você tem mais informações e gostaria de divulgar deixe seu comentário.

Abs,
Rodrigo

BLOG – DevNet Create 2020 – Participe!!

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

Olá Pessoal,

Não sei se todos me seguem em alguma de nossas mídias, entretanto acredito que vale a pena reforçar em um post para que todos possa saber e obviamente participar.

No dia 13 de Outubro inicia-se o DevNet Create, que terá sua cobertura sendo atendida em suas 3 regiões com horários distintos de término, isso deve-se com o intuito de atender de forma mais ampla cada indivíduo espalhando pelo mundo. 🙂

Gostaria também divulgar um video que gravei junto com a Silvia Spiva – Engagement Leader Devnet, para atingir essa fatia brasileira e trazer cada vez mais Engenheiros, Programadores e Exploradores para esse mundo, que hoje tem a intenção de agregar entre áreas de desenvolvimento, automação de redes, segurança, colaboração, etc.

Antes que vocês fiquem preocupados ou imaginem que virei um programador, isso de fato é mentira a ideia é que consigamos fazer algum processo automatizado para nosso dia a dia, entretanto não existe a necessidade de você ser um programador nativo.

Segue a chamada que gravei para publicar o evento e incentivar nossas comunidades, bem como para pensar nesses caminhos.

Agenda

Teremos 4 canais que estarão acontecendo ao mesmo tempo, e dentro deles você pode verificar qual apresentação se encaixa mais em seu perfil. Esses canais estão divididos entre:

DevNet Create\
Creators\
APIs in Action\
Start Now

Após isso, você pode adicionar em sua agenda e participar de cada um em seu respectivo horário. Eu estarei acompanhando mais agenda da região AMER que está relacionado ao timezone PDT, e que na minha situação se enquadra melhor.

Inscrição

Como todos já puderam observar esse ano o evento será online e FREE, o que acaba dando uma oportunidade ainda maior à todos participarem de sua própria casa em seu conforto, sem ter um gasto adicional.

Para isso recomendo fazer o cadastro do DevNet Create 2020 o quanto antes e já verificar sua agenda.

Espero todos lá!

Abraços,
Rodrigo

BLOG – IP Fabric – Gerar Relatório – parte 7

Mon, 11 May 2020 00:00:00 +0000

Olá Pessoal,

Após algum tempo venho trazer mais informações sobre nossa ferramenta de gerência e inventário que venho detalhando para vocês. Em nosso último post trouxe detalhes sobre a nova atualização que temos para trabalhar com as famosas API da Meraki.

Como podem ter observado em nosso título, hoje venho trazer outro ítem que achei bem interessante, pois de alguma forma já temos algo automatizado que podemos entregar em questões de segundos para um nível superior dentro de nossas organização, bem como para outras áreas que tenham interesse para identificar o que de fato temos em nossa rede, bem como alguns problemas que estão sendo evidenciados.

Como gerar os relatórios

A melhor forma demonstrar isso são através de relatório, no qual você vai trazer algo bonito e detalhado, agregado aos números. Pensando desta forma, vamos seguir para demonstrar como obter esse relatório.

Inicialmente precisamos observar em Report -> Network Analysis Report

Após esse procedimento você já pode observar todos os relatórios disponíveis para fazer download. Lembrando que esses relatórios de fato vão estar relacionado com o discovery que você executou em sua infra-estrutura, bem como atrelado com os ” database “ associados a sua base.

Após esse procedimento já podemos observar que nosso documento já estará disponível para utilizarmos.

Agora capturei algumas telas desse relatório apenas para você verificar alguns dados que de fato estão sendo importados para esse documento, e o que você terá para apresentar para seu chefe.

Uma base de dados sobre a quantidade de endereços que você tem em sua infra-estrutura ( Network Total, IP Address, DNS, MAC, etc )

Logo abaixo capturei um dado interessante que demonstra para você quais devices eu tenho naquele momento ” duplex mismatch “.

Neste exemplo abaixo a saúde de sua rede baseado no protocolo OSPF, bem como exportando isso para uma tabela dando uma visibilidade muito rápida onde possíveis problemas podem estar acontecendo devido ao tempo que essa sessão está operacional. Isso já pode ser números para que você possa atacar os problemas mais criticos e trabalhar em um planejamento para resolver esses problemas.

Mais uma informação relacionado a outro protocolo ( BGP ), que rapidamente já temos dados efetivos de toda a nossa infra e avaliar ” Porque temos tantas sessões Active? “, ” Será que estamos fazendo desativações corretas ou temos problemas maiores na rede? “. Enfim, alguns ítens que podemos pensar e agir de forma rápida.

Enfim, temos diversas informações adicionais no relatório que podem ser utilizada por diferentes áreas e consolidar o que de fato é relevante para ações imediatas.

Conclusão

No meu ponto de vista, por se algo muito prático e rápido para captura do relatório é muito vantajoso, pois podemos entregar algo para diferentes áreas que podem trabalhar nas identificações especificas de cada problema detectado.

Um problema que avalio é que de fato o relatorio somente é gerado em Inglês, o que pode impactar para alguns setores a nível Brasil, porém pode ser algo que poderia ser trabalhado junto ao ” vendor “, mas hoje nosso mundo de TI na maioria das vezes por padrão os documentos já devem ser entregue em Inglês.

Espero que vocês tenham gostado de mais essa dica.

Abs,
Rodrigo

BLOG – IP Fabric – Vendor API Meraki – parte 6

Wed, 15 Apr 2020 00:00:00 +0000

Olá Pessoal,

Acredito que todos vem acompanhando os posts que estou relatando sobre essa nova ferramenta que estou testando e avaliando o quanto é interessante para nossas estruturas.

Pois bem, recentemente tivemos atualização para versão 3.5, e como as solicitações estavam sendo demandadas, temos uma nova funcionalidade que é fazer mapeamento de estruturas Meraki. Ohhh!!!

Talvez vocês já estão se perguntando e pensando varios ítens:

- Porque vou utilizar outra ferramenta para inventário?
  > Eu já tenho tudo no dashboard Meraki sobre as informações de equipamento, serial number, licenças, topologia. Esse Rodrigo está doido!
- Porque ter outra ferramenta para eu cuidar, já que tenho tudo no portal Meraki?
  > Vou ter mais trabalho para ficar gerenciando meu ambiente e mais informações perdidas entre as ferramentas. Esse Rodrigo está doido!
- No portal Meraki eu consigo gerar relatório automaticamente, porque usar outra ferramenta?
  > Posso obter todos os dados automaticamente no dashboard. Esse Rodrigo está doido!
- A topologia é completa no portal Meraki?
  > Sim. Esse Rodrigo é doido!

Enfim, talvez aqui poderíamos ter mais questionamentos, e vocês podem ainda estar viajando em outros tópicos. Porém, se você já leu os outros posts e você acredita que posso ainda trazer valor para suas idéias, não me deixe sozinho, acompanhe comigo meu raciocínio.

Configuração API

Para que possamos trabalhar com essa funcionalidade no IP Fabric, é necessario que executamos todo o procedimento através de APIs, ou seja, nossa ferramenta vai buscar todas as informações através das APIs já divulgadas pela Meraki.

Portanto, recomendo vocês pesquisarem em nosso BLOG os posts de Meraki ( temos vários..rsrs ), porém o mais importante para esse momento seria ” Facilidades Através de APIs – Meraki ” que obrigatoriamente você precisa ter esses dados para inserir em nossa ferramenta de gerência – IP Fabric.

Para isso outro dado importante é que você atualize IP Fabric para versão 3.5. Se tiver dúvidas como executar, recomendo ler esse post.

Pois bem, depois de ter essas validações precisamos iniciar o processo de cadastro, que deve seguir através Settings -> Advanced -> Vendors API. Confira abaixo:

Logo abaixo você pode conferir quais dados são necessários preencher para seguir nosso processo.

Como todos sabem o processo de acesso API Meraki é executado via Internet, portanto tenha consciência que sua ferramenta de gerência precisar obrigatoriamente alcançar Internet para consolidar consulta da APIs Meraki, correspodendo ao seu dashboard e organização.

Após esse processo verifique que nosso vendor foi adicionado com sucesso. 🙂

Processo Descoberta no IP Fabric

Após esse procedimento podemos executar nosso discovery e avaliar quais os dados que serão capturados. Verifique abaixo que nosso gráfico ja começou a processar as informações e obter os dados.

Como minha estrutura para teste é pequena, já observamos que meus dois equipamentos já foram populados.

Consolidação dos dados

Para isso, já posso validar o que de fato ele populou em nosso inventário relacionado ao meu MX.

Todos os equipamentos iremos observar um campo denominado ” CLI output “, que por sua vez iremos fazer o download de um arquivo conforme abaixo.

Neste documento basicamente o que teremos são as APIs que o IP Fabric consultou dentro de sua organização/equipamento para obter esse dados que foram populados. Isso acaba sendo interessante para avaliar o procedimento que esta sendo validado e as URIs ( Uniform Resource Identifier ) que estão sendo processadas.

Após esse processo fui validar algum ítem para avaliar as conectividades e acabei apenas pegando algo para filtar sobre ” LLDP ” e já podemos verificar que temos os dados mapeados de portas e suas funcionalidades.

E por último fui consolidar se poderíamos também ter um item interessante que é a validação do trafego dentro de nossa estrutura. Após popular um trace, posso observar que de fato ele traz meu trafego baseado em minha infra-estrutura, o qual eu vejo muito interesse nessa consolidação que é feita por varios dados ( MAC, ARP, Roteamento )

Conclusão

Vocês conseguiram perceber algo que podemos agregar nesse ambiente? Se sim, ufa acho que consegui transmitir a informação correta.

Se não, acredito que eu não tenha colocado as informações corretas ou de fato você caiu de paraquedas neste post, pois a utilização da ferramenta é trazer para você um ” baseline ” e após esse procedimento você tenha consolidações para executar através de diversas bases de dados e avaliar o que está ocorrendo em sua estrutura, o que foi alterado, quais problemas estão sendo vivenciados ( roteamento, mismatch portas, etc ).

Obviamente um ítem para pensar aqui, é que esse é primeiro release para trabalhar com APIs nessa ferramenta e pensando em Meraki, sinto falta pela descrição se teremos todas as validações para um ambiente SDWAN. O jeito é aguardar as proximas ” release ” ou consolidar se tem roadmaps. 🙂

E por fim vem o questionamento. O Rodrigo esta doido?

Espero que tenha gostado.

Abs,
Rodrigo

BLOG – IP Fabric – Topologia Completa Client A – parte 5

Tue, 24 Mar 2020 00:00:00 +0000

Olá Pessoal,

Depois de ter mostrado para vocês nossa estrutura relacionado a nossa ferramenta IP Fabric, hoje estamos aqui para trazer mais dados, com isso demonstrar de fato toda a topologia mapeada.

Vale lembrar que em nosso ultimo post, mostramos nossa topologia e o nosso primeiro ” discovery “ relacionado unicamente ao nosso site denominado Datacenter.

Comparativo de LOGs

Inicialmente aqui temos um comparativo que levantei apenas colocando em produção minha sessão BGP com um snapshot que não havia colocado em operação. As linhas vermelhas declaram para esse caso que no backup anterior isso não existia.

Se obtiver uma base mais antiga, que foi quando demonstrei em nosso post anterior sobre a varredura somente de nosso DC, desta forma podemos ver que não existia nada.

Para reforço as cores que estão em vermelho é de fato a estrutura que não existia e não temos nada relacionado ao protocolo, pois havia selecionado somente parte física.

Inventário

Como em todo ambiente que trabalhamos o inventário sempre é importante, pois à partir dele iremos conseguir analisar o que de fato temos na rede, com isso obter alguns dados mais interessantes.

Segue abaixo um ” snapshot “ selecionando Inventory -> Devices, após isso iremos obter diversas informações de cada equipamento que foi mapeado pela ferramenta. Desta forma temos hostname, IP Gerenciamento, Versão IOS, etc.

Obviamente você vai conseguir fazer seu inventário correto se de fato você tem esse equipamento alcançavel pela gerência e seus usuários cadastrados posso executar comandos de nível 1.

Você já pensou em obter part number automático? Se sim, neste exemplo podemos obter dados interessantes como modelos de SFP, part numbers das placas instaladas, etc.

Entretanto para nosso ambiente virtualizado alguns valores acabam sendo irrelevantes, pois não traz dados reais como se fosse um hardware físico.

E aquela situação que você vai consolidar se a porta ficou em auto/duplex forçado ou automático? Pois bem, logo abaixo você pode visualizar rapidamente e avaliar se é interessante trabalhar nestes parâmetros para fixar algum problema de mismatch, bem como se você está verificando em algum log que existe MAC duplicado, poderá fazer um filtro rápido e avaliar qual é o equipamento.

Inventário pela tecnologia

Pois bem, e agora se eu quiser pesquisar alguns equipamentos e avaliar o que de fato temos baseando-se inicialmente por VLANs dentro das estruturas de LAN e consolidar se estão ativas ou não. Verifique abaixo via Tecnology -> VLANs.

Desta forma ainda temos varias possibilidades de trabalhar relacionando a tecnologia, no sentido de avaliar de fato se podemos ter alguma adjacência de BGP em estado de alerta ( active, opensent, openconfirm, idle, connect ).

Questões sobre Roteamento

Enfim, chegamos em mais um ítem que acho bem interessante que seria trazer visibilidades sobre Topologia completa mapeada por Conectividade Física + Protocolo Layer 2 + Roteamento.

Desta forma, podemos visualizar abaixo a topologia montada e que pode ser utilizada como sua fonte de consulta para futuras consolidações e até validações de ” changes “ não documentadas em seu ambiente.

Nesta topologia você pode arrastar os equipamentos e organizar da melhor forma para verificar as conectividades e após isso salvar o desenho caso queira ter em algum repositório.

E como poderíamos consolidar qual é caminho, equipamentos, assimetria, RPF ( Reverse Path Foward ) temos em nosso ambiente? Vocês podem conferir abaixo.

Neste exemplo estou executando ” traceroute “ de um end-point para outro denominado em um site distinto, assim já podemos ver rapidamente todo o trajeto basedo em varias informações que já foram capturadas dos equipamentos. Lembrando-se que aqui está somente selecionado para checar assimetria, ou seja, as linhas verdes me declaram que eu tenho os caminhos sendo idênticos do ponto A para B e do B para A.

Conclusão

Tenho que declarar que de fato, depois que as informações foram carregadas e as bases de dados já estão populadas, essas consultas se tornam muito rápidas e concisas, pois não precisamos entrar em vários equipamentos para consolidar as informações, bem como você pode obter uma ” baseline “ da sua rede funcional e comparar com os eventos que ocorrem para identificar algumas ações.

O que vocês acharam? Gostaria de verificar alguma informação especifica? Deixe seu comentário, pois pretendo fazer um video e assim posso cobrir alguns tópicos.

Abs,
Rodrigo

BLOG – IP Fabric – Primeiro Discovery – Parte 4

Mon, 09 Mar 2020 00:00:00 +0000

Olá Pessoal,

Conforme prometido estamos aqui para seguirmos com nosso detalhamento sobre a implementação do IP Fabric. Se você não acompanhou os posts anteriores eu recomendo visualizar eles através desse link, assim você acaba entendendo todo o processo e o propósito dessa ferramenta.

Topologia

Para que todos possam entender melhor eu montei uma topologia no EVE-NG com o intuito de testar a ferramenta e avaliar quais os dados são capturados e como eles são trabalhados pela ferramenta.

Segue nossa topologia inicial.

O proposito inicial nessa topologia é tentar criar alguns protocolos e tipos de topologia diferenciado para que possamos ver o que de fato é populado para nós a partir do momento que começamos a fazer a varredura em nossa rede.

Nesse contexto temos as nomenclaturas populadas em cada ambiente, porém segue abaixo a resumo:

**– Backbone MPLS:**Contém PEs, Ps, RR todos definidos através do AS333

– Client A: Inicialmente definido um DC e posteriormente vamos crescer com tipos de sites remotos distintos, utilizando a estrutura compartilhada do backbone mencionado acima.

– Client B: Sites com conectividade ao ambiente backbone, porém apartados via VRFs distintas e com topologias inicias básicas.

Como proposito do DC ( Data Center ) foi colocar a ferramenta nesse ambiente, não é uma topologia ideal pensando que você irá monitorar um cliente diferente, porém devido a recurso (MEM, Proc nohome lab ) eu não quis colocar uma ferramenta também no Client B e também não coloquei no Backbone ( para emular como um prestador de serviço monitorando as pontas ), pois ficaria sem visualizar algo que vamos crescer para protocolos Layer 2 no DC.

Enfim, novamente como mencionando isso é uma ideia inicial e que pode crescer para avaliar, porém vale o exercicio inicial para ver se de fato vale a pena crescer. 🙂

Primeira Descoberta via IP Fabric

Para que possamos fazer nossa varredura pela ferramenta é necessário que alguns ítens iniciais sejam populados, desta forma e como já apresentado nos posts anteriores isso não é feito via SNMP e são feitos através de comandos executados em cada device.

Com isso o primeiro ponto para fazermos a tratativa e termos nosso usuário cadastrado para acesso os equipamentos. Para isso devemos verificar em Settings -> Authentication

Nesta situação podemos adicionar nossa senha e se desejar colocar na aba ( Subnets ) como sendo 0.0.0.0/0, portanto ele vai varrer todo as redes, mas isso pode deixar um pouco mais lento, ou você pode definir que esse usuario esta relacioando a subrede especifica.

Para senha de enable em algumas situações é necessário dependendo de qual vendor você está trabalhando para que de fato você possa pegar algumas informações necessárias.

Após esse procedimento podemo ir na aba de Discovery Seed e se desejar também pode inserir uma subrede ou deixar todas. Como estava consolidando apenas defini a rede do Client A

Snapshot

Após esse procedimento podemos executar nosso snapshot da rede, esperar que os dados sejam populados.

Apoś executar podemos avaliar a varredur, bem como analisar o quanto de banda deixamos habilitada para utilizarmos nessa conectividade. Logo abaixo vemos o gráfico:

Neste momento temos mais dados e logo abaixo já visualizamos os equipamentos sendo descobertos na rede, bem como a demonstração de quantos já foram populados.

Como já informado aqui posso afirmar que não temos nada de SNMP configurado.

Consultar Informações

Para um ínicio básico já podemos consultar as informações capturadas. Logo abaixo você pode verificar através de Diagrams -> Site Diagrams nossa topologia que corresponde ao DC que foi o que eu havia solicitado para ele descobrir através de nossa rede ( Seeds ).

Com isso já temos dados interessantes populados, como STP, Layer 3, Layer 2.

Após isso ainda podemos consolidar quais foram os comandos executados na CLI do equipamento, obviamente através desses comandos ele estruturou as informações para demonstrar isso através do Dashboard. Para os amantes de CLI 🙂 ( assim como eu ) é sempre válido verificar o que de fato foi feito. Segue abaixo o arquivo que você pode fazer download.

Conclusão

De fato como primeira experiência tenho que declarar que as configurações na ferramenta são simples, e os dados capturados trazem de forma clara tópicos que desejamos obter ao longo de nosso dia a dia. Como estou com ambiente virtualizado e uma topologia pequena, eu não consigo afirmar sobre o tempo de processamento para capturar em redes maiores, gigantes, porém isso conseguimos obter através de dados do fabricante.

Em nosso próximo post, iremos agora de fato popular toda a nossa topologia e observar mais afundo alguns detalhes ( MPLS, IGP, Traffic Path, etc )

Fiquem ligados e deixem seus comentários abaixo do que você esta achando de nossa serie ” Netflix “. 🙂

Abs,
Rodrigo

BLOG – Atualização do IP Fabric – Parte 3

Mon, 17 Feb 2020 00:00:00 +0000

Olá Pessoal,

Estamos aqui para mais um post e prometo que esse vocês vão ficar bem animados, pois será de grande utilidade, devido hoje qualquer ferramenta que temos em produção sempre precisamos ficar atentos com as atualizações e de que forma podemos executar isso em nosso dia a dia.

Procedimento

Em nosso procedimento inicial eu instalei a versão 3.3.3 e devido alguns testes que estava executando fui consultar empresa e de fato isso já estava sendo suportado pela nova versão que é denominada 3.4.

A partir desse momento fui validar de que forma executar, e após alguns questionamento aos engenheiros e consolidações podemos fazer de duas formas:

Desde de que tenhamos um pacote adicional para ser instalado, baseando-se em uma nova versão, o updgrade é muito simples, e de pouco impacto ao nosso ambiente de produção, pois temos apenas a necessidade de fazer o download de um único arquivo e proceder com upgrade. Vou detalhar posteriormente esse upgrade\
Caso você tenha uma versão muito antiga e não tenha o pacote adicional para instalação será necessário fazer uma nova instalação, entretanto todas a sua base de dados e informações sobre sua ” base line ” pode ser exportada, para que seja feito upload em sua nova versão.

Upgrade

Para executar o upgrade eu fiz o download do arquivo ( ipfabric-update-3_4_1.tar.gz.sig ) que será inserido para o processo de upgrade.

Para seguir com o procedimento você precisa acessar área de administrador que é feito pelo ” user / password ” definido em nossa instalação inicial.

Após logar com sua senha, nossa próxima menção é acessar a aba ” System Update “.

Normalmente sua máquina de gerência talvez não tenha acesso a Internet, devido a póliticas que você esteja seguindo dentro de sua sua empresa, ou algo de regras de FW, bem como eventos que estão ocorrendo no momento que a ferramenta está tendo alcançar a Internet. Não se preocupe, pois é nesse momento que iremos fazer o upload diretamente.

Após arrastar o arquivo que fizemos download, ele notifica para que seja feito um backup por segurança. Isso é valido também relacionado ao que foi dito no ínicio do post, pois está relacionado sobre sua base line ( estado operacional da sua infra ).

Após carregar o arquivo o processo de atualização acontece em ” background “.

Finalizado o processo, é observado uma janela de que o sistema será reiniciado.

Obs.: Neste ponto talvez, na minha opinião eu acharia interessante ter alguma menção se de fato gostaria de reiniciar agora o servidor ou postergar esse ” reboot “.

Em determinados ambientes de produção, isso pode ser negociado através de uma janela de manutenção, entretanto lembrando-se que essa ferramenta não estaria relacionada com criação de eventos ( ticket ) para a rede sobre seus devices inoperantes, desta forma, talvez essa janela para o reboot, não seja impactante em seu ambiente.

Após reinicialização do servidor, já podemos concretizar que de fato o servidor foi atualizado para a versão que havíamos descarregado ( 3.4.1 ). Segue abaixo através da CLI.

Agora fazendo a consolidação através do portal via WEB ( WEB GUI ).

Conclusão

Podemos notar que de fato atualização pode ser feita facilmente pela browser, o que torna isso muito mais prático e ao mesmo tempo oferecendo uma facilidade para algo que não necessite de um especialista.

Para quem é nativo CLI ( router, switches, etc ) vai entender do que estou falando, pois muitos de vocês já vivenciaram esse mundo e não como nosso grande piada ( Engenheiro Nutella..rsrs )

Obs.: Vale lembrar que é possível fazer atualização via CLI, porém quando existe essa facilidade acabamos nem explorando esses ítens.

Espero que vocês tenham gostado, bem como espero algum comentário abaixo, assim possamos compartilhar ideias.

Abs,
Rodrigo

BLOG – Instalação do IP Fabric – Parte 2

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

Olá Pessoal,

Como vocês podem observar iniciamos uma nova serie de posts, que irá tratar sobre uma nova ferramenta que estou explorando e como não podia ficar de fora vou compartilhar com vocês essas experiências, e de fato é o que eu acho interessante nessa trajetoria.

Como já havia explicado alguns ítens em nosso post anterior, hoje seremos mais direto apenas para demonstrar a instalação inicial, porém como já detalhado não existe muito segredo.

Passos para Instalação

Após fazer o download do arquivo ( .ova ) você pode seguir com a instalação. Lembrando que em nosso ambiente de teste eu estarei utilizando o VMware Workstation.

Inicialmente depois de você selecionar o ” import “ já terá uma opção para escolha relacionado a quantidade devices que a ferramenta irá suportar, ou seja, isso vai estar relacionado com nossa tabela exposta em nosso post anterior, que por sua vez, irá amarrar a quantidade de memoria, espaço em disco para referenciar sua VM.

Em meu homelab selecionei o máximo ( 500 devices ).

Após esse procedimento, seguimos com as consolidações padrões para instalação de nossa VM.

Após as validações anteriores a VM já possui um usuario padrão ( terminal e WEB GUI ) onde agora você irá cadastrar sua senha. Conforme abaixo:

Vale ressaltar que alguns ítens não foram expostos aqui devido a ser um homelab, portanto para instalações em ambientes de produção vale observar os requerimentos ( DNS, NTP, SSL, etc ) ou até solicitar ajuda ao fabricante.

Por fim, verficamos que recebemos um endereço IP ( no meu caso deixei como DHCP ), mas o ideal novamente é reservar um endereço, logo que, isso será sua ferramenta de gerência e não é nada viável depois ficar trocando esse endereço se você tem FW, Políticas, etc. Com isso agora você já pode acessar o IP Fabric via browser e também através do terminal. Veja abaixo:

A partir desse momento você não conseguirá seguir em frente se não obtiver a licença, portanto existe uma forma de fazer uma solicitação TRIAL, e assim desfrutar um pouco dessa ferramenta.

Abaixo segue a página inicial para que você possa inserir sua licença.

ATENÇÃO!!! Após você inserir sua licença um user default é utilizado. Para que você possa logar deve utilizar user: admin /// pwd: netHero!123

Conclusão

Como puderam observar a instalação é bem simples e não existem mistérios, portanto continue seguindo nossos posts que a brincadeira vai começar a ficar empolgante. 🙂

Se você gostaria deixar algum cometário, duvida ou seguestão fique a vontade e pode escrever abaixo que vou fazendo a tratativa.

Abs,
Rodrigo

BLOG – Ferramenta de Gerência e TSHOOT – IPFabric

Wed, 22 Jan 2020 00:00:00 +0000

Bom Dia Pessoal,

Como eu venho fazendo, ou seja, algo que aprendo ou vivencio através de algum canal, sempre gosto depois de compartilhar as experiências. Pois bem, hoje gostaria de compartilhar uma experiência e ideias sobre uma ferramenta que acabei meio que me deparando com ela por acaso.

Entretanto, tenho que confessar que já havia visto que a empresa IPFabric já estava participando do CiscoLive em 2019 e resolvi segui-los pelo Twitter, sempre observando/lendo o que de fato eles estão desenvolvendo, bem como interessado para entender o produto. Depois de um tempo a empresa começou a me seguir no Twitter e resolvi de fato me aprofundar no propósito deles sobre a facilidade de gerenciamento, automação, troubleshooting com historico de eventos, documentação facilitada, etc.

Enfim, após validações e pesquisas verifquei que existe uma forma de solicitar uma licença trial, e tive até a oportunidade de conversar via call com os engenheiros da ferramenta para entender um pouco melhor. Tendo isso, eu agora só preciso repassar isso para vocês, pois tenho que declarar que o proposito dela é muito interessante, e acredito que isso possa ajudar de alguma forma ou no seu dia a dia ou até se estiver pesquisando sobre alguma ferramenta para implementar vale a pena colocar em sua lista.

Empresa

Eles foram fundados em 2015 e hoje já mantém dois escritorios, no qual a matriz fica alocada em Praga ( Republica Checa ) e um escritório em Nova York. A equipe é pequena, onde é composto de engenheiros e programadores, isso deve-se que a ferramenta é intuitiva e muitos parâmetros são automatizados.

O objetivo deles é justamente automatizar documentação de sua rede, através de politicas e capturas de logs, comandos e com isso estruturar todas as informações.

Instalação

Baseado na demanda de mercado, a instalação da ferramenta é bem tranquila baseado que você já pode fazer o download de um arquivo ( .ova ) e disponibilizar isso dentro de seu ambiente, ou seja, diretamente no bare metal ou via uma infra virtualizada.

A documentação deles eu achei bem interessante e prática, pois até o momento daquilo que necessitei pesquisar sempre acabei encontrando de que forma fazer e como fazer. A documentação pode ser visualizada através desse link

Com isso para facilitar para vocês em minha infra ( homelab ) eu fiz o deploy baseado no VMware Workstation para um total máximo de 500 devices e toda a minha infra ( networking ) será baseado em nosso EVE-NG que inicialmente terá equipamentos Cisco e depois ao longo de meus posts vou trazer detalhes sobre Juniper e se possível quero fazer mais alguns testes com outros vendors.

Para rápida consulta você pode visualizar esse dados abaixo sobre quantidade devices x demanda recursos:


Device	CPU	RAM	HDD (OS+Data)
500	4	16 GB	90 GB (80G + 10G)
1000	4	16 GB	100 GB (80G + 20G)
2000	8	32 GB	200 GB (80G + 120G)
5000	12	64 GB	300 GB (80G + 220G)
10000	16	128 GB	550 GB (80G + 470G)
20000	18	256 GB	1000 GB (80G + 920G)

Requisitos Redes ( Devices )

Um ponto importante para eu frizar aqui, é que no inicio eu fiquei muito intrigado, pois essa ferramenta não irá coletar dados de SNMP ou Syslog. Isso foi o ponto mais interessante, pois hoje a maioria das ferramentas sempre trabalham com este intuito.

Talvez vocês me perguntem. OK, então de que forma isso é feito? Pois bem, isso é feito através de coleta de comandos, e com essa base todo o resto é processado para trazer as informações.

Outros questionamentos podem existir, acredito eu você imaginando as possibilidades e alternativas. Sim existe, como eu também pensei. Porquê?

Ela somente funciona para Cisco?
- Não. Existe uma tabela onde são mencionados quais as plataformas são suportadas. Você pode consultar nessa planilha.
SNMP ou Syslog são padrões?
- Infelizmente não, pois em muitos casos ou melhor dizendo ferramentas você precisa fazer o upload das MIBs para capturar as flags corretas de cada vendor, bem como o syslog que também precisa ser tratado e formatado para o output de cada vendor.
Como os comandos são inseridos se o vendor não é suportado?
- A equipe desenvolvimento sempre está atualizando a plataforma, bem como existem roadmaps para essas demandas que também são analisadas com o mercado e a demanda de cada cliente. Porém, posso dizer que é muito mais fácil inserir comandos ( cli ) dos vendors do que executar inserção de MIBs
Essa ferramenta seria para monitoração, ou seja, criar tickets reativos ?
- Esse não é proposito, pois ela obtêm as informações e podem capturar até os eventos baseado em ” snapshots ” que podem ser programados para você entender o que de fato ocorreu nesse evento. Em resumo, você pode pensar usando as terminologias de mercado como sendo uma ” RCA – Root Cause Analysis ” e ” Network Assurance “

Para facilitar segue abaixo um screenshot da propria documentação relacionado aos protocolos e portas que são utilizadas para termos o correto funcionamento.

Como informado anteriormente vou passar o link dos comandos executados que estão na documentação para equipamentos Cisco, e como demonstrado não existe a necessidade de configurar um usuário privilege 15 para os devices, e sim com privilege 1.

Conclusão

De fato até o momento estou gostando sobre o proposito. Em nosso próximo post, vou explicar o passo à passo da instalação e a visualização inicial do dashboard, bem como a topologia inicial que iremos trabalhar para nossos futuros post.

Qual foi sua primeira impressão sobre esse pequeno detalhamento? Você gostaria de obter mais informações sobre o funcionamento?

Deixe seus comentários que esse é o feedaback que tenho se de fato está sendo útil para vocês.

Abs,
Rodrigo

Cisco Meraki – Inicialização Ansible para primeiro playbook

Mon, 02 Dec 2019 00:00:00 +0000

Olá Pessoal,

Como todos sabem que muitas das vezes eu não consigo atualizar os conteúdos conforme eu desejaria, mas na medida do possível vou sempre atualizando nosso seguidores e comunidade sobre os tópicos que vou aprendendo e desenvolvendo para compartilhar com todos.

Enfim, depois de avançar bastante com tópicos de Meraki + Umbrella, hoje vamos continuar sobre nossos desenvolvimentos baseado em Ansible para controlar seu ambiente, bem como gerenciar as configurações de uma forma mais ágil.

Nos estavamos mencionando nos posts anteriores sobre as capturas que podemos fazer via as API através do Postman. Porém, como vamos iniciar trabalhando dentro do Ansible para chamar algumas solicitações para o Meraki, então nesse momento vou demonstrar algumas ações sendo feitas através de alguns modulos já existentes no Ansible e futuramente coloco algum caso utilizando alguma API dedicada diretamente via Ansible.

API Key para Ansible

Como todos sabemos para acesso ao Meraki precisamos utilizar nossa chave e por consequencia é necessario adicionar esses parametros para o Ansible, pois através dessa ” key ” é que teremos permissões para fazer solicitações ( GET, POST, DELETE, UPDATE ) ao ” Dashboard “.

Não devemos esquecer que o ” Control Node ” que está executando o Ansible deve ter acesso a Internet, já que o produto Meraki está hospedado em Cloud pública. Baseado nessa API Key você também precisa ficar atento que hospedar arquivo host em algum respositório ( Git ), pode expor sua chave de acesso dando permissão ” full ” a toda administração Meraki.

Usando Ansible-Vault

Como informado acima temos que usar algumas técnicas para podermos criptografar nosso arquivo que irá ter nossa ” API Key “ e consequentemente mais algumas informações, que podemos denominar como variáveis para utilização em nossa playbook.

Dentro desta estrutura temos um ítem simples e prático para executar essas ações que esta denominado como sendo função ” ansible-vault “. Como esse não é objetivo principal do post vou executar o mais simples, que é criptografar todo o meu conteúdo no arquivo ( group_vars/auth_key_mer.yml ). Caso queira visualizar mais opções visite a documentação do Ansible-Vault.

Para nosso caso estou criando um novo arquivo para preencher com as varíaveis e logo após estou populando as minhas variavéis que será usada posteriormente. Segue abaixo o exemplo:

Após criação dois ítens estou criando a encriptação do arquivo através de uma senha que estou determinado no momento que executo essa ação. Veja abaixo:

Para demonstrar estou abrindo o arquivo após a encriptação para consolidarmos que de fato esse arquivo foi codificado.

Logo após vocês poderiam perguntar. Como vou editar agora esse arquivo?

Se você observar acima eu posso editar ele normalmente utilizando minha senha, e posteriormente ele irá abrir como um arquivo texto normal, podendo ser editado e salvo da mesma forma que estavamos trabalhando anteriormente.

Vale ressaltar que se por algum motivo você esquecer essa senha, infelizmente você perdeu seu arquivo e terá que construi-ló novamente.

Lógica do Playbook

Como havia informado incialmente vamos utilizar os módulo já populados para Ansible e disponivéis para consumir, pois os proprios fabricantes já desenvolvem para ajudar nesses quesitos. Caso queira saber todos os modulos para o Meraki pode consultar nesse link.

Como feito em outras playbooks que venho utilizando no Ansible, eu criei algumas estruturas para segmentar minhas ” tasks “, e assim fazer as solicitações para ter um pouco mais controle e compreender em qual estado estou de minha playbook e interpretar em alguns momentos os erros que recebo. Segue a estrutura de pastas que criei para esse nosso primeiro exemplo:

Modulo Ansible

Para esse primeiro exemplo escolhi trabalhar com o módulo ” meraki_ssid “ para executar 3 ações que desejo fazer em meu equipamento ” MR “. Desta forma, vou criar um SSID novo, deletar esse SSID e posteriormente vou consultar ” query “ quais SSIDs estão configurados na minha organização.

Novamente, vale ressaltar que neste momento estou criando meu SSID com ítens básico, apenas para ser visualizado no portal, mas caso você queira adicionar mais configurações somente é necessário passar os paramêtros desejados.

Volte ao ínicio

Logo abaixo temos nosso código relacionado ao arquivo ( meraki_basics.yaml ) que será a playbook que irá solicitar todas as demandas baseadas nas opções que eu desejo executar na minha playbook.

---
- name: START CONFIGURATION
  hosts: localhost
  gather_facts: no

  vars_prompt:
  - name: "action_ssid"
    prompt: "Please with action would you like to do?
             ( 1 ) - Add
             ( 2 ) - Delete 
             ( 3 ) - Query"
    private: no

  - name: "ssid_name"
    prompt: "Which SSID name will be (add) or (delete) or query (all)?"
    private: no

  tasks:
  - name: DECRYPT KEYS
    include_vars: "./group_vars/auth_key_mer.yml"
    no_log: true

  - name: GET INFO OF ORG
    include_role:
      name: get_info_org
    no_log: true

  - name: GOING TO ADD SSID
    include_role:
      name: add_ssid
    when: action_ssid == '1'

  - name: GOING TO DELETE SSID
    include_role:
      name: delete_ssid
    when: action_ssid == '2'

  - name: GOING TO QUERY SSID
    include_role:
      name: query_ssid
    when: action_ssid == '3'

Feito isso, eu resolvi criar uma ” task “ dedicada para eu obter todas as informações necessárias do dashboard para que posteriormente eu possa usar qualquer varíavel dentro de outras ” task “. Com isso eu tendo a variável registrada eu consigo obter qualquer variavel pois a estrutura de saída do comando já e formatado em JSON. Segue o codigo relacionado ao arquivo ( get_info_org/tasks/main.yaml ).

---
- name: Query information about Organizations associated to the user
  meraki_organization:
   auth_key: "{{ auth_key_api }}"
   state: query
  delegate_to: localhost
  register: meraki_name
  no_log: true

- name: List all networks associated to the Organization
  meraki_network:
   auth_key: "{{ auth_key_api }}"
   state: query
   org_name: "{{ meraki_name.data[0].name }}"
  delegate_to: localhost
  register: meraki_all_net
  no_log: true

Talvez você me pergunte, porque você está usando ” no_log: true”? Isso deve-se justamente relacionados as informações que podem ser populadas através de uma funcionalidade de ” verbose “ que poderiamos usar para visualizar as informações, mas abaixo você pode detectar que nada é mostrado:

Agora se você observar a saída do comando o qual ele pode trazer, e desta forma podemos filtrar especificamente o valor desejado para sua playbook a partir do momento que estou executando a playbook com ” verbose “ e na minha task foi removido ” no_log: true “

Dando sequencia a nossa playbook iremos consolidar sobre inserção de um novo SSID. Como vocês podem observar estou fazendo a execução desta task, baseado no que o usuario responde a partir do questionamento feito no inicio da playbook, ou seja, essa ação será executada se for preenchida com o ” 1 “. Para que eu possa inserir esse SSID estou colocando o estado como ” present “, assim ele irá escrever e colocar como ” enable “ esse SSID no portal.

---
- name: Adding SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: present
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: true
  delegate_to: localhost

Logo na sequencia temos o ” delete “ que é a mesma função anterior, porém preciso colocar o estado como ” absent “ e no modo ” enable “ em falso.

---
- name: Delete-Disable SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: absent
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: false
  delegate_to: localhost

E para finalizar irei colocar uma demanda para fazer ” query “ e fazer ele consultar todos os meus SSIDs configurados, criando assim um loop para ele varrer as variaveis e trazer se de fato o SSID esta habilitado ou desabilitado.

Volte ao ínicio

---
- name: Executing Query
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: query
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
  with_items: data
  register: status
  delegate_to: localhost

- debug: 
   msg="We found the SSID {{ status.results[0].data[item].name }} in your Meraki Dashboard and enable status is {{ status.results[0].data[item].enabled }} "
  loop: 
    - 0
    - 1
    - 2
    - 3
    - 4

Teste da Playbook

Após vocês entenderem a logica de programação, chegou a hora de verificar se fato está funcionando nossa ideia dentro do portal Meraki.

Neste primeiro teste estou executando como ” ansible-playbook –ask-vault-pass meraki_basics.yaml “, onde a demanda do ” Vault “ é justamente para eu digitar minha senha e poder conseguir obter a variavel desejada que necessito para minhas próximas ações.

Logo abaixo pode observar que estou opção ” 1 “ que irá adicionar um SSID denominado como ” Ansible “.

Agora vou consultar meu portal e consolidar se de fato ele populou meu novo SSID. Confira abaixo:

BINGO!!!

Próximo passo seria deletar esse mesmo SSID e consolidar o que vemos no portal.

Podemos observar que ele já foi removido do portal e por padrão sempre quando não temos o SSID configurado ele irá aparecer como ” Unconfigured SSID x “

Para finalizar vamos consolidar todos os nossos SSIDs configurado e habilitados em nosso Dashboard, utilizando nossa função de ” Query “

Como observamos acima, imprimi todos as saídas para identificar o que temos em operação.

Depois de um longo post, chegamos ao final de mais uma ideia ou iniciativa para começar a manipular seus dados no portal Meraki via Ansible. O que vocês acharam? Vale a pena fazer um video para compartilhar os testes ou ficou bem compreendido?

O que vocês acham que poderiamos mudar nesse código ou o que vocês gostariam que eu demonstrasse para vocês?

Deixe seus comentários, pois esse BLOG é construído para todos.

Abs,
Rodrigo