SNMP on Cisco Redes

Resumo do BLOG – Referência 2020

Sun, 03 Jan 2021 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar um pouco sobre nossa trajetória de 2020, um pouco atrasado, pois já estamos em 2021 ( rs ), porém devido a um outro projeto que logo mais vocês irão descobrir, eu acabei atrasando um pouco com as informações, mas volto aqui para trazer alguns números e avaliar o que conseguimos ajudar a comunidade, bem como também conforme a promessa em nosso post executado em 2019, declarando um pouco sobre os temas que iria tentar abordar.

Todos sabem que esse ano foi complicado para todos, mas conforme demonstração de nossos números abaixo, posso dizer como sendo um blog que trata de assuntos específicos e sendo com um hobby adicional, eu declaro que os números estão ótimos ( rs!! ).

Logo abaixo, podemos ver os posts mais visitados, e diga de passagem é um tópico que foi abordado em 2016.

Nesta linha de raciocíonio, eu consegui postar um total de 32 posts ( contando este que seria de 2020..rs!), ou seja, seria 1,5 post por semana, que de alguma forma eu acho um valor expressivo.

Re-avaliando aquilo que havia pensado em 2019, eu até consegui fazer as tratativas, pois eu consegui trazer mais conteúdos técnicos explicando sobre a tecnologia Meraki ( Insight, Umbrella+MR, SDWAN ), Gerência via IPFabric, Segurança WIFI, adicionei mais alguns códigos em minha conta do GitHub, etc

Conquistas

Neste ano de 2020 eu continuei dentro dos 3 programas de comunidades que venho tocando ( Cisco Champion, vExpert, VMUG Leader ), e posso dizer que foram especiais os parâmetros para o CiscoChampion, onde fiz uma entrevista para DevNet Create para divulgar o evento no Brasil e também contar um pouco também sobre nossa comunidade no Brasil, sendo o primeiro blog brasileiro a difundir a informação sobre nossa comunidade e também de divulgar um resumo sobre o ” Kick Off “ executado com os líderes na abertura do evento.

Para nosso capítulo do VMUG São Paulo, onde nele conseguimos fazer 5 eventos durante o ano, com muitas palestras técnicas e também fizemos um encontro reunindo todos os capítulos do Brasil ( total de 6 ), onde foi chamado de VMUGão, inclusive com a presença ilustre de Sanjay Poonen ( COO ).

Certificações

Sobre esse quesito acredito que fiquei bem feliz, pois consegui desbravar algumas áreas que não são de meu cotidiano e posso dizer que vieram somente agregar mais conhecimentos para o dia a dia, e também ajudar no sentido de compartilhar mais tópicos para todos vocês que nos acompanham.

Dentro dessa trilha eu consegui obter a Certificação da Cisco ( CyberOps Associate ), Azure ( Fundamentals ), Aviatrix ( Engineer Multicloud ), Instrutor Netacad ( CyberOps Associate ), e um curso denominado BootCamp da IGTI ( Arquiteto de Cloud ).

Conclusão

Acredito que baseado neste resumo, posso dizer que foi um ano difícil, devido a diversos fatores que influenciaram durante a trajetória.

Tive os sucessos conforme demostrado acima, e que de uma certa forma foram excelentes, porém tenho que revelar que também tive deslizes, na qual teve a iniciativa de escrever um livro, onde não conseguimos evoluir, atualizar meu treinamento que também acabei não executando. Entretanto, acho que essas reflexões nos ajudam também a focar nas necessidades e avaliar para que não tenhamos punições se avaliar como um todo.

Como recomendação façam uma reflexão e sempre verifiquem os lados positivos, para que você não veja somente o lado negativo e possa se punir de forma injusta.

Abs,
Rodrigo

BLOG – NFD20 – PathSolutions – Nova Forma de Troubleshooting

Thu, 04 Jul 2019 00:00:00 +0000

Olá Pessoal,

Devido a diversos fatores eu ainda não havia finalizado meus posts relacionado ao evento que participei em Fevereiro de 2019 via Network Field Day. ( NFD20 ).

Com isso volto hoje aqui, para falar um pouco mais sobre a sessão que tivemos da empresa Path Solutions. Talvez vocês possam me perguntar, nossa porque depois de tanto tempo ele ainda quer falar sobre isso? De fato como estou aqui para trazer informações que de alguma forma é interessante para nosso entendimento, e também seja de algum valor para nossos leitores, pois acredito que isso possa ajudar em seu dia a dia.

Para iniciarmos o ” Slogan ” da empresa é conforme abaixo, ou seja, não deixe sua rede como uma tartaruga ( lenta ).

Essa apresentação foi feita pelo CTO – Tim Titus ( Twitter: @gopathsolution ), no qual a empresa foi fundada no ínicio de 2007, com a intenção de prover maior automação com as informações coletadas e analisadas da rede. Para isso foi colocado as facilidades para executar uma ” root-analyze ” através de uma interface, e assim ter uma dado concreto do porque teve aquele problema.

Não posso mentir, entretanto a interface gráfica da ferramenta não é a mais agradável lembrando algumas épocas passadas ( Windows 95 ), entretanto não se preocupe nesse momento com essa ” perfumaria ” e sim com as funcionalidades do software. Em um dos questionamentos fora da apresentação o Tim mencionou que esse design está sendo analisado para trazer uma melhor visibilidade para os usuários.

Introdução

Desta forma, ele apresentou seu conjunto de ferramentas atrelados ao gerenciamento de desempenho, conhecido como TotalView, no qual ele trouxe a historia que essa solução veio depois de ter passado anos como engenheiro de redes, tentanto entender alertas desconectados e informações de pesquisas ( BLOG, sites de Fabricante, etc ) durante os eventos de ” trou****bleshooting “. Talvez você esteja se perguntando eu faço isso muitas vezes durante o dia.

Acredito que não somente você mas eu também já tive diversos momentos pesquisando sobre as razoes por trás daquelas mensagens de sylog, validações dos contadores de erros das interfaces, por isso que PathSolution criou esse conjunto de ferramentas que ajudaria chamar atenção dos Técnicos para os erros das rede e assim fornecer informações mais consolidadas, com passos úteis para resolver.

Para entender um pouco melhor veja apresentação feita pela empresa:

Detalhamento

Para detalhar um pouco mais sobre o produto o TotalView monitora todas as interfaces de um dispositivo de rede e pesquisa em seus 19 contadores para mostrar uma visão completa da saúde de sua rede. Uma das questões que surgiu foi sobre a metodologia para executar captura ” polling “, pois imagina-se o trafego e dados para capturar todas essas informações, entretanto a menção foi trazer que isso pode ser feito através das MIBs, MIBs personalizadas, porém ainda existe menções sobre perca de desempenho da rede através desses ciclos de pesquisa para ferramenta trazer essa analise. Com isso a empresa mencionou que acredita que o SNMP ainda fornece dados muito rico e que estão faltando ainda em soluções de Telemetria.

A questão principal ainda menciona, como o TotalView evita a falta de dados em ambientes grandes se coleta por padrão de 5 minutos? Sua resposta é um pouco diferente de outras plataformas de monitoramento.

PathSolutions então ao invés de enviar uma única solicitação para um switch de 48 portas para percorrer o MIB e analisar as estatísticas da interface, eles enviam uma única solicitação de 512k/interface para as informações, ou seja, muito mais específico. Isso não só torna o monitoramento leve na rede, mas também garante a coleta rápida e completa. Para empresas com ambientes grandes, este método de coleta pode ser um divisor de águas, especialmente quando combinado com as ajudas baseadas em contexto.

Volte ao ínicio

Esse contexto está muito atrelado ao que já foi mencionado anteriormente, ou seja, imagina você chegando em sua plataforma na qual recebeu um email com o alerta, você verifica que seu switch core incrementou muitos ” FCS Errors “, mas que ao mesmo tempo você já tem essa ” Wiki ” associada, onde ela pesquisou em diversos sites e até do fabricante para trazer um dado mais apurado do porque aquele erro ocorreu. Parece meio mágico, mas isso é algo que esta trabalhando-se com as menções de mercado ” Big Data “, ” Automation ” e ” Previsibility “

Você pode conferir com maiores detalhes apresentação do produto e tirar suas próprias conclusões.

Um dos itens que pode se destacar para você é o mapeamento de sua rede conforme descoberto pelo TotalView. É de grande ajuda para que você possa ver onde os problemas estão acontecendo. Infelizmente, Tim disse que o software não foi capaz de exportar essa topologia para ferramentas como o Visio. De todas as imperfeições ( e não houve muitas que eu tenha visto ) esta foi uma grande imperfeição. A razão por trás dessa decisão foi que a maioria das redes estão em uma grande quantidade de mudanças e um documento do Visio só tira foto do que “era” e não do que “é”. Outro ponto para destacar-se que ainda não tem compatibilidade para analises em IPv6. 🙁

Volte ao ínicio

Enfim, em linhas gerais eu acredito que tem ítens para serem desenvolvidos, mas o motor de analise por tras da ferramenta acaba destacando-se para trazer uma visibilidade mais apurada.

Espero que vocês tenham gostado e deixe seus comentários abaixo sobre o que achou e continue nos seguindo que mais conteúdos serão divulgados.

Abs,
Rodrigo

Cisco Meraki – Configuração SNMP – Parte 2

Tue, 05 Feb 2019 00:00:00 +0000

Olá comunidade,

Como exposto em nosso post anterior, vamos seguir mais um passo para que vocês possam interpretar sobre as definições de SNMP em nosso dashboard Meraki.

Abaixo segue a configuração para que possamos receber os alertas e obviamente serem logados para futuras analises ou ações reativas/preventivas para seu ambiente. Como exposto anteriormente, somente poderemos configurar esse campo com um endereço público e definindo a porta do SNMP, para que neste exemplo foi definido como 162.

Vale ressaltar sobre a menção das portas do SNMP na qual trabalhamos com 161 e 162, tendo assim como especificação a 162 sendo a porta de envio dos traps, ou seja, pelo exposto acima meu servidor irá receber as mensagens via a porta definida.

Talvez você pense em relação a segurança e com certeza é algo que devemos nos preocupar. Pois bem, pensando nisso você pode executar a validação e identificar através do Dashboard ( como explicado neste post ) sobre as configurações do Firewall. Para detalhar segue abaixo as origens ( source ) que irão encaminhar os ” traps ” para seu servidor.

Pois bem, abaixo executo uma regra ” Port forwarding ” para que qualquer solicitação na porta mencionada, ela seja re-direcionada para meu IP privado. PS.: Neste caso estou usando porta padrão na perspectiva do ambiente público para este teste, porém como uma preocupação você também poderia mudar essa porta.

Enfim, após todo esse processo você precisa incluir nas definições de seu Dashboard ( Network Wide -> Alerts ) quais alertas serão direcionados para seu ambiente de monitoração. Para isso existe um acrônimo padrão definido como sendo ” snmp “. Segue abaixo um exemplo:

Após essa definição podemos ver em nossa ferramenta de testes os logs sendo populados diretamente no meu servidor. BINGO!!!

Vale lembrar que esse logs muitas da vezes precisam ser tratados pelas ferramentas de gerência, ou vocês trabalharem para que isso seja concatenado de alguma forma, com o intuito de ser melhor visualizado por qualquer pessoa que de fato não tenha um total conhecimento.

Espero que vocês tenham gostado e deixem seus comentários se algo não ficou muito claro nas configurações ou definições desses recursos.

Abs,
Rodrigo

Cisco Meraki – Configuração do SNMP

Mon, 21 Jan 2019 00:00:00 +0000

Olá Pessoal,

Conforme eu havia prometido, precisamos fazer nossas validações relacionadas ao SNMP, bem como a maneira que vamos habilitar esse serviço em nosso Dashboard. Então segue comigo!!!

Para que possamos habilitar o SNMP devemos acessar nosso dasboard e habilitar através de Organization -> Settings -> SNMP

Como mencionado acima estamos habilitando inicialmente a versão 2, apenas para esclarecer o campo de ” Download ” na figura cima, esta relacionado em fazer o download das ” MIBs – Cloud Meraki ” para que você instale em seu servidor de gerência e possa fazer as consultas no ” Dashboard ” e não seria as MIBs dos equipamentos instalados em sua organização. Em relação aos IPs restritos esta relacionado para que você controle as origens que irão fazer as consultas para os devices, pois se pensarmos em trabalhar com V2 as mensagens são encaminhandas em ” clear text “, portanto são medidas de segurança que podem ser adquiridas.

Após isso devemos configurar nossa community, onde devemos ir Network Wide -> General -> SNMP

Vale ressaltar que o acesso SNMP da Meraki apenas suporta requisições ” get “, então nenhuma alteração na configuração do Dashboard pode ser feita usando SNMP. A Meraki usa somente ” community ” para leitura.

Para que possamos fazer algumas validações vamos instalar no Ubuntu a biblioteca de SNMP para capturar alguns logs. Segue abaixo o pacote para instalação no Ubuntu:

sudo apt-get install snmp

Se você deseja colocar no Windows existe uma ferramenta bem simples chamada SNMPWalk, onde é totalmente free e pode ser feito download no site da Solarwinds.

No comando abaixo estou fazendo uma consulta diretamente para o IP de um equipamento na minha estrutura, para qual eu gerencio através do endereço ( 192.168.0.15 ) + especificando a porta. Após esse processo vou obter uma lista gigante de todos os ” OIDs ” desse equipamento, assim consigo garantir que meu serviço de SNMP configurado no meu ” Dashboard ” está funcionando corretamente.

Se desejar, pode fazer especificamente em um “ OID ” e validar que de fato está correspondendo a consulta anterior:

Até o momento vimos que nosso serviço esta habilitado e operacional, entretanto muito de vocês devem estar perguntando. OK, mas como vou receber os “ traps ” para que eu tenha uma gerência reativa dos equipamentos?

Neste caso temos que seguir através de um novo recurso que de fato ele não fica habilitado por ” default ” em nosso dashboard. Para solicitar essa demanda devemos abrir um “ ticket ” com o pessoal de suporte da Meraki, para que seja visto esse recurso. Abaixo mostro como abrir um chamado diretamente de nosso ” Dashboard “.

Posso declarar que o atendimento foi bem rapido, até porque é um chamado muito simples. 🙂

Após a confirmação, podemos observar abaixo o novo recurso operacional e os campos para que possamos configurar. Isso pode ser visualizado através do Network-Wide -> Alerts -> SNMP

Como explicado acima o servidor que irá receber esses alertas somente pode ser configurado através de um endereço público, isso deve-se pois os alertas são gerados através do ” Dashboard “, consequentemente está atrelado com as menções de download das ” MIBs ” para seu servidor de gerência.

Em nosso próximo post, vou demonstrar sobre esses alertas em uma ferramenta. 🙂

Espero que vocês tenham gostado e aguardo seus comentários.

Abs,
Rodrigo

SNMP – Parte 4

Fri, 06 Dec 2013 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso ultimo post, vamos mostrar como podemos configurar os equipamentos para trabalhar dentro de um ambiente proativo e não reativo.

Vamos partir do principio que nosso ” Gerente SNMP “ já esta configurado utilizando alguma ferramenta mostrada anteriormente, ou seja, vamos trabalhar somente em nosso ” Agente SNMP “.

No SNMP a ” community ” é uma palavra-chave compartilhada entre os gerentes e agentes que deve ser utilizada no processo de configuração dos nós. Segue abaixo como podemos habilitar essa configuração:

CiscoRedes(config)# access-list 10 permit 10.10.10.1

CiscoRedes(config)# snmp-server community Cisco RO 10

CiscoRedes(config)# snmp-server host 10.10.10.1 version 2c Cisco

CiscoRedes(config)# snmp-server enable traps

CiscoRedes(config)# snmp-server trap-source Loopback10

CiscoRedes(config)# snmp-server location “Sala RH – Predio 5”

CiscoRedes(config)# snmp-server chassis-id “Router 1941/K9”

Na primeira linha criamos uma ACL para permitir que somente o ” Gerente SNMP “ possa monitorar nosso equipamento, ou seja, se qualquer outro IP que não seja o permitido na ACL não conseguirá capturar as informações de SNMP. Vale lembrar que através de SNMP podemos manipular o equipamento como se estivessemos na console do equipamento. Nas linhas seguintes informamos a community, o endereço da estação gerente, a versão do SNMP, além de habilitarmos o equipamento para enviar traps ao gerente.

Essas traps são mensagens importantes porque por padrão o gerente somente recebe informações do agente mediante solicitação. As traps permitem que os agentes enviem mensagens de notificação ao gerente caso algo inesperado aconteça, como por exemplo a queda de um link. O comando ” snmp-server enable traps “ habilita todas as traps, no entanto existem vários outros parâmetros que nos permitem escolher quais notificações queremos. Podemos consultar cada evento através desse link.

Enfim nas últimas linhas inserimos informações de qual interface vai ser utilizada como origem para chegar ao ” Gerente SNMP “ e localização do dispositivo bem como seu modelo. Essa é uma boa prática para identificar rapidamente o dispositivo na estação gerente.

Baseado nesse comandos já temos nosso equipamento configurado para que ele seja monitorado proativamente, ou seja, se algum evento acontecer nele ( link down, alto processamento, temperatura elevada ) nosso ” Gerente SNMP “ será notificado e desta forma podemos atuar para evitar maiores danos ao ambiente.

Para o próximo post iremos tratar sobre como validar o status de SNMP no ” Cliente SNMP “.

Abs,
Rodrigo

Fonte:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf014.html

SNMP – Parte 2

Thu, 05 Sep 2013 00:00:00 +0000

Olá Pessoal,

Dando sequencia sobre o protocolo SNMP, na qual foi visto anteriormente, vamos hoje tratar sobre MIBs.

Todos os objetos concedidos pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o Gerente e o Agente devem acordar os nomes e significados das operações GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como MIB ( Management Information Base ). O padrão do SNMP não define a MIB, mas apenas o formato e o tipo de codificação das mensagens. A especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, são especificados por um padrão próprio.

Segue o descritivo:

GET = para obter um valor do dispositivo
SET = para colocar um valor no dispositivo

A definição dos objetos da MIB é feita com o esquema de nomes do ASN.1, o qual atribui a cada objeto um prefixo longo que garante a unicidade do nome, a cada nome é atribuído um número inteiro. O SNMP não especifica um conjunto de variáveis, e como a definição de objetos é independente do protocolo de comunicação, permite criar novos conjuntos de variáveis MIB, definidos como padrão, para novos dispositivos ou novos protocolos. Por isso, foram criados muitos conjuntos de variáveis MIB que correspondem aos protocolos como UDP, IP, ARP, assim como variáveis MIB para hardware de rede como Ethernet ou FDDI, ou para dispositivos tais como bridges, switches ou impressoras.

A MIB pode estar no seu gerente ou pode estar no cliente, entretanto como o gerente está consultado constantemente seu cliente a MIB sempre vai ser consultada no destino para obter as informações necessárias para sua visualização. Nós temos a RFC 3418 que irá trazer as informações detalhada das MIBs, entretanto segue uma figura para demostrar de forma mais sucinta:

Nos temos duas versões de MIB. Na MIB-I, ou seja, no primeiro nível da árvore encontram-se os nós que definem 3 subárvores, destinadas aos órgãos responsáveis pela padronização das MIB’s. No segundo e terceiro níveis encontram-se os nós que definem os órgãos responsáveis pela administração de uma determinada subárvore, que no caso apresentado é o DoD

Quando mencionamos sobre um objeto gerenciável teremos uma visão abstrata daquele recurso no disposito de rede. Cada objeto possui características e podemos tratar como:

Um rótulo (label), em formato texto, e uma identificação única denominada Object IDentification ( OID), que é composta por uma seqüência de números que identifica a posição do objeto na árvore da MIB ( por exemplo: 1.3.6.1.4.1.2682.1 – confira na figura acima ).
Atributos: tipo de dado, descrição e informações de status, configuração e estatísticas entre outras
Operações que podem ser aplicadas ao objeto: leitura (read), escrita (write) e comando (set).

Na MIB-II temos uma nova estruturação para gerenciamento na qual foi definida, e adicionou-se a estrutura original várias informações importantes para o gerenciamento de redes propriamente dito. Como facilidade adicional da MIB, na subárvore entreprises(1) dedicada às empresas privadas, definida sob o nó private(4), podem ser solicitadas subárvores aos órgão de padronização destinadas ao uso específico de um fabricante. O uso de objetos dessa subárvore e de objetos da sub árvore SNMP permite a um dispositivo de rede se identificar de forma precisa. Segue abaixo o exemplo.\

Um exemplo que podemos obter através dessas relações de estruturas de árvores seria sobre a interface Ethernet, para qual temos uma MIB específica através da RFC 1643. A MIB para as interfaces Ethernet é identificada pela OID [ 1.3.6.1.2.1.10. ]. Nós podemos pesquisar qualquer OID no próprio site da Cisco que irá trazer informações sobre a estrutura e flags para determinados alarmes que você precise identificar. Segue o link ( http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en )

Baseado nessa estrutura nos podemos identificar e preparar os equipamentos para que a rede trabalhe proativamente e não reativamente, dessa forma podemos nos prevenir de algumas situações antes que elas efetivamente aconteça.

Para o próximo post iremos falar um pouco das ferramentas que tratam sobre esse processo. Aguardem!!

Abs,
Rodrigo

Endereçamento IPV4 – Parte 2

Tue, 19 Jun 2012 00:00:00 +0000

Olá Pessoal,

Conforme mencionado no post anterior de Endereçamento IPV4, nesta vídeo aula iremos falar um pouco mais sobre o assunto, para o qual trataremos sobre o VLSM/CIDR.

A ideia deste post e novamente trazer a aula para os leitores sem ter a necessidade de explicar o assunto apenas escrevendo em nosso post, entretanto no vídeo iremos explicar passo a passo os cálculos e como é feito a dimensão das redes através das varias formas disponibilizadas para execução desse trabalho.

Segue abaixo nossa vídeo aula:

Conforme visualizaram temos alguns exercícios para a prática do VLSM e iremos seguir novamente como no post anterior, no qual para as respostas serão publicadas no post/comentários após atingir 15 ” shares “ em nossa página do facebook. Acesse e compartilhe www.facebook.com/ciscoredes .

Para disponibilizar mais exercícios indico uma página, no qual traz vários exemplos para a prática desse assunto, pois para a certificação CCNA e posteriores esse assunto é o famoso ” arroz com feijão ”

Espero que vocês gostem apesar do vídeo ter ficado um pouco longo, mas devido ao assunto ser extenso e complicado.

PS.: O arquivo pdf com as apresentaçãoes está disponível para download na nossa sessão de arquivos.

Abs,
Rodrigo

Protocolo OSPF – parte 1

Thu, 23 Feb 2012 00:00:00 +0000

Olá Pessoal,

Gostaria de iniciar um assunto que hoje é muito utilizado no nosso dia a dia, e nele temos vários pontos a se discutir e com certeza para aprender. Iremos iniciar uma sequencia de posts para trazer os conceitos desse protocolo IGP que é muito utilizado dentro das corporações.

– Introdução

O protocolo OSPF (Open Shortest Path First), definido pela RFC 2328, é um protocolo IGP (Interior Gateway Protocol), ou seja, desenhado para uso em um Sistema Autônomo Interno ( intra-AS ). O protocolo OSPF foi desenvolvido para atender às necessidades colocadas pelas comunidades da Internet, que demandavam um protocolo IGP eficiente, não-proprietário e operacional com outros protocolos de roteamento.

OSPF baseia-se na tecnologia “ link-state ”, que é bem diferente e bem mais avançada que a tecnologia utilizada em protocolos puramente vetoriais, como o RIP. Como mencionado, nos temos dois tipos de tecnologia que está envolvida com os protocolos de roteamento, que seria link state e vetor distância, veja quais são as diferenças:

Vetor de Distância: Os protocolos que utilizam dessa tecnologia tem como a principal característica a quantidade de saltos, ou seja, a cada ” hop ” para alcançar aquela determinada rede que você deseja, ela será incrementada na distância ” saltos “.
Link State: Os protocolos que utilizam dessa tecnologia tem como a principal característica em trabalhar através do estado do link, ou seja, a métrica inserida para esse tipo de protocolo é baseado em caracteristicas como banda, delay, confiabilidade, carga etc.

Através desses pontos podemos citar as características essenciais que o protocolo utiliza dentro do ambiente:

Não existe limite de saltos para o OSPF
OSPF permite a utilização de VLSM
Podemos fazer utilização de criptografia para a troca das tabelas de roteamento
Toda atualização/anúncio das redes dentro do protocolo são executadas através de endereços multicast
OSPF permite a execução de balanceamento de carga mais eficaz
Dentro do protocolo podemos fazer a utilização de uma hierarquia mais avançada com a utilização de areas. Fazendo dessa forma um método mais controlado de sumarização de rotas e atualizações de tabela de roteamento.
OSPF permite marcações de rotas vindo de outros protocolos externos como BGP, permitindo um rastreamento dessas redes.
Devido a todos esses pontos citados, obviamente que esse protocolo irá fazer uma utilização maior de CPU e memória, devido a diversos pontos adicionais que ele utiliza para controle do protocolo de roteamento, além do que ele consegue montar uma árvore completa da rede.

Após essa breve explicação de OSPF, iremos avançar para nosso próximo post com os conceitos do algoritmo SPF ( Dijkstra ).

Aguardem cenas do próximo capítulo 😀

Abs,
Rodrigo

Route-Servers – Looking glasses

Mon, 13 Feb 2012 00:00:00 +0000

Olá Caros,

Após a necessidade de uma utilização no qual exigia descobrir alguns parâmetros, resolvi escrever esse post para ajudar em alguns quesitos de nosso dia a dia.

O que vocês entenderiam sobre esse termo route-servers ( looking glass )?

Os route-servers são elementos separados das redes reais, de forma que apenas recebem a tabela de roteamento e não anunciam ou roteiam nada. Ou seja, são meros espelhos de rotas (e daí o nome “route-server”) dos roteadores que, de fato, fazem todo o trabalho. É importante ressaltar a diferença entre route-servers públicos (também conhecidos como “looking glass”, e os route-servers de produção, usados nas operadoras para estabelecimento de peering, dentre outras funções. Uma vez mais, a “ versão pública ” destes roteadores não interferem em nada na operação da rede da operadora caso venha a falhar ou mesmo ser invadido por hackers.

Com isso podemos utilizar-se de alguns recursos para exercer alguma validação:

Validar o AS-PATH ( caminho para chegar naquela operadora ) para validar sua rede localmente anunciada
Testar conectividade ( PING ) ou validar o caminho ( Traceroute )
Validar tabela de roteamento
Validar tráfego

Nesse contexto os router-servers tem apenas uma conexão física com a rede propriamente viva, porém ele recebe todas as rotas que são recebidas pelo roteadores de Internet. Porém ele, por si só, não faz nenhuma divulgação para o mundo Internet, portanto se alguém tentar invadir ou algo acontecer com esse equipamento nada será influenciado na Internet, devido a uma grande regra de filtros que bloqueiam qualquer tentativa de ele fazer anúnico ou bloquear algo na nuvem da Internet.

Enfim chega a hora boa :), que seria como acessar esses equipamentos.

Existem alguns sites que trazem esses recursos atualizados e com uma facilidade para executar os comandos de validação necessária para seu problema. No momento eu tenho usado bastante http://bgp.he.net/ que é do orgão Hurricane, porém temos outros sites http://routeserver.org/, http://traceroute.org/ que trazem esse serviço, ou seja, todos mostram a saída ou tabela de roteamento conforme sua solicitação.

Em alguns casos você pode acessar esses equipamentos via telnet e olhando diretamente através de comandos, porém se você não conhece os comandos, podem ficar tranquilos que você consegue visualizar através dos acesso http disponibilizado nas páginas. Portanto pessoal, fiquem a vontade para trabalhar, ou se divertir pesquisando os endereços públicos :D.

Abs,
Rodrigo\

Semana IPV6 – Campus Party

Wed, 08 Feb 2012 00:00:00 +0000

Olá caros,

Gostaria de notifica-lós que estamos em nossa semana IPV6 em conjunto com nossa famosa Campus Party 2012.

Diversos eventos estão acontecendo essa semana, principalmente para os testes com nossos grandes provedores de conteúdo e acesso para testes dentro de uma infra-estrutura IPV6. Os participantes que fazem parte dessa iniciativa é Globo, iG, KingHost, Locaweb,Mastercard, RNP, Tecla, Telefônica, Terra, UOL e USP, porém existem diversas outras empresa engajadas nesse evento.

Na Campus Party que acontece no Anhembi – São Paulo os usuários, terão conectividade Internet de alta velocidade por uma semana, e com IPv6 nativo. Os participantes da Campus Party serão capazes de auxiliar nos testes, gerando tráfego real IPv6 para os sites Web e redes participantes. Neste evento teremos diversas palestras que podem ser assistidas on-line, como se estivessemos no evento. Visite o site e obtenha informações relacionados ao nosso mundo de tecnologia.

Espero que aproveitem e aguardo comentários. 🙂

Abs,

Rodrigo

INTERNET – Da criação ao Domínio

Tue, 27 Dec 2011 00:00:00 +0000

Olá caros,

Espero que não fiquem cansados com a leitura. 🙁

Como todos sabem, hoje o veículo de comunicação mais popular e difundido é a Internet. A I****nternet é um bem necessário para todos os seres humanos que habitam nosso planeta, pois nela temos diversos recursos, facilidades, ganhos de vida, crescimento profissional, divulgação e as vezes falta de privacidade.

Essa facilidade teve inicio na década de 50 à 60 com o desenvolvimento dos computadores, para qual começou com as comunicações ponto a ponto. Nas décadas de 60 à 70, algumas empresas reuniram-se para a criação de uma variedade de protocolos, na qual ficou mais conhecido pela empresa ARPANET. Na década de 80, ou seja, em 1982 foi padronizado um protocolo conhecido como TCP/IP, pelo qual hoje permanece como um dos protocolos padrões para nossa comunicação dentro do mundo da Internet.

Em 1988 a internet foi iniciada no Brasil. As conexões inicialmente foram feitas em setor acadêmico e somente anos depois foi destinada a usuários domésticos e empresas. Em setembro deste mesmo ano, o Laboratório Nacional de Computação Científica, conseguiu acesso a rede conhecida como “ BitNet ”, através de uma conexão de 9600bits/sec estabelecida com a Universidade de Maryland.

Vocês poderiam perguntar o que seria essa rede BitNet?

Foi uma rede remota criada em 1981, para fazer a ligação de duas universidades americanas ( Nova York and Yale ), com o propósito de criar uma conexão rápida e barata entre os meios acadêmicos. Essa rede funcionava através de um protocolo específico criado pela IBM~~,~~ chamado de NJE ( Network Job Entry). Essa rede chegou a alcançar mais de 2.500 universidades e instituto de pesquisas em todo o mundo.

Após alguns meses da integração do Laboratório Brasileiro, diversas faculdades iniciaram suas conectividades com outras Universidades no Brasil, fazendo com que essa rede fosse utilizada entre os meios acadêmicos. A Universidade Federal do Rio de Janeiro e a FAPESP obtiveram sua conexões internacionais com duas universidades americanas, tendo assim, o acesso a informações e divulgações de conteúdo para o mundo internacional. Com a crescente e visualização de um avanço tecnológico no segundo semestre de 1989, o Ministério da Ciência e Tecnologia lança um projeto pioneiro, a Rede Nacional de Ensino e Pesquisa (RNP). Existente ainda hoje, a RNP é uma organização de interesse público cuja principal missão é operar uma rede acadêmica de alcance nacional. Quando foi lançada, a organização tinha o objetivo de capacitar recursos humanos de alta tecnologia e difundir a tecnologia Internet através da implantação do primeiro backbone nacional.

Podemos consultar um site que traz informações sobre esse tráfego. Segue uma foto sobre a troca de tráfego, na qual pode ser consultada através do site informado anteriormente:

O backbone funciona como uma espinha dorsal, é a infra-estrutura que conecta todos os pontos de uma rede. O primeiro backbone brasileiro foi inaugurado em 1991, destinado exclusivamente à comunidade acadêmica. Mais tarde, em 1995, o governo resolveu abrir o backbone e fornecer conectividade a provedores de acesso comerciais.

A partir de 1997, iniciou-se uma nova fase na Internet brasileira. O aumento de acessos a rede e a necessidade de uma infra-estrutura mais veloz e segura levou a investimentos em novas tecnologias. Entretanto, devido a carência de uma infra-estrutura de fibra óptica que cobrisse todo o território nacional, primeiramente, optou-se pela criação de redes locais de alta velocidade, aproveitando a estrutura de algumas regiões metropolitanas. Como parte desses investimentos, em 2000, foi implantado o backbone RNP2 com o objetivo de interligar todo o país em uma rede de alta tecnologia. Atualmente, o RNP2 conecta os 27 estados brasileiros e interliga mais de 300 instituições de ensino superior e de pesquisa no país, como o INMETRO e suas sedes regionais.

Devido a forte crescente desses serviços disponibilizados na internet, hoje temos facilidades para consultar qualquer informação necessária para seu dia a dia, falar com pessoas que estão localizadas em diversos lugares do nosso planeta, informar aos seus amigos de redes sociais sobre seu pensamento, gosto, atitude, obter opiniões em questão de segundos e analisar o conteúdo para decisões necessárias dm nossa vida, disponibilizar informações sobre conteúdos necessários para o desenvolvimento e aprendizagem de cada ser habitável nesse planeta. Com toda essa facilidade no mercado, hoje temos diversos equipamentos que podem ser colocados na Internet para que você consiga de alguma forma obter informação dele ou executar/acessar algo que seja necessário na rede.

Todos esses equipamentos imagináveis que podemos por exemplo ter dentro de nossas residências, já existe disponibilidade para configurar um endereço IP que seja alcancável pela Internet de qualquer lugar. Um exemplo que podemos citar seria a geladeira de sua casa que pode avisa-ló que o refrigerante terminou e notifica-ló para comprar no supermercado ou se ele poderia efetuar a compra através de um site comercial. Em contra partida, devido a essa crescente~~,~~ que quase incontrolável, todos esses equipamentos necessitam de algum endereço, fazendo com que nós tenhamos alcançado quase um BUG de endereçamento, porém todos devem ter lido ou escutado que isso já havia sido pensado a quase 8 anos atrás.

A nova era que estar por surgir pensando em conectividades com o mundo internet, está voltado para uma tecnologia chamada de endereçamento IPV6, para qual nós fomos atendidos até agora pelo endereçamento IPV4, entretanto, a nomenclatura mencionada anteriormente sobre TCP/IP permanece da mesma forma. O domínio das facilidades existentes na internet apenas tendem a crescer para uma vertente de oferecer cada vez mais serviços que possam facilitar a vida de cada um e oferecer uma interatividade maior entre todos os participantes deste globo.

Abs,
Rodrigo

QoS com NBAR – parte 1

Fri, 23 Sep 2011 00:00:00 +0000

Olá pessoal,

Como todos sabem, o assunto de QoS é muito comentando nos dias de hoje, devido a grande utilidade e capacidade de controle que podemos exercer em cima dessa tecnologia. Dentro desse parâmetro irei trazer uma sequência de posts explicando essa tecnologia através de laboratórios com testes práticos.

Nessa primeira parte vamos aprender sobre o protocolo NBAR.

1) Introdução

A tecnologia de QoS foi difundida para que todos pudessem ter um maior controle de trafégo de sua rede, fazendo com que isso gere uma demanda de controle com muito mais granularidade. Em contrapartida, esses métodos exigem cada vez mais de profissionais com conhecimento, para que seja disponibilizado da melhor forma para sua rede.

Pensando dessa forma, a Cisco disponibilizou um recurso chamado NBAR, no qual pode trazer muitos benefícios para o nosso dia a dia. Esse protocolo tem a facilidade de fazer o reconhecimento das aplicações baseado na sua rede, portanto para determinadas aplicações o protocolo consegue identificar esses serviços, diminuindo a necessidade de um total conhecimento de sua rede.

Quando é mencionado a palavra QoS, todos imaginam que essa tecnologia pode resolver o problema de todos, porém precisamos pensar que esses recursos ajudam a melhorar a performance da rede, e para determinadas situações outros pontos precisam ser avaliados dentro da arquitetura de rede, como avaliação de capacidade de banda, avaliação do correto dimensionamento do equipamento, avaliação de desempenho para determinadas aplicações de negócio, análise interna dentro da sua rede local, otimização dentro do ambiente LAN e WAN.

2) Topologia

Nesta topologia a idéia é demonstrar uma rede com 3 roteadores e executar as configurações, referenciando-se as marcações de pacote conforme mostrado na figura.

Figura 1 – Topologia do Laboratório

Todos os equipamentos são Cisco e utilizando a tecnologia do protocolo NBAR para executar as configurações

3) Equipamentos

Neste laboratório estamos utilizando roteadores 1721, 1760 e 2611 disponibilizado em um rack. Para esse contexto iremos ter 3 modelos de IOS para que possamos utilizar funções de QoS com NBAR.

Segue os modelos de IOS utilizados para esse laboratório:

1721:
c1700-entbasek9-mz.124-15.T13.bin
1760:
c1700-ipvoicek9-mz.124-15.T13.bin
2611:
c2600-ipvoice_ivs-mz.124-25d.bin

Para melhor interpretação dos equipamentos podemos consultar as documentações através do site da Cisco. Para o modelo 1721, 1760 e 2611. Todos os equipamentos estão designados como “ End of Life ”.

Para conectividade dos circuitos WAN estamos utilizando placas com interfaces seriais. Toda a conectividade WAN tem a oferecer uma conexão ponto a ponto de um circuito dedicado com encapsulamento padrão utilizado pela cisco HDLC. A placa oferecida para essa conectividade é a WIC-2T que pode ser consultada através do site da Cisco.

4) Funcionalidade

Este laboratório consiste na demostração de uma tecnologia disponibilizada pela Cisco, na qual é referenciada ao protocolo NBAR. Através deste link você pode obter mais informações referenciando-se ao NBAR.

Dentro desse contexto podemos analisar alguns comandos que utilizamos neste laboratório através de documentações da Cisco, para qual pode facilitar o entendimento de todos os recursos disponibilizados. Esse protocolo foi desenvolvido para fazer o mapeamento da rede em produção, com a intenção de facilitar e montar uma estrutura de planejamento para o QoS. Uma configuração coletada automáticamente pode ser aplicada posteriormente nas interfaces desejadas da sua rede. As aplicações que são referenciadas para esse protocolo pode ser consultada através desse link, no qual vai trazer o tipo de protocolo, porta conhecida e qual versão de IOS vai suporta esse recurso.

Como o NBAR é um protocolo default do IOS nós podemos habilitar através de um comando, para que seja identificado o tipo de tráfego que esta passando por aquela interface. A linha de comando para esse recurso seria:

Router> enable
Router# configure terminal
Router(config)# interface ethernet 2/4
Router(config-if)# ip nbar protocol-discovery
Router(config-if)# end

Nessa linha de raciocíonio podemos utilizar esse recurso para eventuais “ troubleshooting “, com a capacidade de demonstrar ao seu cliente que o maior consumo de tráfego esta sendo utilizado em uma determinada aplicação. Neste exemplo podemos avaliar quais aplicações estão sendo descobertas pelo protocolo e qual o consumo em bytes/packets.

Router# show ip nbar protocol-discovery interface FastEthernet 6/0

 FastEthernet6/0
                            Input                    Output
   Protocol                 Packet Count             Packet Count
                            Byte Count               Byte Count
                            5 minute bit rate (bps)  5 minute bit rate (bps)
   ------------------------ ------------------------ ------------------------
   igrp                     316773                   0
                            26340105                 0
                            3000                     0
   streamwork               4437                     7367
                            2301891                  339213
                            3000                     0
   rsvp                     279538                   14644
                            319106191                673624
                            0                        0
   ntp                      8979                     7714
                            906550                   694260
                            0                        0
   .
   .
   .
   Total                    17203819                 151684936
                            19161397327              50967034611
                            4179000                  6620000

Para os comandos de match podemos consultar esse documento e para as validações referentes ao protocol-discovery podemos avaliar por esse documento.

Em nosso laboratório as configurações exercidas para reconhecimento dos protocolos exemplicados foi através desse método:

Router(config)# class-map ICMP
Router(config-cmap)# match protocol icmp
Router(config)# class-map HTML
Router(config-cmap)# match protocol http
Router(config)# class-map FTP
Router(config-cmap)# match protocol ftp

Gostaria de ressaltar que nesse exercíco estamos exercendo a marcação de pacote na saída do circuito de internet ( R1 ) conectado com o mundo exterior, porém essa técnica não é valida para nosso mundo real, pois em nenhum momento o acesso a rede mundial vai entender a marcação desse pacote. Para um entendimento e disponibilidade de recursos internos o exemplo relacionado a HTTP dentro da rede interna seria de mais fácil disponibilização para a demostração do laboratório.

Toda a conectividade desses circuitos foram exercidadas através de uma largura de banda 1,544Mbps e dentro desse valor suposições de valores para cada classe foi definida, reservando as maiores bandas para o tráfego que teria maior demanda nessa simulação. Por padrão do IOS, quando são definidos “ class-map “ e posteriormente criado a “ policy-map “, a banda que fica definida para efeito de cálculo no momento de aplicar “ service-policy “ é de máximo 75% da banda configurada para a interface.

Com isso fiz a definição:

1500K – ( .75 * 1500 ) = 375K

Nesse caso iremos utilizar para efeito de cálculo 1125kbps. Com isso os valores designados para cada tipo de protocolo foi:

HTTP = 500Kbps
SMTP = 150Kbps
FTP = 190Kbps
Management = 10Kbps
ICMP = 10Kbps
Default = 265Kbps

Lembrando-se que esses valores podem ser definidos da melhor forma que você achar dentro da sua rede. Os valores definidos para este exercício foi devido a facilidade de conseguir demonstrar através de um acesso simples ao protocolo HTTP.

Como o protocolo é default do IOS, podemos ter aplicações que não conseguem serreconhecidas através desse recurso automático, portanto devemos fazer o download de um arquivo que a Cisco designou como sendo PDLM ( Protocol Description Language Module ). O NBAR analisa os pacotes e compara eles com as regras existentes no PDLM. Para fazer o download do arquivo segue a instrução ( apenas usuários cadastrados podem fazer download desse arquivo )

Após o download podemos configurar conforme explicação no documento da Cisco:

Router> enable
Router# configure terminal
Router(config)# ip nbar pdlm flash://citrix.pdlm
Router(config)# end

Para validação se o arquivo foi habilitado dentro do equipamento, podemos avaliar através:

Router# show ip nbar pdlm

The following PDLMs have been loaded:
flash://citrix.pdlm

Não é sempre que o PDLM padrão fornecido atenderá nossa necessidades. Você pode querer adicionar suporte para um protocolo de rede específico, que precisa ser classificado e marcado no QoS ou para efeitos de acompanhamento personalizado. Essa pergunta é respondida com a “ PDLM custom “, o arquivo personalizado é chamado de custom.pdlm, que tem que ser carregado e então modificado conforme as exigências do protocolo.

O IOS que pode ter esse recurso personalizado foi construído na versão 12.X, e a Cisco tem introduzido essa personalização, onde usando “ ip nbar custom NAME [parameters] “ comando, você pode definir seus protocolos customizados. Para vocês que querem saber sobre como o arquivo foi carregado e como pode ser alterado segue o link.

Outro recurso que podemos visualizar através do NBAR seria o mapeamento de portas que existem para as aplicações que temos definidas pelas RFCs, porém eu tenho a capacidade de definir para uma determinada aplicação em qual porta ela poderia trabalhar alterando esse parâmetro. Por padrão segue um output resumido:

R2_1721#sh ip nbar port-map
port-map bgp                      udp 179
port-map bgp                      tcp 179
port-map bittorrent               tcp 6881 6882 6883 6884 6885 6886 6887 6888
port-map citrix                   udp 1604
port-map citrix                   tcp 1494
port-map cuseeme                  udp 7648 7649 24032
port-map cuseeme                  tcp 7648 7649
port-map dhcp                     udp 67 68
port-map directconnect            tcp 411 412 413
port-map dns                      udp 53
port-map dns                      tcp 53
port-map edonkey                  tcp 4662
port-map exchange                 tcp 135
port-map fasttrack                tcp 1214
port-map finger                   tcp 79
port-map ftp                      tcp 21
port-map gnutella                 udp 6346 6347 6348
port-map gnutella                 tcp 6346 6347 6348 6349 6355 5634
port-map gopher                   udp 70
port-map gopher                   tcp 70
port-map h323                     udp 1300 1718 1719 1720 11720
port-map h323                     tcp 1300 1718 1719 1720 11000 - 1999
.
.
Omitted

Para executar a alteração da porta para o serviço desejado devemos fazer no modo de configuração global:

R2_1721(config)#ip nbar port-map sqlnet tcp 63000 63001

Um video foi disponibilizado na nossa seção “ Video Aula “ para demonstrar o funciomento desse protocolo. Esses vídeos foram disponibilizados em 3 partes, devido a quantidade de minutos para esse laboratório. Os arquivos de configurações podem ser obtidos da nossa seção Arquivos.

No próximo post irei demonstrar através do WireShark o cabeçalho IP ( ToS ) com a marcação dos pacotes exercidas dentro do nosso ambiente de estudos.

PS.: Agradecimentos a Alis Silva pelo fornecimento do rack.

Abs,
Rodrigo