Snmp on Cisco Redes

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

Cisco Live Magazine – Edição 16 – 2015

Mon, 14 Sep 2015 00:00:00 +0000

Olá Pessoal,

Segue mais uma edição da revista Cisco Live, na qual menciona sobre IoT ( Internet das Coisas ), recurso de UC e o crescimento no mercado de blades.

Segue abaixo a edição 16.

Abs,
Rodrigo

NetRiders – America Latina – 2015

Thu, 14 May 2015 00:00:00 +0000

Olá Pessoal,

Inicia-se novamente as 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 podem participar dessa competição e concorrer no final da competição a uma bolsa de estudos no Vale do Silício, bem como a viagem a San Francisco.

Consulte com maiores detalhes sobre a competição através desse link.

Fiquem atentos que temos o encerramento das inscrições em 22 Maio. A novidade para esse ano que teremos para o CCENT, CCNA e IT Essentials.

Obs.: Fica como obrigação para meus alunos participarem…rsrsrs… 🙂

Abraços
Rodrigo

Congresso OnLine de TI

Mon, 06 Apr 2015 00:00:00 +0000

Olá Pessoal,

Gostaria de divulgar para vocês sobre um evento que irá ocorrer no mês que vem, onde ele vai ser totalmente online e gratuito.

Neste evento eu vou estar palestrando sobre o tema de Redes, mais voltado para Cisco, para qual o intuito é falar sobre protocolo EIGRP, com uma palestra teórica e outra sessão mais prática. O nome escolhido para a palestra é ” Novidades protocolo EIGRP e soluções escaláveis menor custo “

Esse evento terá diversas palestras tanto voltado para o mundo de carreiras, como para o ambiente de infraestrutura, Redes, Microsoft, Programação, etc.

Vale a pena participar as inscrições são totalmente gratuitas. Confira no link http://bit.ly/1D00MTQ

Abs,
Rodrigo

CCNA Store – Venda seu equipamento

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

Boa Noite Pessoal,

Não sei se todos viram os anúncios feitos pela Cisco, sobre essa nova iniciativa onde o principal papel é divulgar a marca, e com certeza oferecer maiores possibilidades para as pessoas que queiram atuar como empreendoras, e seguir com seu próprio negócio sem necessitar de nenhum outro grande parceiro.

O que isso quer dizer?

Não é mais necessário procurar uma Revenda, se você é CCNA e gostaria de trabalhar por sua própria empresa ou mesmo aumentar sua renda mensal, basta cadastrar-se no Portal,criar seu portfólio de clientes e expandir os seus lucros.

A margem de lucro é bem interessante, para se ter uma idéia, de uma venda de R$ 4.000,00 em equipamentos, o CCNA responsável pela transação pode embolsar até cerca de R$ 700,00 em comissão. Mas não só isso, pois o sistema permite ao Empreendedor embutir a sua mão-de-obra no orçamento, permitindo que o CCNA defina qual o seu lucro total na venda dos produtos.

Para obter maiores informações acesse o site http://ccnastore.com.br/

Obs.: Você que ainda não tem o título de CCNA, não fique frustado o importante é sempre continuarmos focado para alcançar nosso objetivo, e que aquele que luta sempre alcança.

Abs,
Rodrigo

Sorteio de Comemoração – Facebook

Wed, 25 Feb 2015 00:00:00 +0000

Olá Pessoal,

Foi realizado no último domingo nosso sorteio relacionado a promoção que estava acontecendo de nossa fanpage, que no momento que alcançaríamos 2000 likes seria sorteado um roteador 1721 conforme anuncio.

Enfim o sorteio foi realizado e o ganhador foi Eden Ricardo Dosciatti ( sorteiefb.com.br/resultado?id=2lBi ). Uma mensagem foi enviada ao ganhador, se ele ainda se interessa pelo equipamento, caso contrario, um novo sorteio será realizado.

Para quem ainda não havia encontrado nossa fanpage segue o link ( https://www.facebook.com/ciscoredes ).

Abs,
Rodrigo

Cisco Live Magazine – Edição 14 – 2014

Tue, 20 Jan 2015 00:00:00 +0000

Olá Pessoal,

Gostaria de divulgar mais uma edição da Cisco Live Magazine – Edição 14.

Nesta edição temos algumas manchetes principais:

ESPECIAL FUTURECOM 2014: Cisco apresenta inovações ligadas às grandes tendências do mercado de TI e Telecom
IOE: Fast IT coloca governo e empresas na era da Internet de Todas as Coisas
SEGURANÇA: Cisco lança solução de UTM exclusiva para América Latina
VOZ DO CLIENTE: Inovação tecnológica dita ritmo de expansão da Cia. Sulamericana de Distribuição
CISCO Intercloud

Segue a edição:

Abs,
Rodrigo

Feliz Natal e um Feliz 2015

Wed, 24 Dec 2014 00:00:00 +0000

Olá Pessoal,

Gostaria de deixar meu recado para todos os participantes do BLOG e Fórum um Feliz Natal e Prospero Ano Novo.

Que nesse Natal você consiga estar junto de seus familiares e que para 2015 todos os desejos sejam realizados e com certeza novas certificações sejam alcançadas. 😉

Abs,
Rodrigo

Atualização da prova CCNP

Mon, 24 Nov 2014 00:00:00 +0000

Olá Pessoal,

Acredito que essa não seja uma notícia nova, entretanto como estou recebendo alguns questionamentos sobre o novo curriculo para a certificação CCNP, resolvi colocar algumas informações para vocês para tentar esclarecer alguns ítens.

As três provas existentes hoje para o CCNP, poderá ser executada no máximo até 29 de Janeiro de 2015, ou seja, qualquer planejamento para executar essas provas após essa data o agendamento será feito apenas para a nova numeração informada pela Cisco ( 300-1XX ).

Nesse caso que vem a grande dúvida, com os questionamentos:

Se eu fiz alguma prova no curriculo antigo vou perder? Não, você não perde nenhuma prova executada no curriculo antigo, portanto você pode seguir normalmente com seu planejamento para execução das provas.
Eu fiz a prova de ” Routing “ ou ” Switching “ tenho que fazer novamente? Não, como informado você não perde nenhuma prova executada no curriculo anterior.
O período para concluir o CCNP vai mudar? Não, a partir do momento que você executou a primeira prova da grade do CCNP começar a contar o período para conclusão da certificação CCNP R&S, que são 3 anos.
O processo de recertificação mudou? Não, o tempo de expiração da certificação CCNP permanece da mesma forma, que por sua vez são de 3 anos de validade.
Estou estudando para a prova de ” Switching “ ou ” Routing “ e não vou conseguir finalizar os estudos para executar a prova até a data limite. Vou perder todo o conteúdo estudado devido a alteração de prova? Não, sinceramente as mudanças de conteúdo para o CCNP são mínimas baseada no curriculum anterior, na qual o que pode se observar é somente a inserção de alguns tópicos voltados para IPv6 ( nenhuma novidade!! ).
Qual o impacto no conteúdo para essa renovação de curriculum? Eu não vejo nenhuma alteração grande dentro dos novos tópicos, como mencionado alguns ítens sobre IPv6 e somente um ítem adicional de VRF Lite para a prova de ” Routing “.
É interessante esperar para executar as provas na versão nova? Isso é uma pergunta muito particular, pois depende muito de seu cronograma de estudos e planejamento para finalização dos estudos. O grande ponto é, você não precisa ficar desesperado para executar alguma prova até a data limite e de alguma forma estar despreparado ( isso leva a perca de $$$ ).

Enfim, coloquei algumas perguntas e respostas para facilitar o entendimento dessa mudança, mas essa alteração nesse curriculo não tem muito impacto para as provas atuais. Se necessitar de mais algum detalhamento sobre essa mudança você pode consultar nesse link e posteriormente analisar os tópicos de cada prova ( Routing , Switching, TSHOOT ).

Espero que isso esclareça um pouco mais sobre essa alteração e possa deixar um pouco mais tranquilo sobre as alterações. 😉

Abs,
Rodrigo

Finalizado Tradução CCNA 5.0

Mon, 17 Nov 2014 00:00:00 +0000

Olá Pessoal,

Apenas com uma rápida notificação, baseado em nosso outro post sobre o conteúdo do CCNA via Netacademy, onde agora já temos a confirmação oficial de que todos os módulos estão traduzidos.

Fonte: Link Oficial sobre a notificação

Agora fica o grande divisor de águas, quando teremos a prova traduzida? Infelizmente, eu não posso informar nada, pois não temos nenhuma notificação oficial da Cisco.

Abs,
Rodrigo

Cisco Live Magazine – Edição 13 – 2014

Thu, 16 Oct 2014 00:00:00 +0000

Olá Pessoal,

Segue mais uma edição da revista Cisco Live Magazine. As principais manchetes:

ATENDIMENTO PERSONALIZADO: Com recursos de videoconferência, Caixa do Futuro rompe a limitação física e permite oferecer serviços a qualquer hora e lugar
SEGURANÇA: Soluções embarcadas estarão em todos os projetos
SERVIDORES UCS: Plataforma começa a ser produzida no Brasil, se unindo a Roteadores, Switches e Access Points WiFi
VOZ DO CLIENTE: Algar Telecom monta projeto WiFi usando Access Points produzidos no Brasil

Segue abaixo:

Abs,
Rodrigo

Relatório Anual de Segurança – 2014

Tue, 10 Jun 2014 00:00:00 +0000

Olá Pessoal,

Gostaria de publicar um relatório de segurança executado pela Cisco, onde com o crescente aumento das ameaças cibernéticas, o modelo de segurança das empresas deve ser holístico e contemplar, além da rede, dispositivos móveis, endpoints e ambientes virtuais e em nuvem.

O documento é um pouco extenso, mas vale a pena visualizar onde temos nossos maiores ” vilões “ em nossa estrutura, principalmente com a forte crescente do BYOD ( como já mencionado em nosso BLOG ). Hoje sabemos que o sistema Android é o mais vulnerável, bem como as aplicações em Java, em contra-partida tivemos um descendente em relação a SPAM.

Para visualizar o relatório, você pode acessar através de nossa seção Arquivos ou fazer o download direto através desse link.

Baseado nessa informações o que você achou dos resultados? Foi esperado?

Abs,
Rodrigo

CCNA Exam Simulation

Mon, 02 Jun 2014 00:00:00 +0000

Olá Pessoal,

É com grande satisfação que gostaria de compartilhar com vocês sobre essa iniciativa que nosso grande amigo Adilson Florentino esta promovendo.

A ideia é que teremos um simulado ( 24 de Agosto ) com o conteúdo da nova prova do CCNA on-line, ou seja, para participar, basta doar qualquer quantia, e todo o valor arrecadado será utilizado para a compra de um ou mais vouchers do Exame. Os doadores receberão acesso exclusivo ao Portal Netfinders onde poderão usar os Fóruns de Aula para sanar suas dúvidas em relação aos tópicos cobrados pelo Exame.

Para maiores detalhes acesse ( http://www.netfindersbrasil.blogspot.com.br/2014/05/ccna-exam-simulation-day.html ).

Participe e teste seus conhecimentos. Vale lembrar que em nosso BLOG temos também QUIZ, para testar seus conhecimentos. Confira!!!

Abs,
Rodrigo

Hangout – Esgotamento IPV4 no Brasil

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

Olá Pessoal,

Aproveitando para divulgar no dia 16 de Abril, as 15h, o NIC.br promove o Hangout: Esgotamento do IPv4, com Ricardo Patara e Antonio M. Moreiras.

Marque em sua agenda e acesse http://ipv6.br/aovivo/. Não é necessária inscrição prévia. É um evento “ online ”, ao vivo via Internet, e você poderá tirar suas dúvidas no chat. O esgotamento dos endereços IPv4 não alocados se aproxima e por isso é importante explicar o que implica esse momento, quais alternativas existirão e principalmente a importância de estar preparado para o futuro, que é o uso do IPv6.

Serão apresentados dados sobre distribuição dos Recursos Internet, regras existentes e que entrarão em vigor e iniciativas do NIC.BR em relação ao IPv6.

Para uma previsão da data de esgotamento acesse http://ipv6.br/estatisticas/.

Abs,
Rodrigo

Palestra – Vantagens Nova Certificação Cisco

Sat, 29 Mar 2014 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso BLOG, eu fui dar uma palestra em um evento do Senac denominado ” Road Show TI “. Essa palestra foi denominada como ” Vantanges da Nova Certificação Cisco “, na qual eu trago informações sobre NetAcademy, Mercado no Brasil e ítens sobre os novos tópicos adicionados / removidos no CCNA.

Essas palestras foram executadas nas cidades de Mogi-Guaçu e Araçatuba. Agradeço a participação de todos e espero que seja útil para nossos leitores do BLOG.

Se desejar fazer download da apresentação, pode consultar na seção de arquivos onde estar disponível para download, ou fazer o download diretamente.

Abs,
Rodrigo

Campus Party 2014

Fri, 31 Jan 2014 00:00:00 +0000

Olá Pessoal,

Estamos no final da semana, mas vale lembrar que essa semana esta tendo a Campus Party na qual teremos o encerramento no dia 02/01. Ela esta na 7. edição, na qual o objetivo é a troca de informações, muito conhecimento que é trocado durante as palestras, workshop, fórum e etc.

Se quiser saber mais sobre o evento visite o site Campus Party e verifique alguns pontos sobre os fóruns ( Marco Civil da Internet, Segurança ). Enjoy it!!!

Abs,
Rodrigo

BLOG com QUIZ

Sat, 16 Nov 2013 00:00:00 +0000

Olá Pessoal,

Gostaria de divulgar mais um diferencial em nosso BLOG para nossos participantes, para qual agora teremos um QUIZ com perguntas baseado nos conceitos de CCNA e um QUIZ como sendo considerado básico em redes.

Nosso QUIZ pode ser executado por qualquer usuário que acessar nosso site, entretanto somente os usuários cadastrados vão poder executar o mesmo quiz mais de uma vez.

Ele foi baseado em 4 níveis para qual teremos:

– Básico de Redes

– CCNA ( parte 1 , 2 e 3 )

Para você ver uma demonstração do nosso quiz é necessário somente acessar o link ou pode acessar através do nosso menu.

Nesse sistema todos os questionários estão baseados em 10 questões, e os mesmos vão trazer no final a nota e bem como quais foram os erros que vocês comentaram para que na próxima tentativa você consiga alcançar a pontuação máxima.

Espero que vocês gostem e aproveitem para divulgar para seus amigos.

Atenciosamente,
Rodrigo

GNS3 com Switching

Fri, 15 Nov 2013 00:00:00 +0000

Olá Pessoal,

Não sei se todos vocês já viram a noticia sobre o suporte do GNS3 para Switching, entretanto segue um pouco dos detalhes desse avanço para esse software.

A versão 3.1.0 do GNS-3 irá incluir suporte a switches. Segundo os mantenedores do projeto, ao contrário do que muitos pensavam, a emulação de switches na plataforma sempre foi possível, entretanto, demandaria um nível de configuração no lado cliente que tornaria este recurso praticamente impossível de ser usado pela maioria das pessoas.

A nova versão do GNS-3 (3.1.0) deverá ser lançada já no início de 2014. Será liberado uma versão “beta” para teste no dia 20/11, apenas para os que solicitaram convites (e se ainda houver convites disponíveis). Para entrar como “beta-tester” da nova versão, clique aqui.

Obviamente, no início, espera-se que vários bugs sejam encontrados, mas isso vai sendo acertado com o passar do tempo. O que importa é que, agora, haverá uma alternativa, de fato. Até o momento, a única ferramenta de simulação que oferecia suporte a switches multi-layer no nível CCNP ou mesmo CCIE era o IOU, da Cisco (que nunca foi disponibilizado oficialmente pela empresa). Agora, com a nova versão do GNS-3, os estudos rumo ao CCNP ou CCIE ficam muito mais fáceis.

O importante é esperar para vermos se isso de fato vai virar realidade para todos nós que estamos ansiosos para conseguir emular switch em nossos estudos. Espero que aproveitem a dica.

Abs,
Rodrigo

Endereço personalizado para Google+

Fri, 01 Nov 2013 00:00:00 +0000

Olá Pessoal,

Gostaria apenas de notificar que agora temos nosso link personalizado no Google+ para nosso BLOG. Nada foi alterado relacionado ao nosso conteúdo, entretato para memorizar mais rapidamente o nome ficou mais fácil. Nosso BLOG na rede social sempre sendo seguido pelos nossos leitores.

Agora o link para google+ é http://www.google.com/+ciscoredesbr

Abs,
Rodrigo

5 Anos como Instrutor

Wed, 18 Sep 2013 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com todos um reconhecimento que a Cisco esta distribuindo esse ano para todos os instrutores que estão completando alguns anos de dedicação a essa função, que é muito reconhecedora pelo fato de ensinar ao próximo aquilo que você tem de mais valioso ” conhecimento “.

Não posso negar que nesses 5 Anos como Instrutor ensinei muitos alunos e juntos conseguimos que cada um com dedicação e esforço alcançasse a certificação. Eu gosto de lembrar que também aprendi muito muito com meus alunos, trazendo informações e ideias novas a cada dia.

Parabéns a todos os instrutores e alunos.

Atenciosamente,
Rodrigo

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

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

BLOG para Mobile

Mon, 12 Aug 2013 00:00:00 +0000

Olá Pessoal,

Após o anúncio de nosso fórum o nosso BLOG também está adaptado para todo tipo de acesso, ou seja, nossos usuários que gostam de acessar de seus dispositivos móveis e não gostam de perder as funcionalidades, bem como ficar visualizando em uma resolução não muito adequada devido ao tamanho da tela, nós estamos com essa funcionalidade habilitada para que vocês usuários possam acessar de qualquer equipamento nosso BLOG/Fórum com o máximo proveito.

Espero que gostem!!!

Segue algumas fotos:

Abs,
Rodrigo

Fórum visualizado via Mobile

Wed, 07 Aug 2013 00:00:00 +0000

Olá Pessoal,

Como todos devem saber nos temos nosso fórum que funciona através desse link, para qual discutimos os assuntos pertinentes e duvidosos que possam surgir em nosso dia a dia, bem como dicas, classificados entre outros.

A dica aqui é para quem visualiza o fórum através do Android ou iPhone. O fórum utiliza-se através de um aplicativo que pode facilitar a visualização através de uma ferramenta chamada ” Tapatalk “, na qual irá trazer um aplicativo para que seja instalado no tablet, phone ou algum dispositivo móvel. Devido a isso você pode ter a facilidade de navegação, bem como todas as funções como se estivesse no seu desktop. Vale a pensa conferir.

O software pode ser visualizado através do Play Store ou Apple Store.

Segue as telas de visualização:

Abs,
Rodrigo

SNMP – Parte 1

Tue, 07 May 2013 00:00:00 +0000

Olá Pessoal,

Já faz um bom tempo que não posto algo como nossos post anteriores descrevendo as tecnologias/recursos, portanto hoje inicio mais uma sequência para explicar um pouco sobre o protocolo SNMP ( Simple Network Manager Protocol ).

Introdução

O SNMP veio facilitar a forma de administrar e gerenciar ativos na rede, é um protocolo simples, mas poderoso com recursos padronizados para que possa comunicar-se com roteadores, swtiches, impressoras, etc. Através dele é possível enviar dados em um determinado “ local ” da rede para corrigir possíveis problemas, ou mesmo obter informações sobre um roteador ou interface da rede. \

Protocolo SNMP

O protocolo utilizado em redes IP com a finalidade de gerenciar e obter informações de seus recursos da rede, bem como saber se a rede está funcionando e também gerenciar de forma a prevenir possíveis problemas na infraestrutura da rede. O gerenciamento funciona de forma ” Cliente-Servidor “, ele utiliza-se de um agente (Servidor) que comunica-se entre os aplicativos de gerenciamento (Cliente), o agente envia dados para seus “ clientes ” que respondem de acordo com a solicitação do agente, reenviando os dados com o conteúdo das respostas coletadas estruturando as informações em um MIB (Mananger Information Base).

MIB é uma forma de gerenciar as informações para que o agente possa gerenciar equipamentos diferentes em uma rede. As informações que são fornecidas e como o agente e os aplicativos irão acessar os dados é deterninado pela MIB . Dentro da MIB existem também os ODIs (Object Identifier), que são responsáveis pelo endereçamento definido de cada informação dentro da MIB, por este motivo a MIB é comumente chamada de “ Árvore ”, pois o ODI estrutura as informações de uma forma hierárquica como nome, sintaxe, definição permissões de acesso, status e uma breve explicação.

Diferenças entre as Versões

O SNMP hoje já esta na versão 3 que ao longo de sua vida muitas melhorias foram aplicadas para torna-se um sistema mais seguro e confiavél.

A versão SNMPv1 ( criada em 1988 ), tinha muitos problemas de segurança, pois qualquer um podia ter fácil acesso ao agente, pois a senha era passada no formato de um texto puro, não tendo nenhum outro tipo de controle para acesso ou forma segura de transitar as informações em sua rede. A versão SNMPv2 oferece uma boa quantidade de melhoramentos em relação ao SNMPv1 como operações adicionais ao protocolo , melhoria de performance, no entanto seu problema de segurança ainda era seu principal vilão.

Finalmente na versão SNMPv3 foi atribuído uma forma codificada no tráfego dos dados na rede, melhorando a segurança. Uma das modificações mais radicais na versão 3 é o abandono da ideia dos gerenciadores e agentes, que à partir desta versão passam a ser denominados como entidades do SMNP. Cada entidade passa a ser um mecanismo do SNMP em uma ou mais aplicações do SNMP. O mecanismo é formado por 4 componentes:

– Dispatcher = Escalonador, tem como missão enviar e receber mensagens, verifica a mensagem e envia para Message Processing Subsystem.

– Message Processing Subsystem = Subsistema de Processamento de Mensagens, este pepara a mensagem a ser enviada e extrai as informações recebidas.

– Security Subsystem = Sistema de Segurança, oferece recursos de autenticação e recursos de privacidade.

– Acess Control Subsystem = Sistema de controle de Acesso, responde aos controle de acesso dos objetos pela MIB.

Espero que vocês tenham gostado do nosso primeiro post sobre SNMP e no post seguinte iremos falar sobre MIBs e especificações.

Abs,
Rodrigo

Novo Exame CCNA – Anunciado

Mon, 15 Apr 2013 00:00:00 +0000

Olá Pessoal,

Acredito que essa notícia não seja muito nova, pois esse anúncio já foi feito algum tempo atrás, entretanto devido a correria acabei não conseguindo publicar para vocês.

Enfim, os novos exames CCNA foram anunciados pela Cisco e irá atender ao nosso novo conteúdo 5.0 conforme publicado em nosso post. A Cisco não apenas inovou no conteúdo, como também irá alterar a numeração da prova da famosa 640-X para agora como sendo 200-X.

A certificação CCNA tradicional passa a ser chamada oficialmente de CCNA Routing & Switching. A prova atual – 640-802 – poderá ser realizada até 30-09-2013 (isto vale para a prova em Inglês, a versão em português, como ocorreu em outras transições no passado, deverá ficar no mínimo mais uns 8 meses no ar, o que significa que a prova como a conhecemos deverá estar disponível em português até o primeiro/segundo semestre de 2014).

Assim como é feito hoje, continuará sendo possivel concluir o CCNA em duas etapas com as provas de ICND1 e ICND2 ( agora nas versões 100-101 e 200-101, respectivamente.

A Certificação CCENT (ICND1 – a primeira metade do CCNA tradicional) também passou a ser oficialmente pré-req para os CCNAs Voice, Security, Wireless e o CCDA. Segue um exemplo:

Não fiquem assustados, pois o conteúdo teve suas inserções necessárias para enriquecer e valorizar cada vez mais essa certificação. Para maiores informações confira no site da Cisco ( http://www.cisco.com/web/learning/exams/list.html ).

Abs,
Rodrigo

Pesquisa IDC – Área de Tecnologia

Fri, 15 Mar 2013 00:00:00 +0000

Olá Pessoal,

A Cisco publicou os resultados de uma pesquisa encomendada à IDC sobre o mercado de redes e a formação de mão-de-obra para a América Latina até 2015.

[gview file=”https://www.ciscoredes.com.br/wp-content/uploads/Cisco_Networking_Academy.pdf”]

É muito interessante verificar que a Cisco está preocupada não só com as tecnologias e expandir a participação no mercado, mas também está preocupada se haverá pessoas para planejar, configurar, instalar, operar e dar suporte à esses equipamentos e redes.

Vale a pena conferir

Abs,
Rodrigo

Cisco anuncia EIGRP ” Free “

Sat, 16 Feb 2013 00:00:00 +0000

Olá Pessoal,

Enfim a Cisco anunciou que o seu protocolo de roteamento que era privado e somente rodava nos equipamentos será de uso o IETF.

O que isso representa? O famoso protocolo EIGRP será padrão para todos os equipamentos como hoje já temos para o protocolo OSPF.

Veja o anúncio feito no Cisco Live de Londres.

O que vocês acham desse anúncio?

Abs,
Rodrigo

CCNA Video – 5.0

Sat, 09 Feb 2013 00:00:00 +0000

Olá Pessoal,

Segue um vídeo explicando as mudanças que irão ocorrer no CCNA 5.0.

Vejam e deixem seus comentários.

Abs,
Rodrigo

Cisco Redes – Sorteia Cisco 1721

Wed, 30 Jan 2013 00:00:00 +0000

Olá Pessoal,

Para promover cada vez mais nosso BLOG e desta forma conseguir disseminar cada vez mais as informações para todos, vamos efetuar 0 sorteio de um equipamento Cisco através de nossa fanpage no facebook ( facebook.com/ciscoredes ).

O equipamento escolhido é um modelo bem conhecido por todos um Cisco 1721 com fonte de alimentação e cabo de console. As fotos do equipamento pode ser visualizada através do link ( Flickr – Sorteio ).

As regras para participar está em nossa página do facebook.

Participe!! Compartilhe!!

Abs,
Rodrigo

Nova versão da prova CCNA

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

Olá Pessoal,

Como era esperado a nova versão da prova do CCNA foi anunciada, entretanto ela somente menciona o conteúdo em Inglês. Nesta nova versão teremos algumas atualizações no conteúdo, principalmente relacionado ao conteúdo de IPV6 e algumas inserções adicionais sobre tecnologias de voz, wireless e datacenter. Exatemente DATACENTER, isso se deve também a nova certificação criada pela Cisco no nível de Associate que é o CCNA Data Center, que vocês podem conferir nesse link.

Essa alteração tem previsão de iniciar-se em Junho de 2013 e a finalização para Dezembro de 2013.

Alguns pontos mencionados na mudanca do CCNA:

Integração do IPv6 e IPv4 no projeto, configuração, gerenciamento de redes e switches
Utilização de comandos Cisco IOS 15.X para configurar e gerenciar dispositivos de rede
Atualizações tecnológicas avançadas incluindo voz, wireless, segurança e data center
Melhor análise psicométrica dos itens no exame final
Apoio à mobilidade que permite o acesso aos texto e gráficos em plataformas móveis, incluindo a Apple iOS, Android, do Google, e dispositivos Windows 8
Cisco Netspace integrado para melhorar a comunicação, colaboração e experiência do usuário para os alunos e instrutores

Lembrando-se que para as pessoas que estão estudando em Português esse material leva em torno de 1 ano para ser traduzido e populado no NetAcademy, bem como a alteração da prova em português. Portanto não fiquem preocupados que ainda temos um grande período dessa prova 640-802 em Português.

Fonte:

Imakenews

Abs,
Rodrigo

Fórum Operacional!!!

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

Olá Pessoal,

Gostaria de notificar que nosso fórum está operacional e aberto as discussões para os diversos tópicos criados. Você pode acessar-lo através do menu superior ” Forum “ ou através do link direto www.ciscoredes.com.br/forum .

Veja e confira abaixo como esta o visual:

Lembrando-se que para os usuários que já eram participantes e tinham usuários registrados em nosso BLOG terá que executar alguns processos para permanecer com o mesmo usuário, porém terá que sincronizar as duas bases de dados com o mesmo usuário / senha.

Esse processo pode ser visualizados através de nosso post.

Entre e participe desse novo recurso

Abs,
Rodrigo

Novidades no BLOG!!!

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

Olá Pessoal,

Enfim gostaria de anunciar mais uma ferramenta que temos disponibilizado em nosso site. Eu já estava tentando habilitar esse Fórum à algum tempo atrás, entretanto eu havia montado todo o site, mas no final não funcionou a integração da base dados entre as duas ferramentas. Devido a este fato tive que montar um novo Fórum para conseguir integrar as duas base de dados ( BLOG e Fórum ).

Em nosso Fórum temos diversos tópicos que poderão ser colocados as perguntas / discussões na qual iremos conversar sobre os problemas do nosso dia a dia e também dúvidas que podemos tirar com todos os participantes. O Fórum é uma ferramenta que agrega muitos valores, conhecimentos, dicas e sempre temos diversos assuntos sendo abordados para qual não conseguimos demonstrar diariamente em nosso BLOG.

Como nós já tínhamos usuários cadastrados em nosso BLOG, vocês precisam seguir algumas dicas para que a user/senha cadastrada no BLOG seja populada na base de dados do Fórum, fazendo desta forma um login único para ambas as plataformas. No primeiro passo você deve selecionar ” I forgot my password “

Você será direcionado para a página do Fórum conforme abaixo:

Nesses campos você deve preencher com suas informações cadastradas em nosso BLOG, lembrando-se que o user / e-mail tem que ser idêntico ao cadastrado no BLOG, pois você irá receber um e-mail automático do Fórum com uma nova senha para você registrar e autenticar-se. Com isso você irá ter permissão com o mesmo user, porém agora com as senhas sincronizadas. Você poderá alterar sua senha após esse processo para sua senha que melhor desejar. Depois de logado você pode ir ao Painel de Controle do Usuário -> Perfil – Informações de Registro.

Nosso Fórum pode ser acessado através do nosso Menu Superior ou através do link direto.

Espero que vocês participem e contribuam para nosso Fórum, pois ele foi feito pensando em vocês para ajudar cada vez mais nossos participantes e integrantes desse BLOG que cresce os acessos a cada dia. Tenho muito a agradecer vocês que participam e divulgam nosso trabalho.

Abs,
Rodrigo

Laboratório Estudos para CCNA

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

Olá Pessoal,

Após ler uma dica em um blog venho aqui divulgar um manual em PDF com 09 Laboratórios que revisam o conteúdo cobrado no exame Cisco CCNA 640-802.

Para quem está se preparando para prestar o exame 640-802, uma boa dica é fazer os Labs propostos no material disponível para download aqui.

Segue abaixo a Lista dos Labs Propostos:

Lab 1 (Basic IOS of Router + Security)
Parts Basic Fundamentals of LAN
1a – Configure Basic Password and Hostname – pg 6
1b – User Authentication – pg 7
1c – Telnet Password – pg 7
1d – Configure Banner – pg 8
1e – SSH Configuration – pg 8
1f – Switch Static IP address Configuration – pg 9
1g – Verify the SSH Session – pg 10
1h – Configure VLAN & assign interface – pg 12
1g – Port Security – pg 15

Lab 2 (Basic IOS of Switches + Security)
Parts Basic Fundamentals of WAN
2a – Configure IP address – pg 19
2b – Configure Telnet & User Based Authentication – pg 21
2c – Configure SSH Server – pg 23
2d – Configure Serial Connectivity – pg 25
2e – Configure Static Routes – pg 27
2f – Configure PPP – pg 30

Lab 3(VTP and STP)
Parts VTP
3a – Configure VTP Server and Clients – pg 34
3b – Verify VTP – pg 35
3c – Configure & Verify STP – pg 36

Lab 4(Routing Protocols)
Parts Routing Protocols
5a – EIGRP – pg 41
5b – OSPF – pg 44

Lab 5(Security & Port Mapping)
Parts Access-list and Nat
5a – Named Based Access-List – pg 47
5b – Static Nat, Dynamic Nat, PAT – pg 50

Lab 6 (Wide Area Network)
Parts Frame Relay
6a – Configure Hub and Spoke – pg 61

Lab 7 (Inter V LAN Routing)
Parts INTER VLAN ROUTING
7a – Configure Inter V LAN Routing – pg 68

Lab 8 Configure IP V6 to IP V4 Tunnel
Parts IPV6
8a – Configure EIGRP for IPv4 – pg 81
8b – Create a 6 to 4 Tunnel – pg 81
8c – Configure IP V6 static Routes – pg 82

Lab 9 (Secure Device Manager)
Parts Secure Device Manager
9a – How to Install SDM – pg 84
9b – How to configure SDM – pg 87
9b – Configure DHCP Server – pg 89

PS: O Lab de IPv6 na verdade vai além do que é cobrado no exame

Espero que aproveitem e seja uma base de consulta para consolidar os conhecimentos para executar a prova do CCNA.

Fonte:
http://netfindersbrasil.blogspot.com/2012/11/ccna-lab-manual.html#ixzz2CbHS7Yq3

Abs,
Rodrigo

O que seria Proxy-ARP?

Wed, 24 Oct 2012 00:00:00 +0000

Olá Caros,

O Proxy-arp é um método onde um determinado host, que pode ser um router ou firewall por exemplo, responde um arp request em nome de outro host. Este protocolo ( RFC-1027 ) foi desenvolvido no final dos anos 80 pelo Departamento de Ciências da Computação da Universidade do Texas em Austin por necessidade deste em segmentar sua rede de computadores. Porém, naquela época, nem todos os devices de rede podiam ter seus endereços de redes subnetados, ou seja, um endereço classe A não poderia ser dividido em duas, três, doze, etc … redes diferentes pois o dispositivo somente reconhecia a classe de seu IP.

Com o método de Proxy-ARP, foi possível que com um endereço de classe A configurado em diversos hosts com máscara padrão para esta classe fossem segmentados por routers ou firewalls que tivessem o método de Proxy-ARP implementado. Como exemplo de seu funcionamento, temos a topologia abaixo, onde o device Router possui o proxy-arp habilitado com o comando “ip proxy arp” na interface Ethernet 0. Este comando é habilitado por default em devices Cisco, e é recomendado que esteja sempre desabilitado caso seu uso não seja necessário.

O host A ( 172.16.10.100 ) na subnet A quer enviar pacotes para o host D ( 172.16.20.200 ) na subnet B. Como mostrado no diagrama, o host A possui máscara de rede classe B ( 255.255.0.0 ). Isso significa que o host A acredita estar em uma rede diretamente conectada com toda rede 172.16.0.0/16. Quando o host A necessita se comunicar com qualquer device que acredita estar diretamente conectado, ele envia um ARP request ( o famoso pacote “Who has IP_x.x.x.x ? Tell to x.x.x.x ).

Porém, como um arp request é um pacote broadcast, e por default routers não propagam broadcast, este request nunca chegará ao host D. Porém, como o device Router conhece a subnet onde o host D está, o Router em si irá responder o arp-request enviado para o IP 172.16.20.200, como sendo o mac-address 00-00-0c-94-36-ab, e todos os pacotes enviados do host A para o host D terão o fluxo host_A-> Router-> host_D. Porém, tudo isso será transparente para o host A e host D.

Muito bem , vamos abolir os gateways então ??? Nada disso !

Há muitas desvantagens em se usar constantemente Proxy ARP, entre elas o imenso Flooding de solicitações ARP em sua rede e problemas relacionados a segurança e propriamento processamento que podem utilizar-se do equipamento local.

Abs,
Rodrigo

Fonte:
http://under-linux.org/blogs/rvsimoes/proxy-arp-o-que-e-e-como-funciona-546/

Mudanças no Licenciamento do IOS

Fri, 12 Oct 2012 00:00:00 +0000

Olá Caros,

A partir da versão 15, cada caixa Cisco terá uma imagem universal com todas as features inclusas, bastando comprar uma licença ativar os recursos desejados. Como isso irá impactar em nossas vidas ???

Para quem não sabe, o IOS 12.4 já foi descontinuado há algum tempo e seu sucessor, o IOS 15, trabalha com um esquema de licenciamento bem diferente da versão anterior, conforme ilustra a figura abaixo:

Agora temos uma única imagem para cada plataforma (2900, 3900 e assim por diante). Todas as features suportadas pelo hardware já estão lá, basta adquirir a licença correta.

Fica dificil assim uma empresa comprar uma caixa com IOS IP Base (uma imagem “pé duro” sem direção, trava, desembaçador etc …) e fazer um upgrade pirata com um IOS Advanced IP Services.

Esta forma de licenciamento é muito parecida com o que já vinha ocorrendo com o Cisco ASA, você precisa comprar a licença, receber uma PAK Key em um pedaço de papel, registrar esta chave no Cisco.com para receber uma chave de ativação e entrar com ela no roteador. Ufa !!!

Caso haja problemas em uma caixa e você precisa ativar as features adquiridas em um equipamento backup, é necessário transferir a licença de um hardware para outro.

Maiores informações sobre como realizar os procedimentos acima, clique aqui.

Será o fim do uso dos IOS piratas ou apenas trocaremos o uso de IOS priratas por licenças piratas ? Acredito que é bem mais prático apenas ativar as features novas do que trocar o IOS da caixa mas, será seguro ???

O que vcs acham ???

Abs,
Rodrigo

Fonte:
http://etherealmind.com/ios-15-licensing-how-we-work/

BLOG no Google+

Tue, 02 Oct 2012 00:00:00 +0000

Olá caros,

Agora temos como criar páginas no Google+, e como nosso BLOG sempre está na frente vocês já podem adicionar nosso site nessa plataforma e receber as notícias de nossos posts.

Você pode acessar nossa página e clicar seguir, que automaticamente será adicionado ao nosso grupo.

https://plus.google.com/118196174945142341720

Abs,
Rodrigo

Novo Padrão Wireless

Wed, 19 Sep 2012 00:00:00 +0000

Olá pessoal,

Gostaria de trazer uma informação sobre uma nova tecnologia que está sendo visualizada para 2013. Essa tecnologia é sobre a forma de transmissão do formato Wireless, ou seja, essa nova tecnologia tem uma capacidade maior de throughput do que a nova que estamos utilizando hoje ( 802.11n ).

Então, qual é essa nova tecnologia?

Esse novo padrão é o 802.11ac, no qual irá transformar diversos conceitos dos já implementados do 802.11n, entretanto nesse novo formato iremos utilizar apenas a frequência de 5GHz, ao contrário do ” n ” que utilizamos ambas as frequência 2.4GHz e 5GHz. Essa nova tecnologia está sendo chamada ” Gigabit Wi-Fi “, pois o throughput que deseja alcançar em determinados equipamentos como um laptop é de 680Mbps efetivos é quase 1Gbps em camada física. Para os smartphones pode-se chegar a 210Mbps efetivos, ou seja quase 10 vezes mais do que conseguimos alcançar nos equipamentos de hoje.

Como nos sabemos toda essa demanda das redes wi-fi e devido ao grande crescimento de equipamentos como telefones, tablets e propriamente a mobilidade que devemos oferecer para essas redes, fazendo com que cada vez mais seja exigido uma largura de banda maior para trafego de video, voz, dados. Segue um gráfico explicando sobre os produtos certificados pela WI-FI Alliance.

Para explicar um pouco mais sobre a tecnologia segue um vídeo:

Se você teve interesse sobre esse novo formato, temos uma sessão do Quinta as Quinze ” Rede WI-FI uma nova geração ” explicando com mais detalhes sobre essa tecnologia 802.11ac, para qual podemos entender sobre aquilo que vamos enfrentar em 2013.

Abs,
Rodrigo

Cisco ACL

Sun, 19 Aug 2012 00:00:00 +0000

Olá Caros,

Gostaria de trazer mais um assunto que enfrentamos em nosso dia-a-dia e está sendo um dos tópicos mais cobrados recentemente na prova CCNA.

A famosa ACL ( Access Control List ) é um dos recursos que podem ser utilizados em diversas funcionalidades dentro dos equipamentos Cisco, como switches e roteadores.

Nesse momento vou apenas mostrar uma apresentação que considerei com um contexto interessante, para que vocês possam ir se habituando com o tema, pois estou preparando um post explicativo sobre ACL e propriamente uma vídeo aula para treinamento.

Aguarde novas informações sobre ACL. 😉

Abraços,
Rodrigo

NetRiders – América Latina

Sat, 11 Aug 2012 00:00:00 +0000

Olá Pessoal,

Inicia-se mais um ano de competições para os 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.

Segue uma apresentação explicando sobre o processo:

[gview file=”https://www.ciscoredes.com.br/wp-content/uploads/NetRiders Portuguese.pdf” height=”500″ width=”600″ save=”0″ force=”1″]

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

Abraços
Rodrigo

Protocolo OSPF – parte 8

Fri, 27 Jul 2012 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso último post vamos finalizar nossa série de OSPF, mencionando rapidamente sobre os cálculos que são executados para trazer esses valores para a tabela de roteamento.

No post número 2, mencionamos sobre a formula que é utilizada para trazer o valor calculado. Consulte.

Baseado nesse principio iremos ter as diferenças de custo quando as redes são redistribuidas através de outro protocolo ( EIGRP, RIP e etc ) e as diferentes interfaces que estão sendo utilizadas para a troca de informações dentro do protocolo de roteamento. Segue abaixo um pequeno resumo dos valores de custo de cada interface.

Essa tabela tem os cálculos executados através da formula mostrada anteriormente em nosso capítulo 2. Todos esses valores podem ser obtidos através da mesma formula, entretanto alguns padrões já são reconhecidos e lembrados pois são utilizados em nosso dia a dia.

Como todos os recursos são alterados, temos duas formas de executar essa alteração de custo nas interfaces para que o valor seja influenciado e de uma forma tenha alteração na tabela de roteamento de seus vizinhos.

ip ospf cost [ interface-cos ] = Esse comando é o mais tradicional e mais utilizado, pois traz uma resposta mais real da situação. Esse recurso é aplicado dentro da interface e tem-se um range de 1 até 65535.

CiscoRedes>enable
CiscoRedes#conf t
CiscoRedes(conf-t)#interface fast1/0
CiscoRedes(conf-if)#ip ospf cost 10

bandwidth [ valor de banda ] = Esse comando irá alterar o valor que o protocolo utiliza de referência para utilizar no protocolo de roteamento, entretanto esse comando não é o mais recomendado, pois você pode alterar outras funcionalidades para qual é utilizado esse valor, como a falsa impressão da leitura de um MRTG, que irá trazer gráficos de utilização do circuito.

CiscoRedes>enable
CiscoRedes#conf t
CiscoRedes(conf-t)#interface fast1/0
CiscoRedes(conf-if)#bandwidth 1000

Para efetuar a validação dos custos que cada interface possui, iremos validar especificamente através da interface física.

Serial

CiscoRedes#show ip ospf interface s0

Serial0 is up, line protocol is up
Internet Address 128.213.10.2 255.255.255.0, Area 0
Process ID 10, Router ID 128.213.10.2, Network Type
POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 0:00:14
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 200.200.10.1

Ethernet

CiscoRedes#show ip ospf interface e0
Ethernet0 is up, line protocol is up
Internet Address 203.250.14.3 255.255.255.0, Area 0.0.0.0
Process ID 10, Router ID 203.250.12.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 203.250.15.1, Interface address 203.250.14.2
Backup Designated router (ID) 203.250.13.41, Interface address
203.250.14.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:03
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 203.250.15.1 (Designated Router)
Adjacent with neighbor 203.250.13.41 (Backup Designated Router)

Com isso chegamos ao fim de nossa serie sobre OSPF 😀 . Logicamente, temos outros conceitos que não foram abordados nesse pequeno tutorial, entretanto são tópicos interessantes que devem ajudar nossos leitores a descobrir e identificar os problemas nas redes que utilizam-se desse protocolo.

Espero que vocês tenham gostado 😉 e que esse ” tutorialzinho ” possa ter ajudado a interpretar um pouco sobre esse protocolo.

Abs,
Rodrigo

Protocolo OSPF – parte 7

Thu, 19 Jul 2012 00:00:00 +0000

Olá Caros,

Conforme nossa menção no post anterior, vamos hoje falar sobre a sumarização de rotas no OSPF.

Sumarização de rotas consiste na consolidação de múltiplas rotas em um único anúncio. Em uma rede OSPF, esta tarefa normalmente é realizada por um router de borda ( ABR ). Ainda que a sumarização possa ser configurada entre quaisquer duas áreas, a boa prática rege que a sumarização deve ocorrer preferencialmente no sentido do backbone ( Area 0 ). Desta forma, o backbone recebe todas as rotas agregadas e, por sua vez, pode anuncia-las sumarizadas para outras áreas.

Em uma rede OSPF, existem basicamente 2 tipos de sumarização:

Inter-area route summarization = Executado no ABR, cria os LSAs Tipo 3 e 4 e adverte os router IDs do ASBR, ou seja, a sumarização é aplicada as rotas internas do AS, na qual as rotas externas aprendidas via redistribuição não serão consideradas. Segue um exemplo onde teremos essa comunicação:

Para efetuar a configuração no roteador devemos sempre validar se as redes são contíguas e que o range escolhido para efetuar essa sumarização esteja dentro do escopo de suas redes, pois você pode efetuar loop na rede ou efetuar alguma assimetria dependendo de seu design. Segue o comando para efetuar a sumarização:

R2(config)#router ospf 100

R2(config-router)#area 1 range 192.168.10.0 255.255.254.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

External route summarization= É totalmente específico para as rotas externas, inseridas na rede OSPF via redistribuição, ou seja, essas redes são redistribuídas através do ASBR, para qual irá fazer a troca de um protocolo não OSPF. Gostaria de reforçar que a sumarização deve ser contígua para que não tenhamos problemas de redes sobrepostas. Segue abaixo um exemplo:

Neste caso iremos ter o roteador R3 redistribuindo as redes RIP para a área OSPF, portanto neste roteador podemos fazer uma sumarização de todas as redes que será inserida dentro do OSPF, facilitando dessa forma a tabela de roteamento que iremos ter na tabela de roteamento. Para isso podemos executar dessa forma a sumarização:

R3(config)#router ospf 100

R3(config-router)#summary-address 60.60.60.0 255.255.255.0

Depois dessa configuração o roteador irá criar uma rota apontando para a Null0.

Dessa forma concluímos o processo de sumarização que pode ser executado no protocolo OSPF. Espero que tenham gostado e iremos ter nosso último post de OSPF mencionando sobre métricas ( cálculos ).

Aguardo comentários!!!

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 6

Fri, 08 Jun 2012 00:00:00 +0000

Olá Pessoal,

Conforme mencionado anteriormente vamos prosseguir com nosso tutorial sobre OSPF. No último post havíamos falado sobre LSA e nesse post vamos tratar sobre os processos que acontecem quando temos eleição de DR e BDR em topologias de multiacesso.

Basicamente, routers que compartilham um mesmo segmento tornam-se neighbors neste segmento. O estabelecimento de uma relação de vizinhança ocorre por meio da mensagem “ Hello ”. Os roteadores tornam-se vizinhos assim que conseguem ver eles mesmos listados como vizinho no pacote Hello do router vizinho. Desta forma, uma comunicação de 2 vias é garantida. É importante ressaltar que a negociação de vizinhança utiliza apenas o endereço IP primário da interface, ou seja, se a mesma estiver configurada com endereços secundários, estes não serão utilizados no processo. Outro detalhe é que, se endereços secundários forem configurados, estes devem pertencer à mesma área OSPF do endereço primário.

Para a configuração de endereço secundário na interface devemos seguir esse processo:

ip address 10.1.7.252 255.255.255.0 secondary
ip address 10.1.2.252 255.255.255.0

Os roteadores para formar a adjacência entre si, exige que alguns parâmetros sejam validados:

Area-ID: Para 2 routers que possuem interfaces em um mesmo segmento, estas interfaces devem pertencer à mesma área OSPF, pertencer à mesma subrede e possuir a mesma máscara de rede.
Autenticação: Se autenticação estiver sendo utilizada, routers vizinhos devem trocar a mesma senha em um dado segmento.
Hello e “ Dead Intervals ”: Routers OSPF trocam mensagens Hello em cada segmento. O Keepalive HELLO configurado deve ser consistente em um mesmo segmento. O “ Dead Interval ” seria o intervalo de tempo entre o último pacote HELLO recebido e o router considerar o neighbor como “ down ”. Este intervalo também deve ser o mesmo em um mesmo segmento OSPF. Os comandos para configuração destes intervalos nas interfaces são: “ ip ospf hello-interval seconds ” e “ ip ospf dead-interval seconds ”
**“ Stub Area Flag ”:**Dois routers devem também possuir o mesmo valor no campo “ Stub Area Flag ”, no pacote Hello, para formarem uma relação de vizinhança.
MTU Size: Finalmente, temos o MTU Size das interfaces. Se estes valores forem diferentes em cada ponta, a adjacência não será formada. Se por algum motivo existir a necessidade de estabelecer a adjacência mantendo-se MTUs distintas em cada ponta, o comando “ ip ospf mtu-ignore ” configurado em cada interface envolvida no processo resolve o problema.

A adjacência é o processo de formação que ocorre imediatamente após a definição das relações de vizinhança. Roteadores adjacentes são aqueles que foram além da simples troca de pacotes HELLO, e iniciaram o processo de sincronismo da base de dados. Com o objetivo de reduzir a quantidade de informação trocada em um dado segmento, OSPF elege um router para ser o router designado ( Designated Router – DR ), e outro para assumir o papel de backup dele ( Backup Designated Router – BDR ), em cada segmento multi-acesso ( como segmentos Ethernet, por exemplo ). A idéia por trás deste princípio é criar um ponto central na rede multi-acesso para troca de informações.

As atualizações entre o DR e BDR são divulgadas através de um endereço multicast diferente do endereço que é utilizado para divulgação do tabela de roteamento ( LSDB ). O endereço multicast utilizado nesse segmento é 224.0.0.5. A definição de obter DR e BDR seria a redução de informações trocadas, pois utilizamos um cálculo básico para verificar no caso a crescente de adjancências entre os equipamentos.

n ( n-1 ) / 2

n = quantidade de roteadores no mesmo segmento

Veja pela figura como seria a adjacência:

A eleição do router DR é feita pelo pacote HELLO. Pacotes HELLO são trocados entre os routers via multicast, em cada segmento. O router que tiver o maior OID (OSPF ID) em um segmento é eleito o DR para aquele segmento. O mesmo processo é realizado para a eleição do BDR. Em caso de empate, o router com maior RID (Router ID) vence a disputa. A prioridade default para uma interface OSPF é 1. Este valor pode ser alterado pelo comando: “ ip ospf priority “. Uma prioridade “ 0 ″ significa que a interface em questão não será considerada no processo de eleição do DR / BDR.

Quando não temos a configuração de nenhuma loopback nos roteadores a eleição de DR e BDR é feita através dos endereços IPs configurados nas interfaces físicas, não esquecendo que teremos que considerar os endereços mesmo não pertencendo aquele mesmo segmento que está ocorrendo a validação.

Como mencionado sobre a adjacência temos alguns passos que são executados para a validação desse neighbor. Segue abaixo os 7 passos:

De que forma você pode avaliar a adjacência de seus vizinhos bem como o status de DR e BDR, seria através do comando ” show ip ospf neighbor “

Router2# show ip ospf neighbor 

Neighbor ID     Pri    State      Dead Time    Address     Interface
192.168.45.1    1      FULL/DR    00:00:36     10.0.0.1    Ethernet0

Com isso podemos mencionar que o OSPF em links ponto a ponto sempre irá formar adjacências entre eles, entretanto sem a necessidade de eleger um DR e BDR. Um cuidado especial é necessário quando configuramos OSPF em redes NBMA, como Frame Relay, X.25 ou ATM. Por default, OSPF considera estes redes como Broadcast (assim como uma rede Ethernet ). No entanto, redes NBMA geralmente são arquitetadas sob uma topologia “ hub & spoke ”, e não provê o tipo de acesso full mesh que OSPF acredita existir. Neste caso, a seleção do DR e BDR torna-se um problema, já que o DR e o BDR precisam ter uma conexão física entre eles. Além disso, devido à limitação de broadcast existente em redes deste tipo, o DR e o BDR precisam possuir uma lista estática de todos os roteadores pertencentes à rede frame relay.

Alguns pontos podem ser utilizados para evitar a eleição de DR e BDR em acesso NBMA, como a criação de sub-interfaces point-to-point e a configuração do tipo de interface dentro da configuração de interface ( broadcast | non-broadcast | point-to-multipoint ).

Espero que aproveitem as informações e fica a dica para nosso próximo post que seria voltado para a sumarização do OSPF, enfim o último post falando sobre os cálculos que OSPF utiliza para obter o custo e popular esses valores na tabela de roteamento.

Espero comentários.

Abs,
Rodrigo

Endereçamento IPV4 – Parte 1

Sun, 13 May 2012 00:00:00 +0000

Olá caros,

Gostaria de trazer mais um assunto importante para os profissionais que estão estudando o CCNA, ou pessoas que estão estudando em um modo geral Redes. Para este tópico iremos falar sobre o endereçamento IPV4 e como ele foi desenvolvido ao longo desse tempo para ser utilizado até os dias atuais.

Neste post estou oferecendo uma forma diferente, onde eu não irei escrever sobre o assunto, mas vocês irão obter informações e os métodos explicativos dentro da nossa vídeo aula. No total iremos ter o assunto divido em 2 partes para atender aos requisitos e oferecer uma metodologia para o entendimentos dos endereçamento IPV4.

Na primeira parte iremos trazer a nomenclatura do IPV4 e como ele é formado através de seus 4 octetos, explicar as divisões de classes, métodos para o cálculo do endereço ( Binário – Decimal ), públicos, privados, estrutura do endereço de máscara, formação desses endereços e propriamente os exercícios .

Segue abaixo nossa vídeo aula, utilizando uma mesa digitalizadora para assim trazer um método de ensino mais real. Espero que gostem.

Conforme mencionado no vídeo, temos alguns exercícios para a prática desses cálculos, devido a esse primeiro entendimento ser um ponto importante para dar andamento ao nosso próximo capítulo VLSM/CIDR.

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 .

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

PS.: Devido a solicitação disponibilizei a apresentação em pdf na nossa sessão de arquivos.

Abs,
Rodrigo

DHCP Snooping

Sat, 05 May 2012 00:00:00 +0000

Olá caros,

Um servidor DHCP é necessário quando temos várias maquinas e outros equipamentos IP na rede, no qual o serviço DHCP disponibiliza dinamicamente IP/máscara de rede, default gateway, servidor DNS, entre outras informações para o solicitante, com isso facilitando o trabalho do administrador de rede.

Vamos imaginar o cenário onde um usuário malicioso adiciona um computador na rede com o serviço DHCP Server habilitado. Quando uma máquina qualquer precisar de IP ou expirar o lease time, ela vai enviar pacotes DHCP Request em broadcast, no qual esse “ novo ” Servidor DHCP envia o DHCP Reply com seu próprio IP como default-gateway. Quando a máquina “ enganada ” enviar um pacote para fora da rede, o pacote vai passar pelo falso default-gateway, o PC do atacante, e depois enviado para o destino correto. Será questão de tempo para o ” lease time ” dos outros PCs expirarem e o trafego da sua rede ser inteiramente interceptado. Esse é um ataque muito perigoso do tipo “ man-in-the-middle “, pois com um sniffer o atacante consegue coletar vários dados dos usuários inclusive conversas e senhas.

Para evitar este tipo de ataque, devemos primeiro mapear as portas dos switches que não estão sendo utilizadas, e adicioná-las em uma VLAN separada da rede em produção, ou mantê-las em “ shutdown ‘. Porém o atacante ainda pode utilizar o ponto de rede de uma máquina na VLAN correta. Nos switches Cisco ( 2960, 3560, 3750, 4000, 6000 ) temos um recurso chamado DHCP Snooping, que classifica cada porta como trusted ou untrusted ( confiável ou não confiável ). Os servidores DHCP ficam nas portas trusted, e o restante das portas como untrusted, e o switch intercepta todas as requisições DHCP nas portas untrusted antes de encaminhá-las, caso ele receba um DHCP Reply de uma porta não confiável, esse pacote será descartado.

O serviço DHCP é descrito através da RFC 2131 e um dos principais pontos nesse momento para entender seria visualizar as mensagens que são trocadas quando um cliente solicita endereço para o servidor. Segue abaixo as mensagens trocadas:

O DHCP snooping possui uma base de dados com endereço IP, endereço MAC, lease time, etc. Essa base é utilizada em outras features como DAI (Dynamic ARP Inspection) e o IP Source Guard que serão abortados nos próximos posts do Multihop.

Para habilitar o DHCP Snooping digite o seguinte comando no modo de configuração global:

Switchconfig)#ip dhcp snooping

Agora identifique as VLANs que serão protegidas:

Switch(config)#ip dhcp snooping vlan 100\ Switch(config)#ip dhcp snooping vlan 200

Todas as portas do switch ficam no modo untrusted por padrão quando habilitamos o DHCP snooping. Agora vamos configurar as portas onde estão os servidores DHCP da rede como trusted:

Switch#conf t\ Switch(config)#interface FastEthernet 0/0\ Switch(config-if)#ip dhcp snooping trust

Podemos também configurar um limite de requisições DHCP que passam em uma interface, o rate pode ser um valor de 1 a 2048 pacotes por segundo:

Switch(config)#interface FastEthernet 2/1\ Switch(config-if)#ip dhcp snooping limit rate 10

Por padrão é habilitado a opção 82 DHCP, que é descrita na RFC 3046 publicada em janeiro de 2001 ( http://www.rfc-archive.org/getrfc.php?rfc=3046 ). Quando uma requisição DHCP é interceptada em uma porta untrusted, o switch adiciona seu próprio MAC e um identificador da porta de origem no campo option-82, em seguida encaminha para o servidor DHCP. Quando retorna o pacote reply o switch compara o campo option-82 para confirmar que a requisição foi originada de uma porta válida:

Switch(config)#ip dhcp snooping information option

Para verificar as configurações do DHCP Snooping, utilize o comando “show ip dhcp snooping”. Somente portas que estão como trusted ou com rate-limit serão listadas:

Switch # show ip dhcp snooping\ DHCP Snooping is configured on the following VLANs:\ 20 30-40 100 200\ Insertion of option 82 information is enabled.\ Interface Trusted Rate limit (pps)\ --------- ------- ----------------\ FastEthernet2/1 yes 10\ FastEthernet2/2 yes none\ FastEthernet3/1 no 20\ Switch #

Com o comando “show ip dhcp snooping binding” conseguimos visualizar as entradas que correspondem as portas untrusted como MAC, lease time, VLAN, etc:

Switch # show ip dhcp snooping binding\ MacAddress IP Address Lease (seconds) Type VLAN Interface\ ----------- ----------- -------------- ----- ---- ----------\ 0010.01FF.0201 192.168.2.3 1600 dynamic 100 FastEthernet2/1\ 0010.01FA.1B31 192.168.2.4 1600 dynamic 100 FastEthernet2/2\ Switch #

Espero que essas informações possa ajudar em alguma implementação de segurança. 😀

Aguardo comentários.

Fonte:
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/13ew/configuration/guide/dhcp.html

Protocolo OSPF – parte 5

Sun, 29 Apr 2012 00:00:00 +0000

Olá pessoal,

Como mencionado anteriormente, vamos continuar com a nossa sequencia de post relacionado a OSPF. Nesse post iremos tratar sobre os tipos de LSAs existentes dentro do protocolo OPSF.

Devido ao fato de existir nomenclaturas e funcionalidades diferenciadas entre o ABR e ASBR os LSAs tem um papel importante dentro do entendimento de como as rotas são distribuídas dentro do protocolo OSPF, bem como a menção sobre os diversos tipos de áreas existentes dentro do OSPF.

O LSA ( Link State Advertisement ) são pacotes que são distribuídos dentro das áreas OSPF com a funcionalidade de informar seus vizinhos sobre as redes e ao mesmo tempo fazer validações sobre o estado de cada rede ( alcançável e não alcançável ), ou seja, quando uma rede torna-se indisponível esses pacotes LSAs são inundados para que todos os roteadores tenham conhecimento sobre essa alteração de topologia.

Baseado nisto vamos mencionar os tipos de LSAs existentes dentro do protocolo OPSF:

Tipo de LSAs


LSA Type	Nome Comum	Descrição
1	Router	Um por router, listando RID e todas interfaces com endereço IP.
2	Network	Um por rota de rede. Criado pelo DR em uma subrede, e representa a sub-rede e interfaces conectadas ao roteador para a sub-rede configurada.
3	Sumarização Network	Criado pelo ABR para representar uma área do LSA tipo 1 e 2 quando sendo advertida dentro de outra área. Define os links ( sub-redes ) na área de origem e custos, mas não os dados de topologia.
4	Sumarização ASBR	Como o LSA tipo 3, exceto que anuncia uma rota usada para alcançar um ASBR.
5	AS Externo	Criado pelo ASBR para rotas externas injetadas dentro do OSPF.
6	Membros de grupo	Não suportado pelo IOS Cisco.
7	NSSA Externo	Criado pelo ASBR dentro de uma rede NSSA, ao invés de um LSA tipo 5.
8	Atributos Externos	Não esta implementado em roteadores Cisco.

Gostaria de mencionar mais dois pontos relacionados as menções anteriores:

Transit Network: Uma rede sobre a qual dois ou mais roteadores OSPF tem tornando-se vizinhos, então o trafego pode rotear de uma para a outra.
Stub network: Uma sub-rede na qual um router não formou qualquer relação com o vizinho.

Com isso podemos trazer alguns exemplos de topologia para qual temos a troca de LSAs entre os roteadores participantes do protocolo de roteamento OSPF.

Neste exemplo podemos observar todos os tipos de área do OSPF, para qual temos específicos LSAs sendo divulgado ou transportado dentro das áreas. Devemos analisar a utilização do ABR, para qual vai transportar na maioria das vezes tipo 3 e tipo 5, e quando temos o ASBR iremos ter a inserção do tipo 7 dentro da área NSSA.

Para a representação de propagação de LSAs segue abaixo um exemplo:

Neste exemplo podemos observar o tráfego de tipo 2 e 1 dentro da área 3, para qual o ABR da área 3 com a de backbone ( área 0 ) está encaminhando tipo 3. O roteador ABR que esta fazendo a conexão com a área 4 esta divulgando rotas externas vindo da Internet ( tipo 4 e tipo 5 ), ou seja, estaria influenciado com as redes que são distribuídas como external 1 ou 2, e rotas vindo da area 3 como tipo 3 e bem como as redes vindo da área de backbone.

Com base nessas informações os comandos de visualização dentro dos roteadores podem agora ajudar a resolver alguns problemas dentro do nosso dia a dia.

Podemos observar mais alguns comandos para ajudar na validação e detecção dos problemas dentro do protocolo OSPF:

router#show ip ospf border-routers

router#show ip route

router#show ip ospf

router#show ip ospf interface [ id ]

router#show ip ospf neighbor

router#show ip ospf summary-address

Dentro do conceito de LSA posso mencionar que devemos entender essa troca de LSA entre as áreas e os tipos de áreas no protocolo OSPF, para que posteriormente no design de uma rede OSPF essas particularidades não sejam esquecidas ocasionando erros e problemas dentro do protocolo de roteamento.

Para o próximo post iremos tratar sobre as adjacências e vizinhos do OSPF com a menção de DR e BDR.

Espero que tenham gostado e aguardo comentários.

Abs,
Rodrigo

CCIE Mobile Labs

Mon, 16 Apr 2012 00:00:00 +0000

Olá Pessoal,

Gostaria de trazer uma informação para as pessoas que estão estudando para o CCIE ( Written ou LAB ), para qual temos laboratórios móveis que são disponibilizados ao redor do mundo, fazendo com que os profissionais não necessitem viajar obrigatoriamente para os locais fixos onde temos os laboratórios Cisco para a certificação Expert.

Segue as localidades que devem ser atendidas durante esse ano e já temos um prospecto para 2013 desse calendário.

Para os profissionais em fase de conclusão teremos no começo de Junho ( 11 a 15 ) o Mobile Labs alocado no Rio de Janeiro e para o mês de Outubro ( 1 a 5 ) teremos na cidades de São Paulo. Essa datas já estão confirmadas pela Cisco e inclusive já podem ser agendadas as datas.

Não necessariamente iremos ter vagas disponíveis para a execução da prova, devido a grande procura que existe para que não seja necessário um gasto muito grande viajando para os locais fixos, já que a prova também não é nada barato ( U$1.500,00 )

Consulte o prospecto para 2013 e vamos agendar esse laboratório .

https://learningnetwork.cisco.com/docs/DOC-3224

Fonte:

https://learningnetwork.cisco.com/community/certifications/ccie_routing_switching

Abs,
Rodrigo

Protocolo OSPF – parte 4

Fri, 13 Apr 2012 00:00:00 +0000

Olá Pessoal,

Conforme notificado nesse post iremos tratar um pouco sobre áreas dentro da arquitetura OSPF. Confira os posts anteriores para obter informações relevantes sobre o protocolo.

No OSPF sempre iremos escutar e trabalhar com a area 0, chamada de ” área de backbone “. Essa seria a área de transito entre as diferentes áreas que podemos criar dentro do protocolo OSPF. Quando estamos pensando em um projeto de redes utilizando o OSPF, sempre devemos iniciar do ponto central ( área 0 ) e expandir para as áreas subjacentes, fazendo assim uma rede escalável e organizada.

A área 0 deve ser o centro lógico da rede, ou seja, todas as outras áreas devem ter uma conexão física com o backbone. O motivo disso é que OSPF espera que todas as áreas encaminhem informações de tabela/sub-redes roteamento para o backbone, e este, por sua vez, se encarrega de disseminar estas informações para as outras áreas. Veja abaixo a demonstração dessa áreas.

Baseado nas informações acima podemos avaliar alguns conceitos sobre a distribuição dessas áreas e algumas nomenclaturas definidas como ABR e ASBR.

A definição para ABR e ASBR pode ser constituída como:

ABR = Area Border Router no qual é responsável por conectar duas ou mais áreas. Nesse tipo de equipamento nos temos os anúncios das redes ou database de topologia sendo anunciado através do LSA tipo 3.
ASBR = Autonomous System Border Router que conecta outros protocolos de roteamento ( redistribuição ) para dentro do protocolo OSPF. Normalmente isso é executado utilizando a area 0.

Outro detalhe que podemos avaliar seria observando os diferentes tipos de informações que são trafegadas. Informações sobre rotas que são geradas e utilizadas dentro de uma mesma área são chamadas de “ intra-area routes ”, e são precedidas pela letra “ O ” na tabela de roteamento. Rotas que são originadas em outras áreas são chamadas de “ inter-area routes ”, ou “ summary-routes ”. Estas são precedidas por “ O IA ”, na tabela de roteamento. Rotas originadas por outros protocolos de roteamento e redistribuídas em uma rede OSPF são conhecidas por “ external-routes ”. Estas são precedidas pelas letras “ O E1 ″ ou “ O E2 ″, na tabela de roteamento. Quando temos múltiplas rotas para um mesmo destino, o critério de desempate em uma rede OSPF obedece a seguinte ordem: intra-area, inter-area, external E1, external E2.

Quando mencionado sobre a redistribuição dos protocolos IGP ou EGP para o protocolo OSPF temos as diferenças sobre a nomenclatura ( E1 e E2 ), para qual podemos definir dessa forma:

E1 = As métricas definidas pelos protocolos anteriores a essa redistribuição ( ASBR ) serão incluídos para alcançar o próximo salto fora de seu AS.
E2 ( padrão ) = Os custos externos não são repassados para o protocolo interno que está rodando dentro do área interna.

Vocês lembram quando foi comentado que todas as áreas OSPF deveriam conectar passando pela área de backbone? Pois é, isso não é regra.

Como toda regra tem uma exceção e deveríamos ter nesse caso, pois não poderíamos ficar obrigatoriamente ” amarrados ” na condição de que qualquer área nova criada eu deveria ter uma conexão com nossa área de backbone, devido a algumas condições externas ( links, disponibilidade de viabilidade para chegar em seu ponto central, etc ) essa facilidade dentro do OSPF seria restrita. Para resolver esse problema existe as conexões através de link virtuais ” Virtual-link “.

O link virtual OSPF é como uma “ VPN ” que integra uma área que não tem como se conectar diretamente ao backbone, através de uma área diretamente conectada a ele. É importante ressaltar que o artifício de “ virtual links ” é paliativo, ou seja, ele resolve um erro de design, e deve ser encarado como uma solução temporária.

No exemplo acima podemos resolver da seguinte forma:

RouterA(config)# interface loopback 0
RouterA(config-if)# ip address 10.10.10.33 255.255.255.255
RouterA(config)# router ospf 100
RouterA(config-router)# network 172.16.20.128 0.0.0.7 area 0
RouterA(config-router)# network 10.10.10.33 0.0.0.0 area 0
RouterA(config-router)# area 0 range 172.16.20.128 255.255.255.192
RouterA(config-router)# area 1 virtual-link 10.10.10.30

RouterM(config)# loopback interface 0
RouterM(config-if)# ip address 10.10.10.30 255.255.255.255
RouterM(config)# router ospf 100
RouterM(config-router)# network 172.16.20.32 0.0.0.7 area 5
RouterM(config-router)# network 10.10.10.30 0.0.0.0 area 0
RouterM(config-router)# area 1 virtual-link 10.10.10.33

Na próxima parte iremos falar sobre os tipos de LSA ( link state advertisement ) que estão disponíveis no protocolo OSPF.

Espero que tenham gostado e aguardo comentários.

Abs,
Rodrigo

QoS Video – Networking 101

Sun, 08 Apr 2012 00:00:00 +0000

Olá caros,

Após nossos posts sobre QoS, gostaria de trazer mais um vídeo na qual adiciona mais alguns conceitos voltados para essa tecnologia. Esse vídeo é apresentado pelo famoso e engraçado Jimmy Ray, para qual explica um pouco sobre o QoS em Layer 2 e Layer 3.

Confira abaixo:

http://www.youtube.com/watch?v=LtNVmvv9ZUw&feature=player_embedded

Abs,
Rodrigo

Protocolo OSPF – parte 3

Tue, 03 Apr 2012 00:00:00 +0000

Olá Pessoal,

Vamos continuar com nosso tutorial sobre OSPF. O post anterior pode ser consultado aqui.

Neste episódio iremos comentar sobre a configuração que podemos executar dentro do protocolo OSPF. Como todo protocolo de roteamento IGP ( RIP, EIGRP, OSPF ) que é habilitado em equipamentos Cisco temos 2 passos essenciais para configurar esse serviço:

Habilitar o serviço através do comando router ospf [ id process ]
Divulgar as redes que seus vizinhos OSPF devem aprender associando-se as interfaces com a área desejada network [ IP ] [ MÁSCARA ] [ area ]

Quando definimos o [ id process ] estamos relacionando apenas com o processo local do roteador que você esta trabalhando, e o mesmo não tem nenhuma relação com os roteadores vizinhos que irão fazer a adjacência com ele. Vários processos OSPF podem ser executados em um mesmo router, mas este procedimento não é recomendado, entretanto, já que cada instância consome grandes porções de CPU e memória. Em suma, um bom design não utilizaria mais de um processo OSPF em um mesmo router.

Para comando [ network ] diferentemente do que ocorre na configuração de outros protocolos de roteamento, serve, no OSPF, para indicar quais interfaces participarão do processo, e quais as áreas OSPF a que pertencem. Esta é uma particularidade do protocolo.

O ID da área é definido por um número inteiro compreendido entre 0 e 4294967295, e também pode assumir a forma de um endereço IP (ex: área 0 = 0.0.0.0).

O campo referente a [ máscara ] é mencionada como uma ” máscara coringa “, que na verdade é a máscara padrão escrita de uma forma invertida. Nesse caso, como podemos calcular essa máscara?

A máscara coringa seria executada através de uma conta matemática simples que seria a subtração. Para esse cálculo sempre iremos subtrair utilizado a máscara como sendo um /32 ( 255.255.255.255 )

Padrão / 25 = 255.255.255.128
Subtração /32 = 255.255.255.255
Coringa /25 = 0 . 0 . 0 . 127

No protocolo de roteamento OSPF podemos trabalhar com dois tipos de autenticação, para qual tem a função de criar uma segurança maior para o tráfego das tabelas de roteamentos entre seus vizinhos OSPF.

**– Autenticação Simples:**Este método permite que chaves sejam configuradas por área OSPF. Routers em uma mesma área que desejem participar do processo de roteamento devem ser configurados com a mesma chave. A desvantagem deste método é que as chaves são trocadas pela rede, e podem ser facilmente interceptadas.

interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
ip ospf authentication-key ciscoredes

router ospf 10
network 172.16.0.1 255.255.255.0 area 0
area 0 authentication

– Autenticação MD-5: Neste método, uma chave e uma senha são configurados em cada router. O router usa, então, um algoritmo baseado no próprio pacote OSPF, na chave e no ID da chave para gerar um “message digest”, que é inserido no pacote. Este método permite a troca de senha sem a interrupção da comunicação.

interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
ip ospf message-digest-key 10 md5 ciscoredes

router ospf 10
network 172.16.0.1 255.255.255.0 area 0
area 0 authentication message-digest

Baseado nesses conceitos temos uma vídeo-aula, para qual traz um laboratório com os comandos de configurações e exemplos de como a rede se comporta utilizando-se o protocolo de roteamento OSPF.

Nessa vídeo aula temos informações que são mencionadas, para qual ainda não esta contemplado nessa parte, porém aguardem os próximos posts que iremos trazer as explicações.

Deixem seus comentários. 🙂 e iremos falar no próximo post sobre áreas.

Abs,
Rodrigo

MSS – Maximum Segment Size

Thu, 29 Mar 2012 00:00:00 +0000

Olá Caros,

Como havia prometido vamos comentar um pouco sobre o termo mencionado acima. Portanto, o que significa MSS? 😕

MSS está relacionado com o tamanho máximo do datagrama IP, ou seja, ele tem relação com as conexões TCP e UDP. Para isso temos algumas suposições feitas anteriormente de que o tamanho padrão do datagrama tem alguns valores incoerentes. Esse pensamento foi absorvido por volta de 1983:

A origem não pode enviar datagrama maiores do que 576 octetos, a menos que eles tenham um conhecimento específico de que o destino está preparado para aceitar datagrama maiores.

Para solucionar esse conceito, podemos chamar de ambiguidade, o TCP MSS foi definido com a seguinte regra:

O tamanho do TCP MSS é o máximo tamanho do datagrama IP menos 40

O máximo tamanho do datagrama IP é 576
O TCP MSS é 536

A definição para o MSS esta detalhado através da RFC 879. O TCP provê uma opção que pode ser usada no momento que a conexão é estabelecida ( somente ), no qual indica que tamanho máximo no segmento TCP pode ser aceito naquela conexão. O MSS é enviado da origem para o destino e pode dizer ” Eu posso aceitar no segmento TCP até um tamanho X “. Esse tamanho X pode ser maior ou menor do que o padrão, e o MSS pode ser usado completamente independente de cada fluxo de direção do trafego.

Um ponto importante é que o MSS não conta o cabeçalho TCP e o cabeçalho IP, ou seja, ele conta apenas os dados não tendo o TCP SYN e o FIN. Lembrando-se que o TCP sobre Ethernet:

Adiciona 20 bytes para o cabeçalho IPV4 e 40 bytes para o cabeçalho IPV6
Adiciona 20 bytes para o cabeçalho TCP
Adiciona 12 bytes opcional para o TCP timestamps

Baseado nesses conceitos resolvi trazer uma situação real relacionando alguns pontos, para qual podemos enfrentar um problema devido ao pacote ser marcado com o df-bit ( não fragmentar ).

Segue a topologia abaixo como exemplo:

Nesse caso o cliente quer estabelecer uma conexão TCP com o servidor WEB, portanto eles anunciam o MSS deles para o outro para que eles aceitem o maior tamanho TCP nesse segmento. O valor negociado será de 1500 bytes, e o bit “ df-bit ” foi setado no servidor web, portanto esse pacote não poderá ser fragmentado. Quando o servidor devolver esse pacote para o roteador R2, ele irá tentar encapsular o pacote dentro de um túnel para entregar ao R1, porém o tunel GRE tem 24bytes a menos que o MTU configurado no servidor. Portanto o pacote irá ser fragmentado criando um pacote de 1476bytes ( dados e cabeçalho IP ) e um pacote de 44bytes ( 24bytes de dados e um novo cabeçalho IP de 20 bytes ). R2 irá encapsular ambos os pacotes de 1500bytes e 68bytes.

Mas você lembra-se que esse pacote não podia ser fragmentado devido ao df-bit, portanto R2 irá instruir o servidor WEB para enviar pacote menores. Isso significa que irá encaminhar um ICMP ( type 3 code 4 – Destination Unreachable; Fragmentation Needed and DF set ), para qual terá na mensagem o correto valor do MTU a ser usado pelo servidor WEB. Essa mensagem pode ser consultada através da RFC 1191 que trata do PMTUD, e também pode ser visualizada em um outro post através do wireshark mostrado para vocês.

Com isso podemos ter algumas soluções para resolver esse problema da fragmentação:

Modificando o bit ” df-bit “

!
interface FastEthernet0
…
ip policy route-map clear-df
!
route-map clear-df permit 10
match ip address 101
set ip df 0
!
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any

Trocar o valor TCP MSS que comunica através do roteador. Isso será configurado através do comando disponível no IOS 12.2(4)T ou superior pelo ip tcp adjust-mss [ value ], colocando 1436 ( MTU menos o tamanho do IP, TCP, GRE ), ou seja, ( 1500 – 20 – 20 – 24 ).

interface tunnel0
…
ip tcp adjust-mss 1436

Alterar o valor do MTU configurado pela interface túnel

interface tunnel0
…
ip mtu 1500

Com isso podemos concluir que existem diversas formas de avaliar a sua rede em relação aos eventos que encontramos no dia a dia, portanto temos que analisar os pontos para encontrar o real problema de uma perca de pacote ou de uma lentidão reportada por algum usuário.

Espero que aproveitem e deixem seus comentários com experiências vividas em nosso dia a dia. 8)

Abs,
Rodrigo

Fonte:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml
http://www.nil.si/ipcorner/IP_Fragmentation/
http://sd.wareonearth.com/~phil/net/overhead/

BLOG anúncia Vagas

Fri, 23 Mar 2012 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com vocês mais um recurso que estou criando para nosso BLOG. Conforme notificado neste ano, iríamos ter mais novidades, e neste momento divulgo mais um serviço na qual acredito que possa ajudar a disseminar mais oportunidades para todos os contribuidores do BLOG e pessoas que queiram participar desse grupo.

A ideia é ter um grupo onde as pessoas possam divulgar as vagas relacionadas a área de Tecnologia da Informação, tendo como base diversos segmentos ( Dados, Voz, Segurança, Wirelless, Datacenter e etc ) e assim ajudando ao próximo a encontrar seu melhor caminho.

Eu criei no Yahoo o nosso grupo para divulgação de vagas, que podem ser consultadas diretamente pela página do yahoo ou vocês podem conferir diretamente em nosso BLOG, para qual temos uma seção exclusiva com as 15 últimas vagas anunciadas.

O grupo é moderado, portanto tenham respeito com as pessoas que participam do grupo e com certeza estão buscando novas oportunidades para o mercado de trabalho.

Espero que se cadastrem e façam a sua contribuição. 🙂

www.ciscoredes.com.br/vagas

Abs,
Rodrigo

Nova Certificação Cisco – Datacenter

Wed, 21 Mar 2012 00:00:00 +0000

Olá caros,

Vocês devem ter percebido que a Cisco acabou de lançar mais uma certificação a nível de carreira CCIE. A nova categoria criada é CCIE Data Center.

A prova beta vai iniciar em 1 Maio até 15 Junho e no mês de Setembro será liberada para todos para se aventurar em mais uma certificação. Alguém vai se arriscar? 😀

http://www.cisco.com/web/learning/le3/ccie/dc/index.html

Desta forma a Cisco agora tem 9 certificação a nível de ” Expert “

Certificações

Abs,
Rodrigo

Protocolo OSPF – parte 2

Mon, 12 Mar 2012 00:00:00 +0000

Olá caros,

Dando andamento ao nosso assunto sobre OSPF, hoje iremos comentar sobre o algoritmo utilizado e os processos que são executados para trazer a melhor métrica para a tabela de roteamento.

O post anterior pode ser consultado aqui.

– Algoritmo

Como mencionado anteriormente o nome dado para esse algoritmo é ” Dijkstra “, pelo qual o fundador ” Edsger Wybe Dijkstra ” foi o criador desse algoritmo. Ele foi fundado 1956, entretanto foi publicado apenas em 1959.

Abaixo podemos ter uma cronologia referenciando-se especificamente ao protocolo OSPF, ou seja, esse algoritmo utilizado para esse protocolo de roteamento ( OSPF ) foi desenvolvido a muito tempo atrás.

Segue abaixo uma demonstração simples sobre os cálculos exercidos nesse algoritmo.

O modo como o algoritmo opera é colocando o roteador na raiz da topologia, e então calcula o melhor caminho para um destino baseando-se no custo cumulativo até o destino em questão. Cada roteador na rede terá uma visão única da topologia lógica, ainda que todos os roteadores utilizem a mesma base de dados link-state (link-state database).

Uma analogia que podemos mencionar sobre esse protocolo seria: Alguém precisa se deslocar de uma cidade para outra. Para isso, ela dispõe de várias estradas, que passam por diversas cidades. Qual delas oferece uma trajetória de menor caminho?

Nós poderíamos colocar as contas e fórmulas executadas para esse cálculo matemático, porém acredito que não precisaríamos aprender as contas e sim o conceito desse protocolo. Para quem tiver interesse em descobrir os cálculo ou implementar em linguagem de programação esse método, pode consultar através desse link.

– Link State

Como mencionado anteriormente o OSPF utiliza-se de um protocolo chamado link-state. Devido a este fato ele toma algumas decisões sobre qual o melhor caminho a ser tomado. Abaixo menciono os passos de execução para a utilização desse protocolo.

Cada roteador obtém informações sobre seus próprios links e suas próprias redes diretamente conectadas. Isso é obtido pela detecção de uma interface no estado up (ativo).
Cada roteador é responsável por encontrar seus vizinhos em redes diretamente conectadas. Roteadores link-state fazem isso trocando pacotes Hello com outros roteadores link-state em redes diretamente conectadas.
Cada roteador cria um pacote link-state (LSP) que contém o estado de cada link diretamente conectado. Isso é feito com o registro de todas as informações pertinentes sobre cada vizinho, inclusive a ID do vizinho, o tipo de link e a largura de banda.
Cada roteador inunda o LSP para todos os vizinhos, que armazenam todos os LSPs recebidos em um banco de dados. Esses vizinhos, por sua vez, inundam os LSPs para todos os seus vizinhos até que todos os roteadores na área tenham recebido os LSPs. Cada roteador armazena uma cópia de cada LSP recebido de seus vizinhos em um banco de dados local.
Cada roteador usa o banco de dados para criar um mapa completo da topologia e computa o melhor caminho para cada rede de destino. Como se tivesse um mapa de estrada, o roteador tem agora um mapa completo de todos os destinos na topologia e as rotas para alcançá-los. O algoritmo SPF é usado para criar o mapa da topologia e determinar o melhor caminho para cada rede.

Baseado nesses conceitos ainda temos diversos termos dentro do OSPF que são utilizados e iremos tratar logo abaixo:

– Custo

O custo (também conhecido como métrica) de uma interface OSPF é uma indicação do overhead necessário para o envio de pacotes através desta interface. O custo de uma interface é inversamente proporcional a largura de banda desta interface. Uma largura de banda maior indica um custo menor.

Custo = 10^8/Banda (bps).

Por este motivo, é importante a correta configuração do parâmetro Bandwidth em interfaces rodando OSPF. Ela sempre irá pegar o valor configurado para efetuar o cálculo da métrica.

– Roteadores de Fronteira ( Área e Borda )

OSPF utiliza multicast para propagar os anúncios pela rede. O conceito de areas foi criado para criar fronteiras de propagação destes anúncios. A propagação de updates e o cálculo da topologia pelo algoritmo Dijkstra são restritos à área. Todos os roteadores em uma mesma área terão a mesma base de dados topológica. Roteadores que pertencem a mais de uma área terão as bases de dados de cada área a qual pertencem. Este é o caso dos roteadores de fronteira, como os ABRs (Area Border Routers) e os ASBRs (Autonomous System Border Routers). A figura abaixo ilustra a aplicação destes roteadores.

– Tipo de Pacotes Link State

Existem diferentes tipos de pacotes Link-State. Estes pacotes são ilustrados no diagrama abaixo.

Nesta figura temos vários conceitos para qual está envolvido todos os tipos de LSA dentro do protocolo OSPF, porém iremos tratar em outro post específico somente para este contexto. Lembrando-se que os conceitos de Multi-Area e tipos de LSA não são cobrados na certificação CCNA, por isso vou tratar diferenciado para focar em assuntos de CCNP.

No próximo post iremos discutir as configurações do OSPF e uma vídeo aula para adicionar maiores detalhes. Espero que gostem 🙂 .

Abs,
Rodrigo

MTU – Gera lentidão, será?

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

Olá Pessoal,

Nós já havíamos comentado sobre o pacote jumbro frame em um post anterior e como existem conceitos e configurações relacionados a este tópico, resolvi trazer um laboratório prático para demonstrar o funcionamento desse famoso MTU.

Segue abaixo a topologia executada no GNS3. Neste laboratório estou utilizando o Cisco 2691 em conjunto com o IOS: c2691-advsecurityk9-mz.124-15.T14.bin. Para a conectividade serial o hardware adicionado foi a WIC-2T. Os arquivos do GNS3 podem ser obtidos na nossa seção arquivos.

Nesse laboratório iremos mostrar como a mudança de um parâmetro, em algum ponto da rede, ou seja, na conexão entre a origem e o destino podem afetar a transmissão de pacotes através da Internet ou dentro de sua rede interna.

Neste exemplo iremos fazer a alteração em um parâmetro, entre a conectividade Ethernet do PE1 com o roteador de BackBone. Lembrando-se, que quando esses parâmetros são alterados na rede para habilitar um pacote jumbro frame, por exemplo, todo o caminho que irá encaminhar esse pacote deve aceitar a mesma definição para o MTU.

Para efetuar o teste de conectividade entre os dois pontos, foi executado um ping da máquina ( 192.168.3.10 ) e do roteador CE1 para o roteador CE2 ( loopback – 192.168.5.1). Nesse teste a única forma de fazer com que o pacote, não seja fragmentado, seria através de um parâmetro que chamamos de DF-BIT. Esse parâmetro podemos habilitar normalmente através da CLI do roteador, ou através do DOS de seu computador.

No primeiro teste foi executado o ping através desse comando:

CE1#ping 192.168.5.1 size 1401 df-bit

Type escape sequence to abort.
Sending 5, 1401-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

Logo abaixo vocês podem observar o status capturado no WireShark, para qual apresenta o “request” do ping, com a flag “df” habilitada.

Devido ao tamanho do pacote ser maior que o permitido pelo MTU, recebemos uma mensagem de “unreachable”, ou seja, o pacote não foi transmitido devido a flag DF-BIT habilitada.

Nesse outro teste envio um pacote de 1500bytes, sem nenhuma marcação do df-bit.

CE1#ping 192.168.5.1 size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/345/412 ms

Nesse teste é colocado 1400bytes, porém com o parâmetro df-bit habilitado.

Para um teste final, fizemos um ping com pacote de 8192bytes, liberando a fragmentação entre a origem e destino.

Essa configuração executada na interface Ethernet foi colocada como teste.

interface FastEthernet0/0
ip address 10.10.1.5 255.255.255.252
ip mtu 1400
duplex auto
speed auto

Desta forma, podemos demonstrar que temos influências no meio de transmissão, quando trabalhamos com um pacote Ethernet e com isso podemos responder a pergunta colocada no título de nosso post.

Espero que vocês tenham gostado e aguardo comentários 🙂 . Se vocês acharem melhor, eu posso fazer uma vídeo aula para demonstrar todos os testes online. Fico no aguardo.

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

QoS – Configuração de Police – Parte 4

Wed, 11 Jan 2012 00:00:00 +0000

Olá caros,

Como em nosso último post, falamos sobre o tratamento que existem nas filas e como os equipamentos podem trabalhar para efetuar suas operações, hoje iremos comentar um pouco sobre os métodos que temos para efetuar as configurações de police e suas funcionalidades.

Você poderia perguntar o que significa o termo police?

Police seria o termo utilizado pela Cisco, na qual podemos aplicar regras para nossa classe de QoS configurada. Essa police irá trabalhar neste exemplo especificamente para verificar o conform-action, exceed-action e violation-action. Existem outras polices relacionada à esta nomenclatura, porém não iremos tratar nesse post.

Traffic police libera você à controlar margem máxima de tráfego enviada ou recebida em uma interface. Frequentemente, essas configurações são aplicadas nas interfaces de borda da rede para limitar o tráfego de entrada e saída. O tráfego que cai dentro das margens dos parâmetros configurados é enviado, enquanto o tráfego que é excedido dentro dos parâmetros configurados é dropado ou enviados com uma prioridade diferenciada.

Devido ao ” traffic police ” meramente dropar ou re-marcar o tráfego excedente com uma prioridade menor, isso não coloca um ” delay ” para o conform ( não excedido ). Se o tráfego é marcado como dropado, a única coisa a se fazer seria re-transmitir esse pacote. O tráfego re-marcado pode ser colocado com uma prioridade menor dentro da fila que ele foi categorizado, efetuando assim uma medida menos agressiva para as informações que estão sendo processadas pelo seu equipamento.

O método de trabalho que o equipamento utiliza para fazer esses cálculos esta baseado no CAR ( committed access rate ). CAR olha para o tráfego recebido em uma interface, ou um subconjunto daquele tráfego selecionado pelos critérios da ” policy ” configurada, compara a sua taxa à configuração de um ” token bucket “, e então entra em ação com base no resultado ( por exemplo, drop ou remark IP precedência) .

Segue um exemplo sobre a atuação do CAR:

Quando mencionado sobre o token bucket ( balde tokens ), podemos ter confusões relacionados ao CAR. Uma tentativa de esclarecer qualquer confusão, é que o CAR (como o próprio nome descreve) é usado para a política que o tráfego flui naquela taxa de acesso. CAR faz isso com um token bucket, ou seja, um token bucket é um balde com tokens que são representados em bytes (1 byte = 1 token). O balde é preenchido com tokens a uma taxa configurada pelo usuário. Os pacotes que chegam para ser entregue, o sistema irá verificar o token bucket, e se houver tokens suficientes no balde para corresponder ao tamanho do pacote, os tokens são removidos e o pacote é encaminhando (conform-action). Se não há tokens suficientes, o pacote é descartado (exceed-action).

Vamos considerar um exemplo de policy, onde 500 bytes estão atualmente no token bucket. Um pacote é encaminhado exigindo 300 bytes. Os bytes são removidos do bucket, e o pacote é enviado, então antes que o bucket seja re-abastecido com mais tokens, outro pacote de 300 bytes é encaminhado. Devido ao bucket possuir apenas 200 bytes, o pacote não pode ser enviado e é descartado.

Veja abaixo a ilustração para exemplificar:

Esse método exercido através do token bucket é executado através de cálculos para verificar se o tráfego esta dentro dos parâmetros acordados ( SLA ). Police, no entanto, usa o parâmetro Be para especificar o número máximo de bytes que podem ser enviados durante um intervalo de tempo. Portanto, em uma configuração de police, se o Bc é igual ao Be, nenhum excesso de burst ( rajada ) irá ocorrer. Se o excesso bursting ocorrer a police irá considerar esse tráfego de excesso como ( exceed traffic ), ou seja, o CIR acordado foi violado.

Podemos fazer a relação entre Tc, Bc e CIR com a seguinte fórmula:

CIR = Bc / Tc

E podemos re-escrever a fórmula para:

Tc = Bc / CIR

Quando trabalhamos com uma configuração para qual usamos o violation-action, o IOS da Cisco irá utilizar dois bucket para gerenciar os tokens, ou seja, Bc e Be. Se o pacote pode ser usado utilizando o Bc ele estará dentro do conform, mas se ele não pode ser encaminhado usando Bc, ele irá ser encaminhado pelo Be, e estará dentro do exceed, e como última alternativa não podendo ser encaminhado pelo Bc e Be, ele será classificado como violado. Lembrando-se que o trafégo violado ainda pode ser transmitido usando uma combinação de bytes em ambos Bc e Be.

Veja abaixo a ilustração para o método de dois bucket:

Após essas menções vamos colocar alguns comando que podemos usar para a configuração explicada acima:

Neste exemplo podemos notar que a configuração foi executada para um average de 8000bits e um burst de 1000bytes.

Router(config)# class-map access-match
Router(config-cmap)# match access-group 1
Router(config-cmap)# exit
Router(config)# policy-map police-setting
Router(config-pmap)# class access-match
Router(config-pmap-c)# police 8000 1000 conform-action transmit exceed-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface fastethernet 0/0
Router(config-if)# service-policy output police-setting

Neste caso estamos trabalhando com dois buckets, mas colocando o exemplo com um exceed burst.

Router(config)# class-map access-match
Router(config-cmap)# match access-group 1
Router(config-cmap)# exit
Router(config)# policy-map police-setting
Router(config-pmap)# class access-match
Router(config-pmap-c)# police 8000 1000 1000 conform-action transmit exceed-action
set-qos-transmit 1 violate-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface fastethernet 0/0
Router(config-if)# service-policy output police-setting

Baseado nesses fatos conseguimos concluir que dependendo da sua necessidade, uma determinada configuração irá atender melhor sua demanda, ou seja, existem diversas formas de configurar seu ambiente, porém temos que escolher e definir aquilo que é importante para seu negócio.

Um video foi disponibilizado na nossa seção “ Video Aula “ para demonstrar o funciomento dessa configuração. Os arquivos de configurações podem ser obtidos da nossa seção Arquivos relacionado ao nosso primeiro laboratório parte 1.

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

Espero que aproveitem e aguardo comentários 😉 .

Abs,
Rodrigo

Fontes:
Site Cisco – QoS
Cisco Press – Tips

Cloud Computing

Fri, 06 Jan 2012 00:00:00 +0000

Olá Pessoal,

Gostaria de trazer um assunto que hoje estamos escutando com uma certa frequência relacionado a ” Cloud Computing “.

Cloud computing é um termo de marketing para as tecnologias que fornecem software, acesso a dados e serviços de armazenamento que não exigem do usuário final o conhecimento da localização física e de configuração do sistema que fornece esses serviços. Um paralelo a este conceito pode ser desenhado com a rede elétrica, no qual os usuários finais consomem energia sem a necessidade de compreender os dispositivos ou infra-estrutura necessária para prestar o serviço.

Hoje já temos diversos serviços disponibilizados via ” cloud “, pórém alguns termos que escutamos no dia a dia estaria relacionado com esses tipos de serviços que podem ser viabilizados via software, hardware e infra-estrutura. Segue os termos:

Infraestrutura como serviço ( IaaS ) = Fornece ao usuário uma infra-estrutura virtual, tais como servidores e espaço de armazenamento de dados. Isto é onde a virtualização se encaixa na nuvem.
Plataforma como serviço ( PaaS ) = Fornece ao usuário serviços de desenvolvimento de ambiente onde o usuário pode criar e executar aplicações de home-grown.
Software como serviço ( SaaS ) = Fornece ao usuário acesso a aplicativos já criados que estão operando na nuvem.

Segue uma ilustrução para demonstrar a computação em nuvem.

Temos mais um ítem para incluir nesse post que seria sobre as nuvens privadas e públicas.

Nuvems privadas podemos tratar como sua empresa criando uma cloud dentro de seu datacenter para qual pode oferecer serviços, redução de custos e oferecer o IT como um serviço para seus clientes internos.
Nuvems públlicas seriam as empresas oferecendo serviços para seus clientes através de acesso internet, disponibilizando assim todo serviço ( storage, software, infra ).

Como nesse primeiro momento o assunto seria apenas para despertar o interesse, segue um slide interessante da Cisco, para qual apresenta alguns recursos e propriamente produtos para disponibilizar esses serviços.

Nos próximos posts iremos tratar mais desse tópico com alguns exemplos e explicações sobre esses recursos.

Abs,
Rodrigo

Fontes:
http://www.cisco.com/web/solutions/trends/cloud/index.html

QoS – Enfileiramento – Parte 3

Mon, 05 Dec 2011 00:00:00 +0000

Olá pessoal,

Conforme nosso último post, no qual foi mencionado sobre a marcação de pacotes dentro do cabeçalho IP ( ToS ), portanto hoje iremos trazer mais informações sobre QoS, mencionando sobre o método de filas que o equipamento utiliza para encaminhar seus pacotes.

Quando foi explicado sobre a marcação de pacotes e propriamente mencionado sobre as categorias de filas, ou seja, todo esse trabalho exerce uma funcionalidade para que no momento de recebimento desse pacote os equipamentos ( roteadores/swiches ) possam interpretar essa marcação ( preferência ) do pacote, sobre determinadas características em um plano de hardware queueing e software queueing.

Para um melhor entendimento segue um fluxograma de como funciona o tratamento de pacotes:

Para o propósito de hardware queueing:

Esse é o tipo de enfileiramento conhecido como TxQ (fila de transmissão), no qual ele usa o hardware e SEMPRE usa o mecanismo FIFO (First In First Out) e apenas quando essa fila fica cheia o software queueing será acionado. Nesta categoria estamos referenciando-se ao Tx Ring/ TX queue, fazendo dessa forma o enfileiramento quando a fila está cheia, e por sua vez o IOS habilita “queue” nesta interface.

Aqui podemos fazer uma analogia de como os pacotes chegam para uma determinada interface física de um equipamento. 😉

Quando tratamos do assunto de software queueing, teremos 6 categorias para classificar essas informações:

PQ – Priority Queue = Possui 4 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagens: Fornece prioridade restrita para um tráfego na classe. Desvantagem: pode sofrer de um fênomeno chamado: starvation (morte por insuficiência de alimentação).
CQ – Custom Queue = Possui 16 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada.Vantagens: garante banda para aplicações menos críticas. Desvantagem: precisa criar uma política dentro da interface.
WFQ – Weighted Fair Queueing = Enfileiramento justo baseado em peso, ele atua de forma justa eliminando o fenômeno stavartion, ou seja, o primeiro da coluna de cada fila é expedido para o DEQUEUE e todos os pacotes da segunda coluna são expedidos e assim sucessivamente. Desvantagem: ideal para links até 2MBps, caso contrário muitos ciclos de CPU serão executados e não possui uma fila única de prioridade.
CBWFQ – Class-Based Weighted Fair Queue = Possui 64 filas FIFO, que são unidirecionais, e um pacote da fila em espera só entra em ação quando sua superior é esvaziada. Vantagem: recordista do número de classes, suporta até 64 para realizar controle de banda. Desvantagem: sem fila exclusiva de prioridade.
**LLQ – Low Latency Queue =**Conhecido por PQCBWFQ, devido a possuir uma fila PQ e um grupo em CBWFQ. Infelizmente isso é uma “sopa de letrinhas” 😀 Vantagens: ótimo para arquitetura AVVID da Cisco, excelente para aplicações real-time, garante banda e propicia a menor latência, não apenas para portas UDP/RTP mas qualquer outro tipo de porta. O seu único problema diz respeito a sua classificação não ser feita de modo automatizado, havendo a necessidade de configuração. Esse é o nosso método mais utilizado, porém se as classes não estiverem bem ajustadas conforme a realidade, podemos ter alguns problemas, que daí para frente teremos que realizar alguns troubleshootings!
IP RTP Priority = Conhecido por PQWFQ, por ser composto por uma fila PQ e o grupo de WFQ.Vantagens: ótimo para arquitetura AVVID da Cisco, garante banda e propicia a menor latência, não apenas para portas.

Abaixo segue uma tabela comparativa com as filas mais usuais que encontramos no nosso dia-a-dia:

Por padrão o FIFO é habilitado nas interfaces com a bandwidth acima de 2mbps e também por padrão o WFQ é habilitado nas interfaces com a bandwidth abaixo de 2Mbps

Baseado nessas informações temos mais um conceito que é obtido em nossas vídeo aulas, para qual tratamos de métodos para evitar o congestionamento. Na Cisco nós trabalhamos com três métodos, no qual chamamos de Tail DROP, WRED ( Weighted Randon Early Drop ) e CBWRED. Não vamos entrar muito em detalhes para não ficar extenso nosso post, mas podemos explicar rapidamente cada método:

Tail DROP = Descarte de pacotes baseado em hardware e software quando a fila está cheia, ou seja, novos pacotes que chegam na interface são dropados.
WRED = Característica do IOS utilizada para previnir que uma fila seja preenchida pela capacidade descartar o tráfego mais agressivamente quando a fila começa a se preencher. O descarte é feito baseado na prioridade de marcação, onde os pacotes de menor prioriodade terão maior chances de serem descartados. Dentro dessa características podemos chamar de ( minimum threshold, maximum threshold e mark probability denominator).

\
**CBWRED =**Mesma funcionalidade do WRED, porém podemos utilizar baseado por classe.

Como demos uma prévia sobre o conceito segue os comandos que podemos utilizar para fazer esse tipo de configuração.

Router(config-if)# class-map c1
Router(config-cmap)# match access-group 101
Router(config-if)# policy-map p1
Router(config-pmap)# class c1
Router(config-pmap-c)# bandwidth 48
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 8 24 40
Router(config-if)# service-policy output p1

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

Fonte:
Cisco Page – WRED
Cisco Page – Avoidance

Pacote Jumbo Frame – Ethernet

Mon, 07 Nov 2011 00:00:00 +0000

Olá caros,

Hoje iremos tratar de um assunto que escutamos no nosso dia-a-dia, e que em determinados ambientes temos uma grande utilização para esse meio de comunicação ” Metro-Ethernet “.

Neste post vamos trazer informações referenciando-se ao pacote JUMBO FRAME. Vocês poderiam perguntar, porque esse nome?

Na verdade esse nome foi dado, devido a capacidade de informações que podemos inserir dentro do mesmo pacote, para conseguir atravessar o meio sem efetuar fragmentação no pacote. Mas vamos entender melhor esse método, pois dependendo do ambiente isso também não traz benefícios.

O limite de 1500 bytes para o conteúdo dos frames foi criado originalmente como parte das especificações do padrão 10BASE-5, o padrão Ethernet original, de 10 megabits. A idéia era que frames muito grandes agravariam o problema das colisões, permitindo que uma única estação utilizasse o cabo durante um tempo muito longo. Além disso, frames maiores demorariam mais tempo para serem retransmitidos em caso de corrupção do conteúdo, de forma que os 1500 bytes foram aceitos como o melhor custo-benefício.

Dentro das características do padrão ethernet, bem como para o padrão coaxial, segue uma tabela para uma demonstração dessas especificações. Mais detalhes podem ser obtidos através desse link:

O problema é que, de lá pra cá muita muita coisa mudou. O cabeamento evoluiu, a velocidade das redes aumentaram para 100, 1000 e agora para 10000 megabits (1000 vezes a velocidade do padrão original) e, com a substituição dos hubs por switches, as colisões de pacotes deixaram de ser um problema.

Em uma rede de 10 megabits, é possível transmitir 819 frames com 1500 bytes de dados por segundo (lembre-se de que cada frame precisa de 26 bytes adicionais, que incluem os endereços, códigos de CRC e os demais componentes), o que faz com que cada frame demore 1221 nanosegundos para ser transmitido. Em uma rede Gigabit Ethernet, onde a velocidade é 100 vezes maior, o tempo de transmissão de cada frame cai para apenas 12 nanosegundos.

Como o processo de verificação do conteúdo dos frames consome processamento, trabalho que aumenta proporcionalmente conforme aumenta o volume de frames transmitidos, a velocidade das transferências acaba sendo limitada não apenas pelo desempenho das placas, mas também pelo desempenho do processador principal.

Nas redes de 10 e 100 megabits isso não chegava a ser um grande problema, mas a popularização das redes Gigabit Ethernet trouxe o assunto para ser avaliado. Percebendo a possibilidade de melhorarem o desempenho de seus produtos, muitos fabricantes passaram a desenvolver extensões proprietárias, que permitem utilizar frames maiores e assim reduzir o overhead. Estes frames gigantes são os chamados de jumbo frames.

Inicialmente, diferentes padrões eram incompatíveis, mas, com o passar do tempo, os fabricantes concordaram em padronizar o tamanho em 9000 bytes, o que permitiu a interoperabilidade entre produtos de diferentes fabricantes. Em alguns modelos de equipamentos da Cisco, podemos configurar esse valor para 9126 bytes.

A idéia é que o processamento necessário para verificar o CRC de um frame de 1500 bytes de dados não é muito diferente do para verificar um de 9000 bytes, de forma que o uso do processador decai brutalmente com a redução no número de frames transmitidos. Outra vantagem é que recheando cada frame com mais dados, a perda causada pelos 26 bytes adicionais decai proporcionalmente, melhorando o desempenho da rede.

O grande problema dos jumbo frames é que eles não fazem parte dos padrões Ethernet. Como aumentar o tamanho dos frames quebra a compatibilidade com os padrões de rede anteriores, o que é uma das grandes prioridades do IEEE.

Pensando dessa forma, existem alguns métodos para fazer configurações dentro do meio Ethernet, para que possamos encaminhar esses pacotes de 9000bytes dentro da rede. Olhando para os modelos de equipamentos da Cisco, temos diferenças relacionadas as linhas de configuração para cada plataforma ( hardware ). Vamos mencionar alguns modelos, porém podemos consultar a documentação oferecida pela Cisco.

6000 / 6500 / 7600 – Devemos verificar o hardware instalado nesse chassi, para verificar compatibilidade

7609(config)#int gigabitEthernet 1/1
7609(config-if)#mtu ?
<1500-9216> MTU size in bytes

4000 / 4500 – Verificar compatibilidade de hardware, sempre observando qual modelo de supervisora esta sendo utilizado

sup3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
sup3(config)#interface gigabitEthernet 1/1
sup3(config-if)#mtu ?
<1500-9198> MTU size in bytes

3750 / 3560 – Temos diferenças para a disponibilização entre as portas 10/100 e para as portas 1000.

3750(config)# system mtu 1546
3750(config)# exit
3750# reload

3750(config)# system mtu jumbo 9000
3750(config)# exit
3750# reload

2960 – Temos diferenças para a disponibilização nas portas 10/100 e 1000

2960(config)# system mtu 1998
2960(config)# exit
2960# reload

2960(config)# system mtu jumbo 9000
2960(config)# exit
2960# reload

Existem outros modelos referenciando-se aos switches Cisco, porém isso pode ser consultado através desse link.

Como podemos observar esses parâmetros estão designados as conectividades ethernet, ou seja, no momento que estamos trafegando para ambientes WAN que utilizamos outras tecnologias, esse tamanho de pacote vai ser segmentado conforme a especificação daquela interface, para qual vai ter um circuito E1, E3, OC3 e etc.

Podemos mencionar alguns ítens que são necessários para avaliação de habilitar jumbo frame na rede:

Placas e switches GigabiEthernet suportam a utilização de jumbo frame, portanto temos que avaliar os equipamentos instalados na rede.
Avaliar a comunicação fim a fim, pois se determinados meio de comunicação não obtiver essa configuração, você irá segmentar os pacotes, podendo até piorar a performance da rede.
Jumbo frames traz benefícios na transferência de grandes arquivos, pois se a rede utiliza muito streaming, pequenos arquivos você não irá perceber tanta diferença.

Esse detalhe é apenas uma informação que pode ser alterada dentro das especificações ethernet, para qual chamamos de MTU ( Maximum Transmission Unit ). Para o próximo post vou mencionar sobre uma outra particularidade que chamamos de MSS.

Espero que aproveitem as informações e aguardo comentários 😉

Abs,
Rodrigo

Fontes:
https://supportforums.cisco.com/docs/DOC-2013
http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

QoS – Marcação de Pacotes – parte 2

Mon, 24 Oct 2011 00:00:00 +0000

Olá Pessoal,

Conforme anúncio vamos prosseguir com nossos estudos voltados para QoS. No último post havíamos tratado do assunto focando na tecnologia NBAR, e devido ao pontos levantados para execução do laboratório e definições de parâmetros, vamos discutir sobre o cabeçalho IP e a marcação do pacote.

O cabeçalho IP é composto por diversos campos, para qual define funcionalidades específicas para cada ” caixinha “. Todos esses valores são compostos por valores binários e podem ser visualizados através de uma ferramentas de monitoração ( WireShark ).

Segue as definições do cabeçalho IP, com uma relevância para a informação definida no ” ToS “.

Version: Contém o número da Versão IP ( 4 ou 6 ).
Tipo de Serviço (ToS): Valor binário de 8 bits que é usado para determinar prioridade no pacote.
Tempo de Vida (TTL): O valor TTL diminui em pelo menos um a cada vez que o pacote é processado por um roteador ( ou seja, a cada salto ).
Protocolo: Possibilita que a camada de rede passe os dados para camada superior ( 01 – ICMP ; 06 – TCP ; 17 – UDP )
CheckSum: Usado para a verificação de erros no cabeçalho do pacote.
Endereço de Origem: Endereço IP de Origem constituído de 32 bits ( x.x.x.x )
Endereço de Destino: Endereço IP de Destino constituído de 32 bits ( y.y.y.y )

Podemos obter maiores informações sobre todos os campos inseridos dentro do cabeçalho IP utilizando a RFC 791, para qual traz em detalhes cada campo informado dentro do cabeçalho, bem como os valores binários que podemos obter em cada ” caixinha “.

Com base nessa informação temos o formato do nosso IPV4 com 32 bits, para qual pode ser formado através de 4 conjuntos de 8bits cada. Neste formato podemos formar números decimais de 0 à 255. Não irei entrar nesse detalhe, pois iremos tratar desse assunto em outra ocasião, porém segue apenas como informação referenciando-se ao formato desse número que usamos hoje em qualquer lugar/equipamento.

Com base em todas as informações mencionadas acima, vamos apresentar os dados referentes ao tipo de marcação que posso executar dentro do cabeçalho IP para a ” caixinha ” ToS. Esse valor inserido exercerá uma funcionalidade para o pacote que viaja dentro da rede, fazendo com que a sua principal função é dar prioridade para determinados tipos de tráfego/aplicação.

O QoS é o acrônimo de ” Quality of Service “. Trata-se de uma nomenclatura genérica para designar um conjunto de algoritmos capazes de fornecer vários níveis de tratamento para diferentes tipos de tráfego na rede. O propósito dessa tecnologia é otimizar o uso da banda passante provendo um tráfego fim-a-fim eficaz e econômico. O QoS resolve a necessidade da aquisição de mais banda para a rede, pois supre a demanda de tráfego das LANs/WANs de forma inteligente e organizacional através dos mais diversos mecanismos que ele dispõe. Cada um desses tráfegos, merece um tratamento especial conforme suas características. Assim, é necessário que os cuidados especiais sejam obedecidos para que não ocorra possíveis problemas.

Os pontos chaves que o QoS pode tratar melhorando assim a performance da rede, poderia se basear em quatro ítens:

Jitter
Perda de Pacotes
Latência
Bandwidth

Devido aos ítens mencionados acima, foi criado em uma das características do QoS, a marcação do pacote através do DSCP ( Diff Service Point ) ou através de AF ( Assured Forwarding ).

DSCP = ele é composto de 6 bits, no qual temos em decimal a permutação de 2 elevado à 6 que é 64 valores possíveis, variando portanto de 0 à 63. Essa faixa de valores é que define literalmente a marcação dos pacotes. De antemão todo pacote BestEffort (BE) ou melhor esforço é tratado com DSCP 0 ou em binário 000000. Para a instância de voz sobre IP teremos o valor DSCP 46, para qual podemos consultar através da RFC 2598. Segue um exemplo:

AF = Define 4 classes para a proposta de fila, em conjunto com 3 níveis de probabilidade de drops dentro de cada fila. O formato que podemos seguir está baseado em AFxy , no qual esses valores vão implicar em uma tabela ( matriz ) 4 x 3. Os valores mais altos para o X irão ter preferência para serem transmitidos, e os valores maiores em Y terão uma probabilidade maior de drops dentro daquela mesma fila.

PS.: Quando temos a conversão do valor de AF para DSCP, podemos utilizar uma fórmula simples para calcular esse valor. Como mencionamos AFxy podemos fazer:

8x + 2y = valor decimal

Por exemplo: AF41 seria o valor decimal DSCP 34

Com isso podemos mostrar alguns exemplos utilizando as tabelas explicativas abaixo:

Nessa tabela podemos obter informações relacionadas a forma de marcação do DSCP e também como isso é disponibilizado através das categorias de classes. Lembrando-se que para essa marcação temos a disponibilização de 6 bits, podendo combinar diversos valores decimais.

Segue um exemplo da conversão desse valor:

IP Prec 5 (101) maps to IP DSCP 101 000

Essa tabela está referenciando-se ao formato do AFxy, para qual temos a matriz 4×3. Esse conceito pode ser consultados através da RFC 2597.

Baseado nas conversões demonstradas ao lado podemos perceber que temos a utilização apenas 5 bits, para qual é transformado para os valores mapeados em DSCP.

Todas essas informações podem ser consultadas através desse link.

A Cisco tem um modelo para qual podemos seguir dependendo da utilização e da demanda que irá ocorrer em nossa rede. A tabela abaixo pode mostrar o tipo de aplicação e em qual classe é recomendado trabalhar. Vocês poderiam se questionar sobre algumas informações contidas nessa tabela devido a não ter sido explicada anteriormente, mas a coluna ( Queuing and Dropping ), irei citar em outro post tratando especificamente desse assunto.

Essa tabela também esta referenciada através da RFC 4594, seguindo assim as padrões que podemos utilizar para essa tecnlogia.

Uma informação que acredito que seja importante quando falamos de QoS, estaria envolvido com o comportamento dos roteadores/switches. Vocês poderiam perguntar onde os equipamentos podem fazer essa classificação e marcação de pacotes?

Classificação = Somente ingress, e somente se a interface suportar o cabeçalho particular para aquele determinado campo.

Marcação = Somente egress, e somente se a interface suportar o cabeçalho particular para aquele determinado campo.

Em função desses conceitos existe uma vídeo aula disponibilizada em nossa seção, para a demonstração e visualização desses campos, com a marcação dos pacotes trafegados dentro da rede. Sempre recordando que os arquivos para a configuração dos equipamentos está disponibilizado em nossa seção de arquivos.

Os arquivos .txt podem ser utilizados dentro do GNS3, apenas tendo que montar a mesma topologia utilizada para nosso laboratório.

Para nosso próximo post irei trazer informações sobre o tipo de enfileiramento e os modelos que podemos utilizar para o melhor aproveitamento/performance da nossa rede.

Espero que gostem do post e aguardo comentários. 😉

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

Abs,
Rodrigo

Cisco – Wikipédia. Vocês acreditam?

Mon, 17 Oct 2011 00:00:00 +0000

Olá Pessoal,

Gostaria de divulgar mais um meio de estudos e disponibilização de documentações técnicas da Cisco.

A Cisco possui um portal, com o mesmo formato do Wikipédia. Nesse site podemos logar com nossa conta de ” CCO “ e disponibilizar documentos técnicos, bem como editar os documentos já disponibilizados no portal.

Entretanto, existem regras para disponibilizar essas informações e para editar os documentos já postados nesse portal. Como essa ferramenta é nova, as informações estão sendo disponibilizadas aos poucos, mas já existem vários assuntos interessantes com um conteúdo muito bom.

http://docwiki.cisco.com/wiki/Main_Page

Espero que gostem da dica 😉 e aguardo os comentários.

Abs,
Rodrigo

IOS – Configurações de Níveis de Segurança

Mon, 10 Oct 2011 00:00:00 +0000

Caros,

Gostaria de trazer algumas informações referenciando-se aos níveis de segurança que o IOS oferece para a estrutura de acesso. Usando-se senhas e assinando privilégios é o caminho mais simples de providenciar controle de acesso ao seu terminal de rede ( roteadores/switches ).

Por padrão, o IOS da Cisco oferece 16 níveis de privilégio. Nesse caso quanto maior o seu nível mais privilégios você terá para efetuar configurações/validações no equipamento. Dentro desse contexto a CLI ( command line interface ) tem dois níveis padrões de acesso para os comandos:

User EXEC mode: privilege 1
Privileged EXEC mode: privilege 15

Quando o usuário entra no equipamento ele obrigatoriamente irá ser direcionado para o nível 1, e após digitar “enable“, ele será direcionado ao nível 15. Entretanto, você pode configurar níveis adicionais de acesso para os comandos chamados de “privilégio de acesso”, disponibilizando assim a necessidade para cada usuário/grupo. Cada nível de acesso privilegiado é habilitado através senhas separadas, o qual foi especificado quando configurado o nível.

Para obter um nível de segurança mais elevado, existem dois modelos de senhas que podem ser habilitados nos equipamentos ( enable password e enable secret ). Ambos os comandos são os mesmos, o qual libera você a estabelecer uma senha criptograda. A Cisco recomenda o uso do enable secret, pois possui um algoritmo de criptografia mais robusto. Quando são configurados os dois modelos nos equipamentos a precedência é estabelecida para o ” enable secret “.

R2_1721(config)#enable password ?
  0      Specifies an UNENCRYPTED password will follow
  7      Specifies a HIDDEN password will follow
  LINE   The UNENCRYPTED (cleartext) 'enable' password
  level  Set exec level password

R2_1721(config)#enable secret ?
  0      Specifies an UNENCRYPTED password will follow
  5      Specifies an ENCRYPTED secret will follow
  LINE   The UNENCRYPTED (cleartext) 'enable' secret
  level  Set exec level password

Quando temos a criação dos privilégios alguns comandos podem ser úteis para a execução dessa hierarquia de acesso:

show privilege = Mostra o atual nível que encontra-se aquele usuário

R2_1721#sh privilege
Current privilege level is 15

R2_1721>enable 3
Password:
R2_1721#sh privilege
Current privilege level is 3

Como podemos fazer a criação desse nível para utilização de uma senha:

enable secret = Este comando é default para criação de senha para acesso nível 15, porém ele é usado para criação de senhas para outro níveis.

R2_1721(config)#enable secret level ?
<1-15> Level number

R2_1721(config)#enable secret level 3 blog

Agora vamos criar o privilégio para o nível que foi exemplificado:

privilege = É usado para se definir quais comandos estarão disponíveis para o nível específico de criação.

R2_1721(config)#privilege exec level 3 ?
LINE Initial keywords of the command to modify

R2_1721(config)#privilege exec level 3 show startup-config

Este método pode ser aplicado diretamente para a interface console ou AUX, exigindo que aquele usuário siga os mesmos critérios disponibilizados para Telnet.

R2_1721(config)# line console 0****R2_1721(config-line)# privilege level 3

Para exemplificar essa aplicação vamos criar alguns nivéis de privilégio para um determinado usuário:

R2_1721(config)# **enable secret level 3 blog**R2_1721(config)# privilege exec level 3 ping
R2_1721(config)# privilege exec level 3 traceroute
R2_1721(config)# **privilege exec level 3 configure terminal**R2_1721(config)# **privilege configure level 3 interface**R2_1721(config)# **privilege configure level 3 ip**R2_1721(config)# privilege configure level 3 address
R2_1721(config)# **privilege configure level 3 no**R2_1721(config)# privilege configure level 3 shutdown

Após essa configuração o usuário deve digitar:

R2_1721> enable 3

A senha que deve ser informada é a configurada anteriormente ” blog “. Após entrar no modo enable tente executar os comandos liberados para este nível. Após fazer essa validação altere novamente o privilégio de alguns comandos, retirando o comando ( privilege exec level 3 configure terminal ) e tente novamente entrar com o privilégio 3 e configurar o ip da interface.

Lembre-se para fazer essa alteração de configuração, você terá que entrar novamente com o privilégio 15.

Espero que gostem do post! 😉

Fonte:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfpass.html
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftprienh.html

Abs,
Rodrigo

Cisco – Validação de Design

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

Olá Pessoal,

Gostaria de passar uma dica, para qual pode nos ajudar no nosso dia a dia para determinados assuntos relacionados a design de rede. A Cisco disponibiliza soluções de desgin, testes e documentos para facilitar e melhorar o desenvolvimento de projetos para os clientes. Esses designs incorporam a grande variedade de tecnologia e produtos dentro do portifólio de solução que tem sido desenvolvido e endereçado a necessidade de negócio dos clientes.

Cisco Validation Design ( CVD ) é organizado por área de soluções, para qual irá apresentar uma lista de um, dois ou três tipos principais de design.

Um exemplo que podemos consultar seria validar uma documentação/design para um site que iremos disponibilizar serviços de WAN. Dentro dessa categoria podemos ter exemplos de Branch Offices ( Pequeno, Médio, Grande ), com utilização de MultiCast, ferramentas de colaboração, IPT e entre outras.

Esse documentos trazem melhores práticas de configurações ( comandos ), exatamente, quais os comandos vou aplicar em cada equipamento para disponibilizar aquele serviço para meu cliente.

Aproveitem e boa leitura!!

http://cisco.com/go/cvd

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

Tradução IPV6 para IPV4

Wed, 10 Aug 2011 00:00:00 +0000

1) Introdução

Devido ao grande aumento da utilização da Internet e facilidade para acessar os recursos que utilizamos dentro do mundo virtual a conectividade foi sendo solicitada cada vez mais para usuarios comerciais, residencias e móveis.

Na década de 80 tivemos uma divulgação maior sobre o protocolo IPV4 que era utilizado para todas as conectividades que poderiamos fazer com o mundo global sendo para redes domésticas, comerciais e de estudo. O protocolo foi descrito através da RFC791 especificamente no ano de 1981, para qual durante esse período diversas atualizações foram executadas para que o protocolo pudesse se adaptar a demanda que foi crescendo dentro do mundo virtual.

A proposta desse artigo foi exemplificar que nesses dias atuais podemos migrar nossa rede IPV4 para uma rede IPV6, com utilização de sistemas operacionais suportando toda a pilha TCP/IP dentro da nova arquitetura IPV6, tendo com isso um acesso ao mundo externo através de uma rede IPV4.

Neste momento podemos iniciar uma migração da nossa rede interna ( LAN ) para IPV6 com a intenção de suportar futuramente as novas aplicações e suporte das migrações das operadoras.

2) Topologia

Nesta topologia a idéia é demonstrar uma arquitetura IPV6 acessando uma arquitetura IPV4, através da tecnologia NAT-PT.\

Todos os equipamentos estão utilizando tecnologia Cisco, baseado em configurações de protocolo IPV6.

3 ) Equipamentos

Neste laboratório estamos utilizando roteadores 2691 dentro do simulador GNS3. Para esse contexto temos 2 modelos de IOS para que possamos utilizar funções de IPV6 e IPV4.

O IOS é o sistema operacional que utilizamos nos roteadores Cisco. Segue os modelos de IOS utilizados para esse laboratório:

IPV6:
c2691-advipservicesk9-mz.124-15.T6.bin

IPV4:
c2691-advsecurityk9-mz.124-15.T14.bin

Esse hardware pode ser consultado através da página da Cisco, porém ele não é mais vendido devido ter sido determinado como “End of Life”. Neste caso estamos utilizando esse equipamento no simulador devido a granularidade que ele oferece e devido a ser um equipamento de baixo consumo de memória dentro do GNS3. Segue a documentação da Cisco 2600.

Para conectividade dos circuitos WAN estamos utilizando placas com interfaces seriais ofertadas pelo GNS3. Toda a conectividade WAN tem a oferecer como uma conectividade 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 utilização de uma configuração disponibilizada pela Cisco para trabalhar com a migração que deve existir entre os dois protocolos IPV4 e IPV6. Essa tecnologia é chamada de NAT-PT para IPV6.

O protocolo IPV6 tem um total de 128 bits, divididos em oito grupos de 16bits. Toda a representação do IPV6 será feita em hexadecimal ( Base 16 ), ou seja, a conversão dos endereços IPV4 ( decimal ), precisa ser executado para hexadecimal. Segue um exemplo do endereçamento IPV6.

Figure 1: Link

No site NIC.br, podemos ter explicações sobre esse protocolo IPV6, mas uma figura que pode exemplificar especificamente as designações dos endereços pode ser verificada abaixo:

Figure 2 – Link

Devido a grande dificuldade de traduzir o endereçamento para o formato hexadecimal existem calculadoras IP que podem facilitar essa tradução. No momento eu poderia indicar esse site, que pode trazer benefícios para esses calculos.

Os endereçamentos escolhidos para esse laboratório foi referenciando-se em algumas premissas para endereços reservados e endereços roteavéis. As informações referentes a estrutua do IPV6 e designações do formato do protocolo pode ser consultada através da RFC4291.

Para adicionar mais um parâmetro que podemos utilizar dentro desses endereçamentos IPV6, podemos utilizar uma função disponibilizada nos equipamentos para distiguir um endereço local de um equipamento através do endereço MAC da interface. Esse processo damos o nome de EUI-64, para qual faz a conversão de um endereço MAC para um endereço IPV6 da interface propriamente habilitada. Como podemos imaginar, pois o endereço MAC tem 48 bits e iremos transformar esses endereço em 64 bits. O metodo utilizado é adicionar nesse endereço 16 bits, utilizando o FF:FE e fazendo a troca do sétimo bit para 0 ou 1. Segue um exemplo:

Figura 3 – Link

Dentro desse parâmetro podemos ter mais alguns exemplos que podem exemplificar essa configuração. Segue os exemplos:

0000 0000 no qual temos 0 0 in hex
Irá se tornar
0000 0010 no qual temos 0 2 in hex

0000 0101 no qual temos 0 5 in hex
Irá se tornar
0000 0111 no qual temos 0 7 in hex

0000 1110 no qual temos 0 E in hex
Irá se tornar
0000 1100 no qual temos 0 C in hex

Essa tecnologia NAT-PT tem o recurso de fazer a tradução de um endereço IPV6 para uma rede IPV4 dentro das novas características diponiblizadas para o protocolo IPV6. Esse protocolo tem as mesmas particularidades que existem para a tecnologia que utilizamos para o IPV4, dentro as quais não conseguimos prover segurança fim a fim, devido as traduções que existem dentro do ambiente. O NAT ( Network Address Translation ), foi um dos recursos utilizados dentro do protocolo IPV4 para que o mundo virtual pudesse funcionar até o dia de hoje. A essência dessa tecnologia foi transformar diversos equipamentos ( hosts ), acessando recursos do mundo Internet através de apenas um endereço público, portanto isso possibilitou que endereços publicos pudesse ser reservados para suas devidas necessidades. O documento utilizado para suporte as configurações e total entedimento dessa tecnologia pode ser consultado através da página da Cisco.

Neste laboratório foi utilizado a configuração de NAT-PT dinâmico com overload tendo a facilidade de executar mapeamento dinâmico de IPV4. O overload foi executado apenas em um endereço configurado para este laboratório, mas pode ser configurado para um determinado range. Esta funcionalidade pode oferecer uma praticidade nas traduções de endereços, pois não necessitamos controlar o endereço de retorno do IPV4 para o IPV6, sendo assim, todo acesso a rede IPV4 pode ser mapeada automaticamente sem a criação de uma mapeamento estático do endereço IPV4 para o endereço IPV6. Para simulaçao de um ambiente com roteamento dinâmico foi utilizado um protocolo IGP ( Interior Gateway Protocol ).

O protocolo escolhido para esse exemplo foi o OSPFv3, desenvolvido especificamente para suportar a nova arquitetura do IPV6. Dentro desse ambiente foi gerado uma rota default para toda a estrutura em funcionalidade de forçar para que todo o tráfego de Internet seja direcionado apenas para nosso roteador que esta simulando nossa saida de Internet.
Para demonstrar que podemos expandir o acesso, foi exemplificado uma arquitetura baseada toda em IPV4 com diversos endereços e utilizando protocolo de roteamento específico de IPV4, que no exemplo foi adotado o OSPF.

Um video foi disponibilizado na nossa seção “Video Aula” para demonstrar o funcionamento dessa tecnologia bem como os arquivos de configurações que podem ser obtidos através da seção arquivos.

Para o próximo post iremos exemplificar a arquitetura IPV4 acessando o IPV6, através do NAT-PT.

Abs,
Rodrigo