Tutorial on Cisco Redes

Segurança – Entendimento dos Pacotes na Rede WIFI – Parte 2

Wed, 26 Aug 2020 00:00:00 +0000

Olá Pessoal,

Estamos de volta para detalhar um pouco mais sobre o processo iniciado em nosso post anterior, relacionado sobre o ambiente de WIFI. Entretanto, a idéia agora seria explicar sobre os pacotes que viajam pelo nosso meio, bem como interpretar de forma clara a funcionalidade de cada processo.

Vale lembrar que todos esses dados exemplificados abaixo foram capturados através de um processo de monitoração ( escuta do ambiente ), ou seja, esses dados não são visiveis quando você já esta conectado em seu SSID.

Caso você queira visualizar os pacotes reais de trafego ( http, ftp, etc ), você irá seguir o processo idêntico quando você executa seu sniffer em uma rede cabeada, porém selecionando agora apenas sua interface WIFI. 🙂

Autenticação

A autenticação é o processo de comprovação da identidade de uma estação para outra estação ou AP. Em um sistema sem autenticação do usuário ( sistema aberto ), todas as estações são autenticadas sem qualquer verificação.

Como exemplo temos a estação ” A ” envia um quadro de gerenciamento de autenticação que contém a identidade de ” A “, para a estação ” B “. A estação ” B ” responde com um quadro que indica o reconhecimento ( ACK ), endereçado a A.

Na arquitetura de rede fechada, as estações devem conhecer o SSID do AP a fim de se conectarem ao AP, onde pode ser conhecido como ” Hidden SSID “, ou também podemos ter o exemplo de que o SSID pode ser visível para qualquer dispositvo ” BSSID “. A autenticação da chave compartilhada usa um desafio e uma resposta padrão juntamente com uma chave secreta compartilhada.

Logo abaixo, podemos observar os estágios sobre esse processo, lembrando-se que você estar autenticado não é significado que você esta associado ao seu AP. Outra menção, que nesta figura também iremos observar sobre ” Association “

Para que possamos comprovar, logo abaixo temos a captura do pacote para visualizar o que temos em cada cabeçalho no momento de ” Autenticação “. Eu removi alguns ítens para que não fique confuso, entretanto você também vão observar nessa captura que temos a visualização do QoS para essa conectividade.

Associação

Os dados podem ser trocados entre a estação e o AP somente após uma estação ser associada a um AP ( Modo Tradicional ) ou com outra estação no modo ” ad hoc “. Todos os APs transmitem frames ” Beacon ” algumas vezes por segundo que contêm o SSID, tempo, capacidades, taxas suportadas, bem como as estações podem optar por associar-se a um AP em relação a sua intensidade de sinal de cada AP, etc.

A associação é um processo de duas etapas. Uma estação que atualmente não está autenticada e não associada escuta os frames ” Beacon “. A estação seleciona um BSS para se associar, após isso a estação e o AP se autenticam mutuamente, trocando as estruturas de gerenciamento de autenticação. O cliente agora está autenticado, mas não associado.

Na segunda etapa, a estação envia um quadro de Pedido de Associação, ao qual o AP responde com um quadro de Resposta de Associação que inclui um ID de Associação para a estação. A estação é agora autenticada e associada.

Para exemplificar podemos visualizar abaixo o estado de solicitação, na qual o esta sendo solicitado especificamente para um SSID ” ap34b “, e logo abaixo também já podemos visualizar sobre a capacidades de largura de banda pode suportar.

Como exposto, temos agora a nossa resposta a nossa solicitação.

PS.: Uma estação pode ser autenticada com vários APs ao mesmo tempo ( modo clássico onde ficam salvo todos os SSIDs no seu endpoint ), mas associada com no máximo um AP a qualquer momento. A associação implica em autenticação. Não há nenhum estado onde uma estação é associada mas não autenticada.

De-Authentication

Esse processo pode ser considerado ou co-relacionado como ” Man-in-the-Middle “, pois a proposto é enviar pacotes para o AP alertando que o cliente com o seu específico ” mac source address ” foi desautenticado e por essa característica o cliente vai solicitar novamente o processo de autenticação entre cliente->AP.

O que ocorre, é a execução de um ” flood ” de pacotes para justamente fazer com o cliente fique tentando se autenticar e como mencionado podemos relacionar o ” man-in-the-middle ” e capturar esses pacotes que estão trafegando pelo nosso meio. Logo abaixo podemos ter um exemplo do que é mencionado.

Como sempre precisamos demonstrar sobre essa caracteristicas visualizando nosso pacote sempre observando que estamos tendo nossa origem e destino.

Acredito que vocês devem estar perguntando sobre o filto aplicado no Wireshark. Pois bem, existem as flags que podemos controlar desta forma fica mais facil a visualização. Como facilidade segue o parâmetro e logo abaixo temos uma tabela com os principais valores para o filtro.

(wlan.fc.type == 0) && (wlan.fc.type_subtype == 12)

Segue nossa tabela abaixo:


Frame Type/Subtype	Filter
Management Frames	wlan.fc.type eq 0
Control Frames	wlan.fc.type eq 1
Data Frames	wlan.fc.type eq 2
Association Request	wlan.fc.type_subtype eq 0
Association Response	wlan.fc.type_subtype eq 1
Reassociation Request	wlan.fc.type_subtype eq 2
Reassociation Response	wlan.fc.type_subtype eq 3
Probe Request	wlan.fc.type_subtype eq 4
Probe Response	wlan.fc.type_subtype eq 5
Beacon	wlan.fc.type_subtype eq 8
Announcement Traffic Indication MAP (ATIM)	wlan.fc.type_subtype eq 9
Disassociate	wlan.fc.type_subtype eq 10
Authentication	wlan.fc.type_subtype eq 11
Deauthentication	wlan.fc.type_subtype eq 12
Action Frames	wlan.fc.type_subtype eq 13
Request to Send	wlan.fc.type_subtype eq 27
Clear to Send	wlan.fc.type_subtype eq 28
ACK	wlan.fc.type_subtype eq 29

PS.: Vale ressaltar que esse spoof pode ser detectado pelo seu AP, obviamente se ele suporta essa característica, bem como hoje temos modelo de APs / Fabricantes que dedicam exclusivamente um radio para ficar visualizando isso na rede e por consequencia irá bloquear esses pacotes ou mesmo jogar a origem do spoof para uma blacklist.

Beacon

A definição para um ” Beacon Frame ” é de fato aquele pacote que fica sendo anunciado pelos APs ou até mesmo esses equipamentos de IoT ( Internet of Thing ) periodicamente para a rede, ou seja, para aquele ambiente que temos sinal sendo publicado para a infraestrutura.

Basicamente ele é um pacote de gerenciamento do 802.11, que contm todas as informações dos BSS ( Basic Service Set ), que por consequencia irá levar o nome de nosso famoso SSID, desta forma qualquer device escutando esses beacons irá interpretar que tem esse caminho para associar-se aquela infraestrutura.

Abaixo temos um exemplo de um pacote capturado com a flag de ” Beacon “, onde podemos observar sobre o anúncio do nome do SSID, bem como pegar que o endereço destino é de fato um broadcast. Logo na sequencia o periodo que estes beacon estão sendo transmitidos.

PS.: Uma informação para vocês pensarem e pesquisarem, pois não vou explorar esse tópico, mas não é uma boa pratica criar diversos SSID para segregar diferentes aplicações, acessos, regras, pois sua performance pode degradar em seus equipamentos.

EAPOL ( Extensible Authentication Protocol Over LAN )

Enfim, chegamos no protocolo que é utilizado para que possamos carregar nossa autenticação não somente do WIFI, mas é um protocolo usado por outras tecnologias.

A autenticação 802.1X envolve três partes: um suplicante, um autenticador e um servidor de autenticação. O suplicante é um dispositivo cliente (como um laptop) que deseja associar-se à LAN/WLAN. O termo ” supplicant ” também é usado de forma intercambiável para se referir ao software executado no cliente que fornece credenciais ao autenticador. O autenticador é um dispositivo de rede que fornece um link de dados entre o cliente e a rede e pode permitir ou bloquear o tráfego de rede entre os dois, como um switch Ethernet ou ponto de acesso sem fio; e o servidor de autenticação é normalmente um servidor confiável que pode receber e responder a solicitações de acesso à rede, e pode dizer ao autenticador se a conexão deve ser permitida, e várias configurações que devem se aplicar à conexão ou configuração desse cliente.

Logo abaixo, temos um exemplo sobre esses processo observando os frames que são trafegados.

Trazendo para nosso exemplo, após completar os processo de ” Association Request ” e ” Association Response “, já mencionados acima teremos de fato a troca das chaves que esta associado aos pacotes capturados abaixo:

Podem observar que temos a menção de 4 ” Key Message ” que é a troca existente utilizada no procolo para garantir essa comunicação e obviamente garantir a utilização das chaves definidas neste processo.

Para facilitar no filtro em seu arquivo Wireshark pode-se utilizar a menção:

eapol.keydes.type == 2

Conclusão

Hoje vocês puderam entender um pouco mais sobre os pacotes que trafegam por este meio, com o intuito de avaliar quais os parâmetros principais são utilizados para identificar sua rede e obviamente executar sua autenticação.

Vale lembrar que não foi aprofundado sobre os protocolos de criptografia utilizados para esse processo de autenticação, mas por alguns screenshot espero que vocês possam ter observado esses detalhes.

O que vocês acharam? Muito teórico os ítens abordados? Você acredita que pode trazer um entendimento melhor do funcionamento para agregar segurança em sua rede? Responda em nossos comentários e deixe-me saber o que você esta achando/observando/pensando. 🙂

Em nosso próximo post vou mencionar sobre esse quesito da segurança, já que estamos expostos para que nossos pacotes sejam capturados de qualquer forma em um ambiente que pode estar exposto a qualquer indivíduo.

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 – Meraki IPSEC + Oracle OCI IPSEC – Parte 2

Tue, 02 Jun 2020 00:00:00 +0000

Olá Pessoal,

Conforme detalhado em nosso post anterior, hoje iremos fazer algumas tratativas relacionado a criação de uma conectividade entre meu ambiente de homelab com a Oracle Cloud ( OCI ).

Talvez vocês se perguntem o que seria isso? Eu já fiz um post onde eu trazia esse mesmo conceito para uma utilização de infra-estrutura dentro da Azure, desta forma vamos fazer nossa tratativa hoje para executar o procedimento e avaliar as facilidades para Oracle.

Topologia

Temos essa topologia simplificada apenas para que vocês tenham em mente o que de fato iremos construir dentro das estruturas, e a forma de que como isso esta se conectando.

Conceito

Hoje em dia muitas estruturas estão sendo movidas para dentro das clouds, podendo denominar-se como públicas e privadas, ou seja, terá momentos que você irá expor seu serviço para Internet, como também você irá ter apenas serviços denominados para funcionarem internamente em sua empresa, desta forma isso não irá precisar ser visto pelo mundo externo.

Pois bem, em nosso teste iremos tratar como sendo uma VCN ( Virtual Cloud Network ) privada, ou seja, todo esse endereçamento irá responder internamente dentro de meu ambiente. Vale lembrar que por default no ambiente Cloud teremos nossa rede interna sendo definida dentro de uma classe A ( 10.0.0.0/16 ), com isso foi definido neste ambiente cloud que nossas máquinas pertencem a rede ( 10.0.1.0/24 ).

Para que isso ocorra temos a necessidade de efetuar uma conexão ( Site-to-Site ) através de nosso conhecido e famoso IPSEC, entre meu ambiente Meraki e a Cloud Oracle ( OCI ). Portanto, eu irei ter acesso diretamente a qualquer ” Server ” ou ” Client “, sendo acessado diretamente via minha rede Interna Meraki.

Passos para Configuração

Vale lembrar que nesse momento não irei detalhar como executar a criação de instâncias ( VMs ) dentro do ambiente Oracle, e também a criação padrão da VCN, pois isso será explicado em outro post, portanto devo notificar que temos 1 host definido internamente no ambiente Cloud com o IP: 10.0.1.2/24.

A partir desse momento devemos seguir alguns passos para efetuar configuração de conectividade entre os ambientes. Segue abaixo o procedimento:

Criar um CPE ( Customer Premises Equipment )\
Criar um Dynamic Routing Gateways\
Criar o tunnel IPSEC

Configuração passo 1

Por definição a cloud exige que você configure um CPE para termos associações atreladas a esta conectividade, com isso eu criei utilizando uma opção como sendo equipamento Cisco ( temos mais vendor associados ), e posteriormente qual seria o IOS ( ASA ou IOS ), que por sua vez selecione 15.1. Vale lembrar que de fato estou utilizando Meraki ( MX64 ), portanto não faz relação com o IOS selecionado, porém minha opinião que isso seria apenas para atrelar algum vendor e de fato posteriormente ele apresenta ” janelas ” que leva a você ao fabricante, para observar e definir as configurações necessárias para esse vendor. Segue abaixo a configuração:

Após concluir os passos podemos observar que nosso CPE foi criado.

Mais detalhes consulte a documentação Oracle – CPE Configuration.

Escolhemos efetuar as configurações com roteamento estático, pois dentro do ambiente Meraki não temos a opção de subir uma sessão BGP via o tunnel IPSEC ( site-to-site )

Configuração passo 2

Na sequência devemos configurar nosso ” Gateway “, que irá fazer associação ao CPE criado, com isso posteriormente iremos definir ambos os componentes para configuração de nosso próximo passo. Segue abaixo:

Após iniciar ficaremos desta forma as configurações. Neste momento não estou utilizando ” tags “, mas isso para crescimento de sua estrutura pode facilitar para selecionar os serviços corretos.

Configuração Passo 3

Enfim, agora vamos definir nosso tunnel IPSEC com os outros dois componentes criados anteriormente. Para isso devemos ir em Networking -> IPSEC Connections.

No ítem 4 da figura acima é a rota estática que iremos definir para que essa infra-estrutura Cloud possa acessar minha rede local do homelab ( portanto redes atrás do MX ), se tiver mais sub-redes você pode adicionar.

Após isso clique em ” Show Advanced Options ” para selecionar alguns ítens essenciais para seu IPSEC. Um recurso interessante que pode facilitar é que temos como definir via ” FQDN ” seu CPE remoto.

Após isso precisamos definir ” Tunnel ” agregando uma “ shared key ” e a versão do IKE ( já comentado acima ). Vale lembrar que não teremos uma interface tunnel para nosso Meraki, pois iremos criar o tunelamento apenas via o IPSEC.

Após finalizar, pode observar que vai levar uns 5 minutos para o ambiente provisionar essas configurações e logo após você já pode verificar que o status fica ” Available “.

Caso esteja tudo correto em ambos os lados ( Oracle + Meraki ) você poderá observar seu IPSEC está ” UP “.

PS.: Por padrão o dashboard Oracle cria automaticamente dois tunneis para efetuar configuração, tendo dois IP Públicos distintos, porém em nosso lab irei definir apenas 1 tunnel. Oracle usa roteamento assimétrico entre os diferentes tuneis, ou seja, sua VCN pode usar os canais operacionais para devolver para sua estrutura on-premises, ou seja, você precisa controlar esse trafego. Se estiver utilizando BGP você manipula sua metricas.

TIPS: Após a finalização dessa configuração , certifique-se que a ” Security List ” de sua VCN está liberando acesso ao protocolo ICMP “ Ingress ” em sua estrutura.

Configuração MERAKI

Como já exposto em nosso ambiente Meraki, irei definir o MX como sendo um HUB, e após isso devo definir a metodologia ( Phase 1 e Phase 2 ). Para isso, recomendo observar a documentação da Oracle sobre o hash e encriptação para o IPSEC.

Tendo isso em mãos fiz a configuração de uma police “ Custom “, atrelando a ” share Key ” já definida no ambiente de Cloud.

Feito dessa forma iremos ter as informações associadas em nosso ” Dashboard ” como (non-Meraki VPN Peers).

Bem como devemos confirmar qual rede local do meu homelab irá trafegar por essa VPN.

Como demonstrado no dashboard Oracle, aqui também podemos consolidar o status dessa conectividade. Se tudo estiver correto teremos o status “ verde ” 🙂

Consolidação

Nada melhor do que consolidar através de nossas ferramentas essenciais que é o PING e TRACEROUTE ( rsrs ).

Via maquina da homelab ( 192.168.0.0/24 )

Via maquina Oracle Cloud to homelab ( 10.0.1.0/24 )

Conclusão

De fato eu achei bem intuitivo as configurações relacionados ao IPSEC, e consegui estruturar rapidamente para que esse tunel entre os vendor estivessem operacionais. As documentações que precisei pesquisar estavam coerentes e sendo direta ao ponto, sem precisar ficar navegando em diversas abas para obter a informação.

De fato a unica fonte encontrada foi do fabricante, ou seja, não temos ainda muita documentação ou testes executados por esse mundo afora ( rs ). O fato é que cada vez mais está aumentando as informações desse fabricante devido ao seu crescimento nesse segmento.

Em nosso proximo post vou demonstrar como habilitar um serviço http e balancear entre esses servidores. Fique ligado!

Att,
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

BLOG – DNS Encriptado – Parte 6 – Instalação Windows

Wed, 29 May 2019 00:00:00 +0000

Olá Pessoal,

Como informado segue nossa última video aula sobre o DNScrypt. Nesta sessão finalizo com o conceitos sobre a implementação no Windows e as formas de trabalhar com um segurança adicional.

Espero que vocês tenham gostado dessa serie e de alguma forma tenha trazido um conteúdo adicional para sua aprendizagem. Deixe seus comentário e se quiser mencione o que faltou nessa serie ou algum assunto novo que você queira aprender. 💡

Abs,
Rodrigo

BLOG – DNS Encriptado – Parte 5 – Instalação Windows

Tue, 28 May 2019 00:00:00 +0000

Olá Pessoal,

Conforme mencionado e prometido, hoje venho trazer minha video aula explicando sobre a instalação do DNSCrypt na plataforma Windows, o que acaba sendo um pouco diferente relacionado ao que já apresentamos na plataforma Linux.

Para obter o arquivo de instalação você deve acessar o site SimpleDNScrypt. Os próximos passos você pode conferir em nossa video.

Espero que vocês tenham gostado e espere nossa proxima video finalizando nossa serie.

Abs,
Rodrigo

BLOG – DNS Encriptado – Parte 4

Thu, 09 May 2019 00:00:00 +0000

Olá Pessoal,

Conforme vocês tem acompanhando a nossa serie sobre o DNScrypt, hoje venho aqui para trazer mais um parametro de configuração. Basicamente, nessa video explico sobre a opção de trabalhamos com varios ” Resolvers ” públicos ao mesmo tempo, sem ter a necessidade de ficar alterando a todo o momento seu arquivo de configuração ( /etc/dnscrypt-proxy/dnscrypt-proxy.toml )

Segue abaixo nossa video:

O que vocês tem achado sobre essa demanda que estou apresentando para vocês? Esta ficando claro o entendimento?

Deixe seus comentários!!!

Abs,
Rodrigo

BLOG – DNS Encriptado – Parte 3

Wed, 17 Apr 2019 00:00:00 +0000

Olá Pessoal,

Como vocês vêem acompanhando nossa serie, hoje venho aqui para trazer mais informações relacionadas essa demanda, no qual tange a interpretação e testes feitos através das instalações anteriores, portanto explico como adicionar cada parceiro dentro do arquivo de configuração do DNScrypt e mostro algumas capturas online baseado no OpenDNS e CloudFlare.

Vale a pena conferir nossa video. Segue abaixo:

Espero que vocês tenham gostado e coloquem seus comentários para que possamos ir agregando e melhorando cada vez mais.

Abs,
Rodrigo

Cisco Meraki – Regras do Firewall para Acesso a Cloud Meraki

Fri, 27 Apr 2018 00:00:00 +0000

Olá Pessoal,

Como vocês vem acompanhando nossos posts sobre Meraki, e conforme nossas explicações os equipamentos são gerenciados através da Cloud, devido a este parâmetro temos o principio que os equipamentos instalados na sua infra-estrutura precisam acessar ao ambiente público para alcançar o destino, desta forma serão geridos por essa estrutura de Cloud.

Devido a isso, algumas pessoas me perguntam como controlar ou o que liberar dentro de minha infra para que esses equipamentos sejam geridos conforme a demanda do produto. Bom, a resposta é simples, pois temos todas as regras já declaradas para serem aplicadas internamente e obviamente você pode garantir sua politica de segurança conforme os acordos executados internamente dentro da empresa.

Para você obter as regras é necessario acessar o menu principal, clicar em Help ( 1 ), após isso Firewall Info ( 2 ). Veja abaixo:

Após esse processo você pode visualizar as regras que deve ser implementadas, bem como se desejar pode fazer o download, conforme abaixo:

Espero que isso possa responder alguns questionamentos que eu havia recebido e ainda não havia publicado para todos.

Abs,
Rodrigo

Ansible – Validação de Configurações

Mon, 23 Oct 2017 00:00:00 +0000

Olá Pessoal,

Enfim, depois de um longo periodo voltamos para trazer mais tópicos sobre nossa estrutura de DevOps utilizando Ansible. Acredito que algumas pessoas devem ter visto que a RedHat fez anúncio sobre atualização do Ansible para a versão 2.4, e se observarem o módulo de networking foi o que teve a maior quantidade de release, portanto podemos observar que o projeto e a comunidade esta empenhanda em trazer mais beneficios para nossa área. Segue a menção explicada pelo engenheiro do modulo de networking da RedHat

Para critério de equiparação eu já fiz atualização para a nova versão, pois nossos exemplos e laboratórios já estão com os novos módulos. Segue a versão que estamos trabalhando nesse momento.

root@ubuntu:/home/rodrigo# ansible –version ansible 2.4.0.0 config file = /etc/ansible/ansible.cfg configured module search path = [u’/root/.ansible/plugins/modules’, u’/usr/share/ansible/plugins/modules’] ansible python module location = /usr/lib/python2.7/dist-packages/ansible executable location = /usr/bin/ansible python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Como estamos trabalhando em exemplos sobre backups de configuração, historico de configuração, neste post vou trazer algumas funcionalidades que temos agora para comparar nossas configurações e obter outputs que podem trazer beneficios em nosso dia a dia. O módulo voltado para Cisco, onde iremos trabalhar seria “ ios_config “, que por sua vez, teve algumas alterações nessa nova edição. Para contextualizar, existem algumas possibilidades que dependendo do seu ambiente podem-se enquadrar de uma forma diferente, portanto, para nosso caso eu irei criar um arquivo ( .conf ) que iremos apenas adicionar usuários para que possamos comparar nossas configurações. Segue exemplo de meu arquivo:

!
username R1 privilege 15 password 0 rodrigo3
username teste2 privilege 15 password 0 rodrigo3
username teste12 privilege 15 password 0 teste
!
!

PS.: Não é obrigatório a criação do arquivo como sendo ( .conf ), ele pode ser como texto e utilizar a estrutura que você tem em seu ambiente.

Após a criação de nosso arquivo base, iremos construir nosso playbook para que possamos fazer as comparações das configurações. Neste primeiro exemplo, iremos fazer a comparação da ” running-config ” com o arquivo base, e assim output que irá trazer em nossa variavél será a diferença entre os dois arquivos.

---
- hosts: all
  connection: local
  gather_facts: no

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

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

  - name: Compare running-config with base file
    ios_config:
      diff_against: running
      provider: "{{ provider }}"
      src: /home/rodrigo/Documents/ansible/input/{{ inventory_hostname }}.conf
    register: test_diff

  - debug: var=test_diff.updates

Com isso, podemos agora fazer nossa validação através de nosso playbook utilizando comando ad-hoc ( –check ). Vale lembrar que o “check” não irá popular nenhuma configuração em seu equipamento.

Assim podemos comparar com nossa configuração apresentada em nosso roteador que os usuários não estão presentes em nossa configuração ( running-config ), entretanto vocês podem observar que temos um usuario ( rodrigo ) que o mesmo não foi demostrado em nosso output. Porque?

Isso ocorre porque a validação que é feita é somente a comparação do R1.conf com a running-config, trazendo assim somentes as diferenças ( check ) do que temos na configuração base com o que está no roteador ( running-config ), e não o inverso. Teremos outras funções para que essa diferença também seja apresentada.

Devido a este ponto, para os próximos posts irei trazer mais validações usando essa nova funcionalidade ( diff_against ).

Abs,
Rodrigo

Ansible – Criar arquivo host

Wed, 14 Jun 2017 00:00:00 +0000

Olá Pessoal,

Conforme venho comentando com vocês hoje gostaria de trazer a primeira iniciativa para que possamos criar nosso arquivo denominado como host. O que seria este arquivo?

Devido ao seu próprio nome, ele é um arquivo que podemos fazer analogia baseando-se no inventário de sua rede, portanto neste arquivo você deve popular todos os seus equipamentos que serão visívies à partir da instalação que você executou de seu Linux ( Ubuntu – veja nosso post anterior ). Em nossa pequena topologia para testes, eu apenas adicionei meu router CSR1000V dentro dos parâmetros desse arquivo conforme abaixo:

[router]
192.168.0.13

Com isso poderíamos pensar em fazer segmentações nesse arquivo separando roteadores, switches, firewalls conforme exemplo abaixo:

[routers]
192.168.0.13
192.168.0.20

[switches]
192.168.0.21
192.168.0.22

[firewalls]
192.168.0.23
192.168.0.24

Dependendo da escalabilidade de crescimento de seu ambiente esse arquivo pode tomar outras formas, definindo assim, uma melhor forma de criar seu inventário. Uma das possibilidades que você pode executar nesse arquivo seria a criação de uma ” variável “, fazendo com que você implemente uma inserção de informação para esse grupo.

[routers]
192.168.0.13
192.168.0.20

[routers:vars]
ntp_server=200.160.7.186

Seguindo um pouco mais adiante podemos fazer inserção de grupos dentro de grupos e ainda utilizar variavéis para colocar aquela determinada informação.

[routers]
192.168.0.13
192.168.0.20

[switches]
192.168.0.21
192.168.0.22

[dcsaopaulo:children]
routers
switches

[dcsaopaulo:vars]
ntp_server=200.160.7.186

[brasil:children]
dcsaopaulo
dcriodejaneiro
dcbrasilia
dcrecife

Podemos também utilizar um range de endereços IPs que irão seguir uma sequência, facilitando assim a definição dos endereços dentro do arquivo, economizando uma lista maior com somente os endereços IPs

[routers]
192.168.0.[1:255]
192.168.1.[1:128]

Para finalizarmos podemos também fazer associação desses endereços IPs por nome de hosts, mas vale lembrar, para que isso funcione você precisar ter o DNS funcionando corretamente, para que esse nome seja resolvido antes dele consultar seu device na sua infraestrutura. Segue um exemplo:

[routers]
R1_andar_1
R2_andar_1

[switches]
SW1_sala_10
SW2_sala_10

Com isso você já consegue manipular seus equipamentos através de seu arquivo de ” host “, fazendo com essa maquina possa alcançar a sua infraestrutura e manipular seus equipamentos. Para maiores detalhes, exemplos recomendo fazer a consulta através da documentação do Inventory Ansible.

Abs,
Rodrigo

Etherchannel – Configuração – Parte 3

Fri, 18 Nov 2016 00:00:00 +0000

Olá Pessoal,

Dando sequencia em nosso tópico, gostaria de trazer as menções sobre as configurações do etherchannel em Layer 3.

Nesse momento vou mostrar apenas as configurações entre o SW1 e SW2 de nossa topologia ( já apresentada em nossos posts anteriores ). Nesta conectividade continuaremos utilizando o LACP.

Nesta confguração pode ser observado apenas a configuração da porta ethernet 0/2, mas isso deve ser alterado também para a outra porta ethernet 0/3, onde estamos fazendo o *bundle* ´ entre os switches ( **SW1 e SW2** ). Neste exemplo o que gostaria de ressaltar é que podemos ter alterações dependendo do equipamento que estará utilizando, pois em meu simulador atrelado a imagem do IOS que estou utilizando, foi necessário configurar em ambas as portas o comando no switchport ´, para que pudessemos forçar o equipamento a transformar essa porta física em uma conectividade Layer 3.

Na sequencia demonstro que temos conectividade em Layer 3 ( via ping ), bem como podemos observar na resolução ARP que foi mapeado o endereço MAC do meu portchannel 2.

Devido estes ítens podemos observar dentro do comando abaixo a transformação dessa conectividade em L3.

Em nosso próximo post vou mostrar as mudanças que temos em relação ao spanning-tree quando utilizamos etherchannel em L2 e L3.

Espero que gostem e aguardo os comentários.

Abs,
Rodrigo

Desafio 35

Fri, 27 Mar 2015 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio para nosso BLOG.

Desafio 35

Qual estado de porta é introduzido pelo Rapid-PVST?

A – learning
B – listening
C – discarding
D – forwarding

Essa esta simples e rápida para responder, aguardo as respostas 😉

Abs,
Rodrigo

Desafio 34

Mon, 27 Oct 2014 00:00:00 +0000

Olá Pessoal,

Voltemos com um essa semana.

Desafio 34

Baseado na topologia abaixo e assumindo que o protocolo de roteamento referenciado em cada escolha abaixo é configurado com as configurações padrões e dado que o protocolo de roteamento está operacional em todos os roteadores. Quais as duas condições afirma que o caminho escolhido entre as redes 10.1.0.0 e 10.3.2.0 para o protocolo de roteamento mencionado:

A – Se OSPF é o protocolo de roteamento , o caminho irá ser do R1 para R3 para R4 e R5
B – Se OSPF é o protocolo de roteamento , o caminho irá ser do R1 para R2 e R5
C – Se OSPF é o protocolo de roteamento , o caminho irá ser do R1 para R5
D – Se RIPv2 é o protocolo de roteamento, o caminho irá ser R1 para R3 para R4 e R5
E – Se RIPv2 é o protocolo de roteamento, o caminho irá ser R1 para R5

Aguardo as respostas 😉

Abs,
Rodrigo

Desafio 33

Mon, 21 Apr 2014 00:00:00 +0000

Olá Pessoal,

Depois de um longo tempo sem nossos desafios. Voltemos com um essa semana.

Desafio 33

Consulte a topologia e configuração do roteador mostrado na figura abaixo. Um host na LAN está acessando um servidor FTP através da Internet. Qual dos seguintes endereços podem aparecer como um endereço de origem para os pacotes enviados pelo roteador para o servidor de destino?

A – 10.10.0.1
B – 10.10.0.2
C – 199.99.9.33
D – 199.99.9.57
E – 200.2.2.17
F – 200.2.2.18

Abs,
Rodrigo

Desafio 32

Mon, 10 Mar 2014 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio para nosso BLOG.

Desafio 32

O que irá acontecer depois de trocar o ” configuration register “ para 0x2142 e reiniciar o roteador ( Escolha duas respostas )?

A – A imagem do IOS vai ser ignorada
B – O roteador irá para o prompt no modo de configuração inicial
C – O roteador vai para o modo ROM
D – Qualquer configuração executada na NVRAM vai ser ignorada
E – A configuração da memória flash irá ser carregada.

Aproveitem!!!

Abs,
Rodrigo

Desafio 31

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

Olá pessoal,

Segue um novo desafio

Desafio 31

O comandos abaixo foram executados na interface fa0/1 do switch 2950.

2950Switch(config-if)#switchport port-security
2950Switch(config-if)#switchport port-security mac-address sticky
2950Switch(config-if)#switchport port-security maximum 1

O frame ethernet que é mostrado chega na interface fa0/1.

Quais as duas funções que irá ocorrer quando esse frame é recebido pelo 2950Switch? ( Escolha duas opções )

A – A tabela de mac address irá agora ter uma entrada adicional de fa0/1 FFFF. FFFF.FFFF
B – Somente o host A irá ser liberado para transmitir frames na interface fa0/1
C – Esses frames irão ser descartados quando for recebido pelo switch 2950
D – Todos os frames chegando no switch 2950 com destino de 0000.00aa.aaaa irão ser encaminhados para a saída fa0/1
E – Host B e C podem encaminhar frames para saída fa0/1 , mas o frames chegando de outros switches não irão ser encaminhados para saída da fa0/1
F – Somente frames da origem 0000.00bb.bbbb, o primeiro MAC Address aprendido do switch 2950 irão ser encaminhados para saída da fa0/1

Abs,
Rodrigo

Desafio 30

Sun, 19 Jan 2014 00:00:00 +0000

Olá Pessoal,

Segue nosso desafio da semana para tratar sobre NAT.

Desafio 30

Baseado na figura abaixo, qual é afirmação relacionado a configuração para esta rede:

A – A configuração que é mostrada indica que o espaço dos endereços de saída para a tradução são inadequados em relação aos números de endereços internos que são suportados.
B – Por que o endereçamento na interface F0/1, o endereço da interface Serial 0/0 não irá suportar a configuração de NAT conforme mostrado.
C – O número 1 referenciado para o comando ip nat inside source referencia ao access-list número 1
D – O External router deve ser configurado com uma rota estática para a rede 172.16.2.0/24

Abs,
Rodrigo

Desafio 29

Mon, 23 Dec 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio para nosso BLOG.

Desafio 29

Qual é o propósito do ” Inverse ARP “?

A – Mapear um IP conhecido para um MAC Address
B – Mapear um SPID conhecido para um MAC Address
C – Mapear um MAC conhecido para um IP Address
D – Mapear um DLCI conhecido para um IP Address
E – Mapear um IP conhecido para um SPID
F – Mapear um DLCI conhecido para um MAC Address

PS.: Vocês já executaram nosso QUIZ disponíveis para testar seu conhecimento. Verifique em nosso BLOG.

Abs,
Rodrigo

Desafio 28

Mon, 11 Nov 2013 00:00:00 +0000

Olá pessoal,

Segue mais um desafio para nosso BLOG.

Desafio 28

Verifique a figura abaixo para responder o desafio:

O HSRP foi configurado na rede para prover redundância no trafego IP. O administrador da rede verificou que o R2 não esta se tornando ativo quando a Serial 0 do R1 fica ” down “. O que deve ser mudado para resolver o problema?

A – R2 deve ser configurado com um endereço virtual no HSRP
B – R2 deve ser configurado com uma prioridade 100 de ” standby “
C – A interface Serial 0 no R2 deve ser configurada com um valor de decremento 20
D – A interface Serial 0 no R1 deve ser configurada com um valor de decremento 20

Espero que aproveitem, lembrando que esse tema é novo e cobrado na nova versão do CCNA.

Abs,
Rodrigo

Desafio 27

Mon, 07 Oct 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio para nosso BLOG

Desafio 27

Em uma tentativa para negar o acesso a WEB relacionado a uma subnet, todo o trafego foi negado. Qual comando na interface irá remover imediatamente o efeito da ACL 102?

A – no ip access-class 102 out
B – no ip access-group 102 out
C – no ip access-group 102 in
D – no ip access-list 102 in
E – no ip access-class 102 in

Abs,
Rodrigo

Desafio 26

Mon, 16 Sep 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio para essa semana.

Desafio 26

A rede com o endereço IP 172.31.0.0/19 deve ser configurado no roteador com a configuração parcial mostrado na figura abaixo. Qual das seguintes afirmações descreve o número de sub-redes e hosts disponíveis que resultarão desta configuração?

A – Existem 7 sub-redes utilizáveis, com 2.046 endereços de hosts utilizáveis.
B – Existem 8 sub-redes utilizáveis, com 30 endereços de hosts utilizáveis.
C – Há 7 sub-redes utilizáveis, com 30 endereços de hosts utilizáveis.
D – Há 8 sub-redes utilizáveis, com 2.046 endereços de hosts utilizáveis.
E – Existem 7 sub-redes utilizáveis, com 8.190 endereços de host utilizáveis.
F – Há 8 sub-redes utilizáveis, com 8.190 endereços de host utilizáveis.

Espero comentários.

Abs,
Rodrigo

Desafio 25

Mon, 02 Sep 2013 00:00:00 +0000

Olá Pessoal,

Segue um desafio para animar a semana.

Desafio 25

A access list foi configurada na interface Serial 0/0 do router RTB como sendo na direção de ” outbond “. Qual dos dois pacotes, se roteado pela interface deverá ser negado? (Escolha duas ).

access-list 101 deny tcp 192.168.15.32 0.0.0.15 any eq telnet

access-list 101 permit ip any any

A – Endereço IP de origem: 192.168.15.5 / Porta de destino: 21
B – Endereço IP de origem: 192.168.15.37 / Porta de destino: 21
C – Endereço IP de origem: 192.168.15.41 / Porta de destino: 21
D – Endereço IP de origem: 192.168.15.36 / Porta de destino: 23
E – Endereço IP de origem: 192.168.15.46 / Porta de destino: 23
F – Endereço IP de origem: 192.168.15.49 / Porta de destino: 23

Espero que gostem e compartilhe nossos desafios.

Abs,
Rodrigo

NetRiders – America Latina – 2013

Sun, 01 Sep 2013 00:00:00 +0000

Olá Pessoal,

Inicia-se mais um ano de competições para os alunos e ex-alunos inscritos no NetAcademy, para qual temos a competição chamada de NetRiders.

Todos os alunos que são elegíveis na Academia pode participar dessa competição e concorrer no final da competição a uma bolsa de estudos na sede da Cisco nos Estados Unidos.

Para maiores informações e cadastro para participar, visitem o site do Netriders através do http://www.academynetriders.com/file.php/1/netriders_info/region_latam_br.html

Fiquem atentos que temos o encerramento das inscrições em 16 Setembro.

Abraços
Rodrigo

Desafio 24

Mon, 29 Jul 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio

Desafio 24

A figura abaixo mostra o resultado de uma tentativa de abrir uma conexão Telnet ao router ACCESS1 do router Remote27. Qual dos seguintes comandos irá corrigir este problema?

A – ACCESS1(config)# line console 0
ACCESS1(config-line)# password cisco

B – Remote27(config)# line console 0
Remote27(config-line)# login
Remote27(config-line)# password cisco

C – ACCESS1(config)# line vty 0 4
ACCESS1(config-line)# login
ACCESS1(config-line)# password cisco

D – Remote27(config)# line vty 0 4
Remote27(config-line)# login
Remote27(config-line)# password cisco

E – ACCESS1(config)# enable password cisco

F – Remote27(config)# enable password cisco

Abs,
Rodrigo

Desafio 23

Sun, 07 Jul 2013 00:00:00 +0000

Olá Pessoal,

Depois de um longo tempo segue mais um desafio.

Desafio 23

Ao solucionar um problema de conectividade de um PC você obtêm as seguintes informações:

Endereço IP do PC: 10.0.0.35/24
Gateway Padrão: 10.0.0.1
Server remoto: 10.5.75.250/24

Você, então, realiza os seguintes testes d PC local:

Ping 127.0.0.1 – OK
Ping 10.0.0.35 – OK
Ping 10.0.0.1 – Não OK
Ping 10.5.75.250 – Não OK

Qual é a causa deste problema?

A – Existe um problema na camada física remota.
B – A placa de rede do host não está funcionando.
C – A pilha TCP/IP não foi instalado corretamente no host.
D – Existe um problema na camada física local.

Valew,
Rodrigo

Desafio 22

Mon, 27 May 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 22

Verifique abaixo. Os hosts na mesma VLAN podem se comunicar uns com os outros, mas são incapazes de se comunicar com hosts em diferentes VLANs. O que é necessário para permitir a comunicação entre VLANs?

A – Um switch com um link trunk que deve ser configurado entre os switches.
B – Um roteador com um endereço IP na interface física que deverá se conectado ao switch.
C – Um switch com um link de acesso que deve ser configurado entre os switches.
D – Um roteador com sub-interfaces configurado na interface física, que vai ser ligado ao switch.

Abs,
Rodrigo

Desafio 21

Sun, 05 May 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio

Desafio 21

Quais as informações abaixo descreve as funções dos equipamentos em uma WAN? ( Escolha três )

A – A CSU / DSU termina em um loop local digital.
B – O modem termina em um loop local digital.
C – A CSU / DSU termina em um loop local analógico.
D – O modem termina em um loop local analógico.
E – O roteador é normalmente considerado um equipamento DTE.
F – O roteador é normalmente considerado um equipamento DCE.

Abs,
Rodrigo

Protocolo VTP – parte 2

Mon, 11 Mar 2013 00:00:00 +0000

Olá Pessoal,

Conforme mencionado anteriormente em nosso post, vamos tratar de explicar como funciona os anúncios de VTP.

Nos sabemos que o equipamento designado como servidor irá publicar as informações para todos os seus vizinhos que estão associados ao mesmo domínio, bem como os outros modos também irão popular as informações e repassar a mensagem para seus vizinhos, fazendo com que todos possam obter a mesma informação.

Essa informação de comparar as alterações está atrelada especificamente ao número de revisão que cada switch possui, ou seja, os switches que estão no mesmo domínio com uma revisão menor irá ser atualizado caso a revisão que esta sendo enviada tenha um valor maior. Nós iremos visualizar as informações através do comando abaixo:

Router#show vtp status
VTP Version: 2
Configuration Revision: 247
Maximum VLANs supported locally: 1005
Number of existing VLANs: 33
VTP Operating Mode: Client
VTP Domain Name: CiscoRedes
VTP Pruning Mode: Enabled
VTP V2 Mode: Disabled
VTP Traps Generation: Disabled
MD5 digest: 0x45 0x52 0xB6 0xFD 0x63 0xC8 0x49 0x80
Configuration last modified by 0.0.0.0 at 8-12-99 15:04:49
Router#

Acima podemos observar diversas informações, como o número de revisão que vai mencionar se todos os switches estão com seu database sincronizado, quantidade de VLANs populadas nesse switch, dominio que pertence esse equipamento e qual o modo de operação que ele esta trabalhando ( cliente ).

Essas mensagens são divulgadas através do link trunk habilitado entre os switches, fazendo com que essas informações sejam propagadas através do 802.1q. Veja abaixo:

Nos temos 3 métodos na qual esses anúncios são enviados:

Sumarizado = São enviados a cada 5 minutos pelo servidor VTP, informa aos switches habilitados para VTP sobre o número de revisão de configuração de VTP atual e são enviados imediatamente após a alteração de qualquer configuração;

Sub-Conjunto = Contém as informações de VLANs e as alterações que vão disparar o anúncio de subconjunto são:

Criação ou exclusão de uma VLAN
Suspensão ou ativação de uma VLAN
Alteração no nome da VLAN
Alteração no MTU da VLAN

Solicitação = É enviado a um servidor VTP no mesmo domínio VTP, o servidor VTP responde enviando um anúncio de sumarização e, em seguida, um anúncio de subconjunto.

O nome de domínio foi alterado
O switch recebe um anúncio de sumarização com um número de revisão de configuração mais alto do que seu próprio número
Uma mensagem de anúncio de subconjunto é perdido por alguma razão
O switch foi reiniciado

Para que possamos definir em que modo de operação ( servidor, cliente, transparente ) o switch vai trabalhar precisamos definir através:

CiscoRedes(config)#vtp mode [server, client, transparent ]

Desta forma podemos concluir sobre o processo de VTP, bem como a divulgação desse protocolo e os modos de configuração que ele pode trabalhar. Lembrando-se que esse protocolo em certas circunstâncias tem um grande valor, porém também é um ponto de falha se formos pensar em segurança, mas vale lembrar que tudo bem planejado pode trazer benefícios e dinamismo para nosso trabalho.

Espero que tenham gostado de mais um tutorial.

Fonte:
VTP Cisco

Abs,
Rodrigo

Desafio 18

Mon, 04 Mar 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 18

Em uma interface serial do roteador, uma access list de entrada esta configurada para negar todo o tráfego de UDP e TCP portas 21, 23 e 25. Todo o resto do tráfego é permitido. Baseado nessas informações, qual o tipo de tráfego irá ser liberado através dessa interface? ( Escolha três alternativas ).

A – SMTP
B – DNS
C – POP3
D – HTTP

Aguardo comentários

Abs,
Rodrigo

Desafio 17

Mon, 18 Feb 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 17

Selecione todos os endereços IPV6 válidos:

A – ::
B – ::192:168:0:1
C – 2002:c0a8:101:42
D – 2003:dedd:beef:4dad:23:46:bb:101

Abs,
Rodrigo

Desafio 16

Sun, 27 Jan 2013 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 16

Como podemos garantir que o switch P4S-SW3 irá se tornar a root bridge na topologia abaixo:

A – Configurar um MAC Address no P4S-SW3 para ser maior do que o P4S-SW1 e P4S-SW2
B – Configurar um endereço IP no P4S-SW3 para ser maior do que o endereço IP do P4S-SW1 e P4S-SW2
C – Configurar o BID no P4S-SW3 para ser menor do que o BID do P4S-SW1 e P4S-SW2
D – Configurar uma interface loopback no P4S-SW3 com um endereço IP menor do que qualquer endereço configurado no P4S-SW1 e P4S-SW2

Aguardo comentários

Abs,
Rodrigo

Desafio 15

Sun, 06 Jan 2013 00:00:00 +0000

Olá Pessoal,

Mais um desafio para nosso BLOG.

Desafio 15

O administrador de rede criou uma nova VLAN no Switch1 e acrescentou o host C e o host D. O administrador configurou corretamente as interfaces FastEthernet0/13 e FastEthernet0/14 para ser membro da nova VLAN. No entanto, depois que o administrador de rede finalizou a configuração, o host A pode comunicar-se com o host B, mas o host A não pode-se comunicar com o host C ou D. Quais comandos são necessários para resolver esse problema?

A – Router(config)# interface fastethernet 0/1.3
Router(config-if)# encapsulation dot1q 3
Router(config-if)# ip address 192.168.3.1 255.255.255.0

B – Router(config)# router rip
Router(config-router)# network 192.168.1.0
Router(config-router)# network 192.168.2.0
Router(config-router)# network 192.168.3.0

C – Switch1# vlan database
Switch1(vlan)# vtp v2-mode
Switch1(vlan)# vtp domain cisco
Switch1(vlan)# vtp server

D – Switch1(config)# interface fastethernet 0/1
Switch1(config-if)# switchport mode trunk
Switch1(config-if)# switchport trunk encapsulation isl

Aproveite e compartilhe!!!

Abs,
Rodrigo

Desafio 14

Sun, 09 Dec 2012 00:00:00 +0000

Olá Pessoal,

Vamos de mais um desafio.

Desafio 14

A rede mostrada no diagrama abaixo está com problemas de conectividade. Qual das seguintes opções irá corrigir os problemas? (Escolha duas alternativas.)

A – Configure o gateway no Host A como 10.1.1.1.
B – Configure o gateway no Host B como 10.1.2.254.
C – Configurar o endereço IP no Host A como 10.1.2.2.
D – Configure o endereço IP no Host B como 10.1.2.2.
E – Configure as máscaras de ambos os Hosts para ser 255.255.255.224.
F – Configure as máscaras de ambos os Hosts para ser 255.255.255.240.

Abs,
Rodrigo

Desafio 13

Sun, 02 Dec 2012 00:00:00 +0000

Olá Pessoal,

Segue um novo desafio voltado para switch.

Desafio 13

Um administrador de rede configurou dois switch denominados de Londres e Madrid, para usar VTP. No entanto, os switches não estão compartilhando mensagens VTP. Dada a saída do comando mostrado abaixo, porque os switches não estão compartilhando mensagens VTP?

A – A versão VTP não está configurado corretamente.
B – O modo de operação VTP não está configurado corretamente.
C – O nome de domínio VTP não está configurado corretamente.
D – VTP pruning está desativado.
E – O modo VTP V2 está desativado.
F – O Trap VTP está desativado.

Aproveitem!! Compartilhe!!!

Abs,
Rodrigo

Desafio 12

Sun, 18 Nov 2012 00:00:00 +0000

Olá caros,

Segue mais um desafio voltado para calculos de endereços IP. Esse é bem tranquilo.

Desafio 12

Dada as opções abaixo, qual endereço vai representar um endereço unicast?

A – 224.1.5.1
B – FFFF.FFFF.FFFF
C – 192.168.24.59/30
D – 255.255.255.255
E – 172.31.128.255/18

Participem!!! Lembre-se sempre de explicar sua decisão

Abs,
Rodrigo

Desafio 11

Sun, 11 Nov 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 11

Qual das seguintes afirmações melhor descreve as características de transmissão das redes abaixo, observando em questões de domínios de colisão e domínio de broadcast? (Seleccione as duas melhores resposta)

A – Há dois domínios de broadcast na rede.
B – Existem quatro domínios de broadcast na rede.
C – Existem seis domínios de broadcast na rede.
D – Existem quatro domínios de colisão na rede.
E – Existem cinco domínios de colisão na rede.
F – Existem sete domínios de colisão na rede.

Participem!!!

Abs,
Rodrigo

Desafio 10

Fri, 02 Nov 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 10

Dois roteadores nomeados Atlanta e Brevard são ligados por suas interfaces seriais como mostrado na figura abaixo, entretanto não há conectividade de dados entre eles. O roteador Atlanta é conhecido por ter uma configuração correta. Dadas as configurações parciais mostradas, qual é o problema no roteador Brevard que está causando a falta de conectividade?

A – Nenhuma loopback foi definida.
B – O endereço IP está incorreto.
C – A máscara de sub-rede está incorreta.
D – Os encapsulamentos das interfaces seriais são incompatíveis.
E – O MTU é muito grande.
F – A largura de banda não é compatível com o interface conectada.

Participem!!!

Comente suas respostas explicando o porque de sua decisão.

Abs,
Rodrigo

Desafio 9

Sun, 28 Oct 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio:

Desafio 9:

O switch CiscoRedes tem um link trunk configurado com o encapsulamento IEEE 802.1q. Qual é o máximo tamanho do frame Ethernet neste link trunk?

A – 1496 bytes
B – 1500 bytes
C – 1518 bytes
D – 1522 bytes
E – 1548 bytes

Participem!!!

Abs,
Rodrigo

Desafio 8

Mon, 22 Oct 2012 00:00:00 +0000

Olá Caros,

Segue mais um desafio.

Desafio 7

Todos os roteadores da rede ilustrada no gráfico fazem parte da mesma área OSPF. Todos os roteadores são ligados à energia simultaneamente, exceto o Roteador E, que foi ativado no dia seguinte. Qual dos roteadores será o BDR depois da rede convergir?

A – Roteador A
B – Roteador B
C – Roteador C
D – Roteador D
E – Roteador E

Participem!!!

Abs,
Rodrigo

Desafio 7

Sun, 14 Oct 2012 00:00:00 +0000

Olá caros,

Segue mais um desafio.

Desafio 7

Veja a figura abaixo. Os dois dispositivos expostos são os únicos dispositivos Cisco na rede. A interface serial entre os dois dispositivos tem uma máscara de 255.255.255.252. Dada a saída que é mostrada, quais são as três afirmações são verdadeiras?

A- O endereço da serial de Manchester é 10.1.1.1.
B- O endereço da serial de Manchester 10.1.1.2.
C- O roteador Londres é um 2610 da Cisco.
D- O roteador Manchester é um 2610 da Cisco.
E- As informações CDP foi recebido na porta Serial0/0 do roteador Manchester
F- As informações CDP foi enviada pela porta Serial0/0 do roteador Londres.

Participe!!!

Abs,
Rodrigo

Desafio 6

Sun, 07 Oct 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 6

Consulte a figura abaixo e descreva qual afirmação descreve o DLCI 17?

A- DLCI 17 descreve um circuito ISDN entre R2 e R3.
B- DLCI 17 descreve um PVC em R2. Ele não pode ser usado em R3 ou R1.
C- DLCI 17 é o endereço camada 2 usado por R2 para relatar um PVC para R3.
D- DLCI 17 relata um circuito dial-up de R2 e R3 para a operadora.

Participe!!!

Abs,
Rodrigo

Desafio 5

Mon, 01 Oct 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 5

Um administrador de rede gostaria de configurar um roteador EIGRP como um stub router que somente anuncia as redes diretamente conectadas e rotas sumarizadas. Qual o comando que o administrador deve configurar no roteador?

A- eigrp stub
B- eigrp stub connected
C- eigrp stub summary
D- eigrp stub connected static
E- eigrp stub receive-only

Participem!!!

Abs,
Rodrigo

Desafio 4

Mon, 24 Sep 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 4

Consulte a figura abaixo. Qual é o significado do termo dynamic exibido na saída do comando show frame-relay map.

A- A interface serial 0/0 esta passando tráfego.
B- O DLCI 100 foi dinâmicamente alocado pelo roteador R1
C- A interface serial 0/0 adquiriu o endereço IP 172.16.3.1 de algum servidor DHCP
D- O DLCI 100 irá ser dinâmicamente mudado como requirido para adpatar as mudanças na nuvem Frame Relay
E- O mapeamento entre o DLCI 100 e a ponta remota com IP address 172.16.3.1 foi aprendido através do Inverse ARP

Participem!!!

Abs,
Rodrigo

Desafio 3

Mon, 17 Sep 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio. Nesse iremos comentar sobre OSPF.

Desafio 3

Um administrador de rede esta tentando solucionar um problema de configuração dos roteadores OSPF R1 e R2. Os roteadores não podem estabelecer uma relação de adjacência em sua ligação Ethernet. A figura mostra a saída do comando show ip ospf interface ethernet 0 para roteadores R1 e R2. Com base na informação abaixo, qual é a causa deste problema?

A – A área OSPF não está configurada corretamente.
B – A prioridade em R1 deve ser configurado com um valor superior.
C – O custo de R1 deve ser maior.
D – Os temporizadores hello e dead timers não estão configurados corretamente.
E – Um router BDR tem que ser adicionado na rede.
F – O processo OSPF ID deve corresponder.

Participem!!!

Abs,
Rodrigo

Desafio 2

Mon, 10 Sep 2012 00:00:00 +0000

Olá Pessoal,

Conforme combinado segue mais um desafio.

Desafio 2

Uma lista de acesso foi escrita com as quatro declarações mostrada na figura. Qual afirmação da lista de acesso irá combinar todas as quatro declarações em uma única instrução que vai ter exatamente o mesmo efeito?

A – access-list 10 permit 172.29.16.0 0.0.0.255
B – access-list 10 permit 172.29.16.0 0.0.1.255
C – access-list 10 permit 172.29.16.0 0.0.3.255
D – access-list 10 permit 172.29.16.0 0.0.15.255
E – access-list 10 permit 172.29.0.0 0.0.255.255

Abs,
Rodrigo

Desafio 1

Sun, 02 Sep 2012 00:00:00 +0000

Olá Caros,

Gostaria de trazer mais uma ideia para nosso BLOG, na qual irei trazer uma questão por semana para nossos leitores. Espero com isso tentar trazer questões do dia-a-dia, bem como questões que estão caindo nos exames de certificação Cisco.

Vocês podem responder através dos comentários e no final do período para colocar um novo desafio irei colocar a resposta do anterior. Vamos aproveitar para discutir as questões e avaliar os pontos conflitantes.

Conforme solicitado, vamos iniciar nosso primeiro desafio falando de ACL.

Desafio 1

Consulte o gráfico. Foi decidido que o PC1 deve ser negado para acesso ao Server 1. Qual dos seguintes comandos são necessários para evitar apenas que o PC1 acesse o Server1, permitindo assim todo o tráfego a fluir normalmente? (Escolha dois)

A – Router(config)# interface fa0/0
Router(config-if)# ip access-group 101 out
B – Router(config)# interface fa0/0
Router(config-if)# ip access-group 101 in
C – Router(config)# access-list 101 deny ip host 172.16.161.150 host 172.16.162.163
Router(config)# access-list 101 permit ip any any
D – Router(config)# access-list 101 deny ip 172.16.161.150 0.0.0.255 172.16.162.163 0.0.0.0
Router(config)# access-list 101 permit ip any any

Abs,
Rodrigo