A Cisco anunciou dia 10 de junho de 2019 durante o Cisco Live San Diego a mudança no seu programa de certificações, o quem tem gerado muita confusão e dúvidas na cabeça de quem está na trilha de uma certificação Cisco.

Nesse artigo vou tentar esclarecer boa parte dessas dúvidas e se ficar algo de fora ou algo que você não encontrou no artigo que “te preocupa”, basta utilizar o campo de comentários que fica no final do artigo que vamos ajudar (mesmo que você não seja nosso aluno)! Combinado?

Abaixo seguem os tópicos que serão abordados nesse artigo:

• Informações Gerais Sobre as Novas Certificações Cisco
• Preços e Idiomas das Novas Certificações Cisco
• Níveis de Certificação Cisco (a Famosa Pirâmide)
• Mudanças nas Certificações Cisco de Entrada ou Entry Level
• Alterações no Nível Associate – CCNA
• O que Vai Cair no Novo CCNA 200-301?
• Nível de Especialista ou Specialist
• Mudanças no Nível Professional – CCNP
• Mudanças no nível Expert – CCIE
• Mudanças no Nível Arquiteto – CCAr
• Recertificação
• Próximos Passos e Recomendações sobre “O que Fazer?”
• Recomendações para Alunos da DlteC

Tenha uma ótima leitura e lembre-se que você pode usar o campo de comentários para deixar suas dúvidas, sugestões ou seu elogio!

Informações Gerais Sobre as Novas Certificações Cisco

As novas certificações só entram em vigor na data de 24 de fevereiro de 2020, sendo que as certificações atuais poderão ser realizadas até 23 de fevereiro de 2020.

Após a data do dia 24/02/2020 somente as provas novas estarão disponíveis.

Outro ponto interessante é que dessa vez as novas provas não podem ser realizadas ANTES de 24/02/2020!

Qual o PORQUE dessas alterações nas certificações Cisco para 2020?

A Cisco justificou que essas mudanças visam a melhoria contínua do processo de certificação, assim como ajustes nas trilhas e tópicos de estudo para adequação com o novo modelo de Redes que está nascendo!

Uma rede muito mais integrada, flexível e com possibilidades infinitas de conexão.

Preços e Idiomas das Novas Certificações Cisco

Ah, antes que você pergunte ainda não foram divulgados preços das novas provas, apenas que a Cisco pretende reduzir o custo total da trilha de certificações.

Mas custo total não quer dizer individual, portanto vamos aguardar cenas dos próximos capítulos.

Outro ponto geral é sobre o IDIOMA das provas…

… a Cisco divulgou que não tem intenção de traduzir as novas certificações e a princípio ficarão os idiomas atuais: Inglês e Japonês.

Agora vamos dar continuidade em nossa leitura falando sobre os níveis de certificação!

Níveis de Certificação Cisco (a Famosa Pirâmide)

Os níveis de certificação Cisco continuam praticamente os mesmos, com a diferença que agora a Cisco evidenciou um nível de especialista (Specialist) entre os níveis Associate (CCNA) e Professional (CCNP), conforme abaixo.

Os níveis iniciam no Entry Level ou certificações Cisco de entrada, depois passam para o nível Associate, os famosos CCNAs que agora vão ser aglutinados em uma única prova (vamos falar mais sobre o CCNA na sequência).

Após o CCNA temos a novidade que foi evidenciada que são as certificações de especialista ou Specialist.

Até o momento as certificações de especialista eram mais relevantes aos parceiros da Cisco, porém agora elas serão utilizadas para indicar as diversas especializações que um profissional pode ter durante sua trilha de certificações.

Por exemplo, um CCNP Enterprise (vamos falar mais tarde sobre os CCNPs) pode tirar sua certificação com foco em Roteamento, porém ao longo da carreira pode fazer certificações de Wireless e comprovar com um título de especialista essa habilidade extra como CCNP.

Após isso temos o nível profissional ou Professional, que são os CCNPs, logo após os Experts e por último o nível de Arquiteto de Soluções Cisco.

Vamos falar sobre as mudanças em cada nível de certificação na sequência separadamente, não se preocupe.

Outra mudança radical é que a Cisco tirou os pré-requisitos que existiam antigamente para entrada e evolução entre os níveis, ou seja, ela simplesmente RETIROU os Pré-Requisitos.

Isso mesmo… Você agora pode iniciar direto pelo CCNP sem passar pelo CCNA!

Essa mudança foi feita porque a Cisco quer agora respeitar a bagagem e o nível de conhecimento dos profissionais que estão entrando no processo de certificação Cisco, pois se você já tem os conhecimentos, por exemplo, de um CCT e CCNA pode entrar direto no CCNP, sem perder tempo ou dinheiro com a base já conhecida.

A única exceção será para o nível CCAr, o qual apenas sendo CCIE você poderá se candidatar.

Agora vamos ver o que muda em cada um dos principais níveis de certificação.

Mudanças nas Certificações Cisco de Entrada ou Entry Level

No Entry Level ou nível de entrada vamos ter uma mudança drástica, pois a certificação CCENT ou Cisco Certified Entry Networking Technician vai deixar de existir a partir de 24 de fevereiro de 2020 e as certificações de nível técnico chamadas de CCT ou Cisco Certified Technician tomarão seu lugar.

Outra informação é que os CCTs atuais serão descontinuados e novas certificações serão criadas, porém ainda não foram divulgados detalhes sobre essas novas provas.

Na prática isso significa se você tiver a certificação CCENT isolada no dia 24/02/2020 você vai simplesmente perder esse título, pois ela não tem paralelo no novo quadro de certificações, uma vez que o CCT e CCENT não serão totalmente equivalentes.

Portanto, se você é CCENT procure antes da data da virada do programa novo de certificação Cisco tirar o ICND-2 para tornar-se CCNA R&S, ou então quaisquer provas de CCNA que tenham o CCENT como pré-requisito, por exemplo, o CCNA Security.

Assim, quando vier a data da migração você será migrado para o novo CCNA (vamos falar disso a seguir).

Alterações no Nível Associate – CCNA

O nível CCNA ou Cisco Certified Network Associate passou por uma mudança radical também!

Ao invés de vários CCNAs, a partir da data da virada teremos apenas DUAS certificações no nível Associate! Vamos falar da primeira…

Agora não existirão mais CCNAs por área de tecnologia como os atuais: CCNA Cloud, CCNA Collaboration, CCNA Cyber Ops, CCNA Data Center, CCDA, CCNA Industrial, CCNA Routing and Switching, CCNA Security, CCNA Service Provider e CCNA Wireless.

Uma certificação única chamada simplesmente “CCNA” com o código 200-301, a qual terá seu material didático chamado “Implementing and Administering Cisco Solutions” substituirá TODAS as anteriores.

Portanto, se você tiver um ou mais CCNAs válidos até o dia da virada, no dia 24 de fevereiro de 2019 eles serão migrados para uma única certificação chamada CCNA e com o prazo de validade que você possui.

Por exemplo, você tirou o CCNA R&S em janeiro de 2018, ele tem uma validade de três anos e deve expirar em janeiro de 2021. No dia 24/02/2019 você passará a ser CCNA e a data de validade dele será em janeiro de 2021.

Além de migrar sua ou suas certificações para um único CCNA, a Cisco noticiou que dará um “Badge” para cada CCNA versão atual que você tenha, indicando assim suas especializações em outras tecnologias.

O que será esse badge ainda não ficou bem claro, mas atualmente ao passar em uma certificação Cisco já é fornecido o badge da certificação pela Cisco, provavelmente será algo semelhante.

Agora vamos falar sobre a segunda opção no nível Associate…

Além do CCNA também teremos a partir de fevereiro de 2020 o CCNA DevNet, focado em profissionais que trabalharão com desenvolvimento de software, pessoal de DevOPs e especialistas em automação de serviços de Rede.

São os profissionais que atuarão com APIs, desenvolvimento de aplicações, automação da Infraestrutura e demais serviços da nova geração de Redes que está se desenvolvendo.

A certificação terá o nome de DEVASC (Developing Applications and Automating Workflows using Cisco Core Platforms) e o código 200-901.

A validade dos novos CCNAs não foi alterada, ou seja, continua com 3 anos.

Como Será e o que Vai Cair no Novo CCNA 200-301?

O novo Cisco Certified Network Associate (CCNA 200-301) será uma prova de 120 minutos e para nós que não somos nativos na língua inglesa teremos ainda os 30 minutos de “prorrogação”.

Ele vai testar conhecimentos e habilidades relacionadas aos fundamentos de Redes, acesso às Redes, conectividade IP (IPv4 e IPv6), serviços IP, fundamentos de segurança, automação e “programabilidade”.

Não será exigido curso oficial da Cisco para fazer o novo CCNA, assim como já é atualmente.

Se tivesse que resumir o novo CCNA diria que ele é a base do atual CCNA R&S com algumas pitadas de Wireless, Segurança e “Pogramability” (básico de SDN e automação).

A estimativa é que o novo CCNA seja maios ou menos 25% menor que a versão atual em sua totalidade, comparando os conteúdos.

Em relação a conteúdo novo também deve entrar entre 25 a 30% de matérias realmente novas no novo CCNA 200-301.

O novo blueprint (tópicos a serem cobrados na prova) terá os seguintes itens já com seus referidos pesos para a prova de certificação CCNA 200-301:

• 1.0 Network Fundamentals – peso 20%
• 2.0 Network Access – peso 20%
• 3.0 IP Connectivity – peso 25%
• 4.0 IP Services – peso 10%
• 5.0 Security Fundamentals – peso 15%
• 6.0 Automation and Programmability – peso 10%

Entram nessa nova prova muito conteúdo do atual CCNA R&S, CCENT e ICND-2, assim como alguns tópicos do CCNA Security e CCNA Wireless.

Em termos de roteamento ficaram apenas a configuração de rotas estáticas IPv4 e IPv6, assim como a configuração do OSPFv2 (para IPv4) Single Area.

Não vai cair mais as configurações do RIPv2, EIGRP e BGP-4 nessa prova.

Outras coisas que você não vai mais ouvir falar e nem vai mais cair na nova prova do CCNA 200-301: OSI, VTP, Licenciamento e ugrades do Cisco IOS, Tecnologias WAN (serial, PPP, MPLS, Metro Ethernet…) nem APIC-EM.

Ah, continua caindo cálculo de sub-redes IPv4!

A parte de Virtualização e SDN já existiam na versão anterior do CCNA R&S, porém foram complementadas nessa nova versão de CCNA 200-301.

O que terá de novidade no novo Cisco CCNA 200-301:

• Wireless LANs
• Dynamic ARP Inspection e DHCP Snooping
• Arquiteturas de segurança
• Overlay, Underlay, Fabric e DNA Center

Agora vou dar um destaque maior nas novidades da parte de programabilidade e automação, veja os itens novos que entraram em destaque:

• 6.1 Explain how automation impacts network management
• 6.2 Compare traditional networks with controller-based networking
• 6.3 Describe controller-based and software defined architectures (overlay, underlay, and fabric)
  • 6.3.a Separation of control plane and data plane
  • 6.3.b North-bound and south-bound APIs.3 Describe controller-based and software defined architectures (overlay, underlay, and fabric).2 Compare traditional networks with controller-based networking.3.a Separation of control plane and data plane
• 6.4 Compare traditional campus device management with Cisco DNA Center enabled device management
• 6.5 Describe characteristics of REST-based APIs (CRUD, HTTP verbs, and data encoding)
• 6.6 Recognize the capabilities of configuration management mechanisms Puppet, Chef, and Ansible
• 6.7 Interpret JSON encoded data

Você não deve se preocupar com essa mudança se estiver estudando o atual CCNA R&S, continue seus estudos!

Nível de Especialista ou Specialist

Nesse novo programa de certificações Cisco, passando nos exames de nível Professional e Expert você receberá certificações do nível especialista ou “Cisco Certified Specialist Certifications“.

Por exemplo, passando na prova de Core (vamos explicar a seguir) do CCNP Enterprise, que será o exame 300-401 ENCOR, você já recebe a certificação chamada “Cisco Certified Specialist – Enterprise Core“.

Dessa maneira você será reconhecido a cada prova de certificação que fizer, não dependendo de finalizar uma trilha de certificação para obter um título que comprove seus conhecimentos naquela assunto.

Lembre-se que na versão atual de certificação um CCNP pode ter várias provas, porém você só obtém um título quando finalizar a trilha completa.

Por exemplo, o CCNP R&S tem as provas ROUTE, SWITCH e TSHOOT. Ao passar nas provas isoladamente você não recebe nenhuma certificação… só passando nas três provas você recebe o título de CCNP R&S.

Com o novo modelo de certificações você será reconhecido a cada passo, a cada exame que passar!

Mudanças no Nível Professional – CCNP

No CCNP também tivemos mudanças, porém agora vamos encontrar as diversas áreas de especialização que estamos acostumados com poucas alterações.

O CCNP terá as seguintes áreas de especialização:

• CCNP Enterprise: antigo CCNP Routing and Switching, CCNP Wireless e CCDP (Design) foram unificados nessa carreira de Enterprise.
• CCNP Security
• CCNP Service Provider
• CCNP Collaboration
• CCNP Data Center
• CCNP DevNet

A forma de obter a certificação CCNP será através de DUAS provas apenas, uma prova chamada “Core Exam” e outra chamada “Concentration Exam“.

A prova chamada Core cobrará o núcleo de conhecimentos daquela determinada área escolhida pelo candidato a CCNP.

Já a prova chamada Concentration Exam tem várias opções e você poderá escolher o tema que você deseja se desenvolver.

Além disso, você pode passar em mais de um concentration exam e ir ganhando títulos de especialista, conforme explicado anteriormente, para mostrar que você está indo além do CCNP, o que é ótimo!

Vamos a um exemplo com o CCNP Enterprise…

O core exam dele é a certificação 300-401 ou ENCOR (Implementing and Operating Cisco Enterprise Network Core Technologies).

Os concentrations exams podem ser os listados abaixo e para ser CCNP você precisa escolher apenas UM deles:

• 300-410 – ENARSI (Implementing Cisco Enterprise Advanced R-ting and Services)
• 300-415 – ENSDWI (Implementing Cisco SD-WAN Solutions)
• 300-420 – ENSLD (Designing Cisco Enterprise Networks)
• 300-425 – ENWLSD (Designing Cisco Enterprise Wireless Networks)
• 300-430 – ENWLSI (Implementing Cisco Enterprise Wireless Networks)
• 300-435 – ENAUTO (Automating and Programming Cisco Enterprise Solutions)

Veja que dentro do CCNP Enterprise você pode se especializar em Roteamento Avançado, Wireless, Design e Automação/Programação.

O prazo de validade continuará de TRÊS ANOS, porém as opções de migração entre o CCNP atual e o novo varia um pouco mais que para o CCNA.

Para isso a Cisco criou páginas de migração onde você pode ver o seu caso em específico, pois você pode ser CCNP completo ou então ter tirado uma ou mais provas da trilha do nível Professional.

Por exemplo, para o CCNP R&S que será substituído pelo CCNP Enterprise.

Se você for CCNP R&S completo na data da virada, simplesmente receberá a certificação CCNP Enterprise.

Se você passou nas provas isoladas do ROUTE e/ou SWITCH terá que fazer o ENCOR e uma prova de Concentration, ou seja, não ajuda nada!

Se você tiver as provas do ROUTE e SWITCH válidas e só falta o TSHOOT, basta fazer um concentration exam para virar CCNP Enterprise.

Agora se você tiver passado no TSHOOT apenas, basta fazer o ENCOR para tornar-se CCNP Enterprise.

Mudanças no nível Expert – CCIE

O nível Expert terá agora as seguintes carreiras:

• CCIE Enterprise Infrastructure (antigo CCIE R&S)
• CCIE Enterprise Wireless (antigo CCIE Wireless)
• CCIE Collaboration
• CCIE Data Center
• CCIE Security
• CCIE Service Provider
• CCDE (Cisco Certified Design Expert)

A forma de obtenção do título de CCIE continua a mesma, ou seja, com uma prova escrita (Written Exam) e uma de laboratório (Lab Exam).

O “CCIE Emeritus” que era obtido após 10 anos após a mudança de fev de 2020 poderá ser obtido somente após 20 anos de certificação.

Além disso, a recertificação do CCIE passou de DOIS para TRÊS anos, assim como o status chamado “CCIE Suspended” não existirá mais após a virada em fev de 2020.

Mudanças no Nível Arquiteto – CCAr

Não houveram mudanças e o Cisco Certified Design Expert continua sendo o pré-requisito para o CCAr.

Recertificação

Agora todos os exames terão validade de TRÊS anos e podem ser recertificados através da realização de outros exames de certificação ou então utilizando créditos do Continuing Education, o qual será divulgado provavelmente a partir de julho desse ano.

Para recertificação com créditos o candidato precisará de:

• 30 créditos para o CCNA
• 80 créditos para o CCNP
• 120 créditos para o CCIE

Próximos Passos e Recomendações sobre “O que Fazer?”

Eu estou escrevendo esse artigo logo após a notícia da Cisco sobre as mudanças em 2020, portanto dependendo de quando você está lendo os prazos para você podem estar mais apertados.

Para quem pegou no início ainda tem praticamente OITO MESES até a data da virada e isso dá um bom tempo de planejamento, pois SÓ EXISTEM DUAS OPÇÕES:

• Continuar os estudos e tirar sua certificação antes de 23 de fev de 2020 ou
• Para TUDO e aguardar a Cisco ou os produtores de conteúdo como nós da DlteC lançarmos novos materiais de estudo e fazer as provas novas somente a partir do dia 24 de fev de 2020.

Como haverá equivalência entre CCNAs, CCNPs e CCIEs antigos com os novos, se você tem condições de tirar sua certificação completa antes da data da virada, CORRA ATRÁS porque vai valer a pena.

Depois você pode complementar seus estudos com assuntos novos utilizando cursos e quem sabe pode até tirar outras certificações de especialista para complementar seu currículo.

O que NÃO DÁ PARA FAZER é FICAR TRAVADO por causa da mudança, afinal o mercado não vai parar e esperar dia 24 de fev do ano que vem para contratar!

O QUE NÃO VALE A PENA FAZER AGORA?

• Prova isolada do CCENT
• Ser CCNA e tirar uma nova certificação CCNA (por exemplo, ser CCNA R&S e tirar o Security)
• Passar em prova isolada do CCNP sem verificar a ferramenta de migração da Cisco, por exemplo, somente o CCNP ROUTE não vale a pena tirar. Porém verifique o Migration Tools de cada CCNP porque pode haver caso que valha a pena.
• Parar tudo e ficar esperando!

Recomendações para Alunos da DlteC

Se você é nossa aluno Premium e está nos cursos CCNA CCENT, CCNA ICND-2, CCNA Security ou algum do CCNP R&S preste atenção nessas recomendações que estou passando em nossos grupos e listas de alunos!

Vale a pena tirar somente o CCENT até a virada?

Não, somente com o CCENT você não terá nenhuma certificação mais após a virada de fev de 2020. Você precisa também tirar ou o ICND-2 ou o CCNA Security para ter o título de CCNA e ser migrado para o novo CCNA.

Já sou CCNA R&S, vale a pena tirar a certificação do CCNA Security até a virada?

Somente vale a pena se você precisa recertificar seu CCNA R&S atual, senão não vale a pena fazer a certificação, pois não importa quantos CCNAs você tenha após fev de 2020 vai virar uma certificação única.

Mas claro, se você está estudando o conteúdo vale a pena finalizar e ter o certificado para comprovar seu conhecimento no currículo.

Não vou conseguir marcar meu CCNA R&S até a virada em fev de 2020, o que devo fazer? Paro tudo e aguardo o novo material ou continuo estudando?

Continue estudando para o CCNA R&S atual através dos cursos CCNA CCENT e CCNA ICND-2. O conteúdo prova nova será em sua maioria assuntos cobrados na versão atual de prova, portanto você não vai perder nada continuando seus estudos.

Os cursos da DlteC serão atualizados para a nova versão? CCNA R&S para o novo CCNA e CCNP R&S para CCNP Enterprise?

Com certeza iremos atualizar ambos os cursos para o novo modelo antes da data da virada em fev de 2020.

Sobre o CCNP R&S o que eu devo fazer se não tenho ele completo?

Você precisa ter as provas do ROUTE e SWITCH ou o TSHOOT isolado para ter alguma vantagem na migração. O ideal é que você tire seu CCNP até lá para ser migrado para o novo CCNP Enterprise.

Se restou alguma dúvida utilizem o campo de comentários para fazer suas perguntas, estaremos aqui para ajudar da melhor maneira possível!

Se você é nossa aluno e assinante Premium não esqueça que pode também tirar suas dúvidas em nossos grupos do Facebook ou do Telegram.

Muito obrigado e até um próximo artigo!

Confiram o artigo original publicado pela DlteC do Brasil: Entenda o que Muda nas Certificações Cisco em Fevereiro de 2020

O tema sobre gerenciamento de redes e como funciona o SNMP é bastante abrangente e normalmente envolvem ferramentas, tais como softwares de gerenciamento (NMS ou Network Management System), que são capazes de realizar inúmeras tarefas e monitorar o ambiente de rede de maneira abrangente.

Em uma rede de médio ou grande porte parâmetros como os abaixo são constantemente monitorados:

• Utilização de memória
• Carga da CPU (processamento)
• Temperatura dos dispositivos
• Status de dispositivos de rede
• Status de links WAN de roteadores
• Utilização de links WAN ou interfaces trunk

Assim como os parâmetros acima, muitos outros podem ser monitorados via um software de gerenciamento de redes e uma equipe de suporte pode agir proativamente ou de maneira reativa frente a problemas que esse sistema de monitoração informa em suas mensagens de alarmes ou avisos.

Certificações como ICND-2, o CCNAX R&S e a nova prova CCNA 200-301 como um todo cobra o conceito do gerenciamento de um dispositivo e da rede utilizando o Syslog, SNMP e o entendimento do AAA.

Entendendo como Funciona o SNMP

O protocolo SNMP ou Simple Network Management Protocol é utilizado para gerenciar redes TCP/IP complexas.

Com o SNMP, os administradores podem gerenciar e configurar elementos de rede de um servidor  localizado centralmente em vez de ter que executar o software de gerenciamento de rede.

Também é possível usar o SNMP para monitorar o desempenho da rede, detectar problemas de rede e acompanhar quem usa a rede e como ela é usada.

O SNMP trabalha por padrão com o protocolo UDP na porta 161.

Uma rede gerida pelo protocolo SNMP é formada por três componentes chaves:

   1. Agentes SNMP (SNMP Agent): os próprios roteadores e switches.

   2. MIB (Management Information Base): base de dados padronizada que é lida por um gerente SNMP.

   3. Gerentes SNMP ou SNMP Manager: Sistemas de Gestão de Redes ou NMS (Network Management Systems), por exemplo, o pacote de software da Cisco chamado Cisco Prime.

Agentes e Gerentes SNMP

Um Dispositivo Gerenciado é um nó de rede que possui um agente SNMP instalado e se encontra numa rede gerenciada.

Estes dispositivos coletam e armazenam informações de gestão e mantêm estas informações disponíveis para sistemas NMS através do protocolo SNMP.

Dispositivos geridos, também às vezes denominados de dispositivos de rede, podem ser roteadores, servidores de acesso, impressoras, computadores, servidores de rede, switches, dispositivos de armazenamento, dentre outros.

Um Agente é um módulo de software de gestão de rede que fica armazenado num Dispositivo Gerenciado.

Um agente tem o conhecimento das informações de gestão locais e traduz estas informações para um formato compatível com o protocolo SNMP e padronizados em bancos de dados chamados MIB (Management Information Base).

Um sistema NMS é um gerente SNMP responsável pelas aplicações que monitoram e controlam os Agentes SNMP.

Normalmente é instalado em um (ou mais que um) servidor de rede dedicado a estas operações de gestão, que recebe informações (pacotes SNMP) de todos os dispositivos geridos daquela rede, por exemplo, o Whatsup Gold, Cisco Prime, Zabbix, Nagios, HP Openview e outros.

Outras Características do SNMP

Trazendo para a realidade dos roteadores e switches, eles são os dispositivos gerenciados, os quais possuem uma MIB, que é um banco de dados que armazena de forma padronizada informações de hardware, software e parâmetros operacionais.

Um Management Information Base ou simplesmente MIB define variáveis de um dispositivo de rede que podem ser monitoradas e/ou controladas por um software de gerenciamento.

Através de um sistema de gerenciamento (gerente SNMP) podemos ler essas informações e apresentá-las de forma mais intuitiva para que um analista de suporte, por exemplo, tenha informação de quanta CPU está sendo utilizada pelo roteador naquele momento através de um comando SNMP Get.

Esse tipo de operação pode ser automatizado em sistemas de gerência para geração de avisos, por exemplo, o gerenciador pode de 5 em 5 minutos checar o uso de CPU pelo roteador e se chegar a 50% gerar um aviso na tela de gerenciamento que a CPU passou desse limite configurado (threshold ou limiar).

Outro tipo de mensagem que o SNMP pode gerar é um TRAP.

Esse tipo de mensagem é gerada espontaneamente pelo dispositivo para informar que um problema inesperado ocorreu.

Os traps são mensagens SNMP que descrevem uma variável da MIB, porém geradas pelo próprio dispositivo, sem a solicitação do NMS, o qual pode tomar uma ação diferente nesse caso, por exemplo, enviando uma mensagem para um destinatário de e-mail e soar um alarme para a equipe de monitoração.

Versões do Protocolo SNMP

O SNMP possui três versões principais: 1, 2c e 3.

A versão 1 é extremamente antiga e raramente encontrada atualmente, as versões mais utilizadas são a 2c e 3.

A diferença entre as duas últimas é que a versão 2 não possui muitos recursos de segurança, o que foi contemplado para a felicidade de muitos administradores de rede na versão 3 do SNMP.

A versão 3 possui recursos como autenticação, garantia da integridade das mensagens e criptografia.

Como Implementar na Minha Rede?

O primeiro passo é saber se seus dispositivos suportam o SNMP e que versão é suportada.

Normalmente o SNMP exige uma ativação e configuração dos dispositivos gerenciados que podem ser desde computadores até seus dispositivos de redes, por exemplo, roteadores e switches.

Outro ponto é escolher um Gerente, um software de gerenciamento que fará a coleta e envio de avisos do SNMP.

Como já citado, os softwares de gerenciamento são muitos, mas uma coisa você precisa saber é que eles podem ser pagos ou gratuitos.

Dependo do software escolhido sua complexidade pode variar e dificultar sua vida até fazer tudo funcionar perfeitamente, porém no final TUDO SERÁ COMPENSADO!

Pois, se tudo for bem planejado e implementado, nunca mais você ficará sem respostas para seus problemas do dia a dia, assim como com os dados coletados poderá planejar melhor o crescimento da sua rede.

Configurando o SNMPv2 em Roteadores e Switches Cisco

Para configurar o SNMP em roteadores e switches Cisco utilizamos os passos abaixo, sendo que somente o passo 1 é obrigatório, os demais são opcionais:

1. Configurar a community string e o nível de acesso com o comando “snmp-server community comunidade RO|RW” em modo de configuração global.
2. Descrever (documentar) a localização do dispositivo com o comando “snmp-server location”.
3. Documentar o contato responsável pelo dispositivo com o comando “snmp-server contact”.
4. Restringir o acesso SNMP apenas ao servidor ou host que possui o sistema NMS utilizando uma ACL no comando “snmp-server community nome-da-comunidade num-ou-nome-da-acl”.

Veja exemplo de configuração abaixo onde o host de gerenciamento tem IP 192.168.1.15 e a comunidade a ser configurada apenas como leitura tem o nome dltec12345. Vamos também limitar o acesso à comunidade exclusivamente ao host de gerenciamento.

R1(config)#access-list 1 permit host 192.168.1.15

R1(config)#snmp-server community dltec12345 RO 1

R1(config)#snmp-server location Curitiba/PR/Brasil

R1(config)#snmp-server contact Marcelo Nascimento – 41 3045-7810

R1(config)#end

R1#

Se fosse necessário acesso de leitura e escrita o comando que define a comunidade será: “snmp-server community dltec12345 RW 1”, apenas trocamos o RO por RW.

Qual o Próximo Passo?

Quer aprender mais sobre o como funciona protocolo SNMP? Recomendamos o artigo abaixo:

Dicas de validação das configurações Netflow e SNMP v3 para CCNAs e CCNPs

Confiram o artigo original publicado pela DlteC do Brasil: Como Funciona o SNMP e sua Importância no Gerenciamento de Redes

Se você está estudando para o LPI-101 precisa também entender a inicialização e como gerenciá-la, por isso mesmo esse artigo trata do gerenciamento da inicialização do Linux através do SysVinit.

O que é o SysVinit?

O SysVinit é o sistema tradicional de inicialização de serviços.

Após iniciar o processo /sbin/init, o SysV lê o arquivo /etc/inittab para determinar o nível de execução padrão do sistema e iniciar os demais serviços.

Quando falamos em nível de execução, estamos nos referindo a quais serviços deverão ser executados (ou finalizados) no sistema em um determinado nível (numerados de 0 a 6).

Observe a seguir um resumo sobre os níveis de execução e seus propósitos (segundo discriminado no Debian 7.4):

• 0: De forma direta, esse nível desliga o sistema. Também conhecido como halt.
• 1, s ou S: Nível monousuário.Utilizado pelo superusuário para realizar atividades básicas para manutenção do sistema (sem acesso à rede ao compartilhamento de arquivos).
• 2, 3, 4 e 5: Multiusuário.
• 6: Reinicialização do sistema (reboot).

Lembre-se de que os runlevels 0, 1 e 6 são comuns a qualquer distribuição.

Baseado no nível de execução configurado, são executados os scripts presentes nos diretórios /etc/rcx.d/ (ex: rc5.d, rc3.d, etc.).

Nesses diretório encontarm-se diversos links simbólicos para arquivos contidos no diretório /etc/init.d/.

No próximo capítulo iremos estudar o seu arquivo de configuração e aprender a configurar o runlevel padrão e realizar mudanças entre os níveis com o sistema em execução.

Apesar de bastante robusto, este método apresenta como ponto negativo o fato dos serviços serem executados em sequência, fazendo com que a inicialização do sistema seja mais demorada.

Você já deve saber que o/sbin/init manda chamar os scripts pertencentes ao nível de execução configurado como padrão em /etc/inittab.

E quem irá de fato executar esses scripts? O script /etc/init.d/rc.

Esse receberá como parâmetro valores de zero a seis e buscará dentro dos diretórios inicializadores (/etc/rcX.d (onde X representa o runlevel em questão)) pelos scripts de inicialização.

Os scripts contidos nos diretórios de inicialização são, na verdade, links simbólicos para o diretório /etc/init.d.

Em algumas distribuições Linux, o diretório é o /etc/rc.d/init.d.

Dentro dos diretórios inicializadores, podemos ter scripts com nomes iniciados em K ou S.

Aqueles iniciados com a letra K, irá finalizar o serviço naquele runlevel (por exemplo, /etc/rc0.d/K01apache finaliza o Apache no runlevel 0).

Já aqueles que iniciam com a letra S, irá iniciar um serviço naquele runlevel (por exemplo, /etc/rc2.d/S17apache2 inicia o serviço Apache no runlevel 2).

Além disso, os scripts possuem uma ordem determinada.

Por exemplo, o script /etc/rcX.d/S1xxx será executado primeiro que /etc/rcX.d/S2xxx. Durante a inicialização, o último script a ser executado é o /etc/rc.local.

Apesar de bastante robusto, este método apresenta como ponto negativo o fato dos serviços serem executados em sequência, fazendo com que a inicialização do sistema seja mais demorada.

Gerenciamento de Inicialização no SysVinit

Vamos analisar o conteúdo do arquivo /etc/inittab e aprender a como trocar o runlevel do sistema (e configurar o nível padrão a ser utilizado).

Observe os principais campos contidos no arquivo /etc/inittab, bem como breves descrições sobre cada um deles (a partir da distribuição Debian 7.4):

dltec@cap1:~$ cat /etc/inittab

# Este é o runlevel configurado como padrão no sistema.

id:2:initdefault:

# indica o primeiro runlevel executado durante o boot, exceto no modo de emergência.

si::sysinit:/etc/init.d/rcS

# Localização de cada dos serviços e scripts a serem iniciados para cada nível de #execução

# Runlevel 0 => desligamento.

# Runlevel 1 => monousuário.

# Runlevels 2-5 => multiusuário.

# Runlevel 6 => reinicialização.

l0:0:wait:/etc/init.d/rc 0

l1:1:wait:/etc/init.d/rc 1

l2:2:wait:/etc/init.d/rc 2

l3:3:wait:/etc/init.d/rc 3

l4:4:wait:/etc/init.d/rc 4

l5:5:wait:/etc/init.d/rc 5

l6:6:wait:/etc/init.d/rc 6

# O que fazer quando as teclas CTRL-ALT-DEL forem pressionadas.

ca::ctrlaltdel:/sbin/shutdown -t3-r now

# O que deverá ser feito quando ocorrer falta de energia e quando a mesma retornar.

pf::powerwait:/etc/init.d/powerfail start

pn::powerfailnow:/etc/init.d/powerfail now

po::powerokwait:/etc/init.d/powerfail stop

# Terminais virtuais disponíveis para os runlevels em execução

1:2345:respawn:/sbin/getty 38400 tty1

2:23:respawn:/sbin/getty 38400 tty2

3:23:respawn:/sbin/getty 38400 tty3

4:23:respawn:/sbin/getty 38400 tty4

5:23:respawn:/sbin/getty 38400 tty5

6:23:respawn:/sbin/getty 38400 tty6

Analisando as Ações

Além da ação initdefault (define o runlevel do processo init), existem outras. Veja a seguir:

• respawn: O processo é reinicializado caso seja parado ou finalizado.
• wait: O processo é iniciado e o init espera pela sua finalização.
• once: O processo é iniciado no momento em que o runlevel também é iniciado.
• boot: O processo é iniciado no boot do sistema. O runlevel é desnecessário e ignorado.
• bootwait: O processo é iniciado no boot do sistema enquanto o init aguarda a sua finalização. O runlevel também é desnecessário e ignorado.
• off: Não realiza nenhuma ação.
• sysinit: O processo é iniciado durante o boot, porém antes das ações boot/bootwait. O runlevel também é desnecessário e ignorado.
• powerwait: O processo é iniciado em casos de queda de energia. O processo init aguarda a sua finalização.
• powerfail: O processo também é iniciado em casos de queda de energia, mas o init não aguarda a sua finalização.
• powerfailnow: O processo é executado em casos em que a bateria do nobreak está quase acabando.
• powerokwait: No momento em que a energia for restabelecida, o processo relacionado a essa ação é executado.
• ctrlaltdel: Ação a ser tomada no momento em que forem pressionadas as teclas Ctrl + Alt + Del.
• kbrequest: Executa determinada ação quando alguma combinação de teclas especial for pressionada (será necessário alterar o mapa de caracteres do sistema).

Veja um exemplo de ação relacionada ao pressionamento das teclas Ctrl + Alt + Del:

Para verificarmos o runlevel atual, podemos utilizar o comando runlevel:

dltec@cap1:~$ runlevel

N 2

O comando runlevel retorna o nível de execução anterior e o atual. Se o nível permaneceu inalterado desde a carga do sistema, o nível anterior será mostrado como N.

Para trocar o runlevel do sistema, os comandos init ou telinit podem ser utilizados. Por exemplo, para trocar o nível de execução atual para o runlevel 1, um dos seguintes (equivalentes) comandos podem ser utilizados:

dltec@cap1:~$ init 1

dltec@cap1:~$ telinit 1

Os processos poderão também ser administrados através de comandos como:

# Pára o servidor de impressão CUPS

dltec@cap3:~$ /etc/init.d/cups stop

# Inicia o servidor de impressão CUPS

dltec@cap3:~$ /etc/init.d/cups start

# Recarrega o servidor de impressão CUPS

dltec@cap3:~$ /etc/init.d/cups reload

# Verifica o status do servidor de impressão CUPS

dltec@cap3:~$ /etc/init.d/cups status

Qual o Próximo Passo?

Se você gostou desse artigo e está se preparando para a prova LPI-101, recomendamos também que você leia o artigo:

Kit de Sobrevivência para Aspirantes a LPIC-1

Confiram o artigo original publicado pela DlteC do Brasil: SysVinit e Gerenciamento de Inicialização do Linux para LPI-101

Nesse artigo vamos falar sobre o AAA para CCNA, ou seja, o que você precisa saber sobre o AAA para as provas de certificação Cisco ICND-2, CCNAX e também para o novo CCNA 200-301 que será lançado em fevereiro de 2020.

AAA ou Authentication, Authorization, and Accounting é um assunto cobrado tanto nas provas atuais como será cobrado quando o CCNA mudar em 24 de fevereiro de 2020.

O AAA (Authentication, Authorization, and Accounting) oferece uma forma para a autenticação de usuários em servidores ou dispositivos de conectividade (router, switch, etc), além de controlar o nível de acesso destes usuários para os recursos desejados e gravar os comandos realizados para futuras auditorias.

Para que isto seja possível, o AAA participa em três etapas durante este processo:

1. Autenticação de usuários: Com o AAA, é possível centralizar o gerenciamento de todas as contas de usuários e respectivas senhas, facilitando bastante o trabalho do administrador da rede. O administrador da rede poderá especificar diversos mecanismos para a autenticação de usuários, entre eles RADIUS, TACACS+ ou Kerberos e, para que isto ocorra, a ordem de execução destes componentes deverá ser informada e devidamente associada para uma interface ou mais interfaces do equipamento de rede. Por exemplo, um usuário que necessita configurar uma rota em um roteador Cisco poderá informar o seu username e password para o acesso ao equipamento.

• Autorização para a execução de comandos: Após a autenticação do usuário, o AAA precisa informar ao roteador sobre os comandos que o referido usuário poderá executar no terminal. É possível limitar a quantidade de comandos disponíveis para a execução das seguintes formas: por usuário, perfil ou grupo de usuários.

• Auditar os acessos ao equipamento: O AAA enviará dados sobre cada comando executado pelo usuário durante uma sessão com o roteador. Com este recurso, poderemos identificar e controlar todas as atividades de configuração e monitoramento efetuadas no roteador. Por exemplo, o administrador de rede pode analisar o que o usuário dltecuser fez durante sua sessão e quando ele executou os comandos.

Mais especificamente em roteadores e switches Cisco o AAA pode utilizar um banco de dados local ou servidor externo para autenticação e autorização.

Quando falamos de AAA para CCNA temos que falar também dos protocolos que podem ser utilizados na implementação prática: RADIUS e TACACS.

Normalmente o que é configurado na prática é o AAA com servidores externos TACACS+ ou RADIUS e o banco de dados local é utilizado como “fallback”, ou seja, caso haja um problema com a comunicação entre o roteador e o servidor ele pode utilizar um usuário do banco de dados local para fazer o login, por exemplo.

A seguir vamos estudar um pouco mais sobre esses protocolos e suas características.

Protocolo RADIUS

O protocolo RADIUS (Remote Authentication Dial-In User Service) hoje faz parte dos padrões da IETF.

Ele pode funcionar juntamente com outros serviços.

O RADIUS tem uma porta para autenticação/autorização (UDP 1645 ou UDP 1812) e outra para contabilidade (accounting – UDP 1646 ou UDP 1813).

O processo de autenticação do RADIUS utiliza um servidor que tem contato com o cliente, um servidor RADIUS e um banco de dados onde os dados dos usuários são armazenados.

A autenticação é feita por meio de uma mensagem que o cliente RADIUS envia para o servidor RADIUS contendo login e senha.

Quando o servidor recebe a mensagem, ele valida o cliente e verifica o login, senha e outros parâmetros que vêm com a mensagem.

Em caso de uma autenticação válida, o servidor envia ao cliente uma mensagem permitindo o acesso bem como as ações permitidas pelo nível de acesso.

Protocolo TACACS+

O protocolo TACACS+ é proprietário da cisco sendo suportado pela grande maioria dos roteadores da cisco.

É uma melhoramento do protocolo aberto TACACS.

O TACACS+ também é um protocolo que veio após o RADIUS e portanto apresenta algumas vantagens em relação a este.

O TACACS+ usa conexões TCP (mais segura) enquanto que o RADIUS faz transporte via UDP (menos seguro).

Do ponto de vista da segurança a diferença entre os protocolos de transporte utilizados é fundamental.

O RADIUS precisa trabalhar com um número maior de variáveis para suprir a falta de serviços do UDP.

Como TACACS+ usa TCP, que é orientado a conexão, esses detalhes não são preocupação do protocolo TACACS+.

Usando TCP é mais fácil descobrir quando um servidor está off-line e quando ele está simplesmente lento.

O TACACS+ criptografa todo o corpo do pacote e faz a separação entre autenticação e autorização e contabilização.

Com essa separação é possível criar soluções de autorização separadas.

O TACACS+ utiliza o protocolo TCP na porta 49 para transmitir suas informações de maneira segura.

Além disso, o TACACS+ tem suporte multiprotocolo.

Qual o Próximo Passo?

Se você está estudando sobre AAA também deve estar interessado em como podemos acessar dispositivos como Roteadores e Switches da Cisco.

Recomendamos a leitura do artigo abaixo:

Descubra Tudo Sobre como Acessar um Switch ou Roteador Cisco

Confiram o artigo original publicado pela DlteC do Brasil: AAA para CCNA – Authentication, Authorization, and Accounting

Nesse artigo vamos tratar sobre como podemos escrever e interpretar os endereços IPv6, ou seja, como funciona o básico do endereçamento IPv6.

Hexadecimal para Endereçamento IPv6

Vamos começar fazendo uma revisão sobre Hexadecimal com foco em IPv6, isso porque o IPv6 é escrito usando a notação Hexadecimal!

Como já visto em posts anteriores, o endereço IPv6 possui 128 bits e é escrito em hexadecimal, diferente do IPv4 que eram 32 bits (4 conjuntos de 8 bits escritos em decimal pontuado).

Portanto, agora cada algarismo de um IPv6 pode ter os números de 0 a 9, assim como as letras de A a F, totalizando 16 algarismos, por isso o nome hexadecimal.

Veja quanto vale de A a F em decimal (você pode escrever as letras do hexadecimal tanto em maiúsculo como em minúsculo, tanto faz!):

• “A” vale 10 em decimal
• “B” vale 11 em decimal
• “C” vale 12 em decimal
• “D” vale 13 em decimal
• “E” vale 14 em decimal
• “F” vale 15 em decimal

Entendendo o Endereçamento IPv6

Antes de falar de como o endereçamento é dividido vamos ver como podemos escrever um endereço IPv6 (notação em hexadecimal) e também as partes que o compõe.

Como já vimos um endereço IPv6 não é mais escrito em Decimal e sim em Hexadecimal, isso porque seu tamanho em binário tornaria o seu tamanho de escrita em decimal uma coisa impraticável.

Como cada algarismo em hexadecimal tem 4 bits, em 128 bits temos um total de 32 algarismos hexadecimais divididos de 4 em 4, ou seja, oito conjuntos de quatro algarismos em hexadecimal separados por dois pontos “:” (não mais pelo ponto “.” como era no IPv4).

Um exemplo de IPv6 é “2000:1234:ade4:ffa0:2234:0000:0000:0012”.

Existem ainda três contrações (reduções) que podemos fazer nos endereços IPv6:

1. Zero a esquerda pode ser omitido: 2000:1234:ade4:ffa0:2234:0000:0000:12
2. Conjuntos de 4 zeros na mesma casa podem ser reduzidos para um zero: 2000:1234:ade4:ffa0:2234:0:0:12
3. Sequências de zeros podem ser substituídas por dois conjuntos de dois pontos: 2000:1234:ade4:ffa0:2234::12

A única recomendação é que não haja ambiguidade para a terceira contração.

Para entender vamos ver um exemplo com o IP 2000:1234:ade4:0000:0000:2234:0000:12.

Se escrevermos ele com a contração 2000:1234:ade4::2234::12 nós sabemos, por visualizar o IP que deu origem, que existem dois conjuntos de 4 zeros à esquerda do 2234 e um só conjunto à direita.

No entanto, como um dispositivo (roteador ou computador) irá distinguir como ele deve completar isso na prática?

Pois se pegarmos apenas o IP contraído 2000:1234:ade4::2234::12 ele pode ser tanto 2000:1234:ade4:0000:2234:0000:0000:12 como 2000:1234:ade4:0000:0000:2234:0000:12.

Logo, essa notação é inválida, pois para o dispositivo ela é ambígua uma vez que ele não vai saber como preencher os espaços com os zeros.

Portando, o IP deveria ser escrito como “2000:1234:ade4:0:0:2234::12” ou “2000:1234:ade4::2234:0:12”.

Prefixos de Redes IPv6

Outra representação importante, a qual já foi comentada anteriormente, é a dos prefixos de rede.

No IPv6 continuamos escrevendo os endereços como no IPv4 utilizando a notação CIDR, ou seja, “endereço-IPv6/tamanho do prefixo”, onde “tamanho do prefixo” é um valor decimal que especifica a quantidade de bits contíguos à esquerda do endereço que compreendem o prefixo, ou seja, a soma dos bits uns do prefixo.

Um endereço IPv6 pode ser dividido em um Prefixo Global (Global Prefix), Subrede (subnet ID) e endereço da Interface (Interface ID).

O prefixo global normalmente é um /32, já o prefixo de subrede pode ser /48 (usuários corporativos) ou /56 a /64 (para usuários residenciais) dependendo do uso e recomendação de cada país.

Já o endereço da interface utiliza os bits restantes do prefixo, ou seja, 128 bits menos o prefixo de subrede.

Vamos a um exemplo utilizando a rede 2001:db:3000:1::/64, onde sabemos que temos 128 bits totais no endereço, porém 64 bits são utilizados para identificar a sub-rede, portanto termos:

• Prefixo 2001:db:3000:1::/64
• Prefixo global 2001:db::/32
• ID da sub-rede 3000:1
• ID de host: temos 64 bits (ou seja, 2^64= 18.446.744.073.709.551.616 endereços IP)

Da mesma maneira que mostramos no IPv4 com o CIDR e a notação em prefixos.

No IPv6 podemos fazer a agregação de várias subredes de maneira hierárquica para reduzir a quantidade de redes anunciadas pelos protocolos de roteamento.

Portanto, além de continuar valendo o conceito de subrede e a utilização de diferentes prefixos conforme a necessidade de cada rede IPv6, similar ao VLSM.

URLs e Endereços IPv6

Com relação a representação dos endereços IPv6 em URLs (Uniform Resource Locators), eles agora passam a ser representados entre colchetes.

Deste modo, não haverá ambiguidades caso seja necessário indicar o número de uma porta juntamente com a URL, por exemplo:

• http://[2001:db:3000:1::22]/index.html
• http://[2001:db:3000:1::22]:8080

Qual o Próximo Passo?

Se você gostou desse artigo e quer aprender mais sobre IP versão 6, recomendamos também a leitura do artigo abaixo:

Descobrindo Vizinhos no IPv6 com o NDP ou Neighbor Discovery Protocol

Confiram o artigo original publicado pela DlteC do Brasil: Endereçamento IPv6 Básico

Olá caros amigos, leitores do blog e alunos da DlteC, hoje estava navegando pela Internet lendo artigos sobre os 25 anos dessa maravilha da humanidade que é a grande rede e acabei caindo em alguns artigos sobre a história do CCNA, o qual teve sua primeira versão de prova lançada em 1998, quase metade da idade da Internet.

Tudo começa com o CCNA 640-407, o qual tinha entre 60 e 70 perguntas com 75 minutos de prova.

Nele caíam questões de modelo OSI, sub-rede, TCP/IP, AppleTalk, IPX/SPX, Token Ring, ISDN, switches 1900 e por aí vai nos assuntos considerados hoje em dia velharia.

Aí nos idos dos anos 2000 veio a prova 640-507 com poucas mudanças, apenas retiraram AppleTalk e Token Ring e anunciaram a entrada do IOS 12.x, apesar de outras mudanças essas foram as principais.

Por acaso essa que eu fiz (Jun 23, 2003 Exam 640-507 Cisco Certified Network Associate – Passed), porém eu comecei a estudar com o material do 640-407, por isso cheguei a pegar IPX/SPX e algumas coisinhas a mais…

Estou ficando velho mesmo…

Até esse ponto a prova custava 100 dólares, porém mais ou menos em março 2002 lançaram a prova 640-607, foi aqui que comecei a dar aulas na Academia Cisco que ajudei a montar em sua primeira versão no Senai aqui em Curitiba, na época além de professor acabei me tornando o Main Contact.

Nessa versão a Cisco introduziu os laboratórios através de simuladores na prova, pois até a versão anterior não tinha prática, mas em termos de conteúdo não houveram mudanças significativas.

Em 2003 aí sim a coisa começou a mudar com a prova 640-801, até a numeração mudou, além disso foram lançadas as provas 640-821/ICND-1 e 640-811/ICND-2 e o CCNA passou a ter dois caminhos, em prova única ou através das duas provas citadas anteriormente.

Nessa versão de prova saíram alguns tópicos e entraram outros como EIGRP, OSPF single area, configuração de switches Catalyst 2950, etc. As simulações também continuaram e foram aprimoradas.

Aí em outubro de 2007 vem mais uma nova versão, a 640-802.

A Cisco manteve o mesmo esquema de tirar a certificação em uma ou duas provas, porém depois de um tempo transformou a prova do ICND-1 em uma certificação a parte chamada CCENT (Cisco Certified Entry Level) com o ID 640-822, preparando caminho para mudanças mais ousadas em termos de CCNA que veremos mais para frente.

A segunda prova para tirar o CCNA em dois tempos agora passou a ser a 640-816 e continuou a chamar ICND-2.

Nessa nova revisão foram inseridos conceitos avançados de switching, com a configuração do STP, conceitos avançados de EIGRP e OSPF, segurança, troubleshooting, RSTP, wirelles e com isso, em minha humilde opinião de professor, criaram um monstro! Essa prova virou uma verdadeira “salada tecnológica”.

Continuando, por volta de 2008 a Cisco notou que precisava quebrar as disciplinas do CCNA em mais carreiras e assim acompanhar os diferentes CCIEs criados, tais como CCIE Routing and Switching, CCIE Wireless, CCIE Voice, CCIE Security e CCIE Storage.

É bem lógica a mudança, se temos vários caminhos para seguir e diferentes tecnologias no CCIE tanto o CCNA como o CCNP vão ter que seguir a mesma linha, por isso foram anunciados os exames CCNA Security 640-553, CCNA Voice 640-460 e o CCNA Wireless 640-721 inicialmente.

Em 2012 os exames dos CCNAs das outras carreiras foram atualizados para as provas: CCNA Security 640-554, CCNA Wireless 640-722 e CCNA Voice 460-461.

Com tudo isso o 640-802 estava pesado e sem foco real na carreira que era de seu interesse: Routing and Switching.

Aí vem uma nova versão em 2013, a qual atualizamos em nossos cursos online também, a prova 200-120 que passou a se chamar CCNAX ou Interconnecting Cisco Networking Devices: Accelerated.

Opa, olha só, a prova anterior 640-802 era o CCNA Composite, ou seja, todo conteúdo dos livros e exames ICND-1 e ICND-2 em uma prova só, porém agora mudaram de CCNA para CCNAX a prova única.

O ICND-1 continua a certificação CCENT agora com o número 100-101 e o ICND-2 passou a ser o exame 200-101.

Outro fato interessante é que da primeira versão para cá o CCNA R&S subiu de 100 dólares para 290 dólares se for feito em uma prova só (CCNAX) ou 300 dólares se você fizer em duas provas (CCENT+ICND-2).

As provas das outras áreas continuam em 250 dólares.

Mas também com o anúncio das novas versões 200-120/100-101/200-101 a Cisco anuncia que o CCENT agora é o pré-requisito para maioria das carreiras, ou seja, se você quer ir para área de voz não precisa mais ser CCNA R&S, sendo CCENT você já pode prestar o ICOMM (640-461) e ter sua certificação CCNA Voice, por exemplo.

Com isso podemos economizar 150 ou 145 dólares se não quisermos seguir a carreira de Routing and Switching.

Em termos de conteúdo a prova ficou mais focada na carreira de Routing and Switching (R&S) e vários assuntos interessantes entraram, por exemplo, IPv6 com mais profundidade e visão prática, OSPFv3, EIGRPv6, OSPF para IPv4 com mais detalhes, FHRP com os protocolos para redundância no primeiro salto e balanceamento de cargas, troubleshooting com mais estruturação, Netflow e SNMP para gerenciamento da rede,  etc.

Dessa vez a revisão ficou realmente interessante e mais adequada ao que vemos que um CCNA precisa para trabalhar com roteadores e switches.

Além disso, nessa mesma época a Cisco começou a lançar vários CCNAs por áreas m diferentes tecnologias.

A última alteração de prova ocorreu em agosto de 2016, onde o CCNA R&S foi atualizado para a versão CCNAX em uma prova com o código 200-125, no valore de 325 dólares.

As provas do CCENT/ICND-1 e ICND-2 passaram para os códigos 100-105 e 200-105 respectivamente, sendo que o valor de cada prova passou para 165 dólares.

Além da carreira de roteamento e switching, temos atualmente CCNAs para diversas áreas, conforme listagem abaixo:

• CCNA Cloud
• CCNA Collaboration
• CCNA Cyber Ops,
• CCNA Data Center
• CCNA Industrial
• CCNA Security
• CCNA Service Provider
• CCNA Wireless

Além da listagem acima, se contarmos o nível associate como um todo temos ainda o CCDA.

A pouco tempo atrás a Cisco anunciou novas mudanças nas suas certificações, sendo que para os CCNAs com um impacto devastador para uns e animador para outros… a torcida anda meio dividida ainda…

A próxima versão de CCNA virá dia 24 de fevereiro de 2020 e substituirá TODOS os CCNAs anteriores com apenas uma prova chamada CCNA 200-301.

Essa prova será de modelo único, não terá mais opção em duas provas, além disso o nível de entrada CCENT deixa de existir.

Praticamente tudo volta ao início quando tínhamos apenas um CCNA! (rsrs)

O novo CCNA terá como base o CCNA R&S (aproximadamente 70% da prova) com alguns conteúdos de Wireless, Segurança e automação de rede.

Se você quiser saber mais sobre as alterações das certificações da Cisco que ocorrerão em fevereiro de 2020 veja o artigo abaixo:

“Entenda o que Muda nas Certificações Cisco em Fevereiro de 2020“

Bem, já divaguei bastante, contei muita historinha e vou parando por aqui.

Espero que você tenha gostado e usem o campo de comentários abaixo para deixar sua dúvida, sugestão ou até mesmo um elogio!

Abraços e até a próxima!

Confiram o artigo original publicado pela DlteC do Brasil: CCNA – Um Pouco da História do Exame de Certificação da Cisco

Deixa eu começar esse artigo sobre o novo CCNA 200-301 com um provérbio, porque no caso da pergunta que é o título desse artigo não vale o ditado que diz “quem espera sempre alcança” e sim nesse caso será…

… “Quem Espera, Desespera“

Você vai entender o porque desse ditado no final do artigo, por isso leia até o final, combinado?

Depois dessa introdução inspirada, se você é nosso leitor assíduo deve ter notado que tenho um certo gosto por dilemas (rsrs) e por isso vou escrever sobre mais um deles que o novo CCNA 200-301 tem gerado na mente dos nossos alunos do portal, assim como em vários seguidores das nossas redes sociais, que é:

“Eu continuo estudando o CCNA Atual (CCNAX 200-125 ou CCENT 100-105 + ICND2 200-105) ou Espero pelo Novo CCNA 200-301 sair em Fevereiro de 2020?“

Essa é uma decisão importante, pois em nossa visão essa é A OPORTUNIDADE para começar 2020 com uma certificação SUPER RECONHECIDA NO MERCADO e na virada de fevereiro de 2020 ter ela atualizada para a nova versão sem sacrifício.

Isso porque se você for CCNA (qualquer um deles) na virada de 24 de fevereiro de 2020 você receberá automaticamente a nova certificação CCNA mais um badge pela tecnologia do seu CCNA específico atual, simples e fácil assim.

O primeiro ponto importante que temos que analisar é que na tentativa de dificultar o novo CCNA 200-301 a Cisco retirou a opção de duas provas e você precisará a partir de fevereiro de 2020 fazer o CCNA novo em apenas uma prova.

Para você entender como isso impacta nas aprovações no CCNA R&S atual, desde 2013, data em que a Cisco criou o CCNA R&S em duas provas através dos exames CCENT/ICND-1 e ICND-2, nossos alunos que fazem o CCNA em duas provas tem praticamente 100% de aprovação na primeira tentativa.

Somente esse mês que estou escrevendo esse artigo tivemos 8 aprovações na primeira quinzena de julho, sendo que 7 deles de alunos fazendo a opção do CCNA R&S em duas provas e uma de um aluno que optou pelo CCNA 200-125, mesmo fazendo em uma prova ele passou!

Mas nosso índice de aprovação CCNA R&S só não é 100% devido a alunos sem experiência com certificações e optaram pelo exame do CCNA em uma prova, tudo bem que esse índice de aprovação é ainda alto, pois está até quando escrevi o artigo em 98,8% de aprovações em primeira tentativa.

Veja que isso pode impactar nas aprovações de primeira, porém claro que vamos ter que adaptar nosso material e ajustar o mindset dos nossos alunos para essa nova realidade e tentar minimizar esse impacto em nossos índices.

Porém, como em duas provas nossa galera passa mais fácil é muito interessante aproveitar essa janela que a Cisco deu entre julho de 2019 e fevereiro de 2020 para passar em duas provas e, como disse anteriormente, garantir o CCNA R&S mais o novo na virada, concorda?

Mais um ponto importante é que temos todo um histórico com as provas atuais, seja a CCNAX em uma prova ou CCENT+ICND2 em duas provas…

… tanto em nosso conteúdo, como labs e questionários no Portal que garante uma segurança muito maior para nossos assinantes.

Assim como temos vários relatos nos fóruns de aprovados e alunos trocando informações em nossos grupos.

Tudo isso vai ser estabelecido também com o tempo para o novo CCNA 200-301, porém experiência prática com a nova prova vai iniciar somente após 24 de fevereiro de 2020, pois antes disso ninguém vai poder fazer essa prova.

Muitos me perguntaram também o seguinte: “Mas professor Marcelo, não vou ficar desatualizado se fizer um CCNA atual?“

Se você estiver estudando para o CCNA R&S não, pois o novo CCNA será praticamente 70% o CCNA Routing & Switching atual com algumas pitadas de redes sem fio, segurança e programabilidade, coisas fáceis de serem aprendidas, e o melhor…

… se você for assinante do nosso Portal vai poder estudar com nosso material essa diferença, pois antes da virada em fevereiro de 2020 vamos lançar o material do CCNA 200-301 ATUALIZADO!

Então vamos juntos analisar as condições de contorno tratadas até agora e mais algumas informações para que possamos juntos chegar a uma conclusão sobre nosso dilema:

1. A Cisco só vai lançar o livro oficial em Setembro de 2019
2. A prova nova do CCNA 200-301 será liberada apenas 24 de fevereiro de 2020, não teremos como analisar as questões antes disso
3. O novo CCNA não terá mais a opção de uma ou duas provas, ou seja, será apenas em uma prova tornando-o naturalmente mais difícil
4. A Cisco vai aumentar o tempo de prova do novo CCNA 200-301 para nativos de 90 minutos para 120 minutos (um fato que comprova o que ela prometeu sobre as novas certificações ficarem mais difíceis de passar!), para não nativos como nós Brasileiros ainda terá um tempo extra que atualmente é de 30 minutos
5. 70% do conteúdo da prova novo do CCNA 200-301 será IGUAL a prova da versão atual CCNAX 200-125 ou ICND-1 100-105 + ICND-2 200-105, por isso continuar a estudar o CCNA R&S atual não trará prejuízos em termos de contúdo
6. Quem tiver o CCNA atual será migrado automaticamente para o novo em 24 de fev de 2019

Lendo tudo isso creio que você entendeu que É SIM UMA ÓTIMA OPORTUNIDADE FAZER O CCNA R&S ATUAL, principalmente em duas provas.

Mas veja que se você for fazer em duas provas é preciso planejar muito bem o prazo, pois se você passar na primeira prova que é o CCENT ou ICND-1 não terá nenhuma vantagem na virada de fev de 2020, pois essa certificação não existirá mais e simplesmente você perderá seu CCENT.

Para fazer em duas provas você precisa garantir que terá tempo de fazer também o ICND-2 antes da virada, combinado?

É possível passar nas duas provas CCENT/ICND-1 + ICND-2?

Sim, é plenamente possível e recomendável aproveitar essa ÚLTIMA CHANCE que a Cisco está nos oferecendo.

ÚLTIMAS DICAS MUITO IMPORTANTES:

Não esqueça que estamos no Brasil e TODO MUNDO tem o costume de DEIXAR TUDO PARA A ÚLTIMA HORA, portanto se você vai enfrentar ou já está com esse desafio imposto a si mesmo não perca tempo para comprar suas provas no site da Pearson Vue e garanta seu agendamento.

Pode acontecer uma lotação das vagas para realização das provas nos certos da Vue se você pretende fazer as provas entre a segunda quinzena de Janeiro e 23 de fevereiro de 2020. Muito cuidado com isso!

Outra coisa fundamental que eu sempre digo em nossos vídeos, cursos e artigos: mesmo com essa limitação de tempo, estude para sua vida prática, aprenda de verdade que ser aprovado será uma consequência!

Não aceite decorebas, DUMPs, colas, fórmulas mágicas e atalhos, pois depois na vida profissional, no seu dia a dia você será cobrado e PRECISA TER O CONHECIMENTO e não somente um título ou certificação!

Com isso eu finalizo mais um artigo e espero que tenha sido útil e ajudado na sua decisão!

Lembro que qualquer pergunta, dúvida, sugestão ou até mesmo um elogio pode ser feito utilizando campo de comentários no final da página, é só rolar um pouco que você vai encontrar!

Mais uma vez agradeço a leitura e até um próximo artigo!

Confiram o artigo original publicado pela DlteC do Brasil: Passar no CCNA Atual ou Esperar pelo Novo?

Nesse artigo vamos falar sobre as principais ferramentas de gerenciamento de Redes que você pode encontrar no mercado, ou seja, ferramentas de gerenciamento de redes que as empresas mais utilizam no seu dia a dia.

Não queremos aqui falar de TODAS, mas apenas as que consideramos principais por encontrar em diversas empresas ou serem utilizadas por alunos do nosso Portal.

Esse artigo foi feito com base no conteúdo do curso Online do Portal da DlteC chamado “Gerenciamento de Redes“.

NAGIOS

Um dos softwares de gerenciamento muito utilizado é o Nagios, fornecido pela NagiosEnterprises que fornece os produtos oficiais, serviços e soluções baseados no Nagios®.

A NagiosEnterprises foi fundada em 2007 por Ethan Galstad. Ethan criou o que mais tarde se tornaria conhecido como Nagios em 1999 e atualmente atua como Presidente da NagiosEnterprises.

O Nagios foi desenvolvido para ser executado no sistema operacional Linux, nas distribuições CentOS e RedHat. Para sua instalação em servidores com Windows Server é necessário a utilização de um uma máquina virtual, com a utilização de um programa de virtualização, tal como VMWare, Hyper-V ou V-Sphere.

As ferramentas disponibilizadas pela Nagios são:

• Nagios XI: software comercial de gerenciamento de TI e de infraestrutura de TI, com duas versões (Standard Edition e Enterprise Edition).A versão Standard ainda necessita de renovação anual de contrato de manutenção e suporte. É possível fazer o download de uma versão trial para 60 dias.
• Nagios Log Server: ferramenta corporativa para monitorização, gestão e análise de mensagens de log, que permite facilmente visualizar, consultar e analisar todos os logs gerados pelos dispositivos monitorados. Possui apenas uma demonstração on-line além da versão comercial, cujo custo dependerá do número de clusters atendidos.
• Nagios Network Analyzer: solução comercial para análise de fluxo dados de rede, fornecendo uma visualização de todo o tráfego de rede, incluindo a utilização de largura de banda. Permite uma proatividade na resolução de falhas, detectando comportamento anormal e descobrindo as ameaças de segurança antes que eles afetem os processos críticos. Também possui uma demonstração on-line além da versão comercial.
• Nagios Fusion: solução para visualização do status operacional da rede, permitindo uma rápida resolução de problemas de infraestrutura. Utilizada pela equipe de operações de TI para obter uma visão centralizada de toda a infraestrutura, permitindo a rápida detecção de problemas, correlação de eventos e resolução de falhas. Também possui uma demonstração on-line além da versão comercial.
• Nagios Core: é a versão open source base para o desenvolvimento do software de monitoração Nagios XI. É uma versão reduzida do software Nagios XI com muito menos funcionalidades, porém disponibilizada sem custo (free).

Com o NagiosCore é possível monitorar todos os componentes de missão crítica da infraestrutura de TI, conforme mostrado na figura abaixo.

É possível obter uma visão centralizada das operações de toda a infraestrutura de TI e informações de status detalhado através da interface web.

Os alertas podem ser escalonados para os diversos níveis hierárquicos da equipe de TI, através de e-mail e SMS, garantindo o rápido acionamento dos responsáveis, para uma rápida recuperação de falhas.

Outras funcionalidades doNagiosCore são:

• Resolução de problemas: Manipuladores de eventos podem reiniciar automaticamente falha de aplicativos, servidores, dispositivos e serviços quando forem encontrados problemas.
• Planejamento proativo: a visualização das tendências permite planejar proativamente os upgrades.
• Relatórios: os relatórios de disponibilidade permitem garantir que os SLAs estão sendo atendidos e relatórios históricos fornecem registro de informações críticas.
• Múltiplas visões: o acesso multiusuário permite que visualizações específicas do usuário sejam configuradas, para garantir que os usuários vejam apenas a informação específica de interesse.
• Arquitetura expansível: múltiplas APIs permitem a integração com aplicações desenvolvidas pela própria empresa, por terceiros ou pela comunidade de desenvolvedores.

ZABBIX

Outro software muito utilizado para a monitoração de redes é o Zabbix, que é distribuído pela Zabbix LLC, baseada nos Estados Unidos, Europa e Japão, cujo CEO e proprietário é Alexei Vladishev.

O foco da Zabbix LLC é o desenvolvimento de software open source para monitoramento de redes e das aplicações. Além disso, a empresa oferece uma ampla gama de serviços profissionais, projetados para atender as demandas de cada negócio, incluindo a implementação, integração, desenvolvimento personalizado e consultoria de serviços, bem como vários programas de treinamento.

O Zabbix é uma das ferramentas de software open source mais populares utilizados para o monitoramento dos recursos de TI. É utilizada por um grande número de empresas devido à sua escalabilidade, alto desempenho, facilidade de uso e custos de propriedade extremamente baixos.

A primeira versão do Zabbix foi desenvolvida em 2001 e em 2005 foi estabelecida como empresa para prover o serviço de suporte especializado para a ferramenta.

Para monitoração de computadores e servidores é necessário a instalação de um agente de monitoração, o Agente Zabbix. Este agente nativo do Zabbix, desenvolvido em linguagem C, pode rodar nos diversos sistemas operacionais, tais como Linux, UNIX e Windows, coletando informações sobre CPU, memória, discos e interfaces de rede.

Como este agente é muito reduzido e demanda baixos recursos, pode ser instalado em equipamentos mesmo com recursos limitados.

As configurações de monitoração são centralizadas no servidor Zabbix, facilitando o gerenciamento do agente Zabbix, utilizando um arquivo com configuração simples em todos os servidores, como pode ser visto nas figuras abaixo, onde temos a instalação em um servidor Linux e em um servidor Windows.

Os agentes Zabbix suportam a verificação passiva (pooling) e ativa (trapping). O Zabbix pode executar verificações em intervalos de tempo periódicos ou em horários específicos.

• Verificação passiva (pooling): o servidor Zabbix faz a requisição de algum parâmetro para o agente Zabbix, que processa a solicitação e retorna o parâmetro solicitado para o servidor Zabbix.
• Verificação ativa (trapping): o agente Zabbix solicita ao servidor Zabbix uma lista de quais são as verificações ativas. Os agentes enviam periodicamente o resultado dos parâmetros listados.

Monitoração de logs: o suporte para monitoração de mensagens de logs e Log de eventos do Windows é uma função nativa do agente Zabbix. Os logs são analisados constantemente pelo agente Zabbix e quando um item definido de busca é identificado, o servidor Zabbix é notificado e pode tomar alguma ação ou enviar automaticamente uma notificação para um usuário ou grupo.

Suporte a WMI: uma função nativa do Zabbix é o suporte ao Windows Management Instrumentation (WMI) permitindo monitorar e tempo real as informações s de sistema e métricas de performance para estações e servidores Windows.

O agente Zabbix também tem suporte ao Ipv6.

O Zabbix permite a detecção de problemas através da definição de níveis de thresholds ajustados automaticamente.

A visualização pode ser feita através de uma única interface web que permite múltiplas formas de visualização dos recursos de TI, incluindo: dashboards, gráficos, mapas de rede, slideshows e relatórios detalhados.

Uma das funcionalidades do Zabbix é a notificação e remediação, através dos seguintes recursos:

• Envio de mensagens.
• Correção de problemas automaticamente.
• Escalonamento de problemas de acordo com níveis de serviço.
• Personalização de mensagens com base no papel do destinatário.
• Personalização de mensagens com tempo de execução e informações de inventário.

OZabbix permite a proteção dos dados utilizandomecanismos de segurança e autenticação, através de:

• Criptografia forte entre todos os componentes do Zabbix.
• Múltiplos métodos de autenticação: Open LDAP, Active Directory.
• Esquema flexível de permissão de usuários.
• O código doZabbixé aberto para auditorias de segurança.

A implementação do Zabbix é realizada de maneira bastante simplificada, com o uso de centenas de templates disponíveis na comunidade de desenvolvedores.

Outra funcionalidade do Zabbix é o auto-discovery que permite a adição, remoção e modificação de elementos automaticamente, através das seguintes funcionalidades:

• Descoberta de rede: varreduras periódicas da rede, descobrindo o tipo de dispositivos, endereço IP, status e outros, executando ações pré-definidas.
• Descoberta em baixo nível: criação automática de itens, triggers e gráficos para os diferentes elementos em cada dispositivo.
• Auto registro dos agentes ativos: início automático da monitoração dos dispositivos com o agente Zabbix instalado.

Com o Zabbix é possível também fazer o monitoramento distribuído, coletando dados de dispositivos mesmo atrás de Firewalls e DMZ.

E com o uso de APIs é possível integrar o ZAbbix com outras aplicações.

Portanto o Zabbix, mesmo na sua versão Open Source que possui menos recursos do que a versão comercial, é uma ferramenta muito eficiente para o gerenciamento de equipamentos e de ativos de rede.

PRTG

O PRTG é uma ferramenta de gerenciamento de redes, baseada em Windows, desenvolvida pela Paessler AG (www.br.paessler.com), que foi fundada em 1997 na região metropolitana de Nuremberg e hoje tem representantes pelo mundo todo, apoiando os parceiros e clientes localmente.

O PRTG NETWORK MONITOR monitora todos os sistemas, dispositivos e aplicativos de uma infraestrutura de TI. Tudo o que é necessário para o monitoramento está contido no PRTG, não são necessitando de downloads adicionais.

Os requisitos para instalação do servidor principal do PRTG dependerão do número de dispositivo e sensores a serem monitorados, na proporção usual de 10 sensores por dispositivo. O hardware deverá ser um x64, com Windows Server 2012 R2,Windows Server 2016 ou Windows 10, com .NET Framework 4.7.2 ou posterior instalado em todos os sistemas que executam o servidor do núcleo do PRTG ou uma sonda PRTG.

O PRTG monitora tráfego, pacotes, aplicações, largura de banda, serviços da cloud, bases de dados, ambientes virtuais, tempo de atividade, portas, IPs, hardware, proteção, serviços web, ambientes físicos, dispositivos IoT e quase tudo o que se possa imaginar.

Tem suporte a SNMP (todas as versões), tecnologias Flow (i.e.NetFlow, jFlow, sFlow), SSH, WMI, Ping, SQL. e APIs (Python, EXE, DLL, PowerShell, VB, Batch Scripting, REST) para integrar todo o restante das demais aplicações.

É possível fazer o dowload gratuito desta ferramenta, sendo que a versão ilimitada ficará operacional por um período de 30 dias, passando então para a versão gratuita, com determinadas limitações. Para a versão completa é necessário fazer a aquisição da versão comercial após o período de teste.

Com o PRTG é possível gerar alertas flexíveis: com 10 formas de geração de alertas, incluindo e-mail, SMS, execução de arquivos EXE, entre outros. Através do PRTG API permite desenvolver as próprias notificações.

Podem ser utilizadas diversas interfaces de usuário:

• Interface web completa: baseada em AJAX com elevados padrões de segurança, com alto desempenho, graças à tecnologia de Aplicação de Página Única (SPA), e ajuste ideal aos seus sistemas graças ao seu projeto responsivo.
• Enterprise Console: aplicativo nativo do Windows para PRTG on-premises, especialmente para várias instalações PRTG.
• Aplicativos para iOS e Android.
• Todas as interfaces de usuário permitem o acesso local e remoto protegido por SSL e podem ser usadas simultaneamente.

Os mapas e Dashboards podem ser customizados, com mais de 300 diferentes objetos, permitindo a monitoração em tempo real com o status de todos os elementos críticos.

Com as PRTG Remote Probes é possível monitorar várias redes, em diferentes locais e redes separadas dentro da própria empresa (por exemplo, DMZ e LAN), obtendo uma visão geral da rede em um ponto central de monitoração.

Podem ser gerados relatórios periódicos ou por demanda, bem como a exportação dos dados de monitoramento nos formatos PDF, HTML, XML ou CSV.

CACTI

O Cacti é uma solução gráfica para redes, projetada para aproveitar o poder de armazenamento de dados do RRDTool e sua funcionalidade gráfica. O Cacti fornece uma rápida coleta de dados, modelagem gráfica avançada, vários métodos de aquisição de dados e recursos de gerenciamento de usuário adicionais. Tudo isto é encapsulado em uma interface intuitiva, fácil de usar que pode ser utilizada para redes LAN de médio porte até redes complexas com milhares de dispositivos.

O Cacti foi desenvolvido para ser executado em uma plataforma Linux, distribuído no modelo de licença GNU(General PublicLicense), necessitando de alguns softwares adicionais para a sua operação.

Os dados coletados são armazenados em um banco de dados MySQL. Portanto, para a instalação do Cacti é necessário instalar o MySQL antes da instalação do servidor Cacti.

A interface do Cacti é desenvolvida em PHP, sendo necessário instalar esta ferramenta de software, bem como um servidor HTTP, para disponibilizar a interface de acesso ao programa.

Por se tratar de um software Open Source, o site doCacti mantém um fórum de discussão que pode auxiliar na instalação e manutenção da ferramenta, bem como o compartilhamento de novos recursos desenvolvidos pela comunidade.

O Cacti apresenta diversas funcionalidades, tais como:

• Número ilimitado de gráficos por host;
• Envio de alertas via email;
• Script personalizado;
• Armazenamento configurável de históricos;
• Rápido resequenciamento dos itens gráficos;
• Suporte completo ao RRDTOOL;
• Suporte ao protocolo SNMP;
• Modelos gráficos pré configurados;
• Gerenciamento totalmente web;
• Multiusuário web com níveis de acessos.

OPMON

O OpMon é um software de monitoramento de infraestrutura de TI desenvolvido por uma empresasediada no Brasil. Permite gerenciar incidentes de forma automatizada, obtendo dados reais e confiáveis sobre a saúde do seu ambiente. Um dos diferenciais do OPMON é o suporte local e em português, com especialistas emgovernança de TI.

O Hardware e Software mínimo recomendado para acesso ao OpMon são:

• Processador Dual Core 2 Ghz ou superior;
• Memória RAM de 2 GB ou superior;
• Disco rígido de 80 Gb;
• Placa de rede de 10 Mbits ou superior;
• Monitor com resolução de 1024 x 768 ou superior;
• Firefox 45.x, Internet Explorer 11.x, Chrome 45.x, Safari 9.x ou superiores;
• Adobe Flash Player 11.3 ou superior.

A ferramenta é disponibilizada em três versões:

• Free (gratuito para sempre): Todas as funcionalidades da versão PRO, monitora até 30 devices, número de serviços e sensores ilimitados.
• OPMON PRO: Com subscrição anual, permite o monitoramento avançado, gráficos em tempo real, análise de causa raiz, notificações email, SMS e App PUSH, monitoramento adaptativo e relatórios avançados
• OPMON 360 (Monitoramento + Smart CMDB): permite a automatização do ambiente, Discovery Full Stack, Gestão de Documentação, Gestão de Configuração, CMDB & Gestão de Mudanças e Single Point ofFailures.

A nova versão do OpMon provê dashboards automáticos que simplificam a gestão de infraestrutura de TI. Permite visualizar os problemas que devem ser resolvidos prioritariamente. É totalmente responsivo aos dispositivos móveis.

Além do poderoso construtor de dashboardscustomizáveis do OpMon, a nova versão integra-secom o Grafana. Isso permite mais possibilidadesde visualização de dados, gestão à vista e maioragilidade na tomada de decisões.

O OpMon fornece recurso para visualização de alertas definidos por cores, de acordo com o nível de criticidade. São 9 cores que identificam diferentes estados: fora, inacessível, crítico, desconhecido, advertência, instabilidade, reconhecido, manutenção e ok.

Outras Ferramentas

Existem diversas outras ferramentas, tais comoSolarWinds, Verax IT Management Suite (ITMS), NetXMS entre outros

Alguns fabricantes de equipamentos também fornecem softwares de gerenciamento, tal como a HP, que disponibiliza diversas ferramentas específicas, tais como:

• HPE OneSphere: plataforma de gerenciamento multinuvem como serviço que simplifica o gerenciamento de ambientes multinuvem e a infraestrutura no local. Por meio de uma visualização unificada, a TI pode compor nuvens híbridas capazes de suportar tanto aplicativos tradicionais como nativos da nuvem.
• Aruba Central e Aruba Airwave: soluções de gerenciamento para a rede sem fio da Aruba, que é a divisão de WiFi da HPE.
• HPE Intelligent Management Center Enterprise: ferramenta de gerenciamento de rede com e sem fio que conta com suporte ao modelo FCAPS, permitindo que a TI faça um gerenciamento de negócios de ponta a ponta, além da expansibilidade da arquitetura do sistema e a acomodação de novas tecnologias e infraestrutura. A plataforma de software Intelligent Management Center (IMC) Enterprise suporta o gerenciamento de dispositivos da Hewlett Packard Enterprise e de terceiros.

Com isso finalizamos mais um artigo e caso você tenha algum comentário, dúvida ou elogio é só utilizar o campo de comentários logo abaixo do artigo!

Obrigado e até uma próxima!

Confiram o artigo original publicado pela DlteC do Brasil: Conheça as Principais Ferramentas de Gerenciamento de Redes de Mercado

Se você ainda não sabe, em fevereiro de 2020 a Cisco vai “matar” TODOS os CCNAs atuais e trocar por uma única e nova certificação CCNA 200-301.

Então quer dizer que não teremos mais CCNAs por tecnologia? O CCNA Cloud, CCNA Collaboration, CCNA Cyber Ops, CCNA Data Center, CCDA, CCNA Industrial, CCNA Routing and Switching, CCNA Security, CCNA Service Provider e CCNA Wireless TODOS ELES IRÃO MORRER depois de 24 de fevereiro de 2020?

É isso mesmo, com exceção do CCNA Devnet, o qual é também uma novidade, agora as demais áreas não terão mais CCNAs específicos e todos eles serão substituídos pela certificação CCNA 200-301.

Você pode estar se perguntando:

“Então esse novo CCNA vai ser GIGANTE para abranger TODAS as áreas que a Cisco matou para deixar apenas um CCNA!!!“

Não será gigante não, pois ela será praticamente o CCNA R&S atual! Leia todo o artigo e você vai descobrir porque, combinado?

O novo Cisco Certified Network Associate (Certificação CCNA 200-301) será uma prova de 120 minutos, terá versões nas línguas Inglesa e Japonesa e para nós que não somos nativos na língua inglesa provavelmente teremos ainda os 30 minutos de “prorrogação”, como já é feito para as provas atuais.

Veja que esse aumento no tempo de prova já é um sinal que a Cisco pretende dificultar as coisas para obtenção da nova certificação CCNA 200-301!

A nova certificação CCNA 200-301 vai testar conhecimentos e habilidades relacionadas aos fundamentos de Redes, acesso às Redes, conectividade IP (IPv4 e IPv6), serviços IP, fundamentos de segurança, automação e “programabilidade” de rede.

Não será exigido curso oficial da Cisco para fazer o novo CCNA, assim como não haverá mais pré-requisito para realizar a nova certificação CCNA 200-301.

Se eu tivesse que resumir o novo CCNA diria que ele é…

… o CCNA R&S atual com algumas pitadas de Wireless, Segurança e “Pogramability” (básico de SDN e automação).

Conteúdo da Nova Certificação CCNA 200-301

A estimativa é que o conteúdo da nova certificação CCNA 200-301 seja maios ou menos 30% menor que a versão atual em sua totalidade.

Comparando o conteúdo do atual CCNA R&S com a nova certificação CCNA 200-301, deve entrar entre 25 a 30% de matérias novas.

Porém você vai ver que novidade mesmo é pouco, pois alguns tópicos foram herdados do CCNA Wireless e CCNA Security.

O novo blueprint (tópicos a serem cobrados na prova) terá os seguintes itens já com seus referidos pesos para a prova de certificação CCNA 200-301:

Note que os três primeiros itens que tratam sobre fundamentos de Redes, acesso às Redes e Conectividade IP somam um total de 65% da nova certificação CCNA 200-301!

Os conteúdos que você não vai mais ouvir falar e nem vai mais cair na nova prova do CCNA 200-301: OSI, VTP, Licenciamento do Cisco IOS, Upgrades do Cisco IOS, Tecnologias WAN (serial, PPP, MPLS, Metro Ethernet…) nem APIC-EM.

Para quem pensava que o IPv4 iria morrer nessa nova prova saiba que ele vai continuar caindo e cálculo de sub-redes IPv4 também!

Em termos de roteamento ficaram apenas a configuração de rotas estáticas IPv4 e IPv6, assim como a configuração do OSPFv2 (apenas para IPv4) Single Area.

Não vai cair mais as configurações do RIPv2, EIGRP e BGP-4 nessa prova, assim como não serão cobrados protocolos de roteamento dinâmicos para IPv6.

A parte de Virtualização e SDN já existiam na versão atual do CCNA R&S, porém foram complementadas nessa nova versão de CCNA 200-301.

Principais Novidades do CCNA 200-301

O que terá de novidade no novo Cisco CCNA 200-301? Veja abaixo:

• Wireless LANs – conceitos e configurações básicas de APs
• Dynamic ARP Inspection e DHCP Snooping
• Arquiteturas de segurança
• Overlay, Underlay, Fabric e DNA Center

Agora vou dar um destaque maior nas novidades da parte de programabilidade e automação, veja os itens novos que entraram em destaque:

• 6.1 Explain how automation impacts network management
• 6.2 Compare traditional networks with controller-based networking
• 6.3 Describe controller-based and software defined architectures (overlay, underlay, and fabric)
  • 6.3.a Separation of control plane and data plane
  • 6.3.b North-bound and south-bound APIs.3 Describe controller-based and software defined architectures (overlay, underlay, and fabric).2 Compare traditional networks with controller-based networking.3.a Separation of control plane and data plane
• 6.4 Compare traditional campus device management with Cisco DNA Center enabled device management
• 6.5 Describe characteristics of REST-based APIs (CRUD, HTTP verbs, and data encoding)
• 6.6 Recognize the capabilities of configuration management mechanisms Puppet, Chef, and Ansible
• 6.7 Interpret JSON encoded data

O que fazer até a Virada? Vale a pena Estudar o CCNA Routing and Switching atual?

Você não deve se preocupar com essas mudanças se estiver estudando para o CCNA R&S, continue seus estudos!

Seja para uma prova (CCNAX 200-125) ou duas provas (CCENT/ICND-1 100-105 + ICND-2 200-105) continue seus estudos e se puder TIRE SEU CCNA R&S antes da virada em 24/02/2020.

Se você conseguir obter seu CCNA R&S até a virada será uma grande conquista, pois sua certificação será atualizada para a nova certificação CCNA 200-301 e você ainda ganhará um badge confirmando que você conhece roteamento e switching!

Se você não conseguir fazer o exame até a virada, quase tudo o que você estudou vai continuar valendo para o novo CCNA 200-301, pois você viu que a base dele é o CCNA R&S!

Nós vamos lançar o curso com a versão atualizada do CCNA 200-301 antes da virada em fev de 2020, provavelmente até Dezembro de 2019 teremos o curso todo pronto e já liberado para nossos alunos e assinantes no Portal da DlteC.

Conclusão sobre a Certificação CCNA 200-301

Então você se você conhece o histórico das certificações Cisco o que eles fizeram foi voltar ao princípio, onde havia apenas um CCNA!

Sim, já houve uma época onde existia apenas UM CCNA e UM CCNP…

Agora voltamos a ter UM CCNA para as carreiras de tecnologia que estamos acostumados e teremos vários CCNPs com especializações por segmentos de tecnologia.

Como a certificação CCENT vai morrer após a virada, acima você viu o nível Technician vai substituir o nível de entrada e passará a ser o novo Entry Level.

Se você quiser mais informações sobre os demais níveis veja esse artigo abaixo que fala de todas as mudanças:

“Entenda o que Muda nas Certificações Cisco em Fevereiro de 2020“

Se você quiser conhecer um pouco da história de um dos exames de certificação mais famoso do mundo veja esse artigo:

“CCNA – Um pouco da história do exame de certificação da Cisco“

Confiram o artigo original publicado pela DlteC do Brasil: Novidades da Certificação CCNA 200-301: O que realmente tem de novo?

Nesse artigo vamos tratar de um assunto muito importante para quem está na trilha da certificação Linux LPIC-1 que é o gerenciamento de pacotes utilizando as ferramentas RPM e YUM.

Esse assunto sobre o RPM e YUM é cobrado mais especificamente na prova de certificação LPI-101, uma das duas provas que fazem parte da certificação Linux LPIC-1.

Antes de iniciarmos o conteúdo sobre RPM e YUM deixa eu avisar que esse artigo foi feito com base no curso do Portal da DlteC do Brasil chamado: “Instalação do Linux e Gerenciamento de Pacotes“.

Introdução aos Pacotes no Linux

A distribuição Red Hat (e baseadas) trabalham com um conjunto de pacotes agrupados – com extensão .rpm. Veja seguir a estrutura básica de um pacote binário .rpm:

No campo Arquitetura, caso o pacote apresente a informação “noarch“, significa que ele é independente de plataforma (poderá instalado em qualquer hardware). Por outro lado, caso mostre “src“, significa que se trata de um pacote de código-fonte.

Quando estudamos sobre os pacotes do Debian, vimos que o sistema armazena metadados sobre eles. Para os pacotes .rpm, a lógica também é essa: seus metadados são armazenados no diretório rpm, presente em /var/lib.

A gestão de pacotes .rpm pode ser realizada através de duas ferramentas: RPM (Red Hat Package Manager) e YUM (Yellow Dog Updater Modified).

Comando rpm

O gerenciador de pacotes rpm(man rpm) opera apenas sobre pacotes com extensão .rpm. Caso necessite de bibliotecas e dependências, estes deverão ser instalados manualmente.

Principais opções:

• -h, –hash: Exibe um indicador de progresso para a instalação do pacote.
• -v: Modo detalhado.
• -i, –install: Instala um pacote .rpm.
• -U, –update: Instala ou atualiza um pacote .rpm.
• -q, –query: Lista informações sobre um pacote.
• Opções que acompanham a opção -q:
• -a, –all: Lista todos os pacotes instalados no sistema.
• -i, –info: Exibe informações sobre um pacote instalado.
• -d, –docfiles: Exibe documentos e páginas de manuais de um pacote instalado.
• -f, –file: Determina qual pacote instalou o arquivo.
• -l, –list: Lista os arquivos instalados por determinado pacote.
• -R, –requires: Exibe as dependências do pacote.
• –whatrequires: Exibe quais são os programas dependentes do pacote.
• -p: Realiza consultas diretamente no arquivo .rpm.
• -e, –erase: Remove o pacote.

Acompanhe alguns exemplos a seguir:

# Exibe todos os pacotes instalados no sistema

dltec@cap2:~# rpm –qa

# Verifica se o pacote BitTorrent já está instalado no sistema

dltec@cap2:~# rpm -q BitTorrent

# Exibe informações sobre o pacote .rpm

dltec@cap2:~# rpm -qip BitTorrent-5.2.2-1-Python2.4.noarch.rpm

# Exibe as dependências do pacote BitTorrent antes de instala-lo

dltec@cap2:~# rpm -qpR BitTorrent-5.2.2-1-Python2.4.noarch.rpm

# Exibe as dependências do pacote gedit (já instalado no sistema)

dltec@cap2:~# rpm -qR gedit

# Exibe todos os arquivos instalados pelo pacote BitTorrent

dltec@cap2:~# rpm -ql BitTorrent

# Exibe informações sobre um pacote instalado

dltec@cap2:~# rpm -qi BitTorrent

# Exibe as documentações instaladas por um pacote já presente no sistema

dltec@cap2:~# rpm –qdf /usr/bin/vmstat

# Lista os programas que dependem do gedit

dltec@cap2:~# rpm -q –whatrequires gedit

# Instala o pacote sem as suas dependências (Mas os pacotes dependentes já #deverão estar instalados no sistema, caso contrário o programa poderá não funcionar adequadamente)

dltec@cap2:~# rpm -ivh –nodeps BitTorrent-5.2.2-1-Python2.4.noarch.rpm

# Instala o pacote libpcap (com suas dependências)

dltec@cap2:~# rpm -ivh libpcap-0.7.2-37.i586.rpm

# Atualiza o pacote (mantendo um backup do pacote mais antigo)

dltec@cap2:~# rpm -Uvh nx-3.5.0-2.el6.centos.i686.rpm

# Remove o pacote gedit

dltec@cap2:~# rpm -e gedit

# Lista qual pacote instalou o binário /usr/bin/gedit

dltec@cap2:~# rpm -qf /usr/bin/gedit

Comando yum

O gerenciador de pacotes yum (man yum), cujo arquivo de configuração é o yum.conf (localizado em /etc), é outra ferramenta utilizada para gerenciar pacotes rpm – uma espécie de equivalente do apt-get do Debian. Dessa forma, além de fazer o download dos pacotes a partir dos repositórios configurados, antes de instalá-los, são realizadas verificações relacionadas a eventuais dependências dos pacotes e, se for o caso, essas também são baixadas e instaladas.

Arquivos de configuração do YUM

O YUM é configurado através do arquivo /etc/yum.conf. Observe o seu conteúdo parcial:

dltec@cap2:~# cat /etc/yum.conf

[main]

cachedir=/var/cache/yum/$basearch/$releasever

keepcache=0

debuglevel=2

logfile=/var/log/yum.log

exactarch=1

obsoletes=1

gpgcheck=1

plugins=1

bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum

distroverpkg=centos-release

Veja que, dentre as diretivas, podemos destacar o cachedir (representando o diretório de cache do yum – onde são realizados os downloads dos pacotes), debuglevel (nível de depuração do yum) e logfile (arquivo onde são armazenados os logs do yum).

No diretório /etc/yum.repos.d são encontrados arquivos .repo que contém informações sobre quais são os repositórios utilizados pelo yum para download e instalação dos pacotes. Por exemplo, observe a estrutura inicial do arquivo CentOS-Base.repo:

dltec@cap2:~# cat /etc/yum.repos.d/CentOS-Base.repo

[base]

name=CentOS-$releasever – Base

mirrorlist=http://mirrorlist.centos.org/?release=$release=$releasever&arch=$basearch&repo=os

#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/gpgcheck=1

Gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

Para propósitos de exame, vamos comentar sobre as principais partes desta estrutura.

A identificação do repositório é indicada entre colchetes (neste caso, base).

Em seguida, encontramos name, representando a descrição do campo anterior.

Já a instrução mirrorlist representa o endereço do repositório – ou seja, a partir de onde sera efetuado o download dos pacotes (pode ser http, ftp ou file).

Comandos administrativos do YUM

# Lista informações do pacote gedit

dltec@cap2:~# yum info gedit

# Exibe qual pacote instalou o comando ou determinado arquivo de configuração

dltec@cap2:~# yum provides gedit

dltec@cap2:~# yum provides /usr/bin/gedit

Ou

dltec@cap2:~# yum whatprovides gedit

dltec@cap2:~# yum whatprovides/usr/bin/gedit

# Lista os repositórios dos pacotes instalados na máquina

dltec@cap2:~# yum list installed

# Lista os repositórios dos pacotes disponíveis para a instalação (mas ainda não #instalados)

dltec@cap2:~# yum list available

# Lista todos os pacotes disponíveis e instalados

dltec@cap2:~# yum list all

# Exibe quais são os repositórios do yum

dltec@cap2:~# yum repolist

# Busca o termo gedit no cache do yum

dltec@cap2:~# yum search gedit

# Instala o pacote gedit

dltec@cap2:~# yum install gedit

Todas as vezes em que arquivos forem instalados pelo yum, é gerada uma cópia para o seu diretório de cache. Sendo assim, é uma boa prática limpar esses arquivos:

dltec@cap2:~# yum clean all

# Remove o pacote gedit

dltec@cap2:~# yum remove gedit

ou

dltec@cap2:~# yum erase gedit

# Verifica quais são os pacotes que possuem atualizações disponibilizadas

dltec@cap2:~# yum check-update

# Atualiza o pacote gedit

dltec@cap2:~# yum update gedit

# Atualiza todos os pacotes instalados no sistema

dltec@cap2:~# yum update

# Além de atualizar todos os pacotes instalados, o yum também remove os pacotes

# marcados como obsoletos.

# Normalmente, a opção upgrade é utilizada para atualizar a versão atual da

# distribuição.

dltec@cap2:~# yum upgrade

A opção –obsoletes  também poderá ser utilizada com o update para o mesmo propósito

# Lista os pacotes que são necessários para o funcionamento pleno do gedit

dltec@cap2:~# yum deplist gedit

Utilizando o yumdownloader

O yumdownloader é um programa que permite baixar pacotes RPM vindos de repositórios do yum.

As questões de dependências também são resolvidas ao utilizá-lo. Agora, atenção: o comando não irá instalar o pacote – e sim, apenas realizar o seu download.

Como trata-se de um comando disponibilizado pelo pacote yum-utils, será necessário instá-lo primeiramente.

# Instala o yumdownloader

dltec@cap2:~# yum install yum-utils -y

# Utiliza o yumdownloader

dltec@cap2:~# mkdir /opt/downloaded_rpms

dltec@cap2:~# yumdownloadersamba httpd –destdir /opt/downloaded_rpms –resolve

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

* base: mirror.ventraip.net.au

 * extras: mirror.optus.net

* updates: mirror.optus.net

unbound-1.4.20-26.el7.x86_64.rpm

Comando rpm2cpio

O comando cpio é responsável por realizar backups de arquivos, de forma semelhante ao comando tar. Porém, em conjunto com o comando rpm2cpio, responsável por converter um arquivo .rpm para o formato cpio, torna-se possível operar com os arquivos dentro de um pacote .rpm.

# Determina os arquivos que encontram-se em um pacote .rpm

dltec@cap2:~# rpm2cpio nomedopacote.rpm | cpio -t

# Extrai os arquivos dentro do pacote .rpm para o diretório corrente

dltec@cap2:~# rpm2cpio nomedopacote.rpm | cpio -id

Por padrão, o comando envia a sua saída para a saída-padrão (STDOUT).

Com isso finalizamos o artigo sobre o RPM e YUM e se você ainda tiver alguma dúvida, sugestão ou até mesmo um elogio utilize a parte inferior do artigo, onde temos a área de perguntas para deixar sua mensagem!

Obrigado pela leitura e até uma próxima!

Confiram o artigo original publicado pela DlteC do Brasil: LPIC-1: Gerenciando Pacotes do Linux com RPM e YUM

Nesse artigo vamos falar sobre um assunto que se você é profissional (iniciante ou não) da área de Infraestrutura de TI já ouviu falar pelo menos uma vez na sua vida que é VLAN ou “Virtual Local Area Network” ou, em português, Redes Locais Virtuais.

Para falarmos de VLAN você precisa saber que trata-se de um recurso de camada-2 que os switches ethernet podem utilizar para melhorar as segmentação e segurança da Rede Local.

Antes de continuar deixa só eu te avisar que esse artigo foi escrito com base no curso do Portal da DlteC do Brasil chamado: “Redes Completo“, ok?

Introdução ao que é VLAN ou Redes Locais Virtuais

Os switches fazem a divisão ou segmentação dos domínios de colisão, pois cada porta do switch é um domínio de colisão.

Além disso, os switches po padrão (switches L2) não dividem domínios de broadcast, pois são os roteadores ou switches L3 que tem essa capacidade.

Mas vamos imaginar uma rede de grande porte, por exemplo, uma LAN com 1000 computadores ligados a uma rede de switches de 48 portas.

Se dividirmos 1000 por 48 vamos chegar à conclusão que precisaremos de mais de 21 switches, pois ainda temos que pensar em conectar uns aos outros.

Mas será que a performance dessa rede com 1000 computadores trocando informações na mesma sub-rede será razoável?

Em uma rede baseada em IPv4 temos muitos pacotes de broadcast sendo enviados devido ao ARP e muitos dos protocolos utilizarem o broadcast, por exemplo o DHCP, onde o cliente envia a solicitação em broadcast.

Portanto, o ideal seria dividirmos essa rede em vários domínios de broadcast, assim poderíamos ter os computadores divididos por setor, andar, função dos usuários ou da maneira que for melhor para sua administração.

Se utilizarmos roteadores para fazer essa divisão precisaremos de uma interface de LAN para cada subrede a ser criada, o que faria com que o projeto ficasse com um custo muito elevado, pois o custo por porta de um roteador é muito mais elevado quando comparamos com um switch.

Veja a figura seguinte onde queremos ter 3 domínios de broadcast, ou seja, dividir a LAN em três subredes, uma por andar.

Para isso precisaríamos de um roteador com três interfaces, uma para cada sub-rede (uma sub-rede é o mesmo que um domínio de broadcast).

É aí que entram em cena as VLANs ou “LANs Virtuais” que permitem você alocar portas em um domínio de broadcast e segregar a comunicação entre essas “LANs Virtuais”.

O recurso de VLAN é uma facilidade que a maioria dos switches layer 2 e 3 possuem Veja a mesma topologia agora feita com switches que suportam VLAN.

Note na figura anterior que além de segregar os domínios de broadcast de uma maneira mais simples, o uso de VLANs permite que o administrador de redes estenda as VLANs entre os switches, possibilitando uma alocação flexível das portas.

Conectando VLANs entre Switches – Trunks

Para que seja possível a interligação dos switches entre eles ou com outros dispositivos existe o protocolo chamado 802.1Q.

Esse protocolo permite o entroncamento entre os diversos switches e o compartilhamento das informações de VLAN entre os switches ou entre um switch e um roteador ou servidor com placa de rede que tenha suporte ao 802.1Q.

Esses links que interligam os switches com o 802.1Q são chamados de “trunks” ou troncos e formam o backbone da rede (espinha dorsal) servindo como links de infraestrutura.

Nós vamos estudar posteriormente que os trunks ou troncos com o protocolo 802.1Q conseguem trafegar informações de todas as VLANs por um único link “marcando” os quadros com um identificador (VLAN ID). Essa marcação é chamada de “tag” e o processo de “frame tagging”.

Portanto, um trunk não utiliza o quadro padrão ethernet, pois ele insere um “tag” com informações relativas à VLAN que o quadro pertence.

Além das vantagens de segregar a rede em diversos domínios de broadcast e melhorar a performance em termos de tráfego, as VLANs também ajudam a melhorar a segurança da rede, pois ela permite que você crie regras entre as diversas subredes, permitindo ou bloqueando acesso a determinados serviços ou IPs.

Criando uma VLAN e Alocando Portas

Anteriormente estudamos que uma VLAN possibilita dividirmos as portas dos switches layer 2 ou 3 em domínios de broadcast, mas na prática o que isso significa? Como isso é feito nos switches?

O processo de adição de VLANs e alocação das portas nas VLANs são bem semelhantes em todos os fabricantes.

Basicamente você precisa criar a VLAN, que nada mais é que definir os VLAN-IDs que você vai utilizar, e depois entrar via sistema de gerenciamento nas portas do switch e vinculá-las a um dos VLAN-IDs criados.

Veja o exemplo na figura seguinte, note que em todos os switches deveriam ser criadas as VLANs com IDs 1, 2 e 3.

No Switch 3 teríamos que entrar no sistema de gerenciamento e definir que a porta Fast 0/1 pertence à VLAN1, a porta Fast 0/2 pertence à VLAN2 e a Fast 0/3 pertence à VLAN3.

Agora a regra de encaminhamento de quadros de broadcast no switch muda com relação ao que estudamos no capítulo anterior, pois quando o computador que está na Fast 0/1 enviar um broadcast somente as portas alocadas na VLAN1 receberão esse quadro.

Além disso, o trunk também recebe uma cópia desse quadro para poder encaminhar aos demais switches interligados, pois a VLAN pode ser estendida pela rede de switches e esse quadro pode ter importância para um equipamento que está nos switches 1 ou 2.

Portanto, analisando a figura 1 chegamos à conclusão que os hosts “Micro B” e “Micro C”, que estão conectados aos switches 1 e 2 e pertencem à VLAN 1, também receberão esse quadro enviado pelo “Micro A” através dos links de trunk.

Lembre-se que nesse caso temos três domínios de broadcast e portanto precisamos de três subredes IP, uma para cada VLAN criada.

Os switches de layer 2 não conseguem encaminhar quadros entre as VLANs, por exemplo, suponha que o Micro A, que está na VLAN 1 tem o IP 192.168.1.10/24 e quer se comunicar com um micro que está na VLAN 3 com o IP 192.168.2.10/24.

Nesse caso os switches precisarão do apoio de um equipamento de camada 3, por exemplo, um roteador ou switch camada 3, para executar o roteamento entre essas duas VLANs.

Considerando nossa topologia, esse pacote chegaria até o roteador via os links de trunk e seria roteado entre as duas VLANs, ou seja, o roteador faria o encaminhamento entre as duas subredes IP.

Veja a figura abaixo. Esse processo é conhecido como “roteamento entre VLANs” e pode ser executado tanto por um roteador como por um switch de layer 3.

Com isso nós finalizamos o artigo e caso você tenha uma dúvida, crítica, sugestão ou até mesmo um elogio é só utilizar o campo de comentários descendo um pouco mais essa página!

Muito obrigado pela visita, pela leitura e até uma próxima!

Confiram o artigo original publicado pela DlteC do Brasil: O que é VLAN?

Nesse artigo vamos estudar os principais comandos utilizados para verificar e configurar Redes Linux, os quais também podem ser cobrados na certificação LPIC-1.

Só para você saber, esse artigo eu fiz com base no curso do Portal da DlteC do Brasil chamado: “Fundamentos de Redes para Linux“.

Agora chega de conversa e vamos começar a estudar pelo comando ifconfig, o qual creio que se você está estudando ou já utilizou Redes Linux já deva ter utilizado em algum momento da sua vida, correto?

Comando Ifconfig

O comando ifconfig, quando utilizado sem quaisquer opções, exibe as interfaces de rede instaladas no sistema ATIVAS , bem como as configurações (IPs, máscara, etc) atribuídas a cada uma delas:

root@curso9:~# ifconfig

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 192.168.0.108netmask 255.255.255.0broadcast 192.168.0.255

inet6 fe80::8a18:d1bc:c455:3b3dprefixlen 64  scopeid 0x20<link>

ether 08:00:27:5f:3c:cbtxqueuelen 1000  (Ethernet)

        RX packets 202  bytes 39297 (39.2 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 132  bytes 16993 (16.9 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 192.168.0.106  netmask 255.255.255.0  broadcast 192.168.0.255

        inet6 fe80::1084:cbad:7948:5702  prefixlen 64  scopeid 0x20<link>

        ether 08:00:27:86:27:b7  txqueuelen 1000  (Ethernet)

        RX packets 217  bytes 41520 (41.5 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 131  bytes 12717 (12.7 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>mtu 65536

inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Loopback Local)

        RX packets 97  bytes 7804 (7.8 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 97  bytes 7804 (7.8 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Observe na saída anterior que, nesse momento, existem duas interfaces de rede disponíveis: enp0s3 e enp0s8 (a interface de loopback – utilizada para testes locais (127.0.0.1) –  é identificada como lo).

O endereço IP de cada interface é identificado como inet (seja “puro” – referente ao IPv4 – ou inet6, para o IPv6).

Além disso, note a presença de outras informações úteis como o endereço de broadcast (broadcast), a máscara de rede (netmask) e o endereço MAC (ether) – este último, identifica de forma inequívoca uma determinada placa de rede.

Note ainda a presença das palavras UP e RUNNING em cada uma das interfaces – indicando que a placa encontra-se em pleno funcionamento.

Caso o comando seja rodado com a opção -a, mesmo aquelas interfaces inativas instaladas na máquina serão exibidas.

Guarde isso! O comando ifconfig também consegue exibir informações específicas sobre uma determinada interface, bastando ser informada junto ao comando:

root@curso9:~# ifconfig enp0s3

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 192.168.0.108  netmask 255.255.255.0  broadcast 192.168.0.255

        inet6 fe80::8a18:d1bc:c455:3b3d  prefixlen 64  scopeid 0x20<link>

        ether 08:00:27:5f:3c:cb  txqueuelen 1000  (Ethernet)

        RX packets 202  bytes 39297 (39.2 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 132  bytes 16993 (16.9 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Caso seja necessário deixar uma determinada interface de rede inativa, ou seja, para “derrubar” uma placa de rede, o comando ifconfig também poderá ser utilizado – bastando, para isso, informar a instrução down ao comando:

root@curso9:~# ifconfig enp0s3 down

root@curso9:~# ifconfig enp0s3

enp0s3: flags=4098<BROADCAST,MULTICAST>mtu 1500

        ether 08:00:27:5f:3c:cb  txqueuelen 1000  (Ethernet)

        RX packets 577  bytes 499765 (499.7 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 944  bytes 87052 (87.0 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Note que, agora, a interface enp0s3 já apresenta o “UP”, indicando que a interface encontra-se desativada.

Nesse momento, podemos inclusive definir um IP específico à interface enp0s3, informando a seguinte instrução:

root@curso9:~# ifconfig enp0s3 192.168.0.98 up

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 192.168.0.98  netmask 255.255.255.0  broadcast 192.168.0.255

        ether 08:00:27:5f:3c:cb  txqueuelen 1000  (Ethernet)

        RX packets 719  bytes 524024 (524.0 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 959  bytes 88523 (88.5 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Note que, por padrão, o sistema “pega” o endereço informado e já configura a máscara de rede (a padrão, baseada no endereço informado) e o endereço de broadcast.

Caso não seja a intenção do administrador que isso seja aplicado, basta “derrubar” novamente a interface e informar o seguinte comando:

root@curso9:~# ifconfig enp0s3 down

root@curso9:~# ifconfig enp0s3 192.168.0.98 netmask 255.255.255.192 up

root@curso9:~# ifconfig enp0s3

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 192.168.0.110  netmask 255.255.255.192  broadcast 192.168.0.127

        ether 08:00:27:5f:3c:cb  txqueuelen 1000  (Ethernet)

        RX packets 819  bytes 536699 (536.6 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 985  bytes 90811 (90.8 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Perceba agora que o sistema já calculou automaticamente o endereço de broadcast correto utilizado pela subrede 192.168.0.64/26, da qual o endereço 192.168.0.127 faz parte.

Note que a outra interface disponível (enp0s8) também poderá possuir o seu próprio endereço IP, independente daquele configurado na interface enp0s3:

root@curso9:~# ifconfig enp0s8 down

root@curso9:~# ifconfig enp0s8 172.16.23.57 up

root@curso9:~# ifconfig enp0s8

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>mtu 1500

inet 172.16.23.57  netmask 255.255.0.0  broadcast 172.16.255.255

        ether 08:00:27:86:27:b7  txqueuelen 1000  (Ethernet)

        RX packets 1254  bytes 592075 (592.0 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 218  bytes 22837 (22.8 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Comando Route

Agora, entenderemos mais o seu funcionamento do comando route.

Esse comando é responsável por exibir e criar configurações relacionadas às rotas configuradas sistema.

Observe o seu comportamento padrão (utilizado junto à opção -n, para que os endereços IP não sejam resolvidos em nomes):

root@curso9:~# route -n

Tabela de Roteamento IP do Kernel

Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface

172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 enp0s8

192.168.0.64    0.0.0.0         255.255.255.192 U     0      0        0 enp0s3

Precisamos aprender a como interpretar essas informações.

Veja que, quando um pacote for destinado à rede 192.168.0.64, este será enviado à interface enp0s3; da mesma forma, quando um pacote for destinado à rede 172.16.0.0, este será enviado à interface enp0s8.

Uma configuração muito comum a ser realizado com o comando route é a definição da rota padrão – ou seja, quando uma determinada rede não for conhecida por uma dada interface, será essa rota padrão que ela enviará os pacotes em questão (ou através da criação de uma rota específca àquela rede). 

Não esqueça: a rota padrão é utilizada nos casos de uma interface não “conhecer” a rede do host do destino – sendo assim, ela precisará enviar o pacote para alguém.

Quem será esse alguém? O default gateway (o endereço IP do roteador). Ou seja, todos os pacotes que a interface não souber como enviar diretamente ao destino, ela enviará então ao roteador.

Observe a seguir o processo de criação de uma rota padrão:

root@curso9:~# ifconfig enp0s3 down

root@curso9:~# ifconfig enp0s3 192.168.0.55 up

root@curso9:~# route add default gw 192.168.0.1 dev enp0s3

Como o endereço IP da interface enp0s3 é 192.168.0.110, a instrução dev enp0s3 é opcional – já que, quando não utilizada, o sistema já “entenderá” que o usuário deseja configurar a rota padrão à interface enp0s3 (pois se encontra na mesma faixa de endereços).

root@curso9:~# route -n

Tabela de Roteamento IP do Kernel

Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 enp0s3

172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 enp0s8

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3

Observe que agora a interface enp0s3 possui uma rota padrão (192.168.0.1), presente no campo Roteador.

Dessa forma, todo pacote cujo destino não faça parte da rede 172.16.0.0 (enp0s8) e nem da rede 192.168.0.0 será encaminhado ao default gateway, saindo pela interface enp0s3.

O processo de criação de uma rota específica também segue a mesma lógica – mas não a mesma sintaxe:

root@curso9:~# route add -net 10.10.10.0/24 gw 192.168.0.25

root@curso9:~# route -n

Tabela de Roteamento IP do Kernel

Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 enp0s3

10.10.10.0      192.168.0.25    255.255.255.0   UG    0      0        0 enp0s3

172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 enp0s8

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3

Dessa forma, toda vez que for necessário enviar um pacote à rede 10.10.0.0, este será enviado à máquina 192.168.0.25 através da interface enp0s3 (e esta máquina se preocupará enviar esse pacote até o endereço IP de destino).

Comando Ip

As funcionalidades oferecidas pelos comandos ifconfig e route são também obtidas através do comando ip.

Vamos visualizar o seu comportamento através de exemplos:

root@curso9:~# ip link show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN mode DEFAULT group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP mode DEFAULT group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP mode DEFAULT group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

root@curso9:~# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

inet 192.168.0.55/24 brd 192.168.0.255 scope global enp0s3

valid_lft forever preferred_lft forever

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

inet 172.16.23.57/16 brd 172.16.255.255 scope global enp0s8

valid_lft forever preferred_lft forever

root@curso9:~# ip route show

default via 192.168.0.1 dev enp0s3

10.10.10.0/24 via 192.168.0.25 dev enp0s3

172.16.0.0/16 dev enp0s8 proto kernel scope link src 172.16.23.57

192.168.0.0/24 dev enp0s3 proto kernel scope link src 192.168.0.55

# Desabilitando a interface enp0s3

root@curso9:~# ip addr flush dev enp0s3

root@curso9:~# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

inet 172.16.23.57/16 brd 172.16.255.255 scope global enp0s8

valid_lft forever preferred_lft forever

Note na saída acima que as informações sobre IP/Máscara/Broadcast não são exibidas para a interface enp0s3. Ela está UP, mas sem configurações de IP.

# Adicionando um IP através do comando ip

root@curso9:~# ip addr add 192.168.0.67/24 dev enp0s3

root@curso9:~# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

inet 192.168.0.67/24 scope global enp0s3

valid_lft forever preferred_lft forever

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

inet 172.16.23.57/16 brd 172.16.255.255 scope global enp0s8

valid_lft forever preferred_lft forever

Por padrão, o comando ip não configura qualquer endereço de broadcast. Por isso, é preciso especificar ao comando o endereço desejado:

root@curso9:~# ip addr flush dev enp0s3

root@curso9:~# ip addr add 192.168.0.67/24 brd + dev enp0s3

root@curso9:~# ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

inet 192.168.0.67/24 brd 192.168.0.255 scope global enp0s3

valid_lft forever preferred_lft forever

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

inet 172.16.23.57/16 brd 172.16.255.255 scope global enp0s8

valid_lft forever preferred_lft forever

O comando ip possui diversas outras possibilidades e modos de configuração. Por isso, é muito recomendado que você tenha acesso ao seu manual (man ip).

Caso seja necessário fazer com que uma determinada interface “pegue” um IP a partir de um servidor DHCP, podemos utilizar o comando dhclient:

root@curso9:~# ip addr flush dev enp0s3

root@curso9:~# dhclient enp0s3

root@curso9:~# ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP>mtu 65536 qdiscnoqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:5f:3c:cb brdff:ff:ff:ff:ff:ff

inet 192.168.0.108/24 brd 192.168.0.255 scope global enp0s3

valid_lft forever preferred_lft forever

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu 1500 qdiscfq_codel state UP group default qlen 1000

    link/ether 08:00:27:86:27:b7 brdff:ff:ff:ff:ff:ff

inet 172.16.23.57/16 brd 172.16.255.255 scope global enp0s8

valid_lft forever preferred_lft forever

É super importante mencionarmos uma coisa: todas essas configurações serão perdidas quando a máquina for reiniciada (tudo se encontra em memória).

Para que tais procedimentos se tornem permanentes, é necessário envolver arquivos de configuração.

Sendo assim, tais comandos se tornam muito úteis para realizar testes diversos (derrubar interfaces, estabelecer rotas de testes, etc.).

Com isso terminamos mais um artigo e como sempre você pode dar sua sugestão, crítica ou até mesmo deixar um elogio no campo de comentários abaixo!

Obrigado e até a próxima!

Confiram o artigo original publicado pela DlteC do Brasil: LPIC-1: Verificar e Configurar Redes Linux

Olá amigos, nesse artigo vou explicar um pouco da camada física do Modelo OSI.

A camada física do modelo OSI, também chamada de layer 1 ou physical layer, trata da transmissão transparente de sequências de bits pelo meio físico, sendo a parte final da comunicação, ou seja, onde a transmissão pelo meio de comunicação realmente acontece.

Na camada física do modelo OSI estão definidos os padrões mecânicos (conectores, painéis de conexão, cabos, etc…), funcionais (DCE ou DTE, por exemplo), elétricos (voltagens, codificação de linha, etc…) e procedimentos para acesso a esse meio físico.

Nessa camada também temos as especificações dos meios de transmissão, como por exemplo: transmissão via satélite, cabo coaxial, radiotransmissão (rádios digitais ponto a ponto, Wifi, espalhamento espectral, etc.), par metálico (UTP e STP), fibra óptica (monomodo ou multimodo), etc…

Dispositivos da Camada Física

Os dispositivos que estão situados na camada física do modelo OSI são os componentes do cabeamento estruturado, tais como conectores, transceiver, patch panels, cabos e também os HUBs e repetidores. Veja a figura a seguir.

Lembre que os Hubs e Repetidores são dispositivos simples que encaminham os bits recebidos para todas as portas simultaneamente.

São equipamentos que não tem “inteligência”, isto é, eles não têm a capacidade de ler endereços ou tomar decisões baseadas em quaisquer tipos de informações, eles simplesmente atuam como um “curto-circuito” ou um “barramento” encaminhando a informação recebida em uma porta para todas as outras.

Essa transmissão realizada pelos Hubs e Repetidores é realizada com apenas um par metálico, sendo realizada tanto a transmissão quanto a recepção dos dados pelo mesmo par.

Como os bits são sinais elétricos (ondas eletromagnéticas), por exemplo -5 Volts seria o bit zero e +5 Volts o bit 1, se houver a transmissão de dois deles ao mesmo tempo ocorrerá um problema chamado “colisão”.

Uma colisão é no “popular” uma “batida” e é isso mesmo, as ondas colidem ou batem uma na outra e o resultado dessa colisão vai ser uma coisa que nem é um bit zero nem um bit 1, ou seja, um sinal que não pode ser interpretado e deve ser descartado.

Se o computador detecta uma colisão, toda transmissão é interrompida e é emitido um sinal (“jam” de 48 bits) para anunciar que ocorreu uma colisão, o qual tem o objetivo de evitar colisões sucessivas.

Quando isso ocorre os computadores devem parar de transmitir e tomar uma ação, a qual é assumir um tempo aleatório randômico e quem acabar o contador antes inicia a transmitir novamente.

Tecnicamente essa ação é chamada “algoritmo de backoff”.

CSMA/CD

Todo esse procedimento acima está programado nas placas de rede dos computadores que estão conectados aos hubs e é chamado de protocolo CSMA/CD (Carrier Sense Multiple Access with Collision Detection). A tradução da sigla em português diz bem o que é esse protocolo:

• CS (Carrier Sense): Capacidade de identificar se está ocorrendo transmissão, ou seja, o primeiro passo na transmissão de dados em uma rede Ethernet com hub ou repetidor é verificar se o cabo está livre.
• MA (Multiple Access): Capacidade de múltiplos nós concorrerem igualmente pelo meio de transmissão, ou seja, o protocolo CSMA/CD não gera nenhum tipo de prioridade (daí o nome de Multiple Access, acesso múltiplo). Como o CSMA/CD não gera prioridade pode ocorrer de duas placas tentarem transmitir dados ao mesmo tempo e quando isso ocorre há uma colisão, resultando em que nenhuma das placas consegue transmitir dados.
• CD (Collision Detection): Capacidade de detectar a colisão quando ela ocorrer, ou seja, reconhecer quando um sinal diferente do que foi projetado para os bits zero e um e acionar o algoritmo de backoff.

Devido a transmissão e recepção não poder ocorrer simultaneamente, pois temos apenas um meio físico, ela é chamada de “half-duplex”, o half em português quer dizer metade, o que é a pura realidade do que ocorre na prática.

Se você tem que transmitir e somente em outro período de tempo o receptor responde, ou seja, ocorre metade do processo de cada vez, por isso o nome “half-duplex”.

Domínios de Colisão

Outro termo utilizado quando temos redes com Hub e repetidores é o “Domínio de Colisão”.

Esse termo nada mais é que todas as portas que estão ligadas por Hub ou repetidores que podem ter seus bits colididos, por exemplo, se temos um hub de 24 portas todos os micros que estão conectados nessas 24 portas estão em um mesmo domínio de colisão.

Agora, se conectarmos uma das portas desse hub em outro hub de 24 portas, teremos então um domínio de colisão de 48 portas com 46 hosts que podem ter suas informações colidindo entre si (46 porque gastamos 2 portas, uma de cada hub, para interligá-los), e assim por diante.

Portanto quanto maior esse domínio de colisão mais problemas sua rede vai ter, pois temos mais hosts com probabilidade de transmitir simultaneamente e ter seus bits colidindo!

Para fechar o assunto, temos então que os hubs são dispositivos para conectarmos os hosts em uma LAN utilizando apenas um par metálico, por isso eles utilizam a transmissão “half-duplex” e estão sujeitos a colisões, portanto as placas de rede precisam ativar o protocolo CSMA/CD.

Aqui temos a explicação do porque os hubs apresentam uma performance baixa em redes grandes, imagine 50 micros ligados a vários hubs cascateados (ligados uns nos outros), todos tentando acessar a rede, o número de colisões será grande (pois todos estarão em um único domínio de colisão) e a rede ficará naturalmente mais lenta.

Você verá na camada de enlace que os equipamentos de camada 2 conseguem “segmentar” os domínios de colisão e melhorar a performance da rede.

Outro ponto negativo dos hubs é a questão de segurança, pois como a informação trocada entre dois hosts é copiada para todos os outros, se instalarmos em um micro dessa rede um programa que abra essa comunicação, chamado sniffer, poderemos capturar os pacotes trocados e “espiar” essa comunicação.

Assim os atacantes (hackers) conseguiriam descobrir usuários e senhas de rede que sejam trocadas em modo texto, ou seja, sem nenhum mecanismo de proteção como a criptografia.

Com isso finalizamos mais um artigo e talvez você queira saber mais um pouco sobre domínios de colisão, por isso recomendamos também o artigo abaixo:

Como Descobrir a Quantidade de Domínios de Colisão em uma Rede IP

Não esqueça de usar o campo de comentários para deixar sua dúvida, sugestão ou até mesmo seu elogio!

Até um próximo artigo!

Confiram o artigo original publicado pela DlteC do Brasil: Camada Física do Modelo OSI

Olá amigos! Esse é mais um artigo onde vamos abordar um conteúdo útil para a certificação Linux LPIC-1! Mais especificamente da prova LPI-102, combinado?

Um administrador de sistemas Linux possui à disposição uma série de ferramentas que podem (e devem) ser utilizadas para verificar quaisquer portas abertas por serviços que estejam em execução em um dado momento na máquina local – além daquelas que encontram-se localizadas na rede.

Você já deve saber que o comando netstat consegue exibir várias informações importantes relacionadas à rede, como as portas abertas pelos serviços em execução na máquina, a tabela de roteamento configurada, estatísticas relacionadas às interfaces de rede, etc.

Deve saber também que sua documentação é bastante densa mas, para o exame, basta que você se concentre basicamente nas opções -naltp:

root@ubuntu18-04:~#  netstat -naltp

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address  Foreign Address   State       PID/Program name   

tcp0      0 127.0.0.53:53   0.0.0.0:*       LISTEN  299/systemd-resolve

tcp    0      0     127.0.0.1:631    0.0.0.0:*       LISTEN      638/cupsd

tcp6   0      0     ::1:631          :::*            LISTEN      638/cupsd

Note que, através da opção -l, filtramos para que sejam exibidos apenas sockets que estejam em estado LISTEN – ou seja, aguardando por conexões através das portas lógicas – utilizando tcp (opção -t).

É importante ressaltar que esses sockers somente são exibidos caso a opção -a também seja utilizada.

A opção -p é utilizada para exibir o PID do processo (além do nome) relacionado. Lembre-se que a opção -n foi utilizada para que os endereços IP fossem exibidos (e não os nomes associados).

Dentre as conexões abertas no sistema, perceba a existência daquela que encontra-se ouvindo a porta local 631 (serviço de impressão de Internet), utilizando conexão tcp, através do localhost (endereço 127.0.0.1), que poderá receber solicitações de conexão a partir de qualquer fonte (0.0.0.0:*). Trata-se do daemoncupsd!

Se instalarmos o MTA postfix, por exemplo (apt-getinstallpostfix) e rodarmos novamente o comando netstat, veremos que o MTAjá abre a porta 25:

root@ubuntu18-04:~#  netstat -naltp

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   

tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      299/systemd-resolve

tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      638/cupsd

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      8229/master        

tcp6       0      0 ::1:631                 :::*                    LISTEN      638/cupsd

tcp6       0      0 :::25                   :::*                    LISTEN      8229/master

Pesquisando pelo processo 8229, verificamos que se trata do postfix:

root@ubuntu18-04:~#  ps aux | grep 8229

root      8229  0.0  0.2  67372  4196 ?        Ss   18:56   0:00 /usr/lib/postfix/sbin/master -w

Caso o administrador preferisse que fossem listadas as conexões udp ativas, bastaria substituir a opção -t por -u:

root@ubuntu18-04:~#  netstat -nalup

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   

udp        0      0 0.0.0.0:38567           0.0.0.0:*                           579/avahi-daemon: r

udp        0      0 127.0.0.53:53           0.0.0.0:*                           310/systemd-resolve

udp        0      0 0.0.0.0:5353            0.0.0.0:*                           579/avahi-daemon: r

udp        0      0 0.0.0.0:631             0.0.0.0:*                           678/cups-browsed   

udp6       0      0 :::55182                :::*                                579/avahi-daemon: r

udp6       0      0 :::5353                 :::*                                579/avahi-daemon: r

Por fim, se desejarmos visualizar a tabela de roteamento, utilizamos a opção -r:

root@ubuntu18-04:~#  netstat -nr

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irttIface

0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s3

169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s3

192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s3

Caso a opção -n não seja especificada, nomes são mostrados no lugar dos endereços IP:

root@ubuntu18-04:~#  netstat -r

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irttIface

default         roteador        0.0.0.0         UG        0 0          0 enp0s3

link-local      0.0.0.0         255.255.0.0     U         0 0          0 enp0s3

192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s3

Já o comando lsof é responsável por listar os arquivos abertos – e, tome nota: no Linux, uma conexão, uma biblioteca em uso, etc., são todos exemplos de arquivos abertos! Observe uma breve saída do comando:

root@ubuntu18-04:~#  lsof -u pedro

COMMAND    PID  USER   FD    TYPE   DEVICE SIZE/OFF     NODE NAME

systemd   1623 dltec  cwd    DIR     8,1     4096          2 /

systemd   1623 dltec  rtd    DIR     8,1     4096          2 /

systemd   1623 dltec  txt   REG   8,1  1595792    4587610 /lib/systemd/systemd

systemd   1623 dltec  mem   REG  8,1  1700792    4592571 /lib/x86_64-linux-gnu/libm-2.27.so

continua…

Se, por exemplo, o usuário dltec estiver editando um arquivo e, no mesmo momento, o administrador lançar o comando lsof, este arquivo será exibido em sua saída:

dltec@ubuntu18-04:~$vi Arquivos/Documentos/Listadecompras.txt

root@ubuntu18-04:~#  lsof -u dltec

vi        2468 dltec    3u      REG                8,1    12288    4721154 /home/dltec/Documentos/.Listadecompras.txt.swp

bash      2472 dltec  cwd       DIR                8,1     4096    4721450 /home/dltec

bash      2472 dltec  rtd       DIR                8,1     4096          2 /

bash      2472 dltec  txt       REG                8,1  1113504     786439 /bin/bash

bash      2472 dltec  mem       REG                8,1    47568    4592598 /lib/x86_64-linux-gnu/libnss_files-2.27.so

bash      2472 dltec  mem       REG                8,1    97176    4592592 /lib/x86_64-linux-gnu/libnsl-2.27.so

bash      2472 dltec  mem       REG                8,1    47576    4592609 /lib/x86_64-linux

continua…

Para que o comando exiba os arquivos abertos relacionados a conexões de rede, podemos utilizar a opção -i:

root@ubuntu18-04:~#  lsof -i

COMMAND    PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

systemd-r  310 systemd-resolve   12u  IPv4  15842      0t0  UDP 127.0.0.53:domain

systemd-r  310 systemd-resolve   13u  IPv4  15843      0t0  TCP 127.0.0.53:domain (LISTEN)

cupsd      566            root    6u  IPv6  19392      0t0  TCP ip6-localhost:ipp (LISTEN)

cupsd      566            root    7u  IPv4  19393      0t0  TCP localhost:ipp (LISTEN)

avahi-dae  579           avahi   12u  IPv4  19094      0t0  UDP *:mdns

avahi-dae  579           avahi   13u  IPv6  19095      0t0  UDP *:mdns

avahi-dae  579           avahi   14u  IPv4  19096      0t0  UDP *:38567

avahi-dae  579           avahi   15u  IPv6  19097      0t0  UDP *:55182

cups-brow  678            root    7u  IPv4  19549      0t0  UDP *:ipp

master    1309            root   13u  IPv4  21161      0t0  TCP *:smtp (LISTEN)

master    1309            root   14u  IPv6  21162      0t0  TCP *:smtp (LISTEN)

Também podemos especificar quais portas desejamos visualizar. Por exemplo, para visualizarmos as portas relacionadas ao smtp, podemos escolher uma das seguintes formas:

root@ubuntu18-04:~#  lsof -i :smtp

# Ou

root@ubuntu18-04:~#  lsof -i :25

O comando nmap é responsável por realizar um escaneamento geral das portas/serviços abertas(ativas) no sistema (ou alguma outra máquina da rede). Além disso, o comando também informa a quantidade de portas fechadas no sistema.

O comando nmap possui diversas opções. Para o exame, basta conhecer apenas as mais elementares.

Caso não esteja instalado no sistema, basta rodar o comando apt-getinstallnmap. Observe:

root@ubuntu18-04:~#  nmap localhost

Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-20 22:37 -03

Nmap scan report for localhost (127.0.0.1)

Host is up (0.000017s latency).

Not shown: 998 closed ports

PORT    STATE SERVICE

25/tcp  open  smtp

631/tcp open  ipp

Nmap done: 1 IP address (1 host up) scanned in 1.66 seconds

Da mesma forma, o nmap também consegue escanear algum outro hostpresente na rede. Por exemplo, vamos rodar no Ubuntu o comando nmap para que sejam escaneadas as portas abertas/fechadas no endereço IP 192.168.0.11:

root@ubuntu18-04:~#  nmap 192.168.0.11

Nmap scan report for 192.168.0.11

Host is up (-0.0068s latency).

Not shown: 997 filtered ports

PORT   STATE SERVICE

22/tcp open  ssh

23/tcp open  telnet

25/tcp open  smtp

MAC Address: 08:00:27:6F:47:A3 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 14.89 seconds

Podemos inclusive verificar detalhes sobre o sistema operacional instalado na máquina (além de outras informações úteis), através da opção -O:

root@ubuntu18-04:~#  nmap -O localhost

Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-21 09:12 -03

Nmap scan report for localhost (127.0.0.1)

Host is up (0.000019s latency).

Not shown: 998 closed ports

PORT    STATE SERVICE

25/tcp  open  smtp

631/tcp open  ipp

Device type: general purpose

Running: Linux 3.X

OS CPE: cpe:/o:linux:linux_kernel:3

OS details: Linux 3.7 – 3.10

Network Distance: 0 hops

OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 4.00 seconds

Agora, se o objetivo for escanear todas as máquinas presentes na rede 192.168.0.0, podemos lançar o seguinte comando:

root@ubuntu18-04:~#  nmap 192.168.0.1/24

Por fim, o comando fuser é responsável por informar qual processo encontra-se utilizando determinada porta. Por exemplo, se informarmos ao comando a porta 53/tcp, o comando retorna o processo correspondente:

# A opção -u é responsável por exibir o usuário dono do processo

root@ubuntu18-04:~#  fuser 53/tcp

53/tcp:     297

A partir desta informação, podemos rodar o comando ps para verificar o processo correspondente:

root@ubuntu18-04:~#  ps aux| grep 297

systemd+   297  0.0  0.2  70616  4788 ?        Ss   09:03   0:00 /lib/systemd/systemd-resolved

Com isso finalizamos mais um artigo com conteúdo para a certificação Linux LPIC-1 e espero você em um próximo artigo!

Não esqueça de usar o campo de comentário abaixo para deixar sua dúvida, sugestão ou até mesmo um elogio!

Confiram o artigo original publicado pela DlteC do Brasil: Linux LPIC-1 – Auditoria de Portas e Serviços

Saber como um Switch L2 encaminha informações na Rede é fundamental para qualquer profissional de tecnologia, seja você iniciante ou mais avançado, pois muitos problemas podem ser resolvidos se entendemos bem o encaminhamento de quadros através de uma LAN.

Os switches podem ser classificados de várias maneiras, porém quando tratamos de encaminhamento de informações temos que entender o que é e como funciona um Switch L2 ou layer-2 ou camada-2.

Ser um Switch L2 significa que ele atua na camada de Enlace do Modelo OSI e faz o encaminhamento utilizando os Frames ou Quadros de camada-2.

Basicamente aprendendo os endereços MAC de origem dos quadros que estão trafegando em suas portas e guardando em uma tabela de endereços MAC.

Funções de um Switch L2

As três funções básicas de um switch camada-2 ou switch L2 são:

1. Aprender os endereços MAC de origem dos hosts conectados às suas portas.
2. Encaminhar ou filtrar quadros com base no endereço MAC de destino do quadro recebido em uma porta.
3. Evitar loops de camada-2 com o protocolo Spanning-tree ou STP.

Tipos de Endereços MAC

Lembre-se que já citamos que os switches L2 podem ler e tomar decisões com base no endereço de camada-2 do quadro Ethernet, por isso precisamos conhecer os três tipos de endereços MAC utilizados em comunicações via IP:

• MAC de endereços de Unicast: é o MAC da placa de rede do computador, roteador ou de um switch, identifica o dispositivo ou interface em uma LAN de maneira exclusiva, ou seja, para comunicações de host a host (um para um).
• MAC de broadcast: todos os 48 bits setados em 1 “ff:ff:ff:ff:ff:ff” e é utilizado quando um host quer se comunicar com todos os dispositivos da LAN (um para todos).
• MAC de multicast: faixa de 01:00:5e:00:00:00 até 01:00:5e:7f:ff:ff, sempre iniciando em “01:00:5e”. É utilizado para comunicações em grupo (um para alguns hosts do mesmo grupo de multicast).

Ao receber um quadro, o switch aprende o MAC pelo campo de endereço de origem do quadro ethernet e encaminha com base no endereço de destino.

É importante lembrar-se de que o aprendizado depende do estado que o spanning-tree vai colocar a porta após sua convergência, uma porta bloqueada não aprende endereços MAC.

Encaminhamento de Quadros em Switches L2

Na fase de encaminhamento o switch pode tomar três ações básicas:

• Encaminhar para uma porta de destino específica.
• Encaminhar para todas as portas menos pela que recebeu o quadro, processo chamado de flooding ou inundação de quadros. Esse processo é realizado quando o switch não conhece o MAC de destino ou esse destino é um broadcast ou multicast. Outra situação de flooding é quando o número máximo de MACs é atingido, nesse caso o switch acaba se comportando como um HUB.
• Não encaminhar e filtrar esse quadro (bloquear o envio), normalmente em portas onde temos HUBs conectados e os dois hosts estão conectados ao mesmo HUB.

Os MACs de broadcast enviados pelos dispositivos conectados ao switch não são armazenados pela tabela de endereços MAC, por isso quando o switch recebe como endereço de destino um broadcast é sempre feito o flooding dos quadros para todas as portas menos para a porta que originou o quadro.

Por padrão os quadros de multicast também são tratados como os de broadcast, porém existem configurações mais avançadas para melhorar o desempenho de multicasts enviados através de switches, mas isso é um assunto mais avançado e fica para uma próxima postagem!

Os switches encaminham quadros em suas portas de acesso (access) com base no endereço MAC de destino seguindo as regras básicas de abaixo:

1. O quadro recebido tem MAC de destino de Unicast está na tabela de endereços MAC à o switch encaminha para a porta de destino conforme tabela de endereços MAC.
2. O quadro recebido tem MAC de destino de Unicast e não está na tabela de endereços MAC à o switch faz o flooding do quadro para todas as portas pertencentes à mesma VLAN, menos para a porta de origem. O quadro também é encaminha do para o link trunk que tem aquela VLAN permitida.
3. O quadro recebido tem como MAC de destino um endereço multicast ou broadcast à o switch faz o flooding do quadro para todas as portas da mesma VLAN, menos para a de origem. O quadro também é enviado para os trunks que tem a VLAN em questão permitida.
4. O MAC de destino é de Unicast e está listado na mesma porta que o MAC de origem à o switch filtra o quadro, pois essa porta está sendo compartilhada com outros dispositivos através de um HUB ou Switch através de uma porta de acesso, portanto o quadro com certeza não está em outro segmento de rede e não precisa ser encaminhado.

Com as regras acima podemos prever o comportamento normal do switch ao encaminhar quadros para determinado destino específico através de portas de acesso.

Agora vamos analisar o que acontece com os quadros em portas trunk.

Encaminhamento em Portas Trunks 802.1Q

Em portas configuradas como trunk, sejam 802.1Q ou ISL, quando um quadro é recebido ele vem marcado com a Tag da VLAN que ele pertence (VLAN-ID).

O switch que recebeu o quadro precisa retirar a Tag para encaminhar esse quadro recebido para a porta de acesso ou simplesmente encaminhar o quadro com a tag para outro trunk que pertence à mesma VLAN e tem o MAC de destino cadastrado.

Se o switch de destino também não conhece o MAC ele fará um flooding do quadro para todas as portas que estão na mesma VLAN e para os trunks que tem a VLAN em questão permitida, menos para o trunk que o recebeu até alcançar o host de destino.

Os trunks dos switches guardam na tabela de endereços MAC os endereços que foram utilizados remotamente em conversações entre hosts.

Esse comportamento permite a redução do envio de flooding e também permite estender as VLANs entre diferentes switches.

O processo de retransmissão do flooding pelos trunks citado anteriormente vai sendo repetido até o último switch que estiver em cascata, por isso não se recomenda ter redes com um diâmetro muito grande, ou seja, muitos switches em cascata conectados em série.

O uso da topologia em três camadas reduz esse efeito do diâmetro de rede.

Com isso chegamos ao fim de mais um artigo e esperamos que tenham sido úteis as informações que passamos nesse artigo!

Compartilhe o artigo com seus amigos e deixe seu comentário logo abaixo!

Confiram o artigo original publicado pela DlteC do Brasil: Aprenda como um Switch L2 Encaminha Informações na Rede

Você sabe o que é IPv6? Porque estamos ouvindo tanto falar desse termo? IPv6 quer dizer o protocolo IP versão 6, o qual será o substituto da versão atual chamada IPv4 ou protocolo IP versão 4.

Mas porque saber o que é IPv6 é tão importante?

Porque com o esgotamento dos endereços IP versão 4 ou IPv4, o uso do IPv6 na Internet está cada vez mais em alta e isso vai trazer consequências importantes nas Redes de todas as empresas em um futuro muito próximo ou até mesmo, para algumas delas, imediatamente.

Na realidade o IPv6 já vem sendo utilizado há algum tempo, porém sua implantação deve ser acelerada devido ao esgotamento dos endereços IPv4 no Brasil.

O Ipv6 já vem sendo habilitado nos sistemas operacionais a um bom tempo, por exemplo, desde o Windows 2008 Server, Windows 7, maioria das distribuições de Linux e Unix essa configuração já vem de fábrica.

Veja a figura abaixo da configuração de uma placa de rede no Windows 7, a qual é igual no Windows 10.

Principais Características do IPv6

A principal diferença entre as versões 4 e 6 do protocolo IP  é que o IPv4 possui 32 bits e o IPv6 128 bits, o que permite uma quantidade de endereços absurdamente maior.

O valor é de 2 elevado a 128, o que dá 340.282.366.920 seguido por mais 27 casas decimais, ou seja, 340 bilhões multiplicados por 10²⁷.

Esse número atende a demanda atual e previne, em um futuro distante, uma possível nova migração por falta de endereços IPv6.

O IPv6 não é mais representado por octetos em decimal como no IPv4, mas através de números em notação hexadecimal.

No total são 32 caracteres, organizados em oito quartetos e separados por dois pontos, por exemplo: 8888:9999:AAAA:BBBB:CCCC:DDDD:EEEE:FFFF.

No hexadecimal, cada caractere possui 4 bits (16 combinações), sendo assim, temos além dos números de 0 a 9 o hexa utiliza os caracteres A, B, C, D, E e F, os quais representam respectivamente os números 10, 11, 12, 13, 14 e 15.

Um exemplo de endereço IPV6, válido na internet, seria 2001:BCE4:5641:3412:341:45AE:FE32:65.

Para saber se no seu computador existe uma interface IPv6 habilitada abra o prompt de comando ou seu terminal, no caso do Linux ou MAC-OS, e digite “ping ::1”.

O endereço IPv6 “::1” é o endereço de loopback do IPv4 127.0.0.1, o qual faz o teste de ping para a própria interface local.

Com o comando ipconfig /all no windows ou ifconfig no Linux você pode também verificar se existe algum IPv6 configurado na sua placa de rede.

Lembre-se da notação que ensinei anteriormente nesse artigo, se você notar algo parecido é porque tem algum IPv6 sendo fornecido no seu computador.

Na Prática onde o IPv6 Pode Afetar Meu Dia a Dia?

Apesar de muitos artigos, autores e “postadores” na Internet estarem pregando o fim da existência do IPv4, a morte total e absoluta da versão antiga do protocolo IP e que agora TUDO SERÁ IPV6…

… NÃO É BEM ASSIM QUE A COISA VAI FUNCIONAR!

Em muitos países os blocos de IPv4 se esgotaram nos órgãos oficiais, mas muitos provedores ainda tem faixas de IPv4 disponíveis e estão as distribuindo para seus clientes.

Outro ponto é que muita infraestrutura baseada em IPv4 ainda não foi migrada para IPv6 e essa migração pode levar alguns anos, pois envolve normalmente um custo de troca ou atualização dos dispositivos de rede atualmente instalados.

Muitas redes antes de virarem IPv6 puras passarão por uma transição e normalmente serão “dual-stack”, ou seja, terão tanto IPv4 como IPv6 configurado nas interfaces dos dispositivos de redes, computadores e servidores.

O que eu Devo Fazer Então sobre o IPv6?

Indubitavelmente a melhor opção é aprender como funciona esse protocolo, estudando seus conceitos e montando laboratórios para o melhor entendimento do seu funcionamento.

Pois mudam os endereços e alguns serviços importantes como alocação dinâmica de IPs, firewalls e dispositivos de segurança devem estar adaptados para o IPv6, assim como os servidores DNS.

Outro ponto importante é que no IPv6 não vai haver o papel do NAT, o qual no IPv4 “esconde” os IPs internos dos computadores da rede.

No IPv6 TODO MUNDO está exposto na Internet e estará acessível remotamente, portanto os firewalls e demais dispositivos de segurança precisarão estar muito bem ajustados!

Como a DlteC pode Ajudar nos seus Estudos para Entender o que é o IPv6 e seu Funcionamento?

Em nosso portal de assinaturas Premium você pode encontrar diversos cursos que tratam desse assunto, desde a parte teórica como no curso chamado IPv6, até a parte prática para configuração em roteadores e switches Cisco.

Fazendo parte do nosso grupo Premium de assinantes você poderá ativar os cursos e aprender sobre o IPv6 e como configurá-lo de maneira segura em sua rede.

Espero que você tenha gostado do artigo sobre IPv6 e deixe suas dúvidas e elogios em nossa área de comentários.

Sugestões de novos temas também serão bem vindos!

Basta deixar seu recado em nossa área de comentários no final dessa página.

Confiram o artigo original publicado pela DlteC do Brasil: O que é IPv6 – A Nova Geração do Protocolo de Internet

Olá amigos, leitores, seguidores e alunos da DlteC! Nesse artigo você vai aprender por que os fabricantes recomendam trocar o número da VLAN Nativa ou VLAN 1 em seus switches.

O mais importante aqui é frisar a importância de você conhecer seus dispositivos de infraestrutura de rede.

Saber que as configurações de fábrica quase nunca são seguras! Leia com atenção e você vai entender.

Mas primeiro, se você não sabe o que é uma VLAN Nativa dá uma lida no artigo abaixo, aí depois volta para cá, combinado? Segue o link:

Por que raios existe VLAN Nativa nos Switches se os fabricantes recomendam não utilizar?

A VLAN Nativa, assumindo que você está utilizando o protocolo 801.1Q em seus trunks, é enviada sem marcação de quadros por padrão.

Vários fabricantes, inclusive a Cisco, utiliza o VLAN ID 1 (VLAN 1) para designar a VLAN Nativa.

Essa mesma VLAN acaba tendo também a função de VLAN de Gerenciamento nos switches L2.

Além de ser utilizada como Nativa e Gerenciamento, esse tipo de VLAN acaba sendo utilizada para trafegar protocolos como DTP, VTP, CDP, LLDP e BPDUs.

Mas saiba, utilizar a VLAN 1 como nativa e gerenciamento pode ser uma má ideia, principalmente se houver porta de acesso alocada nessa VLAN.

Saiba que por padrão um switch gerenciável que suporta VLANs traz suas portas na VLAN 1, pelo menos maioria deles.

Portanto se você tira um switch da caixa e coloca na sua rede como se fosse um Hub, sem configurar nada, você já está criando brechas de segurança nela!

Mas qual o risco de usar portas na VLAN 1?

Na prática é possível gerar tráfego de uma determinada VLAN e direcioná-lo para outra VLAN diferente.

Normalmente esse tráfego é unidirecional, ou seja, não vai dar possibilidade de retorno a quem está fazendo o envio malicioso.

Isso pode ser usado, por exemplo, para um ataque de DoS ou DDoS para tirar do ar algum serviço ou até uma máquina remota específica que a VLAN atual não tenha acesso.

Normalmente esse tipo de ataque é chamado de VLAN Hopping e pode ser realizado de duas maneiras, através do Switch Spoofing e do Double Tagging.

Como podemos evitar problemas com a VLAN 1 ou VLAN Nativa?

Primeiro configurando as portas de acesso corretamento, evitando protocolos de negociação de trunk dinâmico.

Por exemplo, a Cisco possui um protocolo chamado DTP ou Dynamic Trunk Protocol que vem ativado por padrão.

Esse tipo de protocolo permite facilmente um atacante configurar sua porta de computador como trunk e fazer um switch spoofing.

Portanto, portas onde temos configurados computadores devem evitar negociação.

O segundo ponto importante é mudar o VLAN-ID da VLAN Nativa de 1 para outro número qualquer e não utilizar para alocar portas.

Uma terceira alternativa é fazer com que a VLAN Nativa seja marcada pelo 802.1Q nos trunks, assim não temos mais problemas de double tagging.

Isso é possível em maioria dos fabricantes, porém são comandos que devem ser inseridos em todos os switches da rede para não haver problemas de configurações diferentes, ou seja, o famoso mismatch.

Como você pode aprender mais sobre switches e VLANs?

Para você dominar os conceitos mais importantes sobre switching e VLANs temos no Portal da DlteC 03 cursos essenciais para você:

• Switches Ethernet Parte I
• Switches Ethernet Parte II e
• Protocolo Spanning-Tree de A a Z

Ao completar esses cursos você irá ter concluido uma sequência que dificilmente você encontra no mercado, que são os recursos e facilidades que um switch pode oferecer.

No decorrer desses três cursos você vai encontrar quase tudo que você pode precisar no seu dia a dia, projeto, resolução de problemas e tudo mais (nota: coisas que eu queria saber antes de iniciar a estudar sobre switching e não encontrei em lugar nenhum de forma unificada).

No segundo curso, o switches ethernet parte II, você vai aprender o funcionamento dos switches, desde como ele é formado por dentro até como ele encaminha os quadros na rede.

Muita gente ainda no mercado de trabalho vê os switches como Hubs, ou seja, tira da caixa e conecta cabos que tudo funciona…

… sinceramente não é bem por aí!

Tem muita coisa por trás dos bastidores!

Por último, no terceiro curso chamado de “Spanning-tree de A a Z” você vai aprender como funciona esse importante protocolo. Tão importante que pode causar até demissão!

… opa! Você ouviu demissão?

Claro que estamos exagerando um pouco para chamar sua atenção, porém não é impossível de acontecer, pois já vimos rede de grande porte parar porque alguém ouviu dizer que o spanning-tree podia ser desabilitado (parece incrível, mas é verdade).

Simplesmente parou tudo… imagina isso em uma fábrica? (com certeza cabeças vão rolar)

E a boa notícia é que você pode ter acesso a esses cursos (e a todos os cursos do portal). Basta ativar nosso plano de acesso e começar a se especializar agora mesmo.

E se você já é nosso assinante vá lá e ative os cursos!

Mais uma vez agradeço pela sua paciência em ler meu singelo artigo, espero ter ajudado com esse conteúdo e até uma próxima!

Confiram o artigo original publicado pela DlteC do Brasil: Por que Trocar a VLAN Nativa ou VLAN 1

Esse artigo traz algumas medidas de segurança em switches e reforço na configuração geral dos switches Cisco que você provavelmente já estudou até mesmo no CCNA R&S, mas que para um CCNP é essencial.

De nada vale implementar recursos avançados de segurança na rede e deixar portas óbvias abertas que atacantes pode utilizar muito facilmente.

Lembre-se que existem várias informações e padrões que são divulgados pelos fabricantes, por isso é preciso aplicar algumas configurações e tomar alguns cuidados básicos para que os atacantes não utilizem isso ao seu proveito.

A seguir vamos estudar essas recomendações que você deve seguir em suas implantações para melhorar a segurança em switches Cisco Catalyst.

Configurar senhas seguras

A primeira recomendação é básica para segurança em switches e quaisquer outros dispositivos de rede que utilizam Cisco IOS.

Sempre que possível utilizar o “enable secret” para definir a senha para acesso privilegiado ao invés do “enable password”.

Se possível também implementar servidores de autenticação externos RADIUS ou TACACS+ e utilizar o AAA para implementar no mínimo o processo de autenticação.

Com o AAA e servidores externos as informações de autenticação não são mantidas nos switches e permite a implementação de outros recursos como Autorização e Auditoria.

Outra vantagem da autenticação com servidores externos é a centralização do processo de autenticação, que possibilita implementar mudanças de senhas ou regras de autenticação mais facilmente, pois não é preciso entrar dispositivo por dispositivo para esse tipo de atividade.

Também é importante utilizar o comando “service password-encryption” para aplicar a criptografia das senhas que normalmente são armazenadas em texto claro, tais como senhas de console e VTY locais.

Apesar dessa solução implementar uma criptografia fraca, ela previne que observadores casuais vejam suas senhas quando trabalhando ao lado e você eventualmente entra com um “show running-config”, por exemplo.

Utilizar os banners do sistema

Os banners são importantes porque eles informam a usuários que tiveram acesso aos dispositivos de rede que existe uma política corporativa e essa conexão pode estar sendo monitorada, por exemplo.

A ideia é informar que acesso não é autorizado e que se um usuário conseguiu acesso e pode ser punido conforme os termos contratuais ou códigos de conduta da empresa.

O “banner motd” define o texto para usuários autenticados, tente não inserir informações muito elaboradas ou que um atacante possa utilizar contra o próprio esquema de segurança da empresa.

Apesar de não aumentar a segurança em switches, esse recurso pode pelo menos deixar os avisos padrões para que usuários desapercebidos não façam nada errado.

Implemente Segurança na Interface Web

Utilizar ou não a interface Web do switch é uma decisão corporativa, pois muitas empresas permitem apenas acesso CLI e desabilitam a interface web com o comando “no ip http Server” em modo de configuração global.

Se for preciso utilizar o acesso web prefira sempre através do HTTPS se for suportado.

O comando para ativar o HTTPS é “ip http secure server” em modo de configuração  global

Além disso, limite os endereços que podem acessar o switch via HTTPS, por exemplo, dando acesso via ACL apenas para a rede de administração ou gerenciamento de redes da empresa, e também implemente autenticação local (username/secret ou password) ou através do AAA, se possível.

Veja exemplo abaixo onde a rede de administração é 10.100.50.0/24 e vamos utilizar usuários locais para autenticar a interface HTTPS.

O usuário será “dltec” e a senha secreta “d3lt1c123#!”.

Switch(config)#username dltec privilege 15 secret d3lt1c123#!

Switch(config)#ip http secure server

Switch(config)#ip http authentication local

Switch(config)#access-list 1 permit 10.100.50.0 0.0.0.255

Switch(config)#ip http access-class 1

Proteja o acesso via console e VTY utilizando senhas fortes

Apesar de maioria dos ambientes os switches estarem em locais fechados e de difícil acesso é preciso proteger tanto a porta de console como o acesso remote via VTY com senha. Normalmente é utilizado o mesmo método de controle de acesso da console e VTY.

Proteja o acesso remoto ou virtual terminal access

É importante utilizar autenticação em todas as linhas VTY, limitar o acesso por endereço IP de origem através de ACLs aplicadas às VTYs tanto para acesso remoto via  Telnet ou Secure Shell (SSH).

Além disso, sempre prefira SSH ao invés de Telnet, pois apesar de simples ele não é seguro por enviar mensagens em texto claro, possibilitando o roubo de usuários e senhas de acesso privilegiado.

O SSH possui criptografia e por isso é mais seguro, porém você precisa de um IOS que suporte esse recurso.

Veja exemplo abaixo onde vamos permitir apenas dois servidores de gerenciamento acessar as linhas VTY, os endereços dos servidores são 192.168.100.10 e 192.168.200.100.

Cuidado ao implementar essa configuração e aplicar realmente a todas as linhas VTY, pois algumas vezes os switches separam em line VTY 0 4 e 5 a 15 no show running, gerando confusão na aplicação do comando e deixando abertas portas para conexão sem verificação da ACL.

Veja o exemplo abaixo.

Switch(config)#access-list 10 permit 192.168.100.10

Switch(config)#access-list 10 permit 192.168.200.100

Switch(config)#line vty 0 15

Switch(config-line)#access-class 10 in

Switch(config-line)#transport input ssh

Switch(config-line)#login local

As versões de SSHv1 e SSHv1.5 possuem algumas fraquezas, por isso sempre que possível utilize o SSHv2.

Proteja o acesso para monitoração via SNMP

Para evitar que alterações sejam feitas via SNMP evite utilizar comunidades de escrita e leitura (read-write), elas aparecem no comando “snmp-server community nome-da-comunidade RW”, permitindo apenas comunidades “read-only” (apenas leitura).

É aconselhável utilizar ACLs para limitar o acesso, mesmo utilizando comunidades apenas read-only.

Se possível utilize o SNMPv3 que possui autenticação e criptografia, não dependendo de comunidades com segurança fraca como nas versões SNMPv1 e SNMPv2c.

Proteja portas do switch não utilizadas

As portas dos switches não utilizadas deveriam ser desabilitadas, assim nenhum usuário conseguiria conectar um host sem o conhecimento da administração de redes.

Isso é feito com o comando “shutdown” dentro da interface, porém nem sempre isso é possível devido a possível sobrecarga para equipe de TI que cuida da rede para tratar solicitações desse tipo e também controlar cada porta de switch.

Portas de usuários ou de acesso devem ter o comando “switchport mode Access” na interface, assim um usuário mal intencionado não conseguirá negociar para passar a porta para trunking.

Você também podem colocar portas de acesso não utilizada em uma VLAN inativa e filtrada nos trunks entre switches, assim mesmo que um usuário se conecte em uma porta não autorizada ele ficaria isolado na rede.

Outra opção é o comando “switchport host” no modo de configuração de interface, pois esse comando coloca a porta como acesso, ativa o portfast e desativa negociação de etherchannel na porta. Veja exemplo abaixo.

Switch(config)#int f0/1

Switch(config-if)#switchport host

switchport mode will be set to access

spanning-tree portfast will be enabled

channel group will be disabled

Proteja a operação do STP

Como já estudamos, é possível que um usuário mal intencionado injete BPDUs nas portas do switch para tentar tomar acesso como root bridge e afetar a estabilidade do STP, causar loops ou alterar o fluxo de quadros para um possível sniffing de rede.

Por isso é recomendável ativar o recurso de BPDU guard nas portas de acesso dos switches.

Proteger o uso do CDP e LLDP

Por padrão os anúncios do CDP são enviados em todas as portas do switch a cada 60 segundos. Apesar de muito útil, principalmente em redes com Telefonia IP, o CDP é considerado um risco de segurança por muitos administradores de rede por possibilitarem a coleta de informações sobre os roteadores e switches Cisco, possibilitando descobrir vários informações e ataques como VLAN hopping.

O CDP pode ser ativado e desativado em modo global, afetando todas as interfaces ou então pode ser feito por interface com o comando “[no] cdp enable”.

Se você tem certeza que não vai utilizar o CDP o melhor é desativá-lo.

Com isso terminamos mais um artigo sobre segurança em switches Cisco e espero que tenha ajudado mais um pouco na sua formação.

Dúvidas? Deixe sua pergunta ou sugestão na área de comentários mais abaixo nessa mesma página!

Obrigado e até um próximo artigo.

Confiram o artigo original publicado pela DlteC do Brasil: Reforçando a Segurança em Switches Cisco para CCNAs e CCNPs

Uma coisa básica quando começamos a estudar um sistema operacional é a reinicialização e o desligamento, portanto nesse artigo vamos falar desse assunto mais especificamente para o sistema Linux com foco no exame de certificação LPIC-1 e LPI-101.

Lembre-se que podemos desligar o sistema Linux, reiniciá-lo ou então colocá-lo em Halt, onde o sistema Linux é desligado sem desligar a máquina.

O comando shutdown (man shutdown) reinicia ou desliga o computador com sistema Linux de forma segura.

Por padrão, todos os usuários do sistema são alertados.

Todos os processos recebem sinal SIGTERM (solicita ao processo para que pare de executar) e SIGKILL (finaliza o processo).

Podemos também agendar esses comandos

Agora vamos estudar alguns exemplos do desligamento e reinicialização do sistema Linux.

Deligando o Sistema Linux

Desliga a máquina dentro de 1 minuto
O sistema é finalizado (halt) e a energia elétrica é cortada (poweroff)
dltec@cap1:~# shutdown
Desligue a máquina às 19:30
dltec@cap1:~#shutdown 19:30
Cancela o desligamento
dltec@cap1:~# shutdown -c

Reiniciando o Sistema Linux

Sistema será reiniciado
dltec@cap1:~#shutdown –r
Agenda a reinicialização para daqui a 20 minutos
dltec@cap1:~#shutdown –r +20
Sistema entrará em halt
De forma direta, o Linux será desligado – mas a máquina não (dependerá do hardware).
dltec@cap1:~# shutdown -h

Comandos Auxiliares

Existem outros comandos auxiliares que realizam essencialmente as mesmas coisas. Por exemplo:

reboot: é responsável por reiniciar a máquina.

halt: sistema operacional é finalizado (mas não a máquina).

poweroff: tanto o sistema operacional quanto a máquina são finalizados.

Comando Wall

O comando wall (man wall) pode ser utilizado em conjunto com os comandos anteriores para enviar mensagens a todos os usuários que estejam conectados ao sistema.

Por exemplo, se o administrador do sistema precisar realizar tarefas de manutenção no servidor, ele poderá informar aos usuários conectados sobre a sua intenção (a mensagem será exibida em todos os terminais de todos os usuários logados).

Veja um exemplo a seguir:

dltec@cap3:~$ wall “O sistema será desligado em 10 minutos”

Com isso finalizamos mais um artigo sobre o sistema Linux, sobre a certificação LPIC-1 e a prova LPI-101!

Espero que vocês tenham gostado e compartilhem nosso blog e artigos com seus amigos!

Se tem alguma dúvida ou sugestão é só utilizar o campo de comentários abaixo!

Confiram o artigo original publicado pela DlteC do Brasil: LPIC-1: Desligamento e Reinicialização do Sistema Linux

Nesse artigo vamos falar sobre alguns problemas que uma rede sem fio pode ter e dois deles vamos falar com mais detalhes, que são a perda no espaço livre e a absorção do sinal wireless.

Como o sinal de RF trafega em espaço aberto, ou seja, via ondas eletromagnéticas pelo ar, ele está sujeito a muito mais tipos de interferências, atenuações e problemas que um sinal elétrico que passa por um cabo UTP ou um sinal óptico através de um cabo de fibra.

Portanto, esse tópico é dedicado ao estudo dos principais problemas que um sinal sem fio enfrenta e suas consequências.

Basicamente os sinais sem fio estão sujeitos aos seguintes efeitos que podem atenuar (diminuir a potência do sinal), distorcer, interferir ou afetar as transmissões sem fio:

• Perda no espaço livre
• Absorção (Penetração)
• Reflexão
• Refração
• Espalhamento do sinal
• Propagação multicaminhos

Os problemas que serão apresentados a seguir causam distorções, atenuações, degradação e até em alguns casos o cancelamento do sinal na recepção.

Esses problemas podem ser avaliados e minimizados com o “site survey”.

O sitesurvey é uma visita técnica onde pessoas qualificadas irão analisar o ambiente inserindo APs de prova para coletar informações sobre o sinal e ao final do processo se tem um relatório com o posicionamento que cada AP deve ter para garantir o sinal na área de cobertura escolhida pelo administrador de redes.

Além do posicionamento, muitas vezes teremos também recomendações de tipos de antenas a serem utilizadas, potência dos equipamentos e demais requisitos para que o modelo de AP possa ser especificado.

Agora vamos falar mais sobre os dois problemas que citamos no começo do artigo.

Perda no Espaço Livre

Apenas parte da energia transmitida através das ondas eletromagnéticas é captada pela antena receptora, sendo que a perda é maior quanto maior for a distância percorrida pelo sinal.

Esta perda é denominada Perda no Espaço Livre ou Free Path Loss.

Nesse caso não estamos considerando nenhum anteparo entre o emissor e o receptor, por isso o nome “espaço livre”.

Depois veremos que ao inserir anteparos ou obstáculos outros problemas são adicionados à perda em espaço livre, causando mais atenuações e distorções no sinal original emitido pelo transmissor.

Imagine uma pedra jogada no meio de um lago sem ondulações, do ponto onde a pedra foi jogada para a margem as cristas das ondas vão ficando menores, ou seja, quanto mais perto de onde jogamos a pedra maior será a crista da onda ou sua amplitude.

Esta mesma analogia podemos fazer para as emissões de uma antena de um AP, quanto mais perto do AP mais forte será o sinal, ou seja, a onda eletromagnética emitida pelo AP diminui de potência à medida que nos afastamos dele.

Perda por Penetração ou Absorção

Quando um sinal atravessa um objeto, ou seja, um obstáculo entre a origem e destino da comunicação, este sinal sofre com uma redução do seu nível de potência (atenuação).

Esta perda da potência do sinal ao cruzar os objetos é chamada de perdas de penetração ou absorção.

A perda de penetração depende do material o qual compõe o objeto.

Obstáculos como paredes e janelas, por exemplo, apresentam valores diferentes de perdas de penetração.

Quanto mais metal estiver presente no obstáculo, maior será a perda por absorção.

Como Aprender Mais sobre Redes Sem Fio com a DlteC?

Esse artigo foi feito com base no curso Wireless LANs (Redes sem Fio).

• Clique aqui para assistir uma aula de demonstração do curso de Wireless LAN

Nesse treinamento você vai aprender os conceitos de funcionamento, tecnologias, principais problemas de transmitir em espaço aberto, tipos de redes sem fio e suas topologias, transmissão de dados em redes sem fio, padrões IEEE 802.11, princípios de segurança, como realizar um site survey e como aplicar tudo isso com um super exemplo prático (aula bônus).

Se você já é nosso assinante Premium basta acessar o Portal, ir no Menu cursos e ativá-lo para estudar.

Se você ainda não é assinante, por fazer um testdrive e conhecer alguns capítulos do curso sem compromisso, basta criar um usuário no Portal, ir no menu Cursos e ativar seu testdrive, simples assim.

Com isso finalizamos mais um artigo sobre redes sem fio e esperamos que seja útil.

Não esqueça que se você tiver dúvidas ou sugestões temos um campo para isso bem aqui no final do artigo, é só descer a página para ter acesso!

Obrigado e até uma próxima.

Confiram o artigo original publicado pela DlteC do Brasil: Problemas em Redes Sem Fio – Perda e Absorção