CCNA 50 60 livro marco filippetti

Prévia do material em texto

Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 1 
 
PDF de Compatibilização CCNA 5.0 x CCNA 6.0 
Conforme prometido, disponibilizo aos meus leitores e amigos este material que torna o 
livro CCNA 5.0 100% compatível com o novo exame CCNA 200-125. Este material apenas inclui 
os tópicos que, de alguma forma, foram alterados do exame 200-120 para o exame 200-125 pela 
Cisco. 
Este material pode conter eventuais erros já que não passou por um processo de revisão 
/ editoração. Peço desculpas pelas marcas d’água que aparecem no material, mas foi condição 
imposta pela editora para que eu pudesse disponibilizar este material para vocês. 
Em caso de dúvidas / sugestões, entre em contato via e-mail ccna60@cloudcampus.cc 
Aproveitem! 
Abraços, 
 
Marco A. Filippetti 
 
mailto:ccna60@cloudcampus.cc
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 2 
 
Capítulo 01 (adequação dos dados ao novo exame e formatos das certificações Cisco) 
 
 
Tabela 1.1 - Certificações e focos atualizados 2016 (fonte: Cisco) 
1.2.2 Perguntas Frequentes 
1) O que mudou no exame CCNA R&S da versão 200-120 para a versão 200-125? 
A Cisco colocou como 30 de setembro de 2016 a data final para agendamento do exame 
CCNA 200-120. Após esta data, apenas a versão 200-125 (ou 100-105 e 200-105, caso opte por 
fazer em duas partes) encontra-se disponível para agendamento nos centros autorizados VUE. 
Ao que tudo indica, não vai haver versão em português do novo exame. Até a data do 
fechamento desta publicação, apenas a versão em inglês do exame encontrava-se disponível. A 
nova versão (200-125) trouxe poucas alterações no conteúdo de sua antecessora, com algumas – 
poucas - inclusões e exclusões: Saíram da lista de tópicos do exame: Frame-Relay (já era hora!) e 
VRRP e GLBP. Por outro lado, entraram os temas LLDP, Single-homed BGP e conceitos de 
Cloud Computing, QoS e SDN (Software-defined Networks). O novo exame, ao que parece, visa 
preparar o candidato para algumas especializações, como o CCNA Security e o CCNA 
DataCenter. Como sempre, as chances de aprovação dos candidatos que se preparam apenas 
com base em “braindumps” (simulados encontrados na Internet) foi drasticamente reduzida – 
objetivo permanente da Cisco – elevando o nível geral do exame. Resumindo: não basta decorar, 
tem que entender. O exame CCNA não valoriza tanto a prática e experiência do candidato, 
porém, o novo formato apresenta algumas das questões de forma interativa - por vezes 
simulando um roteador real em operação (veja exemplo no Apêndice C) - praticar os comandos 
vistos com o auxílio de programas simuladores (ou mesmo com routers reais) é de grande 
ajuda, tanto para o sucesso no exame, quanto para seu futuro profissional na área. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 3 
 
2) Qual a vantagem de ser certificado? Como o mercado encara profissionais com a 
certificação Cisco CCNA R&S? 
O Brasil tem uma defasagem histórica de profissionais qualificados na área de redes. 
Estudo realizado em 2015 pelo IDC estima que o déficit de profissionais chegue a cerca de 195 
mil na América Latina até 2019, ou seja: o mercado tem vagas, e muitas. Entretanto, em um 
mercado extremamente competitivo como o atual, a escolha de uma certificação globalmente 
reconhecida e procurada, como é o caso do CCNA R&S, pode fazer muita diferença na disputa 
por um bom emprego, ou mesmo na busca de uma promoção e, consequentemente, de um 
melhor salário. O mercado para profissionais com conhecimentos comprovados em redes é 
imenso e, financeiramente, bastante atraente. Profissionais certificados CCNA R&S atuam na 
configuração e operação de LANs e WANs, entendem a fundo e são capazes de configurar 
redes IP, protocolos de roteamento, conexões WAN, MPLS, IP, Ethernet e listas de acesso, e são 
frequentemente procurados para realizar a otimização de performance de redes. 
4) Como me certifico? Onde me certifico? Quanto custa o exame? 
Para tornar-se um CCNA R&S, basta ser aprovado em um exame, o 200-125 da Cisco. 
Discutiremos mais detalhes deste exame mais adiante. A Cisco ainda abre uma segunda opção: 
é possível “quebrar” o exame em 2 partes. Assim, seria necessário realizar 2 exames para se 
certificar (100-105 ICND1 e 200-105 ICND2). O interessante deste caminho é que, sendo 
aprovado no primeiro exame (100-105), o candidato já adquire o primeiro carimbo da Cisco, a 
certificação CCENT (Cisco Certified Entry Networking Technician). Eu, particularmente, não 
recomendo. É mais barato e mais prático partir diretamente para a 200-125 e obter o status de 
CCNA R&S (muito mais reconhecido e valorizado pelo mercado do que o “novo” e ainda 
desconhecido CCENT). Entretanto, se o seu objetivo não é o caminho R&S (ex: você quer seguir 
o caminho de Security ou Design), talvez o CCENT faça mais sentido. Para candidatar-se ao 
exame, basta inscrever-se em um dos centros autorizados VUE espalhados pelo Brasil. Para 
encontrar o centro mais próximo, ou mesmo para efetuar o agendamento de seu exame online, 
visite o web site <http://www.vue.com> e cadastre-se. O custo para se fazer o exame 200-125, 
até a presente data (Set/2016), é US$295. Se desejar quebrar em duas partes, vai desembolsar 
US$150 para cada ICND (1 e 2). 
5) Preciso participar de algum curso antes? Estudar por conta própria é suficiente? Alguma 
sugestão? 
Não, você não precisa participar de nenhum curso para estar apto a prestar o exame 
CCNA R&S. No entanto, algumas firmas especializadas oferecem uma excelente preparação 
para ele. Estudar por conta própria pode ser o suficiente se você possui bastante determinação, 
disciplina e interesse pelo assunto. Se você não se encaixa nesse perfil, talvez inscrever-se em 
um curso seja o melhor caminho. Outra solução para aqueles que não possuem todas as 
qualidades citadas pode ser a formação de um grupo de estudos, pois o ambiente 
proporcionado acaba exigindo mais disciplina e dedicação. 
Vale ressaltar que existem empresas que oferecem bons treinamentos preparatórios para o 
exame CCNA R&S (e outros) no formato online, com excelente custo/benefício. Uma delas é a 
empresa que iniciei em 2012, e que já conta com mais de 9.600 alunos (número de julho de 2016). 
Visite nosso site e conheça mais! <http://www.CloudCampus.cc>. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 4 
 
1.2.3 Sobre o Exame 200-125 
As questões do novo exame CCNA são agrupadas em sete categorias: 
 Network Fundamentals 
 LAN Switching Technologies 
 Routing Technologies 
 WAN Technologies 
 Infrastructure Services 
 Infrastructure Security 
 Infrastructure Management 
Experiência prática ajuda muito, mas não é essencial para ser bem-sucedido na prova 
CCNA. O grau de conhecimento exigido pode ser alcançado por meio do uso de simuladores e 
de um PC comum. 
 
 
 
 
 
 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 5 
 
Capítulo 02 (adições ao capítulo) 
2.6 Modelo Hierárquico x Modelo Colapsado 
Este é um dos novos tópicos que passaram a ser cobrados no exame CCNA 200-125. 
Apesar de ter sido incluído apenas agora, entretanto, de novo ele não tem nada, na verdade. 
Para os que se lembram das mudanças sofridas pelo exame CCNA no decorrer dos anos, a 
versão 640-802 cobrava conhecimentos do “Modelo de 3 Camadas Cisco”. Pois então, este 
tópico volta a este ponto. 
Sistemas hierárquicos nos ajudam a entender melhor onde deve ser alocado cada recurso, 
como cada recurso se encaixa e interage com os outros e quais funcionalidades vão onde. Eles 
trazem ordem e compreensão para o que seria, de outro modo, algo muito mais complexo. 
Grandes redes podem ser extremamente complexas, envolvendo múltiplos protocolos, 
elementos e tecnologias diversas. A hierarquização auxilia na sumarização de uma vasta gama 
dedetalhes em um modelo mais gerenciável e compreensível. 
O modelo hierárquico de 3 camadas foi idealizado pela Cisco para auxiliar projetistas e 
administradores de redes em tarefas como desenho, implementação e gerenciamento de redes 
complexas. A Cisco define três camadas hierárquicas, como nos mostra a figura 2.17. Note que, 
no diagrama, os uplinks (conexões entre as camadas) possuem uma largura de banda maior, 
conforme se avança no modelo. Isso é necessário, pois, conforme subimos na hierarquia, maior é 
a concentração do tráfego de dados. Por isso, é necessário planejar com atenção para evitar o 
surgimento de “gargalos”. Note também que as conexões entre as camadas são redundantes, o 
que aumenta a disponibilidade e a resiliência da rede. 
 
 
Figura 2.17: O Modelo de 3 Camadas da Cisco. 
Core Layer (Camada Principal): A camada principal é o “coração” da rede. Responsável 
pelo transporte de grandes volumes de dados, de forma simultaneamente rápida e confiável. Se 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 6 
 
ocorrer uma falha em qualquer dispositivo ou processo nessa camada, todos os usuários serão 
afetados. Portanto, tolerância à falha é um fator crítico nessa camada. Nela encontraremos 
dispositivos de rede como switches Layer-3 e/ou routers de alto-desempenho (dependendo do 
tamanho e arquitetura da rede em questão). Como nesta camada ocorre a agregação dos links 
de toda a rede, largura de banda também é um fator crítico. Eis uma lista do que não deve ser 
feito na camada principal: 
 Implementação de processos ou dispositivos que retardem o tráfego de dados, 
incluindo a implementação de listas de acesso, roteamento entre VLANs e 
filtragem de pacotes. De um modo geral, nesta camada não deve ocorrer a 
manipulação de dados, ou seja, do modo como os pacotes ou frames chegam, eles 
devem ser encaminhados, o mais confiável e rápido possível. 
 Implementação de processos ou dispositivos que suportem o acesso a grupos de 
trabalho; 
 Expansão do core pela simples adição de dispositivos. Se a performance tornar-se 
um fator crítico no core, seu upgrade deve ser a opção à sua expansão. 
Distribution Layer (Camada de Distribuição): A função principal desta camada é prover 
o roteamento entre VLANs, filtragem de dados (por meio da implementação de Firewalls, Listas 
de Controle de Acesso ou outros mecanismos) e quaisquer outros recursos necessários pelos 
grupos de trabalho. Também é função desta camada prover o tratamento e manipulação do 
tráfego, ANTES que ele chegue ao Core da rede. É nesta camada que devem ser implementadas 
políticas de acesso à rede. Dispositivos de rede comuns à camada de distribuição são switches 
layer-3 e/ou routers. Eis uma lista de funções que encontram-se disponíveis nessa camada: 
 Implementação de ferramentas como listas de acesso, filtragem de pacotes e queuing; 
 Implementação de políticas de segurança e acesso à rede, incluindo firewalls e tradução 
de endereços (como NAT); 
 Redistribuição entre protocolos de roteamento, incluindo roteamento estático; 
 Roteamento entre VLANs; 
 Definição dos domínios de broadcast (via roteamento). 
Access Layer (Camada de Acesso): A camada de acesso controla o acesso de grupos e 
usuários aos recursos da rede. Normalmente, a maior parte dos recursos de que os usuários 
necessitam estarão disponíveis localmente. Os dispositivos de rede mais comumente 
encontrados nessa camada são os switches de camada 2 (switches de camada 3 também podem 
ser definidos nesta camada, se isso estiver previsto no design da rede). Alguns processos chave 
desempenhados pela camada de acesso: 
 Implementação de políticas de acesso à rede (como IEEE 802.1X) e segurança; 
 Definição de domínios de colisão (via switches) e de broadcast (via VLANs); 
 Conectividade dos grupos de trabalho com a camada de distribuição. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 7 
 
Ao se planejar uma rede hierárquica, é importante ter em mente as diferentes tecnologias 
Ethernet disponíveis. Utilizando-se um “mix” das diferentes tecnologias Ethernet disponíveis 
hoje, é possível a criação de uma rede eficiente a um custo justificável. Eis algumas sugestões de 
onde utilizar cada tipo de tecnologia em uma rede hierárquica: 
 Implementação de switches 10/100/1000 Mbps na Camada de Acesso para promover 
um bom desempenho a um custo relativamente baixo. É interessante implementar 
uplinks de 10 Gbps conectando as camadas de Acesso e Distribuição, para evitar 
“gargalos”. Uplinks, normalmente, adotarão fibra óptica (se possível). 
 Adoção de portas 10 GigabitEthernet (fibra) entre os switches entre as camada de 
distribuição e core. O agrupamento de portas físicas em canais lógicos – conhecidos 
como Etherchannel – pode ser uma forma relativamente simples de se criar uplinks de n 
x 10 Gbps, se necessário. 
 A adoção de links redundantes entre os elementos de diferentes camadas é 
recomendável para contingência e balanceamento de carga. 
Core Colapsado 
O modelo de 3 camadas é bastante útil, mas nem sempre deve (ou pode) ser seguido à risca. 
Por exemplo, suponha que você tenha uma rede que não seja tão complexa. Uma pequena 
empresa, por exemplo. Você não precisa utilizar a hierarquia de 3 camadas neste caso. Pode 
colapsar as camadas Core e Distribuição em uma única. Neste caso, os elementos definidos 
nesta camada colapsada terão suas funções consolidadas. Para efeitos de simplificação de 
desenho, esta abordagem pode fazer muito sentido. No fim, o que temos é algo como o que é 
ilustrado na figura 2.18: 
 
 
Figura 2.18: Modelo de arquitetural com Core colapsado. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 8 
 
Capítulo 07 (adições ao capítulo) 
7.6 Roteamento eBGP single-homed 
Demorou um pouco, é verdade. Mas, finalmente, a Cisco rendeu-se à cobrança de BGP no 
exame CCNA. Calma, não precisa se alarmar. O que se pede para o CCNA em termos de BGP é 
bastante simples e superficial. Basicamente cenários single-homed (com apenas uma opção de 
saída) e apenas anunciando redes via comando “network” – portanto, nada de redistribuições 
ou filtros. 
 Antes de começarmos a nos aprofundar no tema, precisamos entender como o protocolo 
BGP funciona. E BGP, se comparado com os protocolos que vimos até aqui, é bastante 
particular. Podemos definir BGP como “a cola que mantém a Internet unida”. Diferentemente 
dos protocolos que vimos até aqui – os IGPs (Interior Gateway Protocols) – o BGP é um 
protocolo desenhado para a interconexão de redes pertencentes à sistemas autônomos (AS) 
distintos. É o único representante da classe dos EGPs (External Gateways Protocols). Para 
explicar o BGP é preciso, antes, entender o conceito de Sistema Autônomo (Autonomous 
System ou AS). 
Definindo Sistemas Autônomos 
O conceito de AS (autonomous system) nasceu juntamente com a Internet. As mais 
diversas definições podem ser encontradas na net, usando o Google, por exemplo. Todas 
apontam na mesma direção: “Um AS pode ser definido como uma rede ou um conjunto de 
redes sob uma gestão comum”. Bom, isso é uma definição, de fato. Mas… não ajuda muito, 
ajuda? Muitos, quando leem esta definição, pensam: “Ah, OK! Mas… o que é um AS mesmo?!”. 
Ou seja, a definição “oficial” de AS é um tanto quanto ampla. Especificamente para quem está 
começando, esta definição é um tanto quanto vaga. Vamos, então, tentar melhorá-la. 
“Um AS seria uma rede ou um conjunto de redes que, além de se encontrarem sob uma 
gestão comum, possuem características e políticas de roteamento comuns”. Para esclarecer esta 
definição, vamos exemplificar: 
Imagine que você trabalhe em uma empresa que se encontra em franco crescimento. No 
momento, esta empresa possui duas filiais e uma matriz, e todo o acesso IP Internet é 
centralizado nesta última. Como é depraxe em casos como este, suponha que esta empresa 
precise de IPs válidos para endereçar alguns servidores de acesso público (de pessoas que se 
encontram na Internet), como um servidor Web ou e-mail. Estes IPs seriam disponibilizados 
pelo provedor de acesso (chamado de ISP) e, portanto, seríamos vistos pela Internet como uma 
extensão do AS deste ISP. Em suma, teríamos algo como o diagrama abaixo: 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 9 
 
 
 
Observem que, na Internet, temos uma série de ASs distintos, cada qual recebendo um 
número único de identificação. O AS de nosso provedor Internet é número 1122 e, como 
estamos usando os IPs válidos fornecidos por este provedor - e, por consequência, estamos 
sujeitos às políticas de roteamento e gestão deste provedor - nossa empresa é vista pelo mundo 
externo (Internet) como uma extensão do AS de nosso provedor, ou seja, AS number (ASN) 
1122. 
Suponhamos, agora, que as necessidades de conectividade de nossa empresa ficaram mais 
complexas, dado o crescimento da mesma. Agora, como forma de ter uma saída redundante de 
tráfego IP, nossa empresa pensa em contratar um segundo acesso, mas de um provedor distinto, 
chamado de “ISP 2”. Até aqui, tudo bem… mas… existe uma necessidade adicional: Que tanto a 
saída quanto o retorno do tráfego seja balanceado entre os links estabelecidos com ambos os 
ISPs – este é o cenário conhecido como dual-homed ou multi-homed. Bom, se não temos um 
range de endereços IP válido (chamado de “blocos” ou “prefixos”, neste cenário) próprio e 
continuarmos nos submetendo às políticas de roteamento do ISP 1 e, agora, também do ISP 2, 
não temos como definir políticas próprias de roteamento de forma a definir como este tráfego 
deve fluir. Na verdade, até podemos controlar a saída do tráfego, mas o retorno do mesmo 
ainda ficaria nas mãos dos dois ISPs. Prefixos pertendentes ao ISP1 apenas retornam via ISP. E – 
vocês pegaram a ideia – prefixos pertencentes ao ISP2 apenas retornam via ISP2. E não é 
possível alterar isso sem que tenhamos nosso próprio ASN e nossos próprios prefixos. Ou seja, 
se não conseguirmos nos desvincular dos dois ISPs e obter nossa independência, jamais vamos 
ter completo controle de nosso tráfego e, portanto, jamais conseguiremos controle total do 
balanceamento. Qual a solução, então? Simples! Declarar nossa independência! Para isso, 
precisamos solicitar um número de AS e prefixos IP próprios que serão associados a ele. Apenas 
então, rodando BGP, poderemos anunciar para o mundo como nós queremos ser vistos e, 
finalmente, termos total controle sobre o nosso tráfego. Quais prefixos saem por qual ISP e, mais 
importante, por qual ISP o tráfego deve retornar. Tudo isso é possível via BGP, desde que você 
tenha um ASN e prefixos IP próprios. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 10 
 
Nosso diagrama “pós-ASN” ficaria assim, portanto: 
 
O Protocolo BGP 
Percebam que BGP é vital para arquiteturas como a ilustrada anteriormente. É o único 
protocolo que permite um roteamento com base em políticas – diferente das métricas que 
estudamos nos protocolos IGP. BGP usa atributos como forma de definir como prefixos devem 
ser aprendidos e anunciados. Adicionalmente, BGP disponibiliza uma série de sofisticados 
filtros e mecanismos que nos dá total controle sobre a comunicação de nosso AS com o mundo 
externo. Um dos maiores objetivos do BGP é certificar-se que TODOS os routers na Internet 
tenham acesso a TODAS as rotas atualmente existentes (Global Routing Table = 600 mil rotas). 
O exame CCNA 200-125 foca apenas na modalidade single-homed BGP, o que implica em 
termos apenas um ponto de troca de tráfego usando o protocolo. Este cenário não é muito 
realista, uma vez que no mundo real é mais comum termos vários pontos de troca, com 
diferentes operadoras. Mas a ideia da Cisco é manter as coisas o mais simples possível já que, 
em um próximo nível (certificações Professional), você terá muito mais contato com o BGP e 
todas as suas variações. 
Adjacência BGP 
Assim como OSPF e EIGRP, BGP precisa formar uma adjacência com o roteador vizinho 
antes que o processo de troca de prefixos possa ocorrer. Entretanto, existem diferenças 
marcantes se compararmos o processo de adjacência BGP com o de seus primos IGP: 
 BGP não forma adjacência de forma automática. É preciso explicitar quem será o 
router vizinho por meio do comando “neighbor”. Por exemplo: neighbor 1.1.1.1 
remote-as 11. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 11 
 
 BGP usa o protocolo TCP como transporte, o que faz muito sentido já que, 
normalmente, seus vizinhos encontram-se a vários quilômetros de distância e, em 
cenários assim, precisamos de confiabilidade no transporte das informações. TCP 
garante que a comunicação entre routers BGP opere de forma confiável. A porta 
lógica TCP usada pelo protocolo é a 179. 
 BGP, diferentemente dos protocolos OSPF e EIGRP, permite o estabelecimento de 
adjacência mesmo entre roteadores que não se encontrem diretamente conectados, 
ou seja, a conexão entre vizinhos BGP não precisa compartilhar uma mesma 
subrede IP – o que torna muito conveniente o uso de interfaces Loopback para a 
definição de vizinhança. Se os vizinhos não compartilharem a mesma subrede, 
entretanto, a opção multihop deve ser ativada. Ex: neighbor 1.1.1.1 ebgp-multihop 
x, onde “x” indica o número de saltos de distância entre o roteador em questão e 
seu vizinho. 
Existem quatro fases de estabelecimento de adjacência: CONNECT, OPEN SENT, OPEN 
CONFIRM e UPDATE: 
 
Figura 7.18: Processo de formação de vizinhança BGP. 
 
BGP trabalha com o anúncio de PREFIXOS (também chamados de NLRI – Network Layer 
Reachability Information) e não subredes. A diferença é semântica, mas, normalmente, prefixos 
são blocos muito mais amplos que subredes. (Ex: 192.168.0.0 /16). Rotadores BGP recebem os 
prefixos anunciados pelo roteador BGP vizinho e os adiciona à sua tabela BGP local (BGP table). 
Rotas internas também são adicionadas a esta mesma tabela. Uma vez que a tabela BGP 
encontre-se devidamente populada, o protocolo executa o algoritmo de seleção de melhor 
caminho (Best Path Algorithm) e apenas a MELHOR rota para cada rede remota é selecionada e 
instalada na tabela de roteamento. Por padrão, BGP não considera mais de uma rota para uma 
determinada rede remota – algo que também difere do comportamento dos protocolos IGP que, 
por padrão, fazem o balanceamento de carga no caso de empate. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 12 
 
Atributos BGP 
BGP não usa métricas para definir quais prefixos serão adicionados à tabela de 
roteamento. No lugar de métricas, temos algo chamado atributos. Atributos são parâmetros que 
podem ou não ser propagados de um AS para outro via updates. BGP usa os valores destes 
atributos para determinar qual o melhor caminho para uma rede remota. A tabela a seguir 
ilustra os principais (não todos, vale ressaltar) atributos usados pelo BGP em ordem de 
preferência. Em caso de empate, o protocolo analisa o próximo atributo na lista, e assim 
sucessivamente até encontrar o caminho mais apropriado. Em caso de empate em todos os 
atributos, o BGP adotará medidas arbitrárias de desempate, como o menor endereço IP do 
neighbor. Novamente, é importante frisar: BGP – por padrão – não instala mais de uma rota na 
tabela de roteamento. Não há, portanto, balanceamento de carga (a não ser que você altere este 
comportamento e configure o protocolo para adicionar mais de uma rota na tabela). 
 
 
 
EBGP x IBGP 
Você já deve ter ouvido falar que existem dois “tipos” de BGP: IBGP e EBGP. O exame 
apenas foca no EBGP, mas vamos discutir brevemente, aqui, a diferença entre ambos. Em 
termos de protocolo, ambos são BGP (não existem versões diferentes). IBGP indica o modo de 
operação INTERNO (dentrode um mesmo ASN) do protocolo, enquanto EBGP, o modo de 
operação EXTERNO (entre ASNs). O modo de operação IBGP possui características próprias – 
assim como o modo EBGP. IBGP, por exemplo, demanda que as conexões sejam estabelecidas 
em topologia full-mesh – todos os roteadores BGP internos devem fechar vizinhança BGP com 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 13 
 
todos os outros, como ilustra a figura 7.19. Não vamos entrar em detalhes sobre IBGP pois este 
tema encontra-se fora do escopo do exame CCNA. 
 
Figura 7.19: Topologia de rede com EBGP e IBGP. 
 
Agora que conhecemos o básico sobre o protocolo BGP (e, acredite... isso é mesmo apenas 
o básico), vamos ver como proceder para configurá-lo e para realizar algumas verificações. Para 
os exemplos, vamos adotar a topologia ilustrada na figura 7.20. 
 
Figura 7.20: Exemplo de configuração BGP. 
 
A configuração inicial de ambos os roteadores ficaria assim: 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 14 
 
 
Adicionando a configuração BGP para estabelecimento de vizinhança, teríamos: 
 
 
Reparem que, neste exemplo, estamos fechando a adjacência na rede que conecta ambos 
os roteadores diretamente (100.1.1.x). Podemos usar as loopbacks L0 em cada roteador para 
estabelecer a adjacência também, se quisermos. Mais adiante eu ilustro como proceder. Uma 
coisa de cada vez. 
Após alguns segundos, devemos observar a vizinhança sendo estabelecida com sucesso: 
 
 
Se observarmos a tabela de roteamento, entretanto, não temos nenhuma rota BGP 
(ilustrado apenas para R1, neste caso): 
 
O motivo é simples: Ainda não anunciamos nenhum prefixo em nenhum dos dois lados. 
O exame CCNA apenas cobra o método de adição de prefixos usando o comando “network”. 
Vale ressaltar que existem outros métodos, como redistribuição ou mesmo IBGP. BGP possui 
uma característica interessante quando o assunto é propagar rotas: Ele JAMAIS propaga rotas 
que ele não possua em sua tabela de roteamento. Ou seja, é um pré-requisito que determinada 
rota exista na tabela de roteamento antes do BGP poder anuncia-la para o mundo. A motivação 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 15 
 
por trás deste comportamento é bastante compreensível: O BGP foca em confiabilidade. É 
preciso certificar-se que não estamos anunciando prefixos que não conhecemos. 
No nosso pequeno exemplo, em R1, podemos anunciar para R2 via BGP as redes 
1.1.1.1/32 (Loopback 0), 111.111.111.0/24 e 11.11.0.0/16. Em R2, podemos anunciar para R1 as 
redes 22.22.0.0/18 3 2.2.2.2/32 (Looback 0). Mãos à obra, portanto: 
 
 
As redes /32 não foram anunciadas neste exemplo pois as Loopbacks 0 em cada roteador 
foram criadas com outro objetivo – o de demonstrar como estabelecer a adjacência mesmo via 
redes que não estejam diretamente conectadas. Faremos isso mais adiante. 
Concluídos os anúncios BGP, agora devemos ter em nossa tabela de roteamento rotas 
aprendidas por este protocolo: 
 
 
Simples, não? E se olharmos as tabelas BGP de cada roteador, teremos as informações 
específicas sobre como o protocolo aprendeu cada uma destas redes. Observe: 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 16 
 
Observe as informações coletadas para o prefixo 11.11.0.0/16 em R1 e em R2. R1 é o 
“dono” desta rede e, portanto, na saída de R1 observamos que o atributo PATH encontra-se 
apenas com a letra “i”, o que informa que este prefixo foi aprendido pelo BGP em R1 de forma 
interna, via comando “network”. Se olharmos as informações para a mesma rede em R2, 
notaremos o atributo PATH contém o ASN 11 – de onde este prefixo foi aprendido – seguido da 
letra “i”, que indica que o ASN 11 provavelmente é o “dono” deste prefixo e o anunciou via 
comando network. 
EBGP Multihop 
Apesar de fugir um pouco do tema do exame CCNA, vou demonstrar rapidamente como 
estabelecer vizinhança EBGP entre dois roteadores usando interfaces loopback e não os 
endereços IP da rede que os conecta diretamente (como fizemos anteriormente). A vantagem de 
usar interfaces loopback é a estabilidade física e lógica das mesmas. Por serem interfaces 
lógicas, elas não “caem”. Redes BGP devem ser as mais estáveis possíveis, e interfaces 
loopbacks podem ajudar neste ponto. 
O primeiro ponto para que isso funcione é que cada roteador consiga enxergar o endereço 
IP que vamos utilizar. Para isso, vamos criar duas rotas estáticas, uma em cada roteador. 
Vamos, também, desconfigurar BGP em ambos os roteadores: 
 
Agora, vamos repetir os comandos de configuração EBGP apontando para as interfaces 
Loopback de cada lado, e ver o que acontece: 
 
Mesmo após aguardar mais de 1 minuto, nada da adjacência ser formada. E, se testarmos, 
veremos que R1 consegue pingar 2.2.2.2 e R2 consegue pingar 1.1.1.1. Não é um problema de 
conectividade, portanto. Então, o que explica este problema? O comando “show ip bgp 
neighbors” pode nos dar uma dica. Veja abaixo o comando aplicado em R1: 
 
Se lembrarem do que eu escrevi anteriormente, BGP permite que a adjacência seja 
estabelecida mesmo entre redes que não se encontrem diretamente conectadas – mas esta não é 
a ação padrão e tem que ser manualmente configurada. Vamos, então, arrumar nossa 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 17 
 
configuração permitindo que a adjacência seja estabelecida por redes distantes até dois saltos. 
Vamos também informar ao protocolo qual endereço IP usar como origem para os updates – 
apesar de não obrigatório neste cenário, serve como demonstração de outro comando que pode 
ser útil na criação de uma configuração estável. 
 
 
E, após alguns segundos, temos a adjacência BGP formada: 
 
Reparem no endereço IP do neighbor, nas saídas apresentadas acima. Mesmo sendo de 
redes completamente distintas a vizinhança BGP entre eles foi estabelecida com sucesso. Isso é 
possível pois o protocolo de transporte adotado pelo BGP é o TCP. 
Para o exame CCNA, o que foi discutido e apresentado aqui em termos de BGP é mais do 
que o necessário. BGP é muito mais complexo do que o que vimos aqui, entretanto. Mas isso é 
tema para um CCNP. Lembre-se: Um passo de cada vez. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 18 
 
Capítulo 08 (exclusões do capítulo) 
8 Arquiteturas de Alta Disponibilidade 
Não estudar VRRP e GLBP. Estes tópicos foram removidos do novo exame. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 19 
 
Capítulo 09 (adições ao capítulo) 
9.3 Link Layer Discovery Protocol (LLDP) 
LLDP é um dos tópicos adicionados ao exame 200-125. Curioso que a Cisco passou a 
cobrar conhecimentos sobre este protocolo apenas agora, já que este protocolo existe desde 
2004, sendo adotado pela maioria dos fabricantes de elementos de rede (incluindo a própria 
Cisco, claro). 
Tanto o LLDP quanto o CDP, que vimos anteriormente, operam estritamente na camada 2 
(enlace) e ambos têm como objetivo o transporte de informações diversas sobre os dispositivos 
vizinhos (diretamente conectados). O CDP é um protocolo proprietário Cisco, enquanto o LLDP 
é definido pelo padrão IEEE 802.1AB, podendo ser adotado por qualquer fabricante. E é 
exatamente o fato de ser aberto que torna o LLDP tão atraente. Em uma rede composta de 
elementos de múltiplos fabricantes, o CDP é praticamente inútil. Entra em cena, então, o LLDP. 
LLDP usa frames Ethernet para transporte das informações entre vizinhos. Os 
dispositivos adotam um endereço MAC multicast especial (0180:c200:000x, onde “x” pode ser 0, 
3 ou E). Diferentemente de frames multicast tradicionais, estes endereços MAC multicast não 
são propagados pelos switches, ficando restritos apenas aos elementos diretamente conectados. 
Se formos comparar, uma das vantagens do CDPsobre o LLDP é que o CDP opera 
também sobre outros tipos de enlaces (como serial), e não apenas Ethernet. Por outro lado, 
LLDP oferece uma flexibilidade maior em termos da quantidade de informações que podem ser 
transportadas. LLDP usa o formato TLV (Type, Lenght, Value) para codificar as informações 
transportadas e suporta a incorporação de TLVs customizadas (type 127), o que flexibiliza 
muito o processo de definir quais informações que serão transportadas. Adicionalmente, LLDP 
disponibiliza uma extensão chamada MED (Media Endpoint Discovery) que permite a coleta de 
informações adicionais como VLAN ID, prioridade L2, configurações de QoS (Diffserv), device 
location discovery (muito útil em sistemas que usam informações de presença, como telefonia e 
messaging) e gerenciamento de inventário (transporte de informações como fabricante, versões 
de SW e HW, serial number e outras). 
Bom, chega de teoria. Vamos aprender como configurar LLDP em um elemento Cisco. 
Antes de tudo, saiba que LLDP, diferentemente do CDP, não se encontra ativado por padrão. 
Precisamos, portanto, ativar o LLDP em todos os elementos que dependerão deste protocolo 
para a coleta e envio de informações: 
 
A segunda etapa é definir quais informações serão encaminhadas para o vizinho. Se nada 
for especificado, LLDP passará aos vizinhos basicamente as mesmas informações que o CDP 
passaria. Eis as opções: 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 20 
 
 
Por fim, se desejarmos restringir o tráfego LLDP em certas interfaces, isso pode ser feito 
da seguinte forma: 
 
Basta adicionar o “no” ao comando para desabilitar o envio ou o recebimento (ou ambos) 
de LLDP na interface selecionada: 
 
Ou ainda restringir o envio à TLVs específicas: 
 
Uma vez que tudo esteja configurado, vamos colocar o protocolo à prova. Eis a “cara” do 
protocolo LLDP em ação: 
 
Ou use o modo “detail” (sim, como no CDP): 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 21 
 
 
Como se pode notar, as informações enviadas por padrão são basicamente as mesmas que 
o CDP usa. A grande diferença é que podemos usar o LLDP para buscar informações de 
elementos não-Cisco (e vice-versa). 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 22 
 
Capítulo 11 (exclusões do capítulo) 
11 Redes e Protocolos WAN 
Não estudar FRAME-RELAY. Este tópico foi removido do novo exame. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 23 
 
13 Tópicos Adicionais 
13.1 Tópicos Abordados 
 Qualidade de Serviço (QoS); 
 Computação na Nuvem; 
 Software-defined Networks (SDN); 
 
A partir do exame 200-125, a Cisco passou a cobrar conhecimentos básicos sobre 
qualidade de serviço (QoS), Cloud Computing e SDN. Segundo o blueprint do exame publicado 
pela própria Cisco, não haverá cobrança de nada relacionado à configuração, nestes tópicos. 
Apenas conhecimentos teóricos básicos. A adição destes tópicos é muito bem-vinda já que 
profissionais de redes precisam ao menos saber do que se tratam e quais os conceitos por trás 
dos mesmos. Vamos a eles! 
 
13.2 Qualidade de Serviço (QoS) 
Quando TCP/IP ainda engatinhava, não existia o conceito de redes multisserviço. Cada 
serviço trafegava em sua própria rede, com seus protocolos e controles completamente 
apartados uns dos outros. As redes, nesta época, eram criadas aplicando-se o modelo 
determinístico, que – como o nome sugere - determinava a dedicação e especialização dos 
circuitos utilizados para cada serviço. Não havia, portanto, competição por banda entre serviços 
distintos. Paralelamente, dados formatados em pacotes começavam a ser escoados pela 
novíssima infraestrutura IP, criada em cima do modelo estatístico – que pregava o amplo 
compartilhamento dos recursos em prol da flexibilidade, desempenho e controle de custos. 
Serviços como voz, por exemplo, seguiam sendo transmitidos via redes determinísticas como o 
sistema telefônico legado (PSTN). Vídeo, por sua vez, era propagado via radio frequência ou 
pelo ar (TV aberta) ou por cabos coaxiais (TV por assinatura). Naquela época, ninguém sequer 
cogitava a possibilidade de fundir todos estes diferentes serviços – com diferentes requisitos - 
em uma mesma infraestrutura de transporte. Bom, as coisas evoluíram e os serviços 
convergiram. Hoje, o sistema telefônico, por exemplo, é basicamente centrado em redes IP. 
Ainda que nas pontas a voz ainda seja transmitida por meio de modulação PCM, no core das 
redes modernas de telefonia temos o protocolo IP transportando voz (Voz sobre IP). Vídeo 
segue um padrão semelhante. Radio frequência, pouco a pouco, vai sendo substituída por 
transporte IP (Vídeo sobre IP). Hoje, muitas operadoras de TV por assinatura já entregam o 
sinal de vídeo na casa dos assinantes em cima de redes IP. Serviços como o NOW, da NET, Vivo 
Play, da Vivo e Netflix são exemplos disso. Portanto, a tal convergência digital, enfim, parece 
ter chegado com tudo. 
O problema de termos todos estes serviços sendo transportados pelo protocolo IP é que 
redes IP são, conceitualmente, redes compartilhadas (modelo estatístico, lembra?). Se há 
compartilhamento não há dedicação de recursos e, portanto, a competição por banda entre os 
serviços pode acontecer. Isso é ruim para os serviços se não soubermos como tratar cada um 
deles de forma diferenciada. Serviços prioritários – como voz e vídeo, por exemplo – devem ter 
preferência no uso dos recursos (banda). Se possível, poderíamos até dedicar uma certa 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 24 
 
quantidade de recursos para determinados serviços. Então, outros serviços – menos prioritários 
– poderiam competir pelos recursos remanescentes. Parece uma boa idéia? Pois é exatamente 
isso o que QoS implementa: A diferenciação, classificação e tratamento de pacotes IP. 
QoS caracteriza a capacidade de tratar de forma diferenciada fluxos ou classes de tráfego 
com características e requisitos diversos e providenciar diferentes níveis de garantia de entrega 
(largura de banda, atraso, perdas) de forma consistente e previsível. Para isso, deve ser possível 
medir e quantificar o comportamento de uma rede, de forma objetiva, com base num conjunto 
limitado de parâmetros de desempenho. 
NOTA: É importante frisar que QoS apenas faz sentido em redes onde há 
compartilhamento de recursos e competição por banda. Por exemplo, se você monitora todos os 
seus recursos de rede (links, portas, etc) e verifica que historicamente jamais a utilização 
ultrapassa 70%, podemos inferir que não há escassez de banda e, portanto, não vai haver 
competição por este recurso. Em cenários como este, a aplicação de QoS não fará qualquer 
diferença. 
 
13.2.1. Componentes de Qualidade de Serviço 
Para que QoS seja passível de implementação, antes de mais nada, é preciso conhecer as 
necessidades, objetivos, métodos de aferição da qualidade de serviço contratada e tempos de 
recuperação do serviço, em caso de interrupções não programadas. Os documentos que 
definem estes parâmetros são conhecidos como Service Level Agreement (SLA) e Service Level 
Specification (SLS). 
Apesar de o SLA ter se tornado um jargão bastante conhecido e utilizado, é comum 
encontrar documentos mal elaborados, com falta de informações e definições confusas até para 
o próprio provedor de serviços. Claramente, isso não é bom nem para o provedor, e nem para o 
assinante. 
O SLA é muito mais do que um documento descrevendo prazos de atendimento e 
resolução de chamados. Trata-se de um acordo que deve deixar claro todas as garantias que o 
provedor de serviço oferece em relação aos serviços que foram contratados, e a forma como 
estes níveis de serviço serão medidos, reportados e continuamente melhorados. Deve ser, assim, 
um ciclo contínuo, sempre buscando não apenas a manutenção do nível deserviço, mas sua 
melhoria. 
Um bom SLA deve ser capaz de endereçar pelo menos cinco pontos básicos: 
1. O que – Quais serviços estão sendo objetos do SLA em questão? Contextualizar o 
serviço já na primeira parte do documento, por exemplo, torna-se fundamental. Aqui 
também se pode fazer referência ao Catálogo de Serviços. Também é importante definir 
as exclusões, ou seja, as situações em que o SLA em questão não é aplicável. Um dos 
assuntos mais comumente deixados de lado é a definição do “Stop SLA” (ou pausa no 
SLA), onde deveriam ser considerados os períodos em que os casos estão sob tratamento 
do suporte do próprio assinante, ou seja, o provedor não deveria assumir o ônus por 
indisponibilidade durante este período de tempo. Exemplo: Janelas de manutenção. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 25 
 
2. Quando – Neste ponto deve ser definido o percentual de disponibilidade do serviço, o 
horário do serviço (período em que deve estar disponível, por exemplo: em horário 
comercial, 24×7, etc.), o horário do suporte ao serviço (Service Desk por exemplo). 
Importantíssimo também considerar condições de exceção, como feriados, finais de 
semana, etc. 
3. Quanto – Esta pergunta não tem relação com valor a ser pago pelo serviço – algo que, 
normalmente, já se encontra definido no Catálogo de Serviços - mas sim em qual 
quantidade e com qual desempenho o serviço deverá ser entregue. Ou seja, os requisitos 
de serviço, especificamente. Exemplos: Classes de serviço contratadas e respectivas taxas 
de transmissão, atraso máximo, jitter, número máximo de transações simultâneas, 
número máximo de usuários concorrentes, etc. 
4. Como – Este ponto é amparado por um documento chamado de SLS (Service Level 
Specification). É no SLS que o detalhamento de como o que foi definido nos pontos 1 a 3 
será efetivamente alcançado e verificado. O SLS define os objetivos de desempenho, os 
métodos para aferição dos mesmos em intervalos de tempo pré-determinados, as 
definições técnicas das classes de serviço disponíveis e contratadas, etc. Adicionalmente, 
este ponto deve definir: 
o Papéis e responsabilidades - Uma boa prestação de serviço exige que não 
somente o provedor, mas também o cliente cumpram alguns deveres. Assim, é 
importante definir aqui, por exemplo, as limitações do serviço contratado. Um 
exemplo: O serviço não suportará o encaminhamento de frames com MTU superior a 
1600 bytes. 
o Mecanismos de suporte ao Cliente - Neste tópico, algumas informações 
importantes como os possíveis canais de contato do cliente com o Service Desk, 
os tempos de resposta para cada tipo de caso de acordo com os critérios de 
priorização, matriz de escalonamento, etc., devem ser incluídas. 
o Reporte e análise crítica do serviço - Acordos de Nível de Serviço deveriam ser 
claros quanto à periodicidade e a forma como os níveis de serviço serão medidos, 
reportados, analisados criticamente junto ao assinante e continuamente 
melhorados. Este momento é uma excelente oportunidade não só para identificar 
os pontos falhos na entrega de serviços, mas também oportunidades de novos 
negócios. Vale lembrar que este item é, inclusive, um requisito colocado pela 
norma ISO/IEC 20.000. 
o Canais de Reclamação - Ombudsman, ouvidoria, etc. É importante mencionar 
um canal onde o cliente possa reclamar caso não esteja satisfeito com o serviço, e 
garantir que será dado um tratamento adequado a esta reclamação. 
o DRP (Disaster Recovery Plan) – Se aplicável, deve ser explicitado no documento 
o plano de continuidade de serviços no advento de uma situação que fuja 
completamente do controle (ex: um terremoto). Aqui, o provedor deve deixar 
claro quais as medidas contingenciais existentes para o serviço contratado (se 
existirem, claro). 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 26 
 
5. Imprevistos e ajustes – Um SLA é um documento vivo. Deve ser constantemente revisto 
e atualizado, de forma a refletir da melhor forma os interesses de ambas as partes. 
Assim, um SLA definido no ano passado pode não ser mais adequado para as 
necessidades do cliente ou para a realidade da operadora. Isso não pode ser esquecido. 
13.2.2. Processo de encaminhamento de pacotes em uma rede 
O processo normal de encaminhamento trata todos os pacotes (ou frames) como iguais, e 
os aloca em uma mesma fila (queue ou buffer) para serem encaminhados. Em redes Ethernet, por 
exemplo, esta fila adota o mecanismo FIFO (First In First Out). Ou seja, os frames são 
encaminhados de acordo com a ordem em que chegam na interface. Com os requerimentos 
diferenciados que algumas aplicações modernas demandam, este comportamento não é o ideal, 
podendo ocasionar uma série de problemas como alta latência, jitter, perda de pacotes e 
utilização ineficiente da largura de banda disponível (ex: frames de aplicações com baixa 
prioridade sendo encaminhados antes de frames de aplicações críticas e consumindo recursos 
valiosos de rede). 
Pontos chaves do QoS 
Os fatores que determinam a qualidade em uma transmissão são: 
 Latência (delay) 
 Jitter (variação da latência) 
 Perda de pacotes (packet loss) 
 Banda passante 
Latência 
A latência (ou delay) é o tempo despendido entre o primeiro bit de um frame ser 
transmitido e o último bit deste frame ser recebido no destino. As taxas de delay são medidas 
em micro ou milissegundos. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 27 
 
Jitter 
Conhecido como “Variação de Delay”, ou seja, é a variação do atraso entre frames 
consecutivos. Em tese, quanto menor o Jitter maior a prioridade de encaminhamento daquele 
determinado fluxo de frames, já que os frames estarão bastante próximos. 
O Jitter pode ser suavizado através de técnicas de compressão de dados, priorização e 
enfileiramento. 
É importante lembrar que determinadas aplicações são mais sensíveis ao delay e ao jitter 
do que outras. Assim, uma aplicação de correio eletrônico, por exemplo, não sofrerá o mesmo 
impacto sobre a variação da latência que uma aplicação de telefonia IP. 
Perda de pacotes 
Mesmo com a aplicação das mais modernas técnicas de QoS, a perda de pacotes, muitas 
vez, é algo inevitável. Isso porque a capacidade de uma infraestrutura de redes não é infinita. 
Um assinante terá garantia de transmissão apenas sobre o que ele contratou (e está especificado 
no SLA). Qualquer transmissão que exceda o contratado poderá sofre descartes e perdas. 
Adicionalmente, frames ou pacotes com problemas de formatação ou sequenciamento também 
poderão sofrer descarte no processo de transmissão. Abaixo encontram-se listados os principais 
mecanismos de controle de perda de pacotes: 
 Controle de Bits com Erros: Mecanismo que varia de protocolo para protocolo e 
visa a detecção de frames / pacotes corrompidos no processo de transmissão. No 
TCP, por exemplo, existe o controle de FCS (Frame Check Sequence); 
 Classes de Serviços, perfis de banda e políticas de descarte – Definições de classes 
de serviço, classificação e marcação de determinados frames ou pacotes para as 
classes de serviço definidas. Se o recurso configurado para uma classe for exaurido 
durante o processo de transmissão, pacotes podem ser descartados (dependendo 
da ação definida para aquela classe). 
 Especificamente focado em redes VoIP, existe o mecanismo CAC (Call Admission 
Control) que verifica a disponibilidade da rede de dados antes de estabelecer uma 
nova chamada, garantindo assim a qualidade da mesma. 
Bandwidth (banda passante) 
Refere-se ao número de bits por segundo que pode, inteligentemente, ser expedido para 
obtenção de sucesso na entrega do frame ou pacote. A especificação de taxa de transmissão em 
redes Ethernet é feita por meio da definição do CIR e EIR. 
13.2.3. Modelo operacional de redes baseadas em QoS 
Definição de tipos de tráfego e prioridades,classificação, policing, shapping e rate-
limiting são peças fundamentais para que uma rede seja capaz de oferecer o transporte de 
serviços de forma diferenciada. 
1) Definição de tipos de tráfego, prioridades e recursos (banda): Esta etapa deve constar 
de forma clara nos documentos SLA e SLS. O assinante, muitas vezes em conjunto com o 
operador, deve identificar quais são as aplicações críticas e não críticas em sua rede, e 
estabelecer filas de prioridade para cada tipo de tráfego. Normalmente, não mais de 4 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 28 
 
tipos de tráfego serão mapeados (na verdade, a limitação do número de tipos de tráfego 
que podem ser mapeados fica do lado da operadora, deve estar explícito no documento 
SLA). Ex: 
 
Uma vez definidos os tráfegos diferenciados, é preciso identificá-los (marcá-los) para 
que sejam alocados nas respectivas filas. 
2) Identificação (marcação) de tráfego: Tarefa de identificar diferentes tipos de tráfego 
com base em critérios pré-definidos. Os critérios podem ser diversos, como MAC 
address de origem ou destino, VLAN ID, Endereço IP de origem ou destino, aplicação 
(portas TCP/UDP ou NBAR), protocolo, etc. 
 
3) Policing: Consiste na definição das políticas que atuarão sobre o tráfego identificado e 
marcado. As condições verificadas são: Conform, Exceed e Violete. Para cada uma delas, 
uma ação pode ser tomada: 
 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 29 
 
4) Shapping: A diferença primordial entre shapping e policing (ítem 3) é que policing 
permite o comportamento de rajadas, enquanto shapping, não. Shapping implica na 
existência de uma fila e em uma quantidade suficiente de memória (buffer) para 
encaminhamento dos pacotes enfileirados, enquanto o processo de policing, não. 
Adicionalmente, shapping apenas pode existir no sentido OUTBOUND, enquanto 
policing pode atuar também no sentido INBOUND. 
 
Shapping x policing (fonte: Cisco) 
5) Rate-limit – Rate-limit pode ser implementado como uma função do policing ou de 
forma independente, e permite a limitação da taxa de transmissão no sentido IN ou OUT 
em uma interface física ou lógica, baseada em alguns critérios (como MAC address, 
endereço IP, etc). A Cisco define o CAR (Commited Access Rate) como uma prática 
comum para aplicação de rate limit. 
Mecanismos de controle e inibição de congestionamento 
QoS usa o gerenciamento de filas (queue) para priorizar determinados tipos de tráfego, de 
acordo com a marcação contida nos frames (L2) ou nos pacotes (L3). Vários métodos são 
definidos mas nem todos são suportados por todos os elementos de rede. Alguns apenas 
encontram-se disponíveis em elementos L3, por exemplo. Outros, apenas em modelos high-end. 
Eis alguns destes métodos: 
 FIFO (First In First Out) – Talvez o mais conhecido, este é o método padrão 
adotado quando não há configurações QoS na rede. Neste método, o primeiro bit 
que entra na fila é o primeiro a sair. Este método não implementa qualquer tipo de 
classificação ou priorização. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 30 
 
 Fair Queueing - O algoritmo Fair Queueing determina a organização das 
mensagens em fluxos e, para cada fluxo, é alocado um canal. A ordem na fila é 
determinada pelo último bit que atravessa o canal. Este método provê uma 
alocação mais justa de banda entre fluxos de dados concorrentes. 
 
Fair Queueing (fonte: Cisco) 
 Weighted Fair Queueing (WFQ) - Variante do Fair Queuing, WFQ é um método 
proprietário Cisco e adiciona ao cálculo feito pelo Fair Queuing as marcações e 
suas prioridades, organizando a fila de forma a escoar, antes, o tráfego marcado 
como prioritário. 
 
Weighted Fair Queueing (fonte: Cisco) 
 Priority Queueing – Neste método, o tráfego de entrada é classificado em um dos 
quatro níveis de prioridade: alta, média, normal e baixa. Os pacotes que por 
ventura não estejam devidamente identificados são marcados como baixa 
prioridade e encaminhados apenas quando não houver pacotes nas filas de 
prioridade mais elevada. Se incorretamente configurado, este método pode trazer 
problemas, já que pacotes classificados como baixa prioridade podem sofrer com a 
latência e, em casos extremos, até mesmo não serem encaminhados. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 31 
 
 
Priority Queueing (fonte: Cisco) 
 
 Custom Queueing – Este método permite uma alocação de banda (em %) para 
cada uma das 16 filas possíveis. As filas são ordenadas ciclicamente onde, para 
cada fila, é enviada a quantidade de pacotes referente à parte da banda alocada 
antes de passar para a fila seguinte. Um contador configurável é associado a cada 
fila e estabelece quantos bytes devem ser enviados antes da próxima fila ser 
considerada. 
 
Custom Queueing (fonte: Cisco) 
 
Outros métodos: 
 Class-Based Weighted Fair Queue (CBWFQ) – Método Cisco, bastante popular 
pela flexibilidade disponibilizada. Adiciona ao já visto WFQ o suporte a classes de 
tráfego definidas pelo usuário. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 32 
 
 Weighted Random Earlier Detection (WRED) – Mecanismo de prevenção e 
inibição de congestionamento. Procura informar o quanto antes o lado origem da 
conexão TCP sobre eventuais congestionamentos na rede através de um 
mecanismo de descarte aleatório de pacotes, forçando o outro lado a reduzir a taxa 
de transmissão. 
 
13.2.4. QoS de camada 2 x QoS de camada 3 
Qualidade de serviço pode ser implementada tanto na camada 2 (frames) quanto na 
camada 3 (pacotes). O que difere um do outro, basicamente, é o cabeçalho que será processado 
para a extração das informações de QoS. No caso da identificação de frames (camada 2), o 
campo PCP (Priority Code Point, também conhecido como PRI) do cabeçalho IEEE 802.1Q é 
utilizado. No caso de QoS sobre pacotes IP, o campos ToS (Type of Service) do cabeçalho IP é 
usado para as marcações de QoS. 
 
QoS na camada 2 (CoS) 
Apesar de serem definições bastante distintas, não raro CoS é confundido com QoS. 
Classe de Serviço (CoS) é o nome pelo qual o campo PRI ou PCP do frame Ethernet é 
conhecido. A figura abaixo ilustra o cabeçalho Ethernet com o campo usado para a marcação de 
frames (PRI). 
 
O campo PRI possui 3 bits de extensão e permite, portanto, a definição de até 8 (2^3) classes 
distintas de serviço. 
QoS em redes MPLS (EXP) 
Em redes MPLS, a marcação de pacotes ocorre no campo EXP do cabeçalho MPLS. O 
campo EXP, assim como o campo CoS em redes Ethernet, possui apenas 3 bits, o que possibilita 
a definição de até 8 tipos de serviço distintos em uma rede MPLS. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 33 
 
QoS na camada 3 (ToS) 
A marcação e identificação de pacotes na camada 3 é realizada por meio do campo Type 
of Service (ToS), do cabeçalho IP, como ilustrado à seguir. 
 
Fonte: http://what-when-how.com/ 
É importante notar que o campo em si possui 8 bits de extensão, entretanto, existem duas 
formas distintas de fazer a identificação: 
 IP Precedence (IPP) – Implica em utilizar apenas os 3 bits mais significantes do 
campo ToS para a marcação de pacotes. Desta forma, temos apenas 8 
possibilidades de marcação. É considerada a forma “antiga” de marcar pacotes IP, 
dada a sua limitação em termos de combinações possíveis de tipos de serviços 
(apenas 8). 
 Differentiated Service Code Point (DSCP) – Parte da definição do modelo 
DiffServ, faz uso de 6 bits para a marcação de pacotes (apenas 6 e não 8, pois os 
bits 0 e 1 são reservados e não podem ser usados no processo de marcação). 
 
13.2.5. Mapeamento CoS x EXP x ToS 
Normalmente, a questão que surge é: Qual seria a vantagem em se adotar a classificação 
DiffServ, que utiliza 6 bits para diferenciaçãode serviços, enquanto Ethernet e MPLS usam 
apenas 3 bits (CoS e EXP, respectivamente)? 
A resposta é relativamente simples: MPLS é uma tecnologia amplamente utilizada no core 
das redes IP. Assim, não se espera que dezenas de serviços precisem ser diferenciados e 
classificados nesta hierarquia da rede. Quando nos movemos mais para a borda, entretanto, o 
volume de serviços distintos tende a aumentar, e a classificação granular destes pode ser 
benéfica. Assim, a adoção da marcação DSCP, nas bordas, faz sentido. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 34 
 
Isso não quer dizer, necessariamente, que a adoção da marcação Diffserv seja uma 
obrigatoriedade. Se um provedor de serviço não planeja oferecer uma gama muito aberta de 
classes de serviço, este pode adotar o modelo Diffserv, porém, utilizando apenas os 3 bits IPP 
(IP Precedence). Fazendo isso, o mapeamento CoS (Ethernet) x ToS (IP) x EXP (MPLS) fica 
bastante transparente, já que os bits equivalem na proporção 1:1. Exemplo: 
 
E se adotarmos a marcação DSCP de 6 bits e precisarmos mapeá-la para outra, que usa apenas 3 
(como Ethernet CoS, MPLS EXP ou IP Precedence), ou vice-versa, como fazer? A dica é observar 
o padrão de bits e trabalhar com ele. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 35 
 
Repare que no mapeamento acima (apenas uma sugestão, diga-se de passagem), estamos 
focando em manter o padrão dos 3 bits mais significativos (mais à esquerda) mapeados com os 
valores do campo IP Precedence. 
A implicação deste mapeamento é que estamos tendo de encaixar 21 classes de serviço 
distintas em apenas 8 marcações. Assim, teríamos algumas classes distintamente classificadas 
via DSCP mapeadas para um mesmo CoS, IPP ou EXP. 
OBS: Não é necessário saber estas tabelas de conversão para o exame. 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 36 
 
13.3 Computação na Nuvem (Cloud Computing) 
Cloud Computing é um termo que está na moda, e é importante saber que ele pode ter 
significados distintos para pessoas e situações distintas. Olhando de forma simplista, Cloud 
Computing significa que, ao invés de você manter toda a infra localmente (HW e SW), parte 
desta infra será disponibilizada para você como um serviço, composto por um conjunto de 
elementos que você – em determinadas situações - não tem idéia de onde estão ou mesmo de 
como eles encontram-se configurados ou conectados entre si (e daí o termo “nuvem”). Embora 
alguns considerem ser apenas mais uma forma de outsourcing, Cloud Computing é muito mais 
do que isso. 
Talvez, uma das melhores formas de explicar Cloud Computing seja por meio de 
exemplos. Eis alguns que fazem parte de nosso dia-a-dia: 
 Cloud drives (ex: Google Drive, Apple iCloud, Dropbox, etc) 
 Google Docs 
 Microsoft Office 365 
 Serviços de e-mail (Gmail, Outlook, etc) 
Em uma escala mais corporativa, temos serviços como: 
 ERP (como SAP e Oracle) 
 CRM 
 Controle de pessoal e Folha de Pagamento 
 Sistema de contabilidade 
Se você usa algum destes serviços, já parou para pensar onde eles encontram-se 
hospedados e como estão configurados? Imagino que não. E é exatamente este um dos objetivos 
de Cloud Computing: A abstração da complexidade para o usuário final. 
 É curioso pensar que Cloud Computing não é algo novo. Já existe há umas duas 
décadas, pelo menos. Nunca foi muito presente, pois a tecnologia não permitia. Agora, com as 
redes operando em altas velocidades mesmo em nossas casas, Cloud Computing deslanchou. 
Percebam que dois fatores foram essenciais para isso: A evolução do poder computacional e o 
aumento da largura de banda disponibilizada de forma geral. 
 
Aumento do poder computacional e virtualização 
Em 1965, Gordon Moore (co-fundador da Intel) publicou um artigo constatando que a 
miniaturização vinha permitindo dobrar o número de transistores em circuitos integrados a 
cada ano (enquanto o custo permanecia – de certa forma - constante). Moore previu que esta 
tendência deveria se manter por, pelo menos, mais 10 anos. Em 1975 (precisamente dez anos 
depois), Moore atualizou sua previsão, profetizando que o número de transistores passaria a 
dobrar a cada 24 meses, dando origem a famosa “Lei de Moore”. E esta lei tem sido seguida 
quase que a risca pelos fabricantes de processadores (no exemplo abaixo, a própria Intel): 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 37 
 
 
O poder de processamento dos computadores modernos é muito maior do que a maioria 
das aplicações necessita. E isso cria uma ociosidade monstruosa – e cara. Segundo a VMware, a 
maioria dos servidores – se usados na forma convencional - opera com menos de 15% da 
capacidade de processamento, o que leva à proliferação de servidores com capacidade ociosa e 
ao aumento da complexidade do ambiente. O processo de virtualização de servidores resolve 
essa ineficiência, pois permite que vários sistemas operacionais sejam executados como 
máquinas virtuais, cada uma com acesso a recursos como memória, disco e CPU oferecidos pela 
máquina física. O gerenciamento dos recursos fica sob responsabilidade de um sistema 
executado na máquina física chamado de hypervisor. Pense no hypervisor como um síndico da 
máquina física. Ele é quem determina quanto de recurso (memória, disco, CPU e rede) cada 
máquina virtual terá à disposição em um dado momento. As figuras 13.1 e 13.2 ilustram o 
modelo tradicional e o modelo virtualizado. 
 
 
Figura 13.1 – Operação tradicional de servidores, sem virtualização 
 
 
Figura 13.2 – Operação com servidores virtualizados 
 
Esta abordagem traz uma série de benefícios, como: 
 Consolidação dos servidores (vários servidores distintos operando em uma única 
máquina física) 
 Melhor utilização do hardware, evitando o desperdício. 
 Gerência centralizada e descomplicada. 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 38 
 
 Mobilidade (mover uma máquina virtual de uma máquina física para outra é 
algo que pode ser feito em questão de minutos). 
 Confiabilidade (é possível manter um banco de snapshots de cada máquina 
virtualizada, tornando muito rápido o processo de recuperação de um estado anterior). 
 Automação e orquestração 
 
Atualmente, os sistemas de virtualização (hypervisors) mais conhecidos são os ilustrados 
abaixo: 
 VMware vCenter 
 Image Microsoft HyperV 
 Image Citrix XenServer 
 Image Red Hat KVM 
 
Em termos de servidores físicos, A maioria dos fabricantes de servidores, hoje, suporta 
virtualização. A Cisco – com sua linha de servidores UCS – é um deles. 
 
Tipos de virtualização 
Atualmente, quatro tipos principais de virtualização são claramente definidos. São eles: 
 Virtualização de servidores - discutida anteriormente. 
 Virtualização de desktops – Consiste na implantação de desktops como serviços 
virtualizados oferece a oportunidade de responder com mais rapidez a mudanças 
de oportunidades e necessidades. É possível, por exemplo, reduzir custos e 
melhorar o serviço fornecendo de maneira fácil e rápida desktops e aplicativos 
virtualizados em tablets iPad e Android a filiais, funcionários externos e 
terceirizados e trabalhadores móveis. 
 Virtualização de rede - Reprodução completa de uma rede física via software. 
Algo semelhante ao que o GNS-3 faz, mas em uma escala de produção e com alto 
desempenho. A VMware, por exemplo, oferece ferramentas de virtualização de 
rede para permitir a interconexão de máquinas virtuais e hypervisors. 
 Virtualização de storage - Grandes volumes de dados e aplicativos em tempo real 
demandam novos níveis de armazenamento. A virtualização de armazenamento 
permite a abstração dos discos físicos, combinando-os em pools de 
armazenamento de alto desempenho e fornecendo-os como serviço. 
Como fica claro, o processo de virtualizaçãoé essencial para a criação de ambientes de 
computação na nuvem, que exigem flexibilidade, elasticidade, disponibilidade, confiabilidade e 
desempenho. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 39 
 
Atrativos da computação na nuvem 
Existem outros motivos – além do aumento do poder computacional e da disponibilidade 
de banda – para cloud computing estar se popularizando tanto e tão rápido. Eis alguns deles: 
 É descomplicado (para o usuário final). 
 Os serviços oferecidos são totalmente gerenciados. 
 Serviços e infra podem ser criados sob demanda e rapidamente e, da mesma 
forma, podem ser facilmente desativados. 
 O ambiente pode ser público, privado (próprio) ou híbrido. 
 Há uma enorme sinergia e economia de recursos. 
 É flexível e pode crescer rapidamente, se necessário. 
 
Tipos de computação na nuvem 
Hoje, temos bem definidos três tipos de ambientes de cloud computing: Público, privado 
e híbrido. Um quarto tipo vem ganhando popularidade no mundo residencial e de pequenas 
empresas, e foi batizado de “personal”. As diferenças básicas entre eles envolvem localização, 
propriedade e modelo de gerenciamento dos recursos. 
 Pública - A nuvem pública é aquela na qual os serviços e a infraestrutura são 
compartilhados. Estas nuvens normalmente oferecem um maior nível de 
eficiência, no entanto, elas também são mais vulneráveis (em termos de segurança) 
do que as nuvens privadas. O modelo público é uma boa opção quando a 
necessidade é padronizada e não requer infraestruturas complexas, com alto nível 
de customização e demanda de requisitos. Alguns dos Cloud Providers mais 
conhecidos: 
o Microsoft Azure 
o Amazon AWS 
o Google Cloud 
o VMWare vCloud 
o CloudSigma 
 Privada - Construída para atender a uma necessidade ou demanda específica do 
negócio, este modelo oferece um elevado nível de segurança e controle e é 
indicado quando controle, segurança e poder computacional exclusivo são 
fundamentais. 
 Híbrida – Uma combinação de ambas. Há componentes públicos e privados e 
ambos podem interagir. Assim, é possível termos servidores dedicados e 100% 
gerenciados via processos internos operando em conjunto com outros serviços 
oferecidos de forma compartilhada. 
 Personal – Pequenas estruturas que você pode criar e gerenciar em sua casa ou 
empresa. Ex: OwnCloud <owncloud.org>. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 40 
 
O modelo As-a-Service (AAS) 
O conceito AAS ganhou força com o aumento da popularidade dos serviços de 
computação na nuvem. No início, apenas Software-as-a-Service (SaaS) era oferecido. Hoje, 
outros tipos gozam de grande popularidade também, como por exemplo: 
 SaaS (Software-as-a-Service) – O início. Aqui temos as aplicações sendo oferecidas 
como serviços gerenciados. 
 IaaS (Infrastructure-as-a-Service) – Neste modelo, o cliente adquire o acesso aos 
elementos de infra como servidores, storage e até mesmo componentes de rede, e 
pode fazer o que bem entender com eles. 
 PaaS (Platform-as-a-Service) – Modelo em que o contratante tem a sua disposição 
uma plataforma pré-configurada para a realização de testes de conceito 
(desenvolvimento de um app, por exemplo). 
 NaaS (Network-as-a-Service) – Oferecimento de serviços de rede virtual pelo 
proprietário de uma infraestrutura física de rede. 
Vantagens do modelo AAS: 
 Baixo investimento inicial (CAPEX) 
 Flexibilidade 
 Rápido deployment 
 “Pay-as-you-grow” 
 SLAs (para serviços gerenciados) 
 
Desvantagens: 
 OPEX elevado 
 Dependência dos provedores de serviços (o processo de mudança de provedor 
pode ser complexo). 
 Menor nível de segurança 
 Conectividade ao provedor do serviço pode ser um problema 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 41 
 
13.4 Software-defined Networks (SDN) 
Um tópico bastante discutido atualmente, SDN passou a incorporar a lista de conceitos 
que é preciso conhecer para o exame CCNA R&S. SDN ganhou notoriedade nos últimos anos 
quando empresas com demandas massivas de movimentação de dados como Facebook, Google 
e Amazon perceberam que o modelo tradicional de transporte de dados não acomodava o perfil 
altamente dinâmico de seus ambientes. Peguemos o Facebook como estudo de caso, por 
exemplo. Os datacenters da empresa são colossais e altamente complexos. O Facebook adota 
ostensivamente modelos sofisticados de computação na nuvem e virtualização permitindo um 
uso mais eficiente dos recursos alocados e também a consolidação dos servidores. Até aí, nada 
fora do normal. O problema é que em ambientes gigantes e com alto grau de virtualização, 
recursos como servidores e storage – por serem virtualizados – podem mudar de lugar em um 
piscar de olhos. Para alcançar elevados níveis de desempenho, eficiência energética e 
disponibilidade, estes datacenters são configurados para encaminhar, processar e armazenar 
dados de forma descentralizada. E o modo tradicional de transporte de dados simplesmente 
não consegue acompanhar estas mudanças na velocidade necessária. Entra em cena redes 
definidas por software – SDN. 
Antes de qualquer coisa, vale ressaltar que SDN não é um novo protocolo de rede. SDN é 
um novo conceito de rede. Talvez por isso, muitos ainda torçam o nariz para ele. Afinal, SDN 
apresenta uma forma de ruptura com algumas coisas que aprendemos até aqui. A proposta do 
SDN é regida pelos seguintes pontos: 
 Separação dos componentes envolvidos no processo de encaminhamento dos 
frames 
 Análise das funções de cada componente 
 Otimização dos processos envolvidos 
 Definição de uma nova forma de fazer tudo funcionar 
O primeiro ponto envolve desacoplar os componentes participantes do processo de 
encaminhamento de dados. Vamos analisar o funcionamento de um roteador, por exemplo. Um 
roteador tem pelo menos dois componentes necessários para que o encaminhamento de pacotes 
ocorra: 
 Data plane (também conhecido como Forwarding plane) 
 Control plane 
Em alguns casos, temos também um plano adicional – o plano de gerência: 
 Management plane 
Vamos conhecer melhor as funções de cada um destes componentes para, então, entender 
como SDN sugere que o processo seja melhorado. 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 42 
 
Funções do Data Plane 
 Encapsular e desencapsular pacotes em frames na camada de enlace – 
basicamente, fazer a transposição de L2 para L3 e vice-versa. 
 Adicionar ou remover o cabeçalho 802.1Q (VLAN tag) 
 Identificar o MAC Address de destino na tabela MAC (em switches L2) 
 Identificar a rede do endereço IP de destino na tabela de roteamento (em 
roteadores e switches L3) 
 Criptografar os dados e adicionar um novo cabeçalho IP (quando VPNs estiverem 
em uso) 
 Alterar endereços IP de origem ou de destino (se NAT estiver em uso) 
 Descartar dados devido a filtros configurados (ex: ACLs ou switch port-security) 
Funções do Control Plane 
 Protocolos de roteamento (OSPF, BGP, EIGRP, etc) 
 MPLS Label Distibution Protocol (LDP) 
 IPv4 ARP 
 IPv6 NDP (Network Discovery Protocol) 
 Aprendizagem de MAC em switches 
 Spanning Tree Protocol (switches) 
 
 
 
Funções do Management Plane 
 Gerenciamento via Telnet, SSH, SNMP, CDP, LLDP, Syslog, etc 
 
 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 43 
 
Redes tradicionais x SDN 
Em redes tradicionais, o control plane é distribuido entre os elementos. Ex: Cada router 
tem sua instância OSPF, cada switch a sua instância STP, etc. 
Como existe esta distribuição, as informações precisam ser transmitidas de um elemento 
para outro (ex: updates de roteamento ou BPDUs encaminhadas entre os switches no processo 
de convergência STP). Neste processo, a convergência da rede ocorre. Para que tudo funcione 
de forma relativamente rápida, os elementosde rede contam com ASICs (processadores 
dedicados) para agilizar os processos intrínsecos ao data plane. Infelizmente, em redes muito 
dinâmicas (nas quais IPs e elementos mudam de lugar com frequência), o desempenho deste 
modelo operacional deixa a desejar. 
A principal proposta trazida pela arquitetura SDN é a separação entre o control plane e o 
data plane. SDN sugere que o data plane permaneça no elemento de rede, enquanto o control 
plane é removido dele. 
Você deve estar se perguntando: “Mas se retirarmos o control plane, como o elemento 
saberá o que fazer com o frame ou pacote que chegar até ele?”. Excelente pergunta. Vamos à 
resposta! 
SDN introduz a figura do controller – um elemento central – que passa a ser o responsável 
pelo control plane não de um elemento específico, mas da rede como um todo. O grau de 
centralização pode variar. É possível um cenário onde o controller realiza TODAS as funções do 
control plane ou apenas algumas. Ou mesmo um cenário onde apenas alguns elementos são 
gerenciados pelo controller, enquanto outros seguem com seus próprios control planes. 
 
Figura 13.3 – Arquitetura SDN (fonte: Cisco) 
 
Southbound Interfaces (SBIs) são usadas pelo controller para comunicar informações do 
control plane para os elementos. Não confunda o termo interfaces (o “I” em SBI), com portas. 
Interfaces, neste contexto, seriam métodos de interação. Exemplos de SBIs são: 
 OpenFlow (definido pelo Open Networking Forum (ONF) e open-source) 
 OpFlex (definido pela Cisco e usado no framework Application Centric 
Infrastructure – Cisco ACI) 
 Command Line Interface (CLI) – Método definido pela Cisco que permite o uso de 
Telnet, SSH e SNMP como formas de interação com os elementos. Implementado 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 44 
 
no framework Application Policy Infrastructure Controller Enterprise Module – 
Cisco APIC-EM). 
 
A função do controller é passar aos elementos de rede as informações de controle como 
rotas, tabelas de encaminhamento MAC, etc. Mas como os controllers sabem o que adicionar e 
onde? Eles usam o conceito de Northbound Interfaces (NBI) para isso (novamente, aqui, o 
termo interface define métodos de interação e não porta). NBIs são usadas para determinar, por 
exemplo: 
 A lista de todos os elementos SDN da rede. 
 As funções e capacidades de cada elemento. 
 As interfaces (portas) de cada elemento e o estado atualizado de cada uma delas. 
 A topologia (como os elementos encontram-se conectados entre si e via qual 
interface). 
 Configuração dos elementos, como endereços IP, VLAN Ids, etc. 
 
SDN e programabilidade 
Em SDN, toda a interação entre o controller e os elementos ocorre via interfaces de 
programação (SBI e NBI). Para esta interação ser possível, é preciso usar APIs (Application 
Programming Interface). Para que os controllers sejam capazes de programar os elementos de 
rede (adicionar rotas, etc), usa-se APIs específicas como RESTful APIs ou JAVA-based APIs. 
RESTful APIs permitem o uso de transações HTTP para envio de instruções ou coleta de dados 
e usam formas estruturadas de dados para isso, como JSON ou XML. 
 
Soluções SDN Cisco 
A Cisco oferece, hoje, três soluções SDN distintas. São elas: 
 Cisco Open SDN Controller (adota OpenFlow como SBI) 
 Cisco Application Centric Infrastructure (ACI) (adota OpFlex como SBI) 
 Cisco APIC Enterprise Module (APIC-EM) 
 
 
Compatibilização entre os livros CCNA 5.0 e CCNA 6.0 – Marco A. Filippetti 
 
Página | 45 
 
Cisco Application Centric Infrastructure (ACI) 
Implementação SDN Cisco que permite agrupar servidores e máquinas virtuais (VMs) 
com características semelhantes na forma de endpoints. Em cima disso, políticas são aplicadas 
definindo quais endpoints podem conversar com quais, QoS, segurança, etc. 
Uma vez que os agrupamentos de endpoints e políticas tenham sido definidas, o SDN 
controller pode acessar cada um dos elementos e popular as informações do control plane para 
que tudo funcione conforme planejado. Cisco ACI usa RESTful APIs como método NBI e 
OpFlex como método SBI. 
 
 
Figura 13.4 – Arquitetura Cisco ACI (fonte: Cisco) 
 
Cisco Application Policy Infrastructure Controller Enterprise Module (APIC-EM) 
Implementação “SDN-light” Cisco que permite usar switches Cisco que não ofereçam 
suporte SDN nativo (alguns modelos, pelo menos). Este modelo adota o controller APIC-EM e 
não oferece muita flexibilidade – na verdade, o control plane segue distribuído em cada 
elemento e o controller não irá programar suas tabelas. Assim, a solução APIC-EM, na verdade, 
apenas implementa um nível mais elevado de automação e oferece uma forma centralizada de 
administrar os elementos. O Controller usa o SBI para coletar informações dos elementos e usa 
APIs na NBI para reconfigurá-los, quando necessário. 
 
 
Figura 13.5 – Arquitetura Cisco APIC-EM (fonte: Cisco)