ApostilaCursoCCNPSWITCH300115v11 PDF

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.
br
DlteC do Brasil®
www.dltec.com.br
info@dltec.com.br | 41 3045.7810
DLTEC DO APOSTILA/E-BOOK DO CURSO CCNP SWITCH

BRASIL 300-115
Apostila/E-Book do Curso CCNP SWITCH 300-115

DlteC do Brasil®
Todos os direitos reservados©
Apostila/E-Book do Curso CCNP SWITCH Página 1

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.br
Sobre o E-book/Apostila
O presente material traz conteúdo teórico, comandos e configurações exigidos

no blueprint do exame Cisco CCNP SWITCH 300-115, porém temos que deixar
claro que não é um curso e sim uma adaptação do nosso material online
para e-book/apostila.
Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com

professores) e vídeo aulas não fazem parte desse e-book, pois são exclusivos
para alunos devidamente matriculados em nosso site oficial.

Direitos Autorais
Aviso Importante!
Esse material é de propriedade da DlteC do Brasil Ltda. e é protegido pela lei

de direitos autorais 9610/98.
É expressamente proibida cópia física ou em meio digital, reprodução parcial,

reprografia, fotocópia ou qualquer forma de extração de informações deste sem
prévia autorização da DlteC do Brasil conforme legislação vigente.
Seu uso pessoal e intransferível é somente para o cliente que adquiriu o

referido e-book/apostila.
A cópia e distribuição são expressamente proibidas e seu descumprimento

implica em processo cível de danos morais e materiais previstos na legislação
contra quem copia e para quem distribui, sejam cópias físicas e/ou digitais.
Copyright © 2015.

Índice
Capítulo 01 - Introdução .............................................................................................................. 5

Capítulo 02 - Redes com Switches Layer-2 .................................................................................... 8
Capítulo 03 - Implementando VLANs, Trunks e VTP .................................................................... 42
Capítulo 04 - Protocolo Spanning Tree ....................................................................................... 82
Capítulo 05 - Multilayer Switching ........................................................................................... 123
Capítulo 06 - Recursos de Alta Disponibilidade......................................................................... 148
Capítulo 07 - First Hop Redundancy Protocols - FHRP ............................................................... 170
Capítulo 08 - Segurança no Campus ......................................................................................... 203

Capítulo 01 - Introdução
Olá,
Essa apostila/E-Book é uma adaptação em

texto do nosso material online de estudo
(matéria online do curso CCNP SWITCH).
Alguns itens dessa nova revisão 300-115

do CCNP SWITCH são parte integrante do
CCENT e ICND-2, ou seja, do pré-requisito
que é o CCNA R&S, por isso alguns tópicos
aparecem a seguir na listagem fazendo
referência a esses materiais, pois estamos
seguindo a mesma linha de redação dos
materiais oficiais da Cisco.
A seguir você tem uma relação dos tópicos

da prova do CCNP SWITCH 300-115 versus
capítulos da apostila/e-book, sendo que
alguns que são pré-requisitos podem estar
relacionados ao CCENT, ICND-2 e CCNA
R&S.
Esperamos que você aproveite o material e

bons estudos.

Blueprint do CCNP SWITCH 300-115

Vamos começar esse material com o blueprint atual divulgado pela Cisco em seu site oficial
(www.cisco.com/go/certifications) e relacioná-los com os capítulos do e-book/apostila.
Procuramos cobrir todos os tópicos listados no atual blueprint e alguns tópicos que não estão
listados ainda podem cair na prova, por isso você encontrará assuntos que não estão listados
no Blueprint, mas acredite: "ainda estão sendo cobrados na prova atual", por isso estude todo
material contido nesse documento.
Tópico do Exame Apostila/E-Book
1.0 Layer 2 Technologies - 65%
1.1 Configure and verify switch administration

1.1.a SDM templates
Cap II
1.1.b Managing MAC address table
1.1.c Troubleshoot Err-disable recovery
1.2 Configure and verify Layer 2 protocols Caps III e IV
1.2.a CDP, LLDP Cap III
1.2.b UDLD Cap IV
1.3 Configure and verify VLANs
1.3.a Access ports
1.3.b VLAN database
1.3.c Normal, extended VLAN, voice VLAN
1.4 Configure and verify trunking
1.4.a VTPv1, VTPv2, VTPv3, VTP pruning
1.4.b dot1Q
Cap III
1.4.c Native VLAN
1.4.d Manual pruning
1.5 Configure and verify EtherChannels
1.5.a LACP, PAgP, manual
1.5.b Layer 2, Layer 3
1.5.c Load balancing
1.5.d EtherChannel misconfiguration guard
1.6 Configure and verify spanning tree
1.6.a PVST+, RPVST+, MST
1.6.b Switch priority, port priority, path cost, STP timers Cap IV
1.6.c PortFast, BPDUguard, BPDUfilter
1.6.d Loopguard and Rootguard
1.7 Configure and verify other LAN switching technologies
Cap VIII
1.7.a SPAN, RSPAN
1.8 Describe chassis virtualization and aggregation technologies
Caps II e VI
1.8.a Stackwise


2.0 Infrastructure Security - 20%
2.1 Configure and verify switch security features

2.1.a DHCP snooping
2.1.b IP Source Guard
2.1.c Dynamic ARP inspection
2.1.d Port security
2.1.e Private VLAN Cap VIII
2.1.f Storm control
2.2 Describe device security using Cisco IOS AAA with TACACS+ and
RADIUS
2.2.a AAA with TACACS+ and RADIUS
2.2.b Local privilege authorization fallback

3.0 Infrastructure Services - 15%
3.1 Configure and verify first-hop redundancy protocols

3.1.a HSRP
Cap VII
3.1.b VRRP
3.1.c GLBP

Capítulo 02 - Redes com

Switches Layer-2
Nesse capítulo estudaremos
os princípios e fundamentos Objetivos do Capítulo
de Redes com Switches, suas
tabelas, principais Ao final desse capítulo você terá estudado e
topologias e o princípio de deverá compreender:
 Operação de Switches L2 e
encaminhamento cobrados
introdução a Switches L3;
na revisão atual do CCNP  Tabelas CAM e introdução a TCAM;
SWITCH 300-115.  Templates SDM;
 Opções de conexão de Switches;
Aproveite o capítulo e bons  Tipos de portas e suas
estudos! configurações;
 Configurações padrões em switches
L2;
 Recuperação de erros em portas com
Error-Disable;
 Modelos de switches;
 Topologias de redes;
 Arquitetura em três camadas;
 Design de Campus de Pequeno,
Médio e Grande Porte;
 Enterprise Composite Model.
Sumário do Capítulo
1 Operação de Switches Layer 2 ______ 10

1.1 Encaminhamento de Quadros em
Switches L2 __________________________ 13
1.2 Funcionamento de um Switch Cisco
Catalyst L2 ___________________________ 14
1.3 Comandos para Verificar a CAM Table 16
1.1 Templates SDM - Switching Database
Manager ____________________________ 18
2 Padrões nos Switches Camada-2 e
Configurações de Portas ______________ 21
1.4 Opções de Conexões em Switches Cisco
Catalyst _____________________________ 21
1.5 Configuração Básica das Portas dos
Switches L2 __________________________ 23
2.1 Detectando e Resolvendo Erros em
Portas - Error Disable __________________ 26
2.1.1 Configurações e Mensagens de Erro _ 27
3 Modelos de Design de Rede ________ 29

1.6 Modelo Hierárquico em Três Camadas

29
1.6.1 Projeto de Campus de Pequeno Porte 32
1.6.2 Campus de Médio Porte __________ 33
1.6.3 Campus de Grande Porte __________ 34
1.6.4 Visão Geral da Infraestrutura do Data
Center 35
3.1 Exemplos de Switches Cisco e
Posicionamento no Modelo em Três Camadas
36
3.2 Enterprise Composite Model _______ 38

1 Operação de Switches Layer 2

Antes de começar a falar de VLANs vamos voltar um pouco na história dos dispositivos de redes
e lembrar como tudo começou até chegar aos switches de camada 2 (L2 ou Layer-2).
Tudo começa nos HUBs que são equipamentos que simplesmente copiam os bits que entram
em uma porta para as demais portas, necessitando do protocolo CSMA/CD para tratar os
efeitos das colisões, além disso utilizando apenas um dos quatro pares de fios que temos em
um cabo UTP, pois eles são half-duplex, o que dá aos hosts a possibilidade de transmitir ou
receber uma informação sem poder fazer as duas coisas ao mesmo tempo.
Veja a figura abaixo e note que quando o host F transmite uma informação para C TODOS os
demais hosts recebem uma cópia dessa informação, o que além de gastar banda da rede
também representa um risco de segurança, pois com um simples sniffer qualquer vizinho pode
espionar essa informação.
Como grandes domínios de colisão formados por redes com diversos HUBs comprometiam
demais o desempenho foram criadas as Bridges, dispositivos que possuem duas portas e
podem aprender o endereço MAC de cada host conectado ou “pendurado” a cada porta.
Com essa informação dos MACs conectados em cada porta a bridge monta uma tabela de
endereços MAC e toma uma decisão de passar ou não quadros entre cada um dos segmentos,
reduzindo as colisões na rede, porém em redes grandes elas acabaram tornando-se um
gargalo, pois essa filtragem é feita por software e traz atraso no encaminhamento dos quadros.
Essas brigdes são chamadas de “bridges transparentes”.
Veja a figura seguinte com um exemplo de uma bridge transparente. Note no exemplo que a
bridge aprende os MACs dos hosts conectados a cada porta a medida que eles se comunicam.
Com a tabela de endereços MAC completa a bridge é capaz de encaminhar quadros entre os
diferentes segmentos ou domínios de colisão e filtrar quadros que são para o mesmo domínio
de colisão. Por exemplo, quando o host 1 enviar um quadro para o host 5 a bridge não
encaminhará o quadro para o segmento-2 pois ambos os hosts pertencem ao mesmo domínio
de colisão (segmento-1). Ao passo que se o host 1 enviar um quadro para o host 7 a brigde
encaminha o quadro, pois os MACs estão conectados a segmentos diferentes.

Em um próximo passo foram criadas as brigdes multiporta (Multiport Bridges), os reais

precursores dos switches atuais. Essas bridges possibilitaram dividir a rede de HUBs em mais
domínios de colisão e reduzir mais ainda os efeitos delas, porém não as eliminaram por
completo, pois enquanto houver HUBs as colisões tem probabilidade de existir.
Veja a figura abaixo com um exemplo de bridge multiporta e veja que ela é muito semelhante a
uma bridge transparente, porém em sua tabela de endereços MAC (tabela de encaminhamento
ou forwarding table) vamos encontrar mais portas.
O switch é uma evolução da bridge multiporta, pois ele permite a conexão direta dos hosts às
suas portas e também a divisão lógica das portas em VLANs. Veja abaixo a representação de
um switch com VLANs criadas para separação de portas em diferentes domínios de broadcast
(vamos estudar mais sobre VLANs no próximo capítulo), veja que além da porta e o MAC a

tabela de endereços MAC do switch (CAM - Content Addressable Memory) contém também
a que VLAN essa porta/MAC está vinculada.
Além disso, permitem que os hosts conectem-se utilizando full-duplex, ou seja, utilizando um
par de fios do cabo UTP para transmitir (Tx) os dados e o outro para receber (Rx), eliminando
de vez as colisões nas redes e melhorando sensivelmente o desempenho da comunicação.
Em termos práticos, o que caracteriza um switch ser L2 ou L3 é o suporte ao roteamento IP que

não vem ativado por padrão em maioria dos switches Cisco. O comando que ativa o suporte a
roteamento é o “ip route” em modo de configuração global e em um switch L2 esse comando
não está disponível.
Outro detalhe importante é que as portas dos switches L2 todas estão com o comando
“switchport” ativado por padrão, em switches L3 é possível utilizar o comando “no
switchport” para converter uma porta L2 em uma L3, ou seja, converter em uma interface
roteada que pode receber um endereço IP e funcionar de forma similar a uma porta de LAN de
um roteador. Vamos voltar a esse assunto posteriormente quando tratarmos dos switches
multicamada.

1.1 Encaminhamento de Quadros em Switches L2
As três funções básicas de um switch camada-2 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.
Lembre-se que os switches são L2 porque 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 IPv4:
 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.
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 que não são cobertos pelo conteúdo da prova atual do CCNP SWITCH.
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. Para saber se temos um switch Cisco nessa porta basta utilizar o CDP.
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.
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.
1.2 Funcionamento de um Switch Cisco Catalyst L2
Muito do que estudamos anteriormente provavelmente não foi novidade, pois você já deve ter
visto no CCNA R&S ou CCENT/ICND-1 ou ICND-2, certo? Agora vamos um pouco além e
estudar outros detalhes sobre os switches Cisco Catalyst L2.
Vamos utilizar como base a figura abaixo onde Ingress Queues são as filas de entrada, Egress
Queues são as filas de saída e Egress Ports são as portas de saída.

O que acontece quando um quadro (frame) é recebido em uma porta do switch? Conforme a
figura acima ele é colocado em uma fila de entrada daquela porta. Essas filas contêm os
quadros que serão encaminhados e cada uma tem sua prioridade e nível de serviço diferente.
Os switches podem ser ajustados para que quadros mais importantes sejam processados antes
dos menos importantes, como no caso de pacotes de voz, por exemplo. Esses ajustes permitem
que o switch trate os tráfegos em caso de uma sobrecarga no tráfego, permitindo que serviços
mais urgentes continuem funcionando.
Do outro lado, quando um quadro já foi tratado pela fila de entrada e deve ser enviado para a
fila de saída, o switch deve saber para onde e como encaminhar o quadro. Três decisões
fundamentais devem ser tomadas pelo switch, uma é relacionada a encontrar a porta de saída
(consultar a tabela CAM) e duas tem haver com as políticas de encaminhamento.
Tudo isso é feito simultaneamente por blocos funcionais de hardware independentes dos
switches, vamos analisá-los abaixo:
 L2 Forwarding Table (CAM): essa é a tabela de endereços MAC que possui o MAC de
destino, porta de saída e VLAN que essa porta possui, sendo que se o endereço de saída
é encontrado na tabela a porta de saída e a informação de VLAN-ID são lidas da tabela.
Se o MAC não é encontrado esse quadro é marcado como flooding e será encaminhado a
todas as portas na mesma VLAN menos para que recebeu o quadro.
 Security ACLs: as ACLs podem ser configuradas nos switches para identificar frames
através dos endereços MAC, tipos de protocolos, endereços IP, protocolos e portas TCP
ou UDP. A TCAM ou Ternary Content-Addressable Memory contém essas ACLs
compiladas permitindo que a decisão de encaminhar ou não seja realizada com uma
única consulta.
 QoS ACLs: essas listas de controle de acesso são utilizadas para tomar decisões de
acordo com parâmetros de qualidade de serviço (QoS), realizar controles e políticas de
encaminhamento de tráfegos e marcação de parâmetros de QoS nos quadros de saída.
Nesse caso a TCAM também é utilizada para fazer com que tudo seja realizado em uma
única consulta.
Uma vez as consultas às tabelas CAM e TCAM seja finalizadas os quadros são colocados nas
filas de saída da porta correta. A fila de saída pode ser determinada também por valores de
QoS que estão configurados no quadro ou passados dentro desse quadro.
Uma coisa interessante sobre a tabela de encaminhamento ou CAM table é que além das
informações que falamos anteriormente um “time stamp” também é gravado para indicar a
quanto tempo essa informação está na tabela, pois se uma nova entrada com o mesmo MAC for
aprendida a mais antiga é apagada e a nova que ficará valendo na tabela para a mesma porta.
Além disso, por padrão essa informação é mantida por um tempo máximo de 300 segundos
(chamado de aging time), pois a tabela tem um volume máximo de endereços suportados e
entradas antigas e não utilizadas são apagadas para garantir que haja espaço suficiente para
atender a todas as portas. O comando para alterar esse valor segue abaixo, onde no exemplo
alteramos o valor de 300 para 299 em modo de configuração global. Não é aconselhado alterar
esses valores sem uma análise prévia minuciosa.
SW-DlteC-Rack-01(config)#mac address-table aging-time ?

<0-0> Enter 0 to disable aging
<10-1000000> Aging time in seconds
SW-DlteC-Rack-01(config)#mac address-table aging-time 299

SW-DlteC-Rack-01(config)#
No caso de loops de camada-2 onde um endereço MAC é aprendido alternadamente em duas ou

mais portas sequencialmente, pulando ou “flapping” rapidamente, o switch gera uma

mensagem avisando que aquele MAC está na condição de “flapping”, o que é um bom indicativo
de problemas com STP e loops de camada-2. Veja exemplo abaixo onde o MAC 000f.233b.8a80
está “pulando” entre as interfaces Fa1/0/9 e Fa1/0/8 em loop.
Switch#
*Mar 1 02:26:17.394: %SW_MATM-4-MACFLAP_NOTIF: Host 000f.233b.8a80 in vlan 1 is
flapping between port Fa1/0/9 and port Fa1/0/8
Em capítulos posteriores vamos estudar mais sobre o CAM e TCAM, assim como sobre os
switches multicamada (layer-3 ou multilayer).
1.3 Comandos para Verificar a CAM Table
O comando que permite visualizar a tabela de endereços MAC ou CAM Table é o “show mac
address-table” ou em alguns switches mais antigos “show mac-address-table”. Veja
exemplo abaixo.
SW-DlteC-Rack-01#show mac address-table

Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports

---- ----------- -------- -----
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
All 0180.c200.0000 STATIC CPU
All ffff.ffff.ffff STATIC CPU
10 001b.0c96.c5e8 DYNAMIC Fa0/5
10 001d.7060.d31b DYNAMIC Fa0/4
10 001e.130b.1aef DYNAMIC Fa0/24
10 0023.339d.0792 DYNAMIC Fa0/8
10 0025.86b4.0458 DYNAMIC Fa0/1
10 0800.274c.3c56 DYNAMIC Fa0/8
10 1cc1.def9.3f53 DYNAMIC Fa0/1
10 24b6.fd06.be40 DYNAMIC Fa0/5
10 24b6.fd06.dc17 DYNAMIC Fa0/8
10 90e6.bad0.3f07 DYNAMIC Fa0/4
1 0014.6937.e559 DYNAMIC Gi0/1
30 001b.0c96.c5e8 DYNAMIC Fa0/5
30 001d.7060.d31b DYNAMIC Fa0/4
30 0023.339d.0792 DYNAMIC Fa0/8
Total Mac Addresses for this criterion: 39
SW-DlteC-Rack-01#

Os endereços podem ser estáticos (STATIC) ou dinâmicos (DYNAMIC), ou seja, alguns

endereços são pré-configurados pelo switch de maneira estática ou inseridos opcionalmente
pelo administrador de redes. Os demais serão aprendidos dinamicamente com o fluxo de
quadros de camada-2 através das portas do switch.
Veja o exemplo marcado na tabela MAC do endereço de broadcast ffff.ffff.ffff serve para todas
as portas, todas as VLANs e foi definido estaticamente pela CPU. A seguir temos o MAC
001b.0c96.c5e8 aprendido na porta fast0/5 que está mapeada na VLAN10.
Outras variantes do comando bem úteis para monitorar a CAM table seguem abaixo:
SW-DlteC-Rack-01#show mac address-table ?

address Address to lookup in the table
aging-time MAC address table aging parameters
count Number of MAC addresses in the table
dynamic List dynamic MAC addresses
interface List MAC adresses on a specific interface
move MAC Move information
multicast List multicast MAC addresses
notification MAC notification parameters and history table
secure List secure MAC addresses
static List static MAC addresses
vlan List MAC addresses on a specific vlan
| Output modifiers
<cr>
A opção dynamic permite analisar somente MACs aprendidos dinamicamente e podemos

combinar com as opções interface para ver os MACs aprendidos em uma interface específica.
Veja exemplo a seguir:
SW-DlteC-Rack-01#show mac address-table dynamic interface gigabitEthernet 0/1

Mac Address Table
-------------------------------------------

---- ----------- -------- -----
10 90e6.bad0.3f0e DYNAMIC Gi0/1
10 90e6.bad0.3f69 DYNAMIC Gi0/1
10 e0cb.4ecc.9b9b DYNAMIC Gi0/1
1 0014.6937.e559 DYNAMIC Gi0/1
Você pode utilizar o comando "show mac address-table address" que permite verificar se
um MAC específico está na tabela CAM do switch. Veja saída abaixo.
SW-DlteC-Rack-01#sho mac address-table address 24b6.fd06.be40

Mac Address Table
-------------------------------------------

---- ----------- -------- -----
10 24b6.fd06.be40 DYNAMIC Fa0/5
SW-DlteC-Rack-01#
Outro comando interessante para as tabelas MAC é o “clear mac address-table”, com ele
podemos limpar todos os endereços dinâmicos aprendidos por MAC, interface ou VLAN. Veja
exemplo abaixo onde vamos limpar os endereços dinâmicos aprendidos na VLAN1.

SW-DlteC-Rack-01#clear mac address-table dynamic ?

address address keyword
interface interface keyword
vlan vlan keyword
<cr>
SW-DlteC-Rack-01#clear mac address-table dynamic vlan 1
1.1 Templates SDM - Switching Database Manager
Apesar do tópico sobre switches multicamada ser estudado em capítulos posteriores vamos
fazer aqui uma rápida introdução a TCAM para que possamos explicar o conceito dos templates
SDM ou Switching Database Manager.
Em roteadores as ACLs são feitas utilizando o conceito de access control entities (ACEs), ou
seja, cada statement é colocado em ordem sequencial e processado nessa ordem até que um
deles dê "match" e a condição de permit ou deny seja aplicada ao pacote. Isso causa latência
porque antes de encaminhar um pacote de saída o roteador deve testá-lo contra cada entrada
de ACL configurada.
Em "multilayer switches" o processo de "matching" da ACLs é implementado em um hardware

chamado TCAM, como já citamos em tópicos anteriores nesse capítulo. Com a TCAM o pacote é
avaliado contra toda as regras criadas na ACL em uma única consulta da tabela!
Maioria dos switches tem na realidade várias TCAMs: inbound e outbound para ACLs de
segurança e ACLs de QoS, as quais podem ser avaliadas em paralelo ou até inteiramente em
paralelo com decisões de encaminhamento de Layer 2 ou Layer 3.
O Cisco Catalyst IOS Software tem dois componentes operacionais da TCAM:

 Feature Manager (FM): depois de criada ou configurada uma ACL o Feature Manager
software compila ou insere as entradas ACEs dentro da tabela TCAM, assim ela poderá
ser consultada na velocidade de encaminhamento de um frame.
 Switching Database Manager (SDM): em alguns modelos de switches Catalyst a
TCAM é particionada em diversas áreas para suportar diferentes funções. O software
SDM configura e ajusta as partições da TCAM se necessário. A TCAM é fixa nos modelos
de switch Catalyst 4500 e 6500, não podendo ser reparticionada.
Switches Cisco High-end Cisco são desenhados para atuar como multilayer switches em
qualquer local da rede (acesso, distribuição ou core), por exemplo, modelos de switches como
os Catalyst 4500 e 6500 podem ser utilizados tanto no core, distribuição ou acesso porque seu
hardware possui "switching engines" (recursos de hardware e software) e espaço em tabela
para quaisquer aplicações.
Em contrapartida, modelos como Catalyst 2960, 3560, 3750 e 3850 tem uma arquitetura fixa e
espaço limitado em suas tabelas de switching, pois as tabelas CAM, FIB e outras tabelas
acabam compartilhando os mesmos recursos.
Por exemplo, um switch de acesso deve privilegiar tabelas relacionadas ao Layer 2 switching,
ou seja, a CAM table deveria ser maior que outras tabelas e a FIB ou tabela de roteamento
deveria ocupar menos espaço. Em outro exemplo, se um switch estiver sendo utilizado para
fazer roteamento entre VLANs ou rotear tráfego sua FIB table deveria ocupar mais espaço que
sua CAM table.
Isso pode ser realizado através dos templates de SDM, o qual gerencia as partições de memória
nos switches low-end. Basicamente teremos cinco opções de template em switches L3: default
(padrão), access (switch de acesso), vlan (prioriza tabela CAM e aprendizado de MACs), routing

(para switches que priorizam o roteamento) e dual IPv4-IPv6 (redes dual stack). Switches L2
por não suportarem roteamento não terão a opção de routing.
Para o exame não é preciso decorar o que cada partição traz como opção de espaço e sim você
deve entender o conceito, saber verificar a configuração atual e alterá-la se necessário.
Para verificar a alocação atual de memória você pode utilizar o comando "Switch#show sdm
prefer" em modo privilegiado. No exemplo a seguir será mostrado a saída do comando para
um switch modelo 2960 layer-2 puro. Note que em destaque está mostrando que o switch
utiliza o template padrão (default).
SW-DlteC-Rack-01#show sdm prefer

The current template is "default" template.
The selected template optimizes the resources in
the switch to support this level of features for
0 routed interfaces and 255 VLANs.
number of unicast mac addresses: 8K

number of IPv4 IGMP groups: 0.25K
number of IPv4/MAC qos aces: 0.375k
number of IPv4/MAC security aces: 0.375k
SW-DlteC-Rack-01#
Veja mais um exemplo, agora em um Catalyst 3550 L3.
Switch#show sdm prefer

The current template is the default template.
8 routed interfaces and 1K VLANs.

number of igmp groups: 1K
number of qos aces: 1K
number of security aces: 1K
number of unicast routes: 8K
number of multicast routes: 1K
Note que aparecem mais opções se compararmos as saídas em ambos os switches, pois em
switches L3 existem mais opções de templates de SDM, veja abaixo as opções no comando
"Switch(config)#sdm prefer ?" em modo de configuração global.
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#sdm ?
prefer Config TCAM and ASIC RAM size. Warning: need to reset switch for
configuration to take effect.
Switch(config)#sdm prefer ?
access multicast and qos/acl bias, drop unicast
extended-match Using extended match for unicast routing
routing unicast bias, drop qos/acl
vlan vlan bias, drop routing
<cr>

Ao configurar uma opção diferente da padrão o switch envia um aviso que é preciso reiniciar o
switch para que a configuração tenha efeito, além disso dá um aviso que ao utilizar essa opção
de VLAN as configurações de layer-3 não serão salvas após o reload.
Switch(config)#sdm prefer vlan

Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.
NOTE: Use caution with 'sdm prefer vlan', as any current Layer3 configuration
data will not be saved after a reload.
Switch(config)#
Vamos configurar o template SDM do roteador do exemplo anterior para routing, reinicializá-lo
e depois vamos verificar as alterações.
Switch(config)#sdm prefer routing

Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.
Switch(config)#end
Switch#wr
*Mar 1 02:17:32.863: %SYS-5-CONFIG_I: Configured from console by console
Building configuration...
[OK]
Switch#reload
Proceed with reload? [confirm]
###Saídas Omitidas ###
Switch#show sdm prefer

The current template is the routing template.
8 routed interfaces and 1K VLANs.

number of igmp groups: 1K
number of qos aces: 512
number of security aces: 512
number of unicast routes: 16K
number of multicast routes: 1K
Switch#
Se você comparar as saídas notará que a quantidade de memória dobrou para entradas de
rotas de Unicast com o template de routing.

2 Padrões nos Switches Camada-2 e Configurações de Portas

Você lembra as configurações padrões de fábrica dos switches Cisco (switches zerados)? Não?
Então antes de seguirmos para o próximo capítulo vamos relembrar:
 Sem senha definida para acesso via console e privilegiado;
 Acesso remoto via IP desabilitado;
 Hostname padrão “Switch”;
 Todas as portas alocadas na VLAN 1;
 Portas configuradas para negociação automática do modo duplex (duplex auto) e
também da velocidade (speed auto);
 Não possui IP de gerenciamento (interface vlan 1 em shutdown);
 Cinco VLANs criadas por padrão que não podem ser alteradas ou apagadas: 1 e de 1002
a 1005;
 VLAN 1 é a nativa (passa informações nos trunks sem marcação de quadros);
 VTP em modo servidor com domínio nulo (null) e sem senha;
 Todas as portas com o protocolo DTP (negociação dinâmica de trunks) ativado.
Lembre-se também que por padrão os switches são camada-2, mesmo os que possuem
suporte a roteamento precisam ter esse recurso ativado com o comando “ip routing”, por isso
quando as questões feitas no CCNA R&S (CCNAX ou CCENT ou ICND-2) de maneira geral sobre
switches respondemos considerando que eles são camada-2 (layer-2 ou L2), apesar de
sabermos que existem switches que atuam em outras camadas do modelo OSI. É isso que vai
mudar nesse curso, vamos estudar também os switches multicamada, multilayer ou switches
camada-3 (L3 ou Layer-3).
1.4 Opções de Conexões em Switches Cisco Catalyst
Em termos de tecnologia de conexão e cabos os switches Cisco basicamente trabalham com

portas da família Ethernet a 10Mbps (Ethernet), 100Mbps Fast Ethernet), 1000Mbps ou 1Gbps
(Gigabit Ethernet) e 10Gbps (10-Gigabit Ethernet). Essas velocidades são suportadas em quase
todas as linhas de switches, tais como Catalyst 2960, 3560, 3750, 4500, 6500, Nexus, etc.
Outras opções mais recentes são conexões de 40Gbps e também de 100Gbps, principalmente
utilizadas em Datacenters e soluções para provedores de serviços. Essas interfaces são
suportadas em switches de maior porte como os da linha 6500 e o Nexus 7000.
Quando falamos das tecnologias 10/100/1000 Mbps podemos utilizar tanto cabos UTP categoria
5 ou superior com conector RJ-45 para distâncias até 100m ou fibras ópticas para links mais
longos ou conexões entre switches. Todas essas tecnologias tem a mesma raiz no 802.3 e
seguem o mesmo formato de quadro, operação do CSMA/CD, full duplex e outras
características do Ethernet, porém o padrão específico do Gigabit Ethernet é definido no 802.3z,
pois a sua camada física teve que sofrer alterações devido ao aumento da velocidade de
transmissão. Veja alguns padrões e suas respectivas distâncias a seguir.

Padrão/Tecnologia Tipo de cabo Pares Comprimento do

enlace
10BASE-T UTP categoria 3, 4 e 5 2 100m
100BASE-TX UTP categoria 5 2 100m
100BASE-FX Fibra óptica multimodo 62,5/125 (MMF) 1 400m half-duplex
ou 2000m full-
duplex
Fibra óptica monomodo (SMF) 1 10km
1000BASE-T UTP categoria 5 4 100m
1000BASE-SX Fibra óptica multimodo 62,5/125 (MMF) 1 275m
Fibra óptica multimodo 50 mícron e 1 550m
laser 850nm (MMF)
1000BASE-LX/LH Fibra óptica multimodo 62,5/125 e laser 1 550m
de 1300nm (MMF)
Fibra óptica multimodo 50 mícron e 1 550m
laser 1300nm (MMF)
Fibra óptica monomodo 9 mícron e laser 1 10km
de 1300nm (SMF)
1000BASE-SX Fibra óptica monomodo 9 mícron e laser 1 70km
de 1550nm (SMF)
Fibra óptica monomodo 8 mícron e laser 1 100km
de 1550nm (SMF)
Já o 10-Gigabit Ethernet segue a 802.3ae que difere das antecessoras na camada física (PHY –
Phisical layer) operando apenas com full-duplex. Além disso, são definidos vários tipos de
transceivers utilizados como Protocol Media Dependent ou PMD e classificados como:
 LAN-PHY: utilizado em LANs predominantemente no Core.
 WAN-PHY: utilizado em interfaces SDH/Sonet para conectar principalmente em redes
MAN.
Assim como para os padrões antecessores o 10-Gigabit tem nomenclaturas e padrões que
determinam o meio físico e distâncias cobertas pelos enlaces, vamos ver os principais exemplos
a seguir.
Padrão/Tecnologia Tipo de cabo Comprimento do enlace

10GBASE-SR/SW Fibra óptica multimodo 50 mícron (MMF) 66m
(850 nm serial) Fibra óptica multimodo 50 mícron (MMF – 300m
2GHz km modal bandwidth)
Fibra óptica multimodo 62,5 mícron (MMF) 33m
10GBASE-LR/LW Fibra óptica monomodo 9 mícron (SMF) 10km
(1310 nm serial)
10GBASE-LR/LW Fibra óptica monomodo 9 mícron (SMF) 40km
(1550 nm serial)
10GBASE-SR/SW Fibra óptica multimodo 50 mícron (MMF) 300m
(850 nm serial) Fibra óptica multimodo 62,5 mícron (MMF) 300m
Fibra óptica monomodo 9 mícron (SMF) 10km
10GBASE-CX4 Par metálico CX4 com conector Infiniband 15m
10GBASE-T UTP categoria 6A ou 7 100m
Normalmente encontramos switches de acesso com portas 10/100 Mbps ou 10/100/1000 Mbps
através de portas UTP de 8, 12, 16, 24 e 48 portas com duas ou até quatro SFPs que são
entradas para módulos de fibra. As conexões de 10G normalmente são disponibilizadas em
módulos chamados XENPAKs, X2 e SFP+, sendo que os módulos X2 são menores que as
XENPAKs e as SFP+ são menores ainda que as duas, permitindo a conexão em switches

menores, pois as duas outras normalmente são utilizadas em módulos de switches como 4500
e 6500. Veja algumas imagens com diferentes padrões de módulos de fibra.
Existem modelos de switches como o 4500-X mais novos que vêm com interfaces de 10GBASE-
T de fábrica, não precisando a inserção de módulos adicionais.
Outro tipo de conexão que podemos encontrar em campo é GigaStack, StackWise e

StackWise Plus utilizados para o empilhamento (stacking) de switches através de conectores
proprietários que permitem altas taxas de transmissão. Veja exemplo abaixo onde temos uma
pilha de switches conectados através de StackWise deixando as portas liberadas para conexão
de clientes.
1.5 Configuração Básica das Portas dos Switches L2
As interfaces dos switches não modulares, aqueles que possuem 8, 12, 16, 24 ou 48 portas
fixas, são numeradas de acordo com seu tipo, módulo (sempre zero por não terem módulos) e
número da porta:
- Switch(config)#interface tipo módulo/número

- Exemplo: Switch(config)#interface fastethernet 0/1
Se você tem uma pilha de switches entra mais uma variável na configuração que é a posição do
switch na pilha antes do módulo/número, pois a pilha é administrada como se fosse apenas um
dispositivo. Por exemplo, você tem três 3750 empilhados e deseja configurar a segunda porta
do segundo switch na pilha, então deve entrar com o comando:
-Switch(config)#interface fastethernet 2/0/2
Outra dica é se você está com dúvidas sobre a numeração das portas pode utilizar o “show
interface status” ou o “show run” para verificar como elas foram numeradas. Veja exemplo a
seguir do comando para um switch 2960 de 24 portas com duas gigas para uplink.

SW-DlteC-Rack-01#show interfaces status
Port Name Status Vlan Duplex Speed Type

Fa0/1 portas sem telefon connected 10 a-full a-100 10/100BaseTX
Fa0/2 portas sem telefon notconnect 10 auto auto 10/100BaseTX
Fa0/4 com vlan de voz connected 10 a-full a-100 10/100BaseTX
Fa0/5 com vlan de voz connected 10 a-full a-100 10/100BaseTX
Fa0/6 com vlan de voz notconnect 10 auto auto 10/100BaseTX
Fa0/7 Impressora HP-8100 notconnect 10 full 100 10/100BaseTX
Fa0/8 com vlan de voz connected trunk a-full a-100 10/100BaseTX
Fa0/20 notconnect 10 auto auto 10/100BaseTX
Fa0/23 Portas da sala de notconnect 20 auto auto 10/100BaseTX
Fa0/24 connected trunk a-full a-100 10/100BaseTX
Gi0/1 connected trunk a-full a-1000 10/100/1000BaseTX
Gi0/2 notconnect 10 auto auto 10/100/1000BaseTX
SW-DlteC-Rack-01#
Para configurar as portas podemos entrar uma a uma, utilizar a opção “range” ou até criar
uma macro no Cisco IOS para representar um grupo de portas que utilizamos mais vezes, veja
exemplos abaixo:
SW-DlteC-Rack-01#conf t
SW-DlteC-Rack-01(config)#! Entrando na interface fast 1
SW-DlteC-Rack-01(config)#interface fastEthernet 0/1
SW-DlteC-Rack-01(config-if)#exit
SW-DlteC-Rack-01(config)#! Entrando nas interfaces de 1 a 24 simultaneamente
SW-DlteC-Rack-01(config)#interface range fastEthernet 0/1 - 24
SW-DlteC-Rack-01(config-if-range)#exit
SW-DlteC-Rack-01(config)#! Criação da macro Int-Giga que entra
SW-DlteC-Rack-01(config)#! nas interfaces Giga0/1 e 0/2 simultaneamente
SW-DlteC-Rack-01(config)#define interface-range ?
WORD macro definition
SW-DlteC-Rack-01(config)#define interface-range Int-Giga ?

FastEthernet FastEthernet IEEE 802.3
GigabitEthernet GigabitEthernet IEEE 802.3z
Loopback Loopback interface
Port-channel Ethernet Channel of interfaces
Tunnel Tunnel interface
Vlan Catalyst Vlans
SW-DlteC-Rack-01(config)#define interface-range Int-Giga gigabitEthernet 0/1-2

SW-DlteC-Rack-01(config)#interface range macro Int-Giga
SW-DlteC-Rack-01(config-if-range)#

As configurações básicas de uma interface de switch são:

- Identificação das portas com o comando “description”;
- Velocidade com o comando “speed” (padrão automático);
- Modo duplex com o comando “duplex” (padrão automático);
- Desativar as portas não utilizadas conforme política de cada empresa com o comando “no
shutdown” (nos switches o padrão é a porta estar ativada, ao contrário dos routers).
Veja exemplo abaixo:
SW-DlteC-Rack-01(config-if)#description Teste do curso CCNP SWITCH DLTEC
SW-DlteC-Rack-01(config-if)#speed ?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration
SW-DlteC-Rack-01(config-if)#speed auto
SW-DlteC-Rack-01(config-if)#duplex ?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation
SW-DlteC-Rack-01(config-if)#duplex auto
SW-DlteC-Rack-01(config-if)#do sho run int f0/2
Current configuration : 255 bytes

!
interface FastEthernet0/2
description Teste do curso CCNP SWITCH DLTEC
switchport access vlan 10
switchport mode access
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust cos
auto qos voip trust
spanning-tree portfast
end
Note que as configurações de velocidade e modo duplex realizadas não aparecem no final no
comando “show run” porque deixamos os padrões. Com o comando “show interfaces” e
“show interface status” você pode verificar como a porta ficou ao final da negociação se tudo
estiver no automático.
SW-DlteC-Rack-01#sho interfaces fastEthernet 0/1

FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0024.5161.6a01 (bia 0024.5161.6a01)
Description: portas sem telefone IP
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
… Saída omitida

SW-DlteC-Rack-01#sho interfaces fastEthernet 0/1 status

Fa0/1 portas sem telefon connected 10 a-full a-100 10/100BaseTX
SW-DlteC-Rack-01#
Nesse ponto normalmente podemos encontrar problemas na autonegociação da velocidade e do

modo duplex, principalmente quando conectamos com equipamentos de outros fabricantes ou
um dos lados tem a configuração fixa e do outro automático ou os dois lados tem a
configuração fixa, porém com parâmetros diferentes.
No caso da autonegociação do duplex os switches utilizam números de prioridade conforme

cada tecnologia, sendo que as prioridades mais altas são as preferenciais. Por exemplo, o fast
ethernet tem compatibilidade com o ethernet (portas 10/100Mbps), por isso uma porta fast
suporta as prioridades 6 (100BASE-TX), 2 (10BASE-T full duplex) e 1 (10BASE-T half duplex).
Se ambos os lados estiverem com autonegociação para o modo duplex normalmente a
prioridade 6 vai ser a negociada e ambos os lados serão full duplex a 100Mbps.
Lembre-se que se você utilizar configurações fixas, sem o uso do auto, deve assegurar que o
mesmo padrão foi utilizado em todos os switches para que não haja o famoso “duplex
mismatch”, onde um lado é full e outro half-duplex, o que traz problemas para aquela conexão
como colisões.
2.1 Detectando e Resolvendo Erros em Portas - Error Disable
Em certos casos específicos mesmo que a configuração mostre que uma porta que deve estar
habilitada e o software no switch detecta uma situação de erro na porta, o Cisco IOS desativa a
porta. Portanto, existem situações onde a porta é desabilitada automaticamente pelo Cisco IOS
do switch devido a uma condição de erro que é encontrada na porta, conhecida como Error
Disable ou "err-disabled", mostrado no status da interface através do comando "show
interfaces". Veja exemplo abaixo.
Switch1#show interfaces gigabitethernet 0/1 status

Gi0/1 err-disabled 10 full 1000 1000BaseSX
Quando uma porta é desabilitada por erro, ela é desligada (shutdown) e nenhum tráfego é
enviado ou recebido nessa porta. O LED da porta fica aceso em laranja e quando você executa
o comando show interfaces o status da porta é mostrado como err-disabled.
Além disso, se a interface foi desabilitada devido a uma condição de erro, você poderá ver
mensagens semelhantes a estas no console e no syslog:
%SPANTREE-SP-2-BLOCK_BPDUGUARD:
Received BPDU on port GigabitEthernet0/1 with BPDU Guard enabled.
Disabling port.
%PM-SP-4-ERR_DISABLE:
bpduguard error detected on Gi0/1, putting Gi0/1 in err-disable state
Essa mensagem de exemplo é exibida quando uma porta de host recebe um BPDU, porém a
mensagem real depende do motivo da condição de erro.
A função de desativação de porta por erro atende a duas finalidades básicas:

 Informar o administrador sobre quando e onde há um problema de porta.
 Eliminar a possibilidade desta porta poder fazer com que outras portas no módulo (ou no
módulo/switch inteiro) falhem.

Essa falha pode ocorrer quando uma porta com problemas monopoliza buffers ou mensagens
de erro dessa porta monopolizam as comunicações entre processos na placa, o que pode causar
problemas de rede sérios. O recurso de desativação de porta por erro ou Error Disable
ajuda a prevenir estas situações.
2.1.1 Configurações e Mensagens de Erro

A detecção de condições de erro são ativadas para todos os tipos de mensagem nos switches
Cisco por padrão, porém você pode verificar o estado com o comando "show errordisable
detect", veja exemplo abaixo tirado de um switch modelo Catalyst 2960.
SW-DlteC-Rack-01#show errdisable detect

ErrDisable Reason Detection Mode
----------------- --------- ----
bpduguard Enabled port
channel-misconfig Enabled port
community-limit Enabled port
dhcp-rate-limit Enabled port
dtp-flap Enabled port
gbic-invalid Enabled port
inline-power Enabled port
invalid-policy Enabled port
link-flap Enabled port
loopback Enabled port
lsgroup Enabled port
mac-limit Enabled port
pagp-flap Enabled port
port-mode-failure Enabled port
psecure-violation Enabled port/vlan
security-violation Enabled port
sfp-config-mismatch Enabled port
small-frame Enabled port
storm-control Enabled port
udld Enabled port
vmps Enabled port
SW-DlteC-Rack-01#
Se algum item estiver desativado ou houver a necessidade de desativação utilize o comando

"Switch(config)#[ no ] errdisable detect cause [ all | nome-causa ]" em modo de
configuração global.
As causas do error-disable (nome-causa no comando) mais importantes são mostradas na

lista abaixo, porém dependendo do modelo do switch algumas causas não aparecerão na lista
devido ao suporte de recursos presentes na versão do Cisco IOS:
 all: Detecta todos os tipos possíveis de erro.
 arp-inspection: Detecta erros com dynamic ARP inspection (DAI).
 bpduguard: Detecta quando um BPDU é recebido em uma porta configurada como
PortFast.
 dhcp-rate-limit: Detecta um erro relacionado ao DHCP snooping.
 dtp-flap: Detecta quando o encapsulamento do trunk varia de um tipo para outro.
 gbic-invalid: Detecta a presença de uma GBIC ou SFP inválida.
 inline-power: Detecta erro relacionado ao PoE.
 l2ptguard: Detecta erro com o protocolo L2TP (Layer 2 Protocol Tunneling).
 link-flap: Detecta quando o estado da porta está em “flapping”, variando de up para
down e vice versa constantemente.
 loopback: Detecta quando uma interface foi "loopada" ou "colocada em loop".
 pagp-flap: Detecta erro quando um grupo de portas de EtherChannel não tem
configurações consistentes.

 pppoe-ia-rate-limit: Detecta erros com a taxa limite do PPPoE Intermediate Agent.

 psecure-violation: Detecta condições que ultrapassaram os limites configurados via
port security em uma determinada porta.
 psp: Detecta erro relacionado a proteção de tempestade configurada no "protocol storm
protection".
 security-violation: Detecta erros de segurança relacionados ao 802.1X (autenticação
de porta).
 sfp-config-mismatch: Detecta erros relacionados a configurações em uma SFP.
 small-frame: Detecta erros quando pacotes de VLAN-tagged são pequenos demais para
chegar em determinada taxa.
 storm-control: Detecta quando o limiar do storm control theshhold foi ultrapassado em
uma porta.
 udld: Detecta quando um link passou a ser visto como unidirecional (dados são
transmitidos ou recebidos em uma só direção).
Uma vez o Cisco IOS detecta um erro ele desativa a porta e coloca-a em estado de error-
disable, portanto a porta por padrão ficará desativada até que o administrador de redes acesse
o dispositivo com o problema, entre na porta e utilize os comandos "shutdown" e depois "no
shutdown" para que a porta suba. Porém se o erro persistir a porta volta a cair até que a causa
raiz do problema seja resolvida.
É possível configurar uma recuperação automática da porta ou Automatic Recovery com o

comando "Switch(config)#errdisable recovery cause [ all | nome-causa ]" em modo de
configuração global. Mais uma vez é possível configurar para todas as causas (all) ou para
causas específicas (nome-causa).
Por padrão se um erro ocorrer e o "automatic recovery" estiver configurado a porta em

errdisable fica desativada por 5 minutos (300 segundos). Para alterar esse valor utilize o
comando "Switch(config)#errdisable recovery interval segundos", sendo que o intervalo
vai de 30 a 86.400 segundos (24 horas).
Por exemplo, podemos definir que portas desativadas pelo Port Security fiquem nesse estado
por 3 minutos e depois o switch ativará a porta automaticamente, veja as configurações abaixo.
SW-DlteC-Rack-01(config)#errdisable recovery cause psecure-violation

SW-DlteC-Rack-01(config)#errdisable recovery interval 180

3 Modelos de Design de Rede

Esse capítulo inicia bem parecido com o que estudamos no CCNP ROUTE, isso considerando
que você fez o curso do ROUTE com a DlteC, porém vamos dar um enfoque maior para criação
de redes LAN e Campus.
Atualmente estamos passando pela fase da integração ou convergência das redes em uma
única infraestrutura que inclui voz, vídeo, dados, gerenciamento de rede, tráfego de
roteamento, diversos tipos de aplicações e aplicativos de usuários, e muito mais.
Cada tipo de tráfego exige um desempenho diferente quando falamos sobre de largura de
banda, atraso e variação no atraso (bandwidth, delay e jitter), assim como cada um desses
tráfegos têm seus próprios requisitos de segurança.
Por exemplo, o tráfego de Web é robusto, pouco sensível a atraso ou perda de pacotes, pois ele
trabalha com TCP e não exige tráfego em tempo real (real time). Já o tráfego de voz ou vídeo
precisa de largura de banda dedicada, assim como são sensíveis ao atraso, à variação do atraso
(jitter) e a perda de pacotes.
Portanto o design de rede deve prover um framework para integrar cada diferente tipo de
tráfego dentro da mesma rede e, para isso, ao longo dos anos foram desenvolvidos alguns
modelos para que fosse possível entender e projetar uma rede e seu fluxo de dados de maneira
a facilitar o entendimento em topologias mais complexas.
Os principais modelos que estudaremos com mais detalhes nesse capítulo são:
 Modelo hierárquico tradicional (três camadas)

 Enterprise Composite Model (modelo empresarial composto)
1.6 Modelo Hierárquico em Três Camadas
Esse é o modelo tradicional e mais utilizado até os dias de hoje em projetos de redes mais
complexas, dividindo a rede em três camadas: Acesso, Distribuição e Núcleo (Access,
Distribution e Core). Veja a figura abaixo.
Nessa topologia temos um campus com switches de acesso em seus andares, os quais são
agregados nos switches de distribuição em cada edificação, normalmente switches layer-3. Por
sua vez os switches de distribuição dos diversos prédios são agregados em um ou mais
switches de núcleo, conforme a necessidade de redundância e porte da rede.

Resumindo, no acesso ou access estão os switches onde conectamos os dispositivos dos

usuários, a distribuição ou distribution agrega os switches de acesso em blocos, os quais por
sua vez são interconectados através do núcleo ou core da rede.
Note que essa estrutura permite que qualquer usuário na camada de acesso se comunique com
outro dando no máximo três saltos entre switches, ou seja, o diâmetro da rede é fixo e sempre
bem conhecido.
Resumindo, as funções de cada camada são:
 Acesso - Access Layer: Fornece conectividade aos grupos de trabalho, estações,

Access points, telefones IP, estações de vídeo conferência, etc. Nessa camada temos
switches que podem ter algumas características específicas tais como:
o Redundância com fontes secundárias e/ou RPSs (Redundant Power System) para
garantir uma alternativa de energia em caso de quedas da rede elétrica principal.
o Links backup e/ou etherchannels para garantir redundância de caminho em
direção à distribuição.
o Os links podem ser tanto com par metálico (UTP) como conexões via fibra com
SFPs ou GBICs.
o Utilização de protocolos como STP, RSTP e MST para evitar loops de camada-2 e
tempestades de broadcast.
o Suporte a QoS e multicast permitindo serviços avançados como Telefonia e vídeo
IP.
o Recursos de segurança como o Dynamic ARP Inspection, DHCP snooping, BPDU
Guard, port-security e IP source guard, os quais visam proteger a rede
principalmente contra ataques no primeiro salto (first hop), ou seja, entre o
endpoint e seu switch ou gateway.
o Controle de acesso à rede através de 802.1X, etc.
 Distribuição - Distribution Layer: Faz a conectividade entre as diversas camadas de
acesso intermediando os dados entre a camada de acesso e o Core da rede com base
em políticas. Normalmente formam blocos de switches que podem ser prédios ou grupos
de setores de uma empresa. Vamos agora citar algumas características específicas de
switches de distribuição:
o Fazem a agregação dos diversos switches de acesso.
o Devem ser capazes de prover conexões de alta disponibilidade, QoS e
balanceamento de cargas (load balancing), etc.
o Alta disponibilidade através de módulos ou até mesmo switches redundantes,
assim como possibilitar a criação de caminhos alternativos para conectar tanto os
switches de acesso como o Core.
o Utilização de FHRP (First Hop Redundancy Protocol) para balanceamento de carga
e redundância do gateway padrão dos dispositivos dos usuários finais.
o Capaz de aplicar políticas (policy), tais como políticas de roteamento,
sumarização de rotas, QoS e políticas de segurança.
o Segmentação e isolamento dos grupos de trabalho para evitar que problemas se
propaguem através do core da rede, normalmente realizado com a combinação
de links Layer 2 (Access-Distribution/Distr-Distr) e Layer 3 (Distr-Core/Core-
Core).
 Núcleo - Core Layer: Fornece chaveamento rápido entre os diversos switches de

distribuição ou blocos de switches. Vamos a algumas características específicas dos
switches de Core:
o Prover conexões Layer-3 de altíssima velocidade entre os diversos switches de
distribuição sempre com escalabilidade e confiabilidade.
o Confiabilidade através módulos (fontes e placas supervisoras redundantes),
equipamentos e links redundantes.

o Uso de protocolos de roteamento para comunicação entre as diversas partes da

rede Campus.
o Links de alta velocidade (10 Gigabit Ethernet) possibilitando a integração de
dados, voz e vídeo entre LAN, WAN e MAN.
o Não utilização de políticas nessa camada, tais como ACLs ou filtros para não
interferir na velocidade de chaveamento do tráfego.
A vantagem desse modelo é a possibilidade de termos links de backups na camada de acesso,

assim como links e equipamentos backups nas camadas de distribuição e núcleo, o que
possibilita um modelo altamente redundante, ou seja, com uma alta disponibilidade (tolerante a
falhas – fault tolerant).
A desvantagem desse modelo é de não definir claramente todos os aspectos de uma rede, tais
como:
 Onde dispositivos sem fio devem estar posicionados?
 Como o acesso à Internet e a parte de segurança envolvida deve ser provisionada?
(Firewall/IPS)
 Como o acesso a usuários remotos deve ser fornecido? (VPNs)
Resumindo, é um modelo de topologia focado em uma estrutura mais convencional, porém

ainda muito utilizado na prática!
Outro ponto interessante de discussão sobre esse modelo é a real necessidade da camada de
Core. Será que não poderíamos ter simplesmente distribuição e acesso? Pense um
pouco no assunto e depois continue a leitura!
Dependendo do tamanho da rede isso pode até ser uma realidade, onde os switches de
distribuição e Core estão colapsados (um switch fazendo as duas funções) formando uma
única estrutura, porém em redes de maior porte isso exigiria que todas as distribuições
fizessem uma conexão full-meshed entre si, encarecendo muitas vezes o custo do projeto pela
quantidade de interfaces necessárias para essas conexões.
Portanto, inserir o core em redes mais complexas traz uma hierarquização que possibilita
menos conexões entre os switches de distribuição e facilita também a sumarização de rotas.
Vamos a seguir aplicar esses conceitos estudando modelos de topologias para pequenas,
médias e grandes redes.

1.6.1 Projeto de Campus de Pequeno Porte

Em uma topologia de pequeno porte, por exemplo, até 200 endpoints, o Core e a Distribuição
pode ser combinada em uma única camada, o que chamamos de topologia com Core e
Distribuição colapsados.
Nesse tipo de rede um único switch multicamadas (multilayer switch) pode prover a função das
três camadas, veja a seguir um exemplo de topologia com Core colapsado.
Abaixo segue mais um exemplo de Core colapsado agora com dois switches de Distr/Core,
aumentando sensivelmente a disponibilidade da rede, pois aqui eliminamos o ponto único de
falhas (SPOF – Single Point of Failure) do exemplo anterior. Nesse modelo se um switch falhar
o segundo assume as funções sem prejuízo para os usuários finais.
Em ambos os exemplos os links entre os switches, seja distribuição-acesso ou entre os switches

redundantes podem ser layer-2, ou seja, são interfaces com o comando “switchport” ativado e
não recebem endereço IP próprio, necessitando de interfaces virtuais ou SVIs para o
roteamento entre VLANs ou então um roteador com subinterfaces (arquitetura ROAS – Router
on a Stick).
Nesse tipo de arquitetura encontramos normalmente switches da linha Catalyst 3560/3560-X

ou 3750/3750-X na distribuição e os modelos Catalyst 2960 no acesso.

1.6.2 Campus de Médio Porte

Entre 200 e 1000 dispositivos de usuários ou endpoints podemos considerar a rede de médio
porte. Nesse tipo de rede é bem provável que a quantidade de endpoints exija diversos
switches de acesso e por isso também diversos switches de distribuição, exigindo por sua vez a
presença de um Core na rede, veja a figura a seguir.
Os switches de acesso são normalmente fixos (12/24/48 portas 10/100/1000Mbps mais

“uplinks” em fibra) e sem caminho redundante até o usuário, a redundância de link é apenas
entre o próprio switch de acesso e seu agregador na distribuição.
Cada prédio ou andar é um bloco do campus com diversos switches de acesso conectados à
distribuição com links redundantes, sendo que os switches de distribuição são multilayers,
normalmente modulares e redundantes tanto em direção ao acesso como em direção ao Core.
Além disso, os switches de distribuição são conectados até o Core através de links layer-3
redundantes, porém nada impede que você tenha toda sua estrutura baseada em links layer-2.
Veja a figura a seguir.

Você pode estar se perguntado, mas será que eu poderia fazer tudo layer-3? Links
entre acesso-distribuição e distribuição-core através de links camada-3?
A resposta é sim, porém os switches de acesso se tornariam mais caros por necessitarem
suportar roteamento, ou seja, também serem multilayers, por isso não é tão comum esse tipo
de estrutura em redes de médio porte.
Nesse tipo de rede podemos encontrar switches de maior porte, tais como os da linha Catalyst
3750/3750-X, 4500, 4500-X ou 6500.
1.6.3 Campus de Grande Porte

Campus de grande porte tem normalmente mais de 2000 usuários finais e devem ter sua
estrutura modelada em três camadas (Core, Distribution e Access) de maneira bem
estruturada.
Em termos de arquitetura final ela fica bem parecida com as de médio porte com as três
camadas, porém com mais “blocos” de distribuição, veja exemplo abaixo.
Podemos encontrar switches Catalyst 4500-E e 6500 tanto no core como na distribuição nesse
tipo de rede, assim como switches Nexus 7000 no data centers.

1.6.4 Visão Geral da Infraestrutura do Data Center

Na última figura do tópico anterior vimos que o Core do Campus conecta os usuários finais
entre as diferentes distribuições e também ao Data Center.
Falando mais especificamente do segmento de rede do datacenter em um campus, ele pode

variar muito em tamanho, de alguns servidores conectados aos mesmos switches de acesso
que conectam os endpoints até uma rede separada e composta por três camadas como
estudamos para o Campus.
Porém, as três camadas de um Data Center variam um pouco do que estudamos para o
Campus, veja algumas diferenças abaixo:
 Core layer: Conecta o core do campus e fornece chaveamento de alta velocidade tanto
para dentro como para fora do data center.
 Aggregation layer: Fornece serviços como server load balancing (balanceamento de

cargas entre servidores), content switching (switching com base em conteúdo), SSL off-
load e segurança através de firewalls e IPS.
 Access layer: Fornece acesso à rede para servidores e storages. Podem ser switches
Layer 2 ou Layer 3, além de poderem suportar tipos de conexões diferentes das que
estudamos para as LANs.
Veja a figura abaixo onde temos a interação entre a rede Campus e um Data Center.

3.1 Exemplos de Switches Cisco e Posicionamento no Modelo em Três Camadas
Vamos começar pela camada de acesso, onde precisamos normalmente de alta densidade de
portas, Power over Ethernet (PoE) e geralmente custo reduzido.
Para o acesso podemos utilizar as linhas de Switch Cisco Catalyst 2960-X, 3650 e 3850. Esses
modelos suportam diversas quantidades de porta, indo de 8, 16, 24 até 48 portas, podendo
formar switches virtuais através de cascateamento (será estudado em capítulos posteriores)
formando dispositivos com grande número de portas.
Também o Catalyst 4500E é uma opção de chassis único que pode ser equipado com diversas
placas de linha (line cards), suportando grande número de conexões e tipos de interface. Além
disso, o 4500-E suporta módulos supervisores e fontes redundantes, sendo capaz de upgrades
de software sem impacto na rede de produção.
Para distribuição e core necessitamos de recursos bem similares, normalmente através de

switches Layer 3 com alto throughput e suporte a diversas conexões de fibra óptica. Para essa
finalidade podemos utilizar os switches Catalyst 3750-X, 4500-X, 4500E e 6800.

Veja a tabela abaixo com o resumo das características mais importantes dos switches citados
nesse tópico.
Modelo do Densidade Máxima de Uplinks Taxa Máxima Principais Recursos

Switch Portas do Backplane
2960-X 384 - até 8 switches de 2 10GE ou 4 80 Gbps RIP, OSPF e PoE+
48 portas em uma pilha Gigabit
(stack) Ethernet por
switch
3560 432 - até 9 switches de 2 Gigabit 160 Gbps Todos recursos de
48 portas em uma pilha Ethernet ou 4 roteamento, wireless
(stack) 10GE controller integrado e
PoE+
3850 432 - até 9 switches de 4 Gigabit 480 Gbps Idem ao 3560
48 portas em uma pilha Ethernet ou 4
(stack) 10GE
4500-E 384 - até 8 módulos de Até 12 portas 928 Gbps Dual supervisors,
(Acesso) 48 portas por chassis 10GE por Todos recursos de
módulo roteamento, wireless
controller integrado, PoE+
e UPoE
4500-X 80 interfaces de 10GE Não se aplica 1.6 Tbps Redundância via Dual-
chassis Virtual
Switching System (VSS)
4500-E 96 interfaces de 10GE ou Não se aplica 928 Gbps Supervisores redundantes
(Distribuição 384 interfaces (dual)
e Core) Gigabit Ethernet
6807-XL 40 interfaces de 40Gbps, Não se aplica 22.8 Tbps Supervidores redundantes
160 de 10GE ou 480 (dual) e VSS
Gigabit Ethernet
Ao longo do material outros modelos mais antigos e até atuais podem ser citados, pois existem
diversos switches e mesmo mais antigos como os Catalyst 6500 podem ser encontrados ainda
em produção, mesmo tendo sido descontinuado para venda.

3.2 Enterprise Composite Model
Este é um novo modelo de design proposto pela Cisco, o qual trata dos pontos não endereçados
pelo modelo hierárquico, especificando e recomendando como e onde certas funções devem ser
implementadas na rede. Este modelo faz parte do modelo de referência chamado Security
Architectures for the Enterprise ou SAFE, que traz melhores práticas, recomendações e
configurações para o desenho e implementação de redes com segurança.
Este modelo divide a rede em módulos (blocos) para facilitar o entendimento e projeto da rede:
 Enterprise Campus: switches e dispositivos que compõe a LAN da empresa e fornecem

acesso aos dispositivos dos usuários, fornecendo acesso de voz, dados e vídeos
corporativos.
 Enterprise Core: este módulo integra os diversos módulos da topologia de rede.
 Intranet Data Center: módulo capaz de agregar um grande número de sistemas com
a finalidade de prover as diversas aplicações corporativas e armazenar grandes volumes
de dados.
 Enterprise Internet Edge: este módulo, como o nome já diz, provê a conexão da
Intranet (privada) com a Internet (pública), atuando como gateway entre a rede interna
e o restante do mundo exterior.
 Enterprise WAN Edge: é a parte da infraestrutura de rede que agrega os links de WAN
que conectam filiais geograficamente distantes a um site central, utilizada para conectar
as unidades remotas à matriz.
 Enterprise Branch: fornece conectividade para usuários e dispositivos remotos, os
quais normalmente conectam-se ao site central através de uma VPN através da
Internet.
 Management: parte da infraestrutura dedicada ao gerenciamento de redes.

Na realidade, nesse modelo continuamos utilizando o conceito de uma rede hierárquica,

aproveitando sua tolerância a falhas, porém adicionando detalhes que não existiam. Por
exemplo, note na figura seguinte onde no Enterprise Campus temos as conexões dos
switches com referência no modelo hierárquico, porém adicionando nome e funções a cada uma
das partes:
 Campus Backbone: o core da rede LAN

 Building Distribution: camada de distribuição da LAN
 Building Access: camada de acesso da LAN
 Management: gerenciamento de rede fora da banda (out-of-band)
 Server Farm: para conectar servidores corporativos
 Edge Distribution: camada de distribuição para conectar a serviços de WAN
Os serviços de Internet e conexão com outras redes como a de Telefonia convencional (PSTN)
podem ser realizados através do Service Provider Edge, uma agregação da Enterprise
Internet Edge, Enterprise WAN Edge e Enterprise Branch, conforme mostramos a seguir. Nessa
composição temos os blocos WAN, E-commerce (servidores corporativos que serão acessados
via Internet por clientes internos e externos), Internet e Remote Access (acesso remoto a
unidades e usuários).

Como você pode perceber a complexidade da rede e seus blocos integrantes aumenta de
acordo com o porte da empresa e no que tange a escolher os protocolos de roteamento para
essa arquitetura vai depender do que estudamos anteriormente.
Por exemplo, no bloco da Internet e E-Commerce, se a empresa for um sistema autônomo

precisaremos utilizar o BGP-4 para conectar com os outros ASs e ISPs vizinhos com quem
vamos trocar tráfego.
Já na rede Interna podemos utilizar o OSPF se roteadores de outros fabricantes forem utilizados
ou então o EIGRP se a rede for toda Cisco.
Podemos agora juntar todas as peças e formar uma topologia complexa, porém projetada e
implementada de maneira segura conforme previsto na filosofia SAFE da Cisco, conforme
mostrado na figura a seguir, dividindo a rede em Enterprise Campus (a Intranet), Enterprise
Edge (a parte que está conectando a rede Interna com o mundo exterior ou unidades remotas
através da WAN) e o Service Provider Edge, o qual conecta a rede ao mundo público dos
provedores de serviço de WAN, Internet, Telefonia e demais serviços de comunicação.
Note que toda a divisão feita tem como base o modelo em três camadas, sendo várias
distribuições e acessos conectados a um núcleo (core) único, porém cada um deles ocupando
um espaço distinto no design de rede.


Capítulo 03 -
Implementando VLANs,
Nesse capítulo vamos Trunks e VTP
estudar os conceitos sobre
VLANs, entroncamento Objetivos do Capítulo
entre switches, agregação
de links e o protocolo VTP. Ao final desse capítulo você terá estudado e
deverá compreender:
 Conceito de VLANs.
 VLANs locais e VLANs estendidas.
Esses protocolos são  Implementação e testes de
amplamente utilizados em ambientes com VLAN.
redes com switches e apesar  Protocolos de trunk 802.1Q e ISL
de também parte do CCNA  Configuração dos trunks entre
switches.
R&S são alvo de estudo no  VLANs de voz ou Voice VLANs.
CCNP SWITCH com um foco  VLANs Wireless para conexão de APs
mais voltado a soluções de Autônomos e Lightweight.
maior porte.  Agregação de links e Etherchannel
 Protocolo VTP – conceito e
configurações.
 Comandos show e dicas para
Aproveite o capítulo e bons troubleshooting.
estudos!

Sumário do Capítulo 5 Resumo do Capítulo ______________ 81
1 Implementando VLANs ____________ 44

1.1 Tipos de Implementações de VLANs _ 44
1.2 Planejando a Implementação de VLANs
46
1.3 Criação de VLANs e Associação de
Portas 46
1.4 Conectando Switches – Trunks ISL e
802.1Q ______________________________ 51
1.4.1 Melhores Práticas na Configuração de
Trunks 58
3.3 Voice VLAN e PoE ________________ 59
3.3.1 Configurando VLANs de Voz _______ 60
3.3.2 Protocolos CDP e LLDP ____________ 60
3.3.3 Power Over Ethernet - PoE ________ 63
3.3.4 Configurando e Verificando o PoE ___ 63
3.4 VLANs e Trunks para Suporte a Redes
Sem Fio _____________________________ 64
3.4.1 Configurando Suporte a APs Autônomos
64
3.4.2 Configurando Suporte a LAPs e WLCs 65
2 Implementação de Ethernchannel –
Agregação de Links __________________ 67
2.1 Balanceamento de Cargas no
Etherchannel _________________________ 68
2.2 Configurando um Etherchannel _____ 69
2.3 Exemplo de Configuração do PAgP __ 70
2.4 Exemplo de Configuração do LACP __ 73
3.5 Evitando Problemas de Configuração
com Etherchannel Guard _______________ 73
3 VTP - VLAN Trunking Protocol _______ 75
3.1 Versões e Modo do VTP ___________ 75
3.2 Anúncios do VTP _________________ 76
3.3 Configuração do VTP _____________ 77
3.4 VTP Pruning ____________________ 78
4 Dicas de Troubleshooting __________ 79
4.1 Conectividade de Usuários_________ 79
4.2 Conexão entre Switches - Trunking __ 80
4.3 Problemas com VTP ______________ 80

1 Implementando VLANs
Você deve se lembrar de que as VLANs são utilizadas principalmente para dividir uma rede em
segmentos lógicos menores, trazendo vários benefícios administrativos e técnicos, tais como
redução no tráfego de broadcast em um segmento lógico, facilidade na implementação de
políticas de segurança, etc.
Uma Virtual LAN (VLAN ou LAN Virtual) é uma LAN lógica ou uma sub-rede lógica, ou seja,
define um domínio de broadcast, ou seja, cada VLAN por padrão precisa ter uma sub-rede
própria.
Mas porque sub-rede lógica? É simples, lembre-se que uma sub-rede física é um grupo de
dispositivos que compartilham um mesmo meio físico, já um grupo lógico está vinculado a um
grupo de portas de um switch que estão configuradas com o mesmo número de VLAN ou VLAN
ID, não importando onde fisicamente esses dispositivos dos grupos estão conectados.
Essa configuração de VLAN por porta (em inglês “VLAN membership”) pode ser feita tanto de
maneira estática como dinâmica por endereço MAC ou usuário através de um servidor VMPS
(VLAN Management Policy Server). O mais comum na prática é a alocação estática.
Lembre-se também que os switches que utilizam Cisco IOS tem todas as suas portas por
padrão alocadas na VLAN 1, que é uma das cinco VLANs padrões que um switch tem
configurada (1, 1002, 1003, 1004 e 1005). Essas VLANs padrões não podem ser apagadas
ou alteradas.
1.1 Tipos de Implementações de VLANs
Basicamente podemos implementar as VLANs de duas maneiras:
1. Fim a fim (End-to-end VLAN): Nessa configuração as VLANs cruzam a rede passando
por diferentes switches e seus membros podem estar em diferentes switches através da
rede. Essa topologia é utilizada quando o administrador precisa manter uma política
comum para um grupo de usuários independente da localização física, pois eles estarão
na mesma VLAN independente do posicionamento do switch na rede. O problema desse
tipo de implementação é que o troubleshooting se torna mais complexo porque muitos
switches acabam trafegando a mesma informação sobre uma VLAN específica e também
broadcasts acabam cruzando muitos switches na rede. Veja a figura abaixo, onde as
VLANs 1 e 2 cruzam vários switches através dos quatro andares da empresa, ou seja,
cruzando muitas vezes a distribuição e o Core da rede.

Normalmente quando utilizamos VLANs fim a fim os usuários são agrupados de acordo com
requisitos comuns e possuem quase o mesmo tipo de padrão de tráfego, seguindo a regra do
80/20, ou seja, 80% do tráfego fica local ao grupo de trabalho e 20% é destinado a
segmentos remotos de rede. Apesar da suposição que apenas 20% do tráfego cruze o Core
para chegar até outra rede devemos lembrar que é possível que 100% do tráfego cruze toda a
rede, por isso esse tipo de arquitetura deve ser muito bem estudada quando for necessária em
campo.
2. Locais (Local VLAN): Nessa arquitetura os hosts são alocados a VLANs conforme sua
localização, andar no prédio, setor em uma mesma infraestrutura, sem cruzar a rede e
ficando restritos entre o acesso e a distribuição. Veja a figura abaixo onde as VLANs
estão divididas localmente por andar.
O design com VLANs locais além de ser mais escalável e tem o troubleshoot mais simples
porque o tráfego das informações é muito mais previsível por estar restrito entre o acesso e a
distribuição. Outra facilidade com essa topologia é que facilita a redundância e minimiza falhas
dentro do mesmo domínio de broadcast.
Outro ponto importante é que maioria das redes atualmente tem um perfil de tráfego conforme
a regra 20/80, ou seja, 20% do tráfego é trocado localmente e os 80% restantes são
destinados a segmentos remotos de rede, o que torna a arquitetura com VLANs locais muito
mais adequada para os perfis de tráfego atuais. É só lembrar que maioria dos serviços
corporativos atualmente ficam disponibilizados em servidores em nuvem, em datacenters ou na
própria Internet.
Em ambos os casos é necessário um dispositivo de camada-3 para fazer o roteamento entre as

VLANs, podendo ser um switch multicamada ou um roteador.

1.2 Planejando a Implementação de VLANs
Ao planejar uma estrutura utilizando VLAN devemos considerar o tráfego e a capacidade dos
links entre os switches. Para isso devemos considerar os padrões de tráfego das aplicações que
vamos utilizar na rede, por exemplo, o tráfego de voz sobre IP se dá diretamente entre os
telefones, porém antes eles trocam sinalização com o Cisco Unified Communications Manager
(CUCM), além disso, outros serviços como email e Citrix possuem outro perfil de tráfego com
diferentes demandas da nossa rede. Resumindo “as aplicações influenciam a largura de banda
que vamos utilizar nos trunks” (links entre switches).
Por isso temos que dimensionar corretamente os links entre acesso e distribuição, distribuição e
core, saída de Internet e assim por diante, para que não tenhamos gargalos na rede. Além
disso, é preciso monitorar esses links e verificar a hora correta para um upgrade de velocidade.
Uma dica prática é que nos links entre Acesso e Distribuição devemos utilizar Gigabit Ethernet
ou 10-Gigabit Ethernet com uma taxa de “oversubscription” menor que 20:1. Por exemplo,
temos 20 clientes conectados a 100Mbps, ao invés de termos um link de
20*100Mbps=2000Mbps, vamos provisionar 2000Mbps/20 = 100Mbps, ou seja, um link fast
apenas entre o switch de distribuição e acesso.
Já entre a distribuição e Core vamos utilizar switches multicamada, links Gigabit Etherchannel
ou 10-Gig Ethernet e “oversubscription” com no máximo 4:1.
Além do que estudamos acima também devemos considerar os seguintes pontos no

planejamento da implementação de VLANs:
 Numeração e nome das VLANs;

 Esquema endereçamento IP (IPv4 e IPv6 se necessário);
 Tipo de estrutura de VLAN - local ou fim a fim;
 Onde os trunks serão necessários para interconectar switches;
 Parâmetros do VTP;
 Scripts de configuração para facilitar a implementação incremental de componentes;
 Plano de verificação e testes de implantação.
1.3 Criação de VLANs e Associação de Portas
Existem duas maneiras básicas de criação e alocação de portas em VLANs, estática e dinâmica
utilizando um servidor VMPS, mas como já citado em tópicos anteriores essa versão de prova
até o momento que o material foi escrito cobre apenas VLANs estáticas.
A grande vantagem da criação de VLANs estáticas é que a alocação de portas é realizada

através de hardware com ASICs (Application Specific Integrated Circuits), o que traz um ganho
em performance porque todo mapeamento de portas é tratado pelo hardware, simplificando o
processo de busca de informações.
O primeiro ponto importante antes de começar a configuração é conhecer a faixa de numeração

de VLANs. Por padrão podemos criar das VLANs 2 a 1001, pois a VLAN 1 e de 1002 a 1005 já
vem criadas por padrão nos switches Cisco Catalyst. Podemos utilizar a VLAN1, porém de 1002
a 1005 são reservadas para compatibilidade com redes mais antigas FDDI e Token Ring.
O sistema operacional dos switches suporta ainda uma faixa estendida de VLANs que vai de 1 a
4094, porém essa faixa não é suportada pelo protocolo VTP e obrigatoriamente você precisa
usar o comando “vtp mode transparent” se for utilizar a faixa estendida quando utilizando as
versões 1 e 2. A versão 3 do VTP já suporta essa faixa, mas ainda não está disponível nos
switches Catalyst baseados no sistema operacional Cisco IOS. Vamos estudar mais sobre o VTP
posteriormente.

Por padrão essas VLANs tem MTU (Maximum Transmission Unit) igual a 1500 bytes.
Dica prática: Ao configurar VLANs da faixa estendida se depois você necessitar voltar atrás
para utilização do protocolo VTP será necessário antes de mudar o estado do VTP de
Transparente para Server ou Cliente, apagar as VLANs da faixa estendida e também refazer o
VLAN Membership colocando as portas que estão associadas aos IDs de 1006 a 4094 dentro da
faixa normal de 1 a 1001.
Para criar as VLANs e fazer o membership nada muda do CCNA R&S para o CCNP, utilizamos os
mesmos comandos, veja abaixo:
1) O VTP deve estar como modo Server ou Transparent para que a criação de VLANs seja
permitida, o modo Client não permite.
2) Criação da VLAN com o comando “vlan”. Note que utilizamos o “name” dentro do modo
de configuração de VLAN e existem outros comandos, porém demos destaque para o
“mtu” (permite alterar o padrão de 1500 bytes caso necessário) e o “shutdown” que
desabilita a VLAN.
SW-DlteC-Rack-01(config)#vlan 700
SW-DlteC-Rack-01(config-vlan)#name Salas-de-aula
SW-DlteC-Rack-01(config-vlan)#?
VLAN configuration commands:
are Maximum number of All Route Explorer hops for this VLAN (or zero
if none specified)
backupcrf Backup CRF mode of the VLAN
bridge Bridging characteristics of the VLAN
exit Apply changes, bump revision number, and exit mode
media Media type of the VLAN
mtu VLAN Maximum Transmission Unit
name Ascii name of the VLAN
no Negate a command or set its defaults
parent ID number of the Parent VLAN of FDDI or Token Ring type VLANs
remote-span Configure as Remote SPAN VLAN
ring Ring number of FDDI or Token Ring type VLANs
said IEEE 802.10 SAID
shutdown Shutdown VLAN switching
state Operational state of the VLAN
ste Maximum number of Spanning Tree Explorer hops for this VLAN (or
zero if none specified)
stp Spanning tree characteristics of the VLAN
tb-vlan1 ID number of the first translational VLAN for this VLAN (or zero
if none)
tb-vlan2 ID number of the second translational VLAN for this VLAN (or
zero if none)

3) Para verificar a configuração saia do modo de VLAN e entre com o “do show vlan brief”
ou com um “end” volte ao modo privilegiado e entre com o comando sem o “do”.
SW-DlteC-Rack-01(config-vlan)#exit
SW-DlteC-Rack-01(config)#do show vlan brief
VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------
1 default active Fa0/21, Fa0/22
10 corp active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Gi0/2
20 sala-aula active Fa0/23
22 VENDAS active
30 vlan-voz active Fa0/4, Fa0/5, Fa0/6, Fa0/11
Fa0/12, Fa0/13, Fa0/14, Fa0/15
Fa0/16, Fa0/17, Fa0/18, Fa0/19
Fa0/20
40 temporaria active
60 VLAN0060 active
100 Teste sus/lshut
700 Salas-de-aula active
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsup
4) Para apagar a VLAN 700 basta repetir o comando de criação com o “no” enfrente, veja
abaixo:
SW-DlteC-Rack-01(config)#no vlan 700

SW-DlteC-Rack-01(config)#do show vlan brief

---- -------------------------------- --------- -------------------------------
Fa0/5, Fa0/6, Fa0/7, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Gi0/2
22 VENDAS active
Fa0/12, Fa0/13, Fa0/14, Fa0/15
Fa0/16, Fa0/17, Fa0/18, Fa0/19
Fa0/20
60 VLAN0060 active
100 Teste sus/lshut

5) Entre em modo de interface, configure a porta como acesso (recomendação da Cisco

para desativar o DTP em portas de acesso) e faça o VLAN Membership, veja abaixo:

SW-DlteC-Rack-01(config-if)#switchport ! opcional
SW-DlteC-Rack-01(config-if)#switchport mode access
SW-DlteC-Rack-01(config-if)#switchport access vlan 700
SW-DlteC-Rack-01(config-if)#
O comando adicional “switchport” garante que a porta seja camada-2, pois uma porta camada-
3 não permite VLAN Membership. Na prática usamos esse comando somente se necessário.
Para verificar a alocação use o mesmo comando show anterior, veja a seguir.
SW-DlteC-Rack-01(config-if)#do show vlan brief

---- -------------------------------- --------- -------------------------------
Fa0/6, Fa0/7, Fa0/9, Fa0/10
Fa0/11, Fa0/12, Fa0/13, Fa0/14
Fa0/15, Fa0/16, Fa0/17, Fa0/18
Fa0/19, Fa0/20, Gi0/2
22 VENDAS active
Fa0/12, Fa0/13, Fa0/14, Fa0/15
Fa0/16, Fa0/17, Fa0/18, Fa0/19
Fa0/20
60 VLAN0060 active
100 Teste sus/lshut
700 Salas-de-aula active Fa0/4
SW-DlteC-Rack-01(config-if)#
Note que utilizamos nesses exemplos um switch que tinha configuração prévia, com VLANs
criadas e VLAN Membership realizado. Analisando a saída anterior tente responder às perguntas
abaixo:
1) Quantas e quais VLANs foram criadas pelo administrador de redes?

2) Quais VLANs não foram criadas pelo administrador de redes e por quê?
3) Todas as VLANs estão ativas?
4) Se houver alguma, qual está inativa e qual o provável motivo?
5) Porque a porta Gig0/1 não aparece na listagem de portas do campo “Ports”?
As respostas estão na próxima página! Responda sem consultá-las!

Repostas:
1) Oito VLANs: 10, 20, 22, 30, 40, 60, 100 e 700.
2) As VLANs padrões: 1, 1002, 1003, 1004 e 1005. Porque elas já vêm criadas no switch.
3) Não.
4) A VLAN 100 provavelmente está shutdown porque está como sus/lshut e não active no
campo Status do comando.
5) Porque ela é uma porta de trunk.
Além do comando show citado acima podemos utilizar outros comandos para verificar a
interface configurada:
 “show running-config” ou “show running-config interface fast 0/4” para verificar
a configuração da interface fast0/4.
 “show mac address-table interface fa0/4”: para verificar os MACs aprendidos
pela interface após a convergência do STP.
 “show interfaces fa0/4 switchport”: mostra opções das portas camada-2, como o
estado do DTP (Dynamic trunk protocol), VLAN alocada, estado operacional e outras
informações.
 “show interfaces fastEthernet 0/4 status”: mostra o status resumido da porta.
SW-DlteC-Rack-01#sho running-config int f0/4


!
switchport access vlan 700
switchport mode access
end
SW-DlteC-Rack-01#show mac address-table interface fastEthernet 0/4

Mac Address Table
-------------------------------------------

---- ----------- -------- -----
700 001d.7060.d31b DYNAMIC Fa0/4
700 90e6.bad0.3f07 DYNAMIC Fa0/4
SW-DlteC-Rack-01#show interfaces fastEthernet 0/4 switchport

Name: Fa0/4
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 700 (VLAN0700)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: none
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
SW-DlteC-Rack-01#show interfaces fastEthernet 0/4 status

Fa0/4 --------------- connected 700 a-full a-100 10/100BaseTX
SW-DlteC-Rack-01#
1.4 Conectando Switches – Trunks ISL e 802.1Q
Até o momento configuramos as portas Access que conectam os hosts, nesse tópico vamos
configurar as portas de trunk, utilizadas para conectar dois switches:
 Portas de acesso: onde são conectados os dispositivos finais, como computadores,
telefones IP, servidores, etc. Comando “switchport mode Access”.
 Portas de tronco ou trunk: as quais são utilizadas para fazer a comunicação entre os
switches. Comando “switchport mode trunk”.
Para que um trunk transporte a informação de todas as VLANs e consiga separar de quem é
cada quadro é utilizada uma técnica chamada “marcação de quadros” ou “frame tagging” e
existem dois padrões para marcação de quadro:
 IEEE 802.1Q – padrão aberto IEEE para comunicação entre Switches.
 ISL (Inter Swicth Link) – padrão proprietário da Cisco que pode não ser suportado
em modelos mais novos de switches Catalyst.
O 802.1 Q e o ISL utilizam uma estrutura de quadro de camada 2 ligeiramente diferente do

quadro original do Ethernet, incluindo um campo para identificar a que VLAN aquele quadro
pertence.
Portanto, quando um switch recebe um quadro por um link trunk ele consegue saber para que
porta ou portas o quadro deve ser encaminhado através da análise da tag ou marcação.
O ISL coloca uma tag no início do frame e outro no final, por isso algumas vezes é chamado de
“Double tag”. No Header do ISL que existe o VID ou VLAN ID, que indica o número da VLAN
que aquele quadro pertence. Veja o quadro do ISL abaixo.
Note que o quadro Ethernet é inserido inteiro e não é alterado pelo ISL. Quando o quadro chega
no seu destino e vai ser encaminhado para uma porta de acesso o ISL precisa apenas retirar o
Header e o FCS para transmiti-lo para a respectiva porta de acesso.
Já no 802.1Q a Tag é inserida no meio do quadro Ethernet original, por isso é chamado de
internnal ou single tagging. Dentro do campo de tag do 802.1Q encontramos VID ou VLAN

ID, que indica o número da VLAN que aquele quadro pertence, o qual tem 12 bits, porém
utilizamos apenas os números de 1 a 4094, porque os números 0 e 4095 são reservados, assim
como o VID 1 é o que por padrão passa a VLAN nativa. Veja a seguir o quadro do 802.1Q.
Uma diferença entre a operação do ISL e 802.1Q é que o quadro ethernet ao ser enviado para
uma porta de acesso pelo 802.1Q vai precisar recalcular o FCS antes da sua transmissão para o
host, isso porque a tag do 802.1Q é inserida no meio do quadro, diferente do ISL que preserva
o quadro ethernet original.
Por padrão os trunks ISL e 802.1Q permitem passar TODAS as VLANs, tem o DTP ativo no
modo “dynamic desirable” e utilizam a VLAN 1 como nativa (sem marcação de quadros -
untegged). Por incrível que pareça a Cisco recomenda alterar todos esses padrões por motivos
de segurança, ou seja:
 Restringir as VLANs que passam pelo trunk por motivos de desempenho e segurança;
 Desativar o DTP para evitar que switches intrusos (rogue switches) entronquem com a
rede;
 Alterar a VLAN nativa e não utilizar a VLAN 1 também para evitar alguns ataques como
Double-tagging que será estudado posteriormente.
Abaixo segue um resumo das configurações de um trunk:
1) Entrar na interface ou range:
Switch(config)#interface tipo mod/porta
2) Comando opcional para fazer com que a porta seja L2:
Switch(config-if)#switchport
O comando é opcional porque ele é o padrão nos switches. Ele deve ser aplicado se a porta
estiver com o comando “no switchport” ativado, o qual faz com que a porta de um switch
multicamada seja camada-3 e não poderá ser configurada como trunk.
3) Configurar o encapsulamento do trunk:
Switch(config-if)#switchport trunk encapsulation {isl | dot1q | negotiate}
A opção “isl” faz com que o encapsulamento seja ISL, o dot1Q é para uso do 802.1Q e a opção
“nogotiate” faz com que o switch negocie o encapsulamento. Caso os dois lados suportem ISL
ele será o preferido.

Nesse ponto tenha atenção porque em alguns switches como as linhas 2950 e 2960 você não
encontrará esse comando, pois eles suportam somente o 802.1Q. A partir dos switches linha
3550 ou 3560 que esses comandos estão disponíveis, porém na prova pode ser cobrado ambos
os casos.
4) Alterar a VLAN nativa e untagged (porém antes a VLAN deve ser criada com o comando
“vlan” em modo de configuração global):
Switch(config-if)#switchport trunk native vlan vlan-id
5) Limitar as VLANs que podem cruzar o trunk ou alterar as configurações prévias,

lembrando que por padrão TODAS as VLANs são permitidas:
Switch(config-if)#switchport trunk allowed vlan {vlan-list | all | {add | except |

remove} lista-das-vlans}
Vamos analisar as opções de configuração desse comando utilizado para administrar a

permissão de VLANs nos trunks a partir do comando “switchport trunk allowed vlan”:
 vlan-list – define as VLANs permitidas utilizando-se traço para definir uma faixa
contínua e vírgulas para separar as faixas, por exemplo, vamos permitir as VLANs de 1 a
5 e a 10: “switchport trunk allowed vlan 1-5,10”.
 all – permite todas as VLANs ativas de 1 até 4094.
 add vlan-list – adiciona VLANs à lista de permissão, por exemplo, queremos que a
VLAN 11 que não estava no comando do exemplo da vlan-list entre na configuração,
utilizamos: “switchport trunk allowed vlan add 11”.
 except vlan-list - permite todas as VLANs ativas de 1 até 4094 exceto as que você
explicitar na lista do vlan-list desse comando.
 remove vlan-list – faz o contrário do comando “add”, retirando VLANs específicas da
lista de permissão de VLANs.
Esse recurso é também conhecido como pruning manual.
6) Configurar o estado do DTP (Dynamic trunk protocol):
Switch(config-if)#switchport mode {trunk | dynamic {desirable | auto}}
O DTP é um protocolo que tem a função de negociar a formação de trunks dinamicamente

enviando quadros a cada 30 segundos. As portas dos switches Cisco Catalyst tem como padrão
o DTP no modo “dynamic desirable” ativado, porém a recomendação geral é a desativação
dessa negociação, para isso utilizamos os comandos abaixo:
Switch(config-if)#switchport mode trunk

Switch(config-if)#switchport nonegotiate
A opção “switchport mode trunk” faz com que o switch fique permanentemente em modo
trunk, porém o DTP está operacional e se a porta remota estiver trunk, dynamic auto ou
dynamic desirable um trunk será negociado e ativado com sucesso. O comando adicional
“switchport nonegotiate” desativa permanentemente o envio dos quadros DTP evitando que um
trunk seja negociado. Nesse caso somente se as duas pontas estiverem com o “mode trunk”
configurado o trunk subirá.
As outras duas configurações tem o seguinte efeito nas portas dos switches:
 Dynamic desirable (padrão) – nesse estado a porta local tenta ativar um trunk
ativamente “pedindo” para o lado remoto através do envio de quadros DTP. Nesse caso
uma porta do outro lado configurada como trunk (sem o nonegotiate), dynamic
desirable ou dynamic auto faz com que o trunk suba.

 Dynamic auto – nesse estado a porta sobe como trunk somente se o outro lado
solicitar, portanto somente se do outro lado tivermos a configuração como trunk ou
dynamic desirable. Duas portas dynamic auto sobem como acesso (Access).
Vamos a seguir ver um exemplo de configuração em um switch Catalyst 2960, o qual não tem o
comando do encapsulamento do trunk por ser 802.1Q. Vamos configurar a interface como
trunk, sem negociação via DTP, permitindo apenas as VLANs 1, 10, 20 e 30 trafegarem quadros
pelo trunk e vamos alterar a VLAN nativa para a VLAN 10.
SW-DlteC-Rack-01(config)#vlan 10
SW-DlteC-Rack-01(config-vlan)#name native
SW-DlteC-Rack-01(config-vlan)#exit
SW-DlteC-Rack-01(config)#int g0/1
SW-DlteC-Rack-01(config-if)#switchport mode trunk
SW-DlteC-Rack-01(config-if)#switchport nonegotiate
SW-DlteC-Rack-01(config-if)#switchport trunk allowed vlan 1,10,20,30
SW-DlteC-Rack-01(config-if)#switchport trunk native vlan 10
SW-DlteC-Rack-01(config-if)#end
SW-DlteC-Rack-01#sho run int g0/1

!
interface GigabitEthernet0/1
switchport trunk native vlan 10
switchport trunk allowed vlan 1,10,20,30
switchport mode trunk
switchport nonegotiate
end
SW-DlteC-Rack-01#
Ao configurar um trunk e ele estiver operacional a interface deve sair da lista do comando
“show vlan”, além disso, podemos analisar as configurações com os comandos show abaixo que
deverão ser cobrados na prova:
 “Show interfaces trunk” ou “show interface gig0/1 trunk”

 “Show interfaces switchport” ou “show interface gig0/1 switchport”
Agora vamos configurar a interface fast0/1 de um switch modelo Catalyst 3560 como trunk,
utilizando 802.1Q, VLAN nativa deve ser a 100, permitindo as VLANs de 2 a 10 e 100
trafegarem pelo trunk e no modo dynamic desirable, fazendo com que a interface envie
quadros DTP para formação de trunk dinamicamente.
CAT-3560#conf t
CAT-3560(config)#
*Mar 1 05:56:52.877: %SYS-5-CONFIG_I: Configured from console by console
CAT-3560(config)#vlan 100
CAT-3560(config-vlan)#name native
CAT-3560(config-vlan)#exit
CAT-3560(config)#int f0/1
CAT-3560(config-if)#switchport trunk encapsulation dot1q
CAT-3560(config-if)#switchport trunk native vlan 100
CAT-3560(config-if)#switchport trunk allowed vlan 2-10,100

CAT-3560(config-if)#switchport mode dynamic desirable

CAT-3560(config-if)#
*Mar 1 00:01:45.142: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/1, changed state to down
*Mar 1 00:01:48.162: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch
discovered on FastEthernet0/1 (100), with CAT-3550 FastEthernet0/3 (1).
*Mar 1 00:01:49.077: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent
peer vlan id 1 on FastEthernet0/1 VLAN100.
*Mar 1 00:01:49.077: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/1 on
VLAN0100. Inconsistent local vlan.
FastEthernet0/1, changed state to up
Note que após a configuração a interface subiu, mas deu um erro de VLAN nativa (CDP-4-
NATIVE_VLAN_MISMATCH), porque uma está 100 (FastEthernet0/1 (100)) e a outra ponta está
no padrão (CAT-3550 FastEthernet0/3 (1)). Vamos agora analisar os comandos show citados
anteriormente e ver o que ocorreu com a configuração:
CAT-3560#show interfaces f0/1 trunk
Port Mode Encapsulation Status Native vlan

Fa0/1 desirable 802.1q trunking 100
Port Vlans allowed on trunk

Fa0/1 2-10,100
Port Vlans allowed and active in management domain

Fa0/1 100
Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 none
Note no primeiro comando que o trunk foi estabelecido, mesmo do outro lado estando no
padrão, sem configuração. Isso porque o padrão é o estado em desirable que forma trunk com
outra ponta desirable. No segundo campo temos a configuração do trunk allowed, permitindo as
VLANs 2 a 10 e a 100, seguido da VLAN permitida ativa, que é só a 100.
Vamos abaixo ao segundo comando para analisar o estado da porta L2 (switchport). Note que
em amarelo temos o estado administrativo e depois o operacional da porta, ou seja, ela está
configurada como dinâmica e desirable, porém operacionalmente logo abaixo mostra que a
porta subiu como trunk. Em verde a mesma coisa para o encapsulamento, ele foi configurado
como 802.1Q e subiu como 802.1Q. Depois podemos ver em cinza que o DTP está ativo, na
sequência em azul que a VLAN nativa é a 100 e lá embaixo em rosa vemos nossa configuração
que fizemos com o comando “switchport trunk allowed”.
CAT-3560#show interfaces f0/1 switchport

Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 100 (native)

Voice VLAN: none
Trunking VLANs Enabled: 2-10,100
Pruning VLANs Enabled: 2-1001
Protected: false
CAT-3560#
Nesse exemplo mostramos vários campos que podem ser cobrados no exame, você pode
receber a saída desses comandos e ter que responder qual o estado do trunk, porque ele não
subiu, etc.
Agora vamos verificar a outra ponta do link e arrumar a configuração, vamos começar com os
comandos show. O switch 3560 está conectado com a porta f0/3 de um 3550 que tem a
configuração padrão de fábrica. Faça a comparação das saídas dos dois switches e note o que
precisa ser alterado via comandos show, esse é um dos tipos de questão que podem cair para
você na prova!
CAT-3550#
CAT-3550#
CAT-3550#sho run int f0/3

!
switchport mode dynamic desirable
end
CAT-3550#sho int f0/3 trunk
Port Mode Encapsulation Status Native vlan

Fa0/3 desirable n-802.1q trunking 1
Port Vlans allowed on trunk

Fa0/3 1-4094
Port Vlans allowed and active in management domain

Fa0/3 1
Port Vlans in spanning tree forwarding state and not pruned

Fa0/3 none

CAT-3550#
CAT-3550#sho int f0/3 switchport
Name: Fa0/3
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: dot1q
Voice VLAN: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Protected: false
CAT-3550#
Vamos então ajustar a configuração do 3550 para parar a mensagem de mismatch da VLAN
nativa e também deixar os dois trunks no mesmo padrão.
CAT-3550#conf t
CAT-3550(config)#vlan 100
CAT-3550(config-vlan)#name native
CAT-3550(config-vlan)#exit
CAT-3550(config)#int f0/3
CAT-3550(config-if)#switchport trunk encapsulation dot1q
CAT-3550(config-if)#switchport trunk native vlan 100
CAT-3550(config-if)#switchport trunk allowed vlan 2-10,100
CAT-3550(config-if)#switchport mode dynamic desirable
Existe um comando opcional para verificar o DTP “show dtp”, que pode ser dado sozinho ou por
interface, segue exemplos abaixo:
CAT-3550#show dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
12 interfaces using DTP

CAT-3550#
CAT-3550#show dtp interface fast0/3
DTP information for FastEthernet0/3:
TOS/TAS/TNS: TRUNK/DESIRABLE/TRUNK
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q
Neighbor address 1: 001C58236483
Neighbor address 2: 000000000000
Hello timer expiration (sec/state): 22/RUNNING
Access timer expiration (sec/state): 293/RUNNING
Negotiation timer expiration (sec/state): never/STOPPED
Multidrop timer expiration (sec/state): never/STOPPED
FSM state: S6:TRUNK
#times multi & trunk 0
Enabled: yes
In STP: no
Statistics
----------
53 packets received (53 good)
0 packets dropped
0 nonegotiate, 0 bad version, 0 domain mismatches,
0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other
56 packets output (56 good)
53 native, 3 software encap isl, 0 isl hardware native
0 output errors
0 trunk timeouts
1 link ups, last link up on Mon Mar 01 1993, 00:01:26
0 link downs
CAT-3550#
Dica prática: Quais os problemas mais comuns quando o trunk não sobe?
1) Estado do DTP, por exemplo, os dois lados como dynamic auto ou um lado como access
e outro como trunk.
2) Domínio de VTP diferente em uma das pontas da conexão, mesmo que um lado ou
ambos sejam transparentes.
1.4.1 Melhores Práticas na Configuração de Trunks

Vamos dar algumas dicas que são descritas como melhores práticas quando trabalhamos com
entroncamento entre switches:
 Alterar a VLAN nativa de 1 para outro valor e não utilizá-la para nenhum usuário (não
alocar portas na VLAN 1 nem na nativa).
 Desativar o DTP com o switchport mode trunk e switchport nonegotiate.
 Em portas que não devem ser trunk desative a negociação, colocando o switchport
mode access ou switchport mode host, comando que coloca a porta como acesso,
ativa o Portfast e desativa a negociação via EtherChannel automaticamente.
 Limitar o tráfego de VLANs para apenas as que serão trafegadas com o comando
“switchport trunk allowed”.

3.3 Voice VLAN e PoE
Os switches Cisco podem ser configurados para inserir dinamicamente os telefones IP em uma
VLAN auxiliar chamada Voice VLAN, para separar os pacotes de voz dos pacotes de dados
provenientes de um computador que pode ser conectado ao telefone IP.
As Voice VLANs permitem que os telefones IP sejam alocados em uma sub-rede IP diferente
dos demais hosts, ter tratamento de QoS (utilizando 802.1Q/p) e políticas de segurança
aplicadas dinamicamente, facilitando inclusive o troubleshooting.
Maioria dos telefones IP Cisco possuem um switch interno de duas portas externas e uma
interna que marcam com o 802.1Q o tráfego de voz, assim como marcam através do bit de
Class of Service (CoS) ajudando a priorização dos pacotes de voz quando eles chegam até os
switches de acesso.
Os dados são enviados sem marcação de quadros (untagged) como a VLAN nativa. Apesar
dessa operação quando utilizamos VLANs de voz não significa que o link é um trunk, pois a
porta continua sendo de acesso, por isso esse recurso é chamado de “multi-VLAN access
port” ou porta de acesso com suporte a múltiplas VLANs.
A VLAN de voz é aprendida pelos telefones IP de maneira estática (configuração manual -

raramente utilizada) ou dinâmica através do protocolo CDP (Cisco Discovery Protocolo -
proprietário da Cisco) ou do protocolo LLDP (Data Link Layer Discovery Protocol - protocolo
aberto padronizado pela IEEE e recomendado para uso com telefones que não sejam Cisco).
Portanto, os telefones IP utilizarão o CDP ou o LLDP para descobrir que VLAN de voz utilizar. O
protocolo a ser utilizado vai depender do modelo do telefone e também do próprio switch, pois
se você utilizar telefones IP Cisco e Switch Cisco o CDP será utilizado por padrão, porém com
telefones IP ou switches de outros fabricantes será necessário o uso do LLDP.
Nada de especial precisa ser feito no caso do uso do CDP, todos os comandos aprendidos no
CCNA R&S e/ou ICND-2 continuam valendo. No caso do LLDP vamos estudar em tópico
posterior.

3.3.1 Configurando VLANs de Voz

Antes de iniciar a configuração da Voice VLAN devemos criar a VLAN em modo global e se
houver necessidade de uso de port-security aumente o máximo de MACs seguros para pelo
menos dois (MAC do telefone IP + MAC do PC conectado à porta do switch). Para configurar a
VLAN de voz utilizamos o seguinte comando:
Switch(config-if)#switchport voice vlan {num-vlan-voz | dot1p | untagged | none}
O padrão é utilizar apenas “switchport voice vlan 10”, o qual tem o opcional “none” por
padrão. Na opção dot1p a voz é inserida na VLAN zero e não é necessário criar uma VLAN
especial para voz. Na opção untegged os pacotes de voz são colocados na VLAN de nativa.
Para verificar é só utilizar o comando “show interface switchport”.
3.3.2 Protocolos CDP e LLDP

Você deve lembrar que o CDP é um protocolo proprietário da Cisco com função
de descobrir informações sobre vizinhos de rede. Ele irá descobrir informações apenas das
interfaces diretamente conectadas e não de redes remotas.
O CDP trabalha na camada-2 do modelo OSI, sendo que seu enquadramento é feito com
quadros SNAP. É importante lembrar que o CDP vem habilitado em todas as interfaces dos
roteadores e switches.
Existem duas versões do Cisco Discovery Protocol, sendo que a versão 1 não é mais utilizada e
a versão passou a ser adotada por ter mais recursos, por exemplo, como as "device-tracking
features". Esse recurso permite reconhecer erros de configuração em LANs nativas e erros de
duplex (mismatched port-duplex) entre dispositivos diretamente conectados. Além disso, como
já estudamos, permite que telefones IP Cisco descubram qual sua VLAN de voz dinamicamente.
Para desabilitar o CDP você pode fazer em modo de configuração global, desabilitando em
todas as interfaces simultaneamente, ou dentro de cada interface. É aconselhável desativar o
CDP nas interfaces onde seu uso não é necessário, pois ele pode ser visto como um risco de
segurança por trazer informações sobre seus vizinhos diretamente conectados. Veja um
exemplo abaixo.
Router#conf t
!desabilita o CDP para todo o roteador
Router(config)#no cdp run
!habilita o CDP para todo o roteador
Router(config)#cdp run
Router(config)#interface s0/0
!habilita o CDP para uma interface específica
Router(config-if)#cdp enable
!desabilita o CDP para uma interface específica
Router(config-if)#no cdp enable
Router(config-if)#end
Router#
Para verificar as informações sobre os vizinhos utilize o “show cdp neighbors”, com o
comando “show cdp neighbors detail” você terá informações mais detalhadas. Veja o
exemplo a seguir.

LAB_A#show cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID LocalIntrfce Holdtme Capability Platform Port ID
Switch Fas 0/1 155 S I WS-C2950-2 Fas 0/2
Switch Fas 0/0 155 S I WS-C2950-2 Fas 0/1
Lab_B Ser 0/0.1 133 R 2620XM Ser 0/0.1
LAB_C Ser 0/0.200 164 R 2620XM Ser 0/0.1
Lab_D Ser 0/0.300 164 R 1721 Ser 0.1
Para verificar informações sobre um vizinho específico, entre com o comando “show cdp entry
hostname_do_vizinho”. O comando “show cdp entry *” tem a mesma função do comando
“show cdp neighbors detail”.
SW-DlteC-Rack-01#show cdp entry SW-DlteC-Sala-01.dltec.com.br

-------------------------
Device ID: SW-DlteC-Sala-01.dltec.com.br
Entry address(es):
IP address: 192.168.1.6
Platform: cisco WS-C2950T-24, Capabilities: Switch IGMP
Interface: GigabitEthernet0/1, Port ID (outgoing port): GigabitEthernet0/1
Holdtime : 126 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA13, RELEASE
SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by cisco Systems, Inc.
Compiled Fri 27-Feb-09 22:20 by amvarma
advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27,
value=00000000FFFFFFFF010221FF00000000000000146937E540FF0000
VTP Management Domain: ''
Native VLAN: 10
Duplex: full
Management address(es):
IP address: 192.168.1.6
SW-DlteC-Rack-01#
Note que o comando detalhado traz várias informações do switch vizinho, tais como o
hostname do vizinho (device ID), endereço IP de gerenciamento, modelo do hardware, versão
do CDP (versão 2), VLAN nativa que o vizinho está utilizando (VLAN 10) e modo do duplex da
porta conectada (full-duplex).
O CDP troca informações via Multicast (endereço ethernet multicast 01-00-0C-CC-CC-CC o

mesmo utilizado pelo VTP) de 60 em 60 segundos. Em caso de perda de comunicação com o
vizinho ele guarda a informações por 180 segundos antes de retirá-la de sua base de dados
(holdtime).
O protocolo LLDP (IEEE 802.1AB) permite que dispositivos de rede como Servidores, Switches e
Roteadores descubram uns aos outros indo além do CDP por ser um protocolo aberto e limitado
aos dispositivos Cisco. Ele opera na camada de enlace do modelo OSI (camada 2) permitindo
que informações básicas como hostname, versão do Sistema Operacional , endereço da
interface, entre outros, sejam aprendidas dinamicamente por equipamentos diretamente
conectados.

A extensão do LLDP chamada de Media Endpoint Discovery extension (LLDP-MED) é muito

utilizada para Telefonia IP e provê informações como VLAN de voz a ser utilizada, prioridades
na marcação de pacotes e quadros para fins de QoS, identificação do local do dispositivo,
funções para PoE, etc.
Por padrão o LLDP vem desabilitado em um switch Catalyst switch e para verificar o status do
protocolo você pode utilizar o comando "show lldp". Para ativar e desativar o LLDP utilizamos o
comando "lldp run" em modo de configuração global e "no lldp run" respectivamente. Veja
exemplo abaixo.
SW-DlteC-Rack-01(config)#do show lldp

% LLDP is not enabled
SW-DlteC-Rack-01(config)#lldp run
SW-DlteC-Rack-01(config)#do show lldp
Global LLDP Information:

Status: ACTIVE
LLDP advertisements are sent every 30 seconds
LLDP hold time advertised is 120 seconds
LLDP interface reinitialisation delay is 2 seconds
Para ativar ou desativar o LLDP em uma interface específica utilize o comando "Switch(config-
if)#[ no ] lldp { receive | transmit }" em modo de configuração de interface.
O comando "show lldp neighbors [ type member/module/number ] [ detail ]" permite verificar
as mesmas informações que estudamos anteriormente via CDP. Veja exemplo a seguir.
SW-DlteC-Rack-01#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID

SEP0023339D0792 Fa0/8 180 B,T 0023339D0792:P1
SEP001D7060D31B Fa0/4 180 B,T 001D7060D31B:P1
SEP001B0C96C5E8 Fa0/5 180 B,T 001B0C96C5E8:P1
Total entries displayed: 3
SW-DlteC-Rack-01#
Lembre-se que o uso do LLDP se faz necessário quando utilizamos dispositivos de outros
fabricantes e assim como a recomendação para o CDP também devemos utilizá-lo somente nas
portas necessárias, desativando o protocolo onde ele não se faz necessário pelo risco de
segurança que ele representa por divulgar informações sobre vizinhos e até mesmo o próprio
dispositivo local.

3.3.3 Power Over Ethernet - PoE

Os telefones IP podem receber a alimentação elétrica através de fontes externas ou
diretamente pelos cabos de rede através de switches PoE, eliminando a necessidade de mais
um ponto de tomada na mesa do usuário. Além disso, através do PoE é mais simples de se
administrar a redundância de energia caso a principal caia, pois precisaríamos apenas de uma
fonte alternativa próximo aos switches de acesso e os telefones permaneceriam ativos.
Existem dois padrões para PoE suportado pelos switches Cisco:

 Cisco Inline Power (ILP)  proprietário da Cisco.
 IEEE 802.3af  padrão aberto.
Ambos os métodos são capazes de verificar se existe um dispositivo que necessita de PoE na
porta, economizando energia.
O 802.3af especifica um método para determinar quanta energia é necessária para alimentar o
dispositivo, onde o switch inicia a fornecer uma pequena voltagem e mede a corrente de
retorno, se uma resistência de 25K ohm for detectada é sinal que um dispositivo alimentado via
PoE está presente na linha. Dispositivos Cisco quando conectados a switches Cisco podem
utilizar o CDP para negociar o PoE quando utilizado o ILP.
Maioria dos telefones IP necessitam 15,4 W de potência especificada no padrão 802.3af (classe
zero), porém novos telefones, access points e câmeras de vigilância podem requisitar mais
potência. O padrão 802.3at especifica até 50 W de potência (classe 4), chamado PoE Plus.
Alguns switches Cisco como os da linha Catalyst 3750-E podem fornecer 20 W de potência,
chamado “enhanced PoE”. As classes de potência vão de zero a quatro.
Porque o switch assume que o dispositivo conectado precisa de 15.4 W até que o dispositivo via
CDP informe algo diferente, é recomendado calcular a quantidade de potência necessária
(power budget) com base nos 15.4 W para cada dispositivo, pois quando um switch reinicia até
que os telefones via CDP informem a quantidade correta de potência o switch vai passar 15.4 W
nas portas ativas com PoE. Dispositivos que não usam CDP terão alocados sempre 15.4 W de
potência.
O PoE pode ser disponibilizado fisicamente de duas maneiras:

 Para o ILP da Cisco através dos pares 2 e 3 do UTP (pinos 1 /2 e 3/4) com 48 V DC.
 Para o IEEE 802.3af pode ser como o ILP ou então utilizando os pares 1 e 4 do UTP
(pinos 4/5 e 7/8).
Outro cuidado é que existem switches Cisco PoE que não suportam o recurso em todas as
portas, por isso tenha cuidado ao especificar ou adquirir um switch, pois existem modelos de 24
portas que suportam PoE apenas nas oito primeiras portas, por exemplo. Outro fator ao
escolher o switch é a potência máxima que ele suporta com PoE. Por exemplo, se você precisar
alimentar 10 dispositivos com 50 W de potência serão necessários 500 W no total, o que nem
todo switch suporta de carga total ou budget de potência.
3.3.4 Configurando e Verificando o PoE

O PoE normalmente é detectado automaticamente pelos switches, portanto eles já fornecem
potência aos dispositivos alimentados via PoE sem necessidades de configuração. Porém
podemos ajustar as configurações, ativando e desativando o PoE das portas. Veja sintaxe do
comando abaixo.
Switch(config)#interface tipo mod/num

Switch(config-if)#power inline {auto [max mili-watts] | static [max-mili-watts] |
never}

Para desativar o PoE utilize o comando “power inline never” e para reativar no padrão utilize
o comando “power inline auto”. Você pode também no auto definir a potência máxima
definida com a opção “Max” ou definir uma potência estática com a opção “static”. Com a opção
“static” o switch não irá mais interagir com o telefone IP para definir a melhor potência, sempre
será no valor definido pelo administrador.
Para verificar o PoE utilize o comando “show power inline [tipo mód/num]”. Veja exemplo
abaixo.
SW-DlteC-Rack-01#show power inline

Available:370.0(w) Used:15.0(w) Remaining:355.0(w)
Interface Admin Oper Power Device Class Max

(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Fa0/1 auto off 0.0 n/a n/a 15.4
Fa0/4 auto on 5.0 IP Phone 7911 2 15.4
SW-DlteC-Rack-01#
Os comandos “debug ilpower controller” e “debug cdp packets” podem ser utilizados para
monitorar a negociação feita entre o dispositivo e o switch para definir a potência ou classe
alocada para a porta.
3.4 VLANs e Trunks para Suporte a Redes Sem Fio
Agora vamos estudar como configurar as portas dos switches para conectar APs autônomos e
LAPs (Lightweight Access Points ou APs controlados por WLCs - Wireless LAN
Controllers) na LAN ou Campus. A parte da configuração dos APs e WLCs não é coberta pelo
CCNP SWITCH, pois faz parte das atribuições da carreira de Wireless (CCNA/CCNP Wireless).
3.4.1 Configurando Suporte a APs Autônomos

Os APs autônomos podem ser conectados para estender a LAN aos clientes sem fio basicamente
de duas maneiras:
 Sem o uso de LANs ou estender uma VLAN específica utilizando uma porta de acesso do
switch, pois nesse caso não é preciso ter um trunk. Nesse caso é preciso de apenas um
SSID.
 Utilizando VLANs para passar múltiplas VLANs através de diferentes SSIDs. Para esse
modelo precisamos configurar um link de trunk entre o switch e o AP.
Vamos configurar o switch para o exemplo a seguir. A conexão é feita na porta giga 1/0/1.

Segue a configuração do switch.
Switch(config)#vlan 10
Switch(config-vlan)#name SSID-DlteC-Aluno
Switch(config-vlan)#vlan 20
Switch(config-vlan)#name SSID-DlteC-Adm
Switch(config-vlan)#exit
Switch(config)#interface gigabitethernet1/0/1
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport trunk allowed vlan 10,20
Switch(config-if)#spanning-tree portfast trunk
Switch(config-if)#end
Switch#
Não se esqueça de verificar a energização do AP, se for via PoE conecte-o a uma porta com
suporte a essa facilidade.
3.4.2 Configurando Suporte a LAPs e WLCs

Os LAPs são projetados para serem configurados pela WLC, conhecido como “zero touch
deployment”, ou seja, não precisa fazer nada nos LAPs, eles inicializam e pegam todas as
configurações da sua controladora (WLC - Wireless LAN Controller). Por padrão os LAPs são
configurados em uma porta de acesso vinculados a uma VLAN específica conforme
planejamento da sua rede.
Além disso, como no AP autônomo precisamos nos preocupar com a energização do LAP que
pode ser feita através de um switch PoE ou utilizando outros métodos como Power injectors ou
fontes de alimentação externa.
No exemplo de configuração a seguir vamos utilizar a VLAN 100 para conectar os LAPs aos
switches de acesso. Nesse caso vamos utilizar a porta giga 1/0/2 do switch para conectar o
LAP. Nessa topologia o WLC utiliza as VLANs 10, 20 e 30 vinculados aos SSIDs DLTEC-1,

DLTEC-2 e DLTEC-3, respectivamente. Veja figura abaixo e na sequência a configuração da

porta do LAP.
Switch(config-vlan)#name Gerencia-LAPs
Switch(config)#interface gigabitethernet1/0/2
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 100
Switch(config-if)#spanning-tree portfast
Switch(config-if)#power inline auto ! comando opcional porque é o padrão do PoE
Switch(config-if)#exit
Note que não é preciso ter as VLANs 10, 20 e 30 chegando até o LAP, porque a comunicação
entre os clientes e o restante da rede é fornecida pelo WLC utilizando um túnel entre ele e o
LAP. As configurações dos SSIDs, VLANs e tudo mais são feitas no WLC e repassadas por ele ao
LAP.
A configuração da porta do switch de distribuição que conecta o WLC deve ser um

etherchannel, conforme desenho da topologia, além disso, deve ser um trunk permitindo as
VLANs 10, 20 e 30. Veja como ficam abaixo as configurações abaixo considerando que o WLC
está conectado nas portas giga 1/0/20 até a 1/0/23 (4 portas em um etherchannel).
Switch(config-vlan)#name SSID-DLTEC-1
Switch(config)#interface range gigabitethernet1/0/20 - 23
Switch(config-if)#channel-group 1 mode on
Switch(config)#interface port-channel 1
Switch(config-if)#switchport encapsulation dot1q
Switch(config-if)#switchport trunk allowed vlan 10,20,30
Switch(config-if)#spanning-tree portfast trunk
Switch(config-if)#no shutdown
O comando “spanning-tree portfast trunk” tem a mesma função do portfast que utilizamos em
portas de acesso desativando os passos do STP na porta, ou seja, passando de blocking para
forward automaticamente. Esse comando deve ser utilizado apenas em links como esse onde o
WLC está terminando a rede e não há possibilidade de caminhos alternativos, senão podem
ocorrer loops de camada-2.

2 Implementação de Ethernchannel – Agregação de Links

Agregação de links ou Link Aggregation já faz parte do novo conteúdo do CCNA R&S (em
nosso material é estudado no preparatório para o ICND-2), porém os alunos que vieram das
versões 640-802 ou abaixo e não fizeram o curso na DlteC provavelmente não estudaram ou
praticaram o assunto, pois em nosso material desde a versão 640-802 já tínhamos laboratórios
sobre esse assunto específico, isso porque sabemos que é muito utilizado nas empresas.
Um EtherChannel ou Link Agregado (Aggregated link) é a combinação de vários links físicos

entre switches para formar uma única conexão lógica.
Isso é feito porque normalmente o Spanning Tree bloqueia links redundantes e não importa
quantos existam entre dois switches ele mantém somente um ativo.
Os EtherChannels tratam essa característica habilitando o balanceamento de cargas (load

balancing) entre os links físicos que fazem parte do grupo e criando uma conexão lógica que é
enxergada pelo STP como uma única interface. Claro que para evitar loops de camada-2 os
switches devem entender essa configuração e fazer um tratamento especial do tráfego através
desse bundle ou grupo de interfaces.
Outro ponto interessante é que o próprio protocolo de agregação trata a questão da

redundância, sendo que se um link ficar indisponível tudo continua funcionando normalmente,
assim como no retorno desse link o próprio protocolo faz com que ele retorne ao grupo
automaticamente sem intervenção do administrador de redes.
Podemos fazer um grupo de links agregados de dois até oito links de 100Mbps, 1Gbps ou
10Gbps, se contarmos que um link de 10Gbps full-duplex tem um throughput total (Tx + Rx)
de 20Gbps podemos criar um link agregado de 160Gbps!
A formação do link agregado segue algumas regras, não podemos formar etherchannels de
qualquer maneira e para a prova esse é um assunto normalmente cobrado. Veja abaixo a lista
de pré-requisitos para formação do link agregado:
 As portas devem ter a mesma configuração de speed e duplex.

 Todas as portas no grupo devem estar ativadas.
 Nenhuma porta no grupo pode ter o SPAN ativado (espelhamento de portas).
 Se não forem trunks as portas precisam estar na mesma VLAN.
 Se as portas estiverem configuradas como trunks devem ter as mesmas VLANs
permitidas e ter a mesma VLAN nativa configurada.
 As interfaces devem ter as mesmas configurações relativas ao STP.

Outras dicas úteis:

 A configuração aplicada ao Port Channel (interface lógica) afeta todo EtherChannel.
 Já a configuração aplicada a uma interface física específica afeta somente aquela
interface.
 Se você quiser fazer um link agregado layer-3 o endereço IP deve ser configurado na
interface lógica (Port Channel).
2.1 Balanceamento de Cargas no Etherchannel
O balanceamento do tráfego entre os links pode ser feito por endereço MAC, IP ou número de
porta TCP/UDP (suportado apenas em switches de maior porte como 4500 e 6500). O comando
para configurar o balanceamento de cargas é executado em modo de configuração global,
portanto ela vai valer para todos os links agregados configurados. Segue exemplo abaixo:
SW(config)#port-channel load-balance tipo
As opções de configuração do tipo de balanceamento seguem abaixo:
 src-ip - Endereço IP de origem e existe em todos os modelos de switches Catalyst com

Cisco IOS.
 dst-ip - Endereço IP de destino e existe em todos os modelos.
 src-dst-ip – Endereço IP de origem e destino através de um XOR. Existe em todos os
modelos. Padrão quando os switches utilizam L3.
 src-mac – MAC de origem e existe em todos os modelos. Padrão para switches L2.
 dst-mac - MAC de destino e existe em todos os modelos.
 src-dst-mac - Endereço MAC de origem e destino através de um XOR. Existe em todos
os modelos.
 src-port – Porta de origem e existe apenas para as linhas 6500 e 4500.
 dst-port - Porta de destino e existe apenas para as linhas 6500 e 4500.
 src-dst-port - Porta de origem e destino através de um XOR. Existe apenas para as
linhas 6500 e 4500.
Podemos verificar o modo de operação com o comando “show etherchannel load-balance”

ou no comando “show etherchannel port-channel”, veja exemplo abaixo:
SW-DlteC-Rack-01#show etherchannel load-balance

EtherChannel Load-Balancing Configuration:
src-mac
EtherChannel Load-Balancing Addresses Used Per-Protocol:

Non-IP: Source MAC address
IPv4: Source MAC address
IPv6: Source MAC address
SW-DlteC-Rack-01#
Um ponto interessante sobre o balanceamento é feito de forma determinística e nem sempre

vai ser feito por igual, pois isso depende do número de links utilizados do algoritmo de hashing
utilizado para determinar a porta de saída.
Esse algoritmo pode levar em conta os últimos bits dos tipos de endereços utilizados no
balanceamento ou um OR exclusivo (XOR quando dois endereços são utilizados no
balanceamento) para determinar as portas que serão utilizadas para os fluxos que estão
passando pelo etherchannel. No final ele é utilizado para calcular um padrão binário que define
o número do link que deve ser utilizado para transportar cada quadro.

Para determinar a porta que deve receber um fluxo são utilizados índices, por exemplo, um
link agregado com duas portas necessitará de dois índices apenas, portanto um bit só será
necessário, pois teremos 0 e 1. Se 4 portas forem utilizadas precisaremos de dois bits para
representar as portas: 00 (porta 0), 01 (porta 1), 10 (porta 2) e 11 (porta 3). A mesma lógica
segue até o máximo de oito portas agregadas que utilizará três bits (2^3=8).
2.2 Configurando um Etherchannel
Basicamente para criar um link agregado L2 você precisa configurar uma interface lógica (port-
channel) e inserir interfaces no grupo (channel-group):
SW(config)#interface port-channel num
Para transformar o link agregado em Layer 3 basta fazer as seguintes configurações (dentro
das configurações do port-channel):
SW(config-if)#no switchport
SW(config-if)#ip address endereço máscara
O próximo passo é inserir interfaces físicas ao grupo (lembrando-se das condições que foram
citadas no início do capítulo para que um link agregado suba). Se você não criar o port-channel
e configurar direto o passo 2, inserindo as interfaces ao um mesmo channel-group o port-
channel é criado automaticamente.
Nessa fase de inserir os links físicos nos grupos podemos escolher entre dois protocolos: Port
Aggregation Protocol (PAgP – proprietário da Cisco) e o Link Aggregation Control
Protocol (LACP – protocolo aberto da IEEE).
Abaixo seguem as configuração do PAgP.
SW(config)#interface tipo mód/num

SW(config-if)#channel-protocol pagp
SW(config-if)#channel-group num mode {{auto | desirable} [non-silent] | on}
A primeira etapa da configuração é entrar na interface e definir o “channel-protocol” como

“pagp”. Na sequência definimos o número do port-channel deve ser o mesmo que você vai
utilizar no channel-group (num), podendo ir de 1 a 64. Esse número deve ser o mesmo em
todas as interfaces físicas participantes do link agregado.
O Port Aggregation Protocol (PAgP) pode negociar dinamicamente a formação do canal

agregado e podemos configurar três modos de operação:
 On: não existe negociação utilizando PAgP e a outra ponta deve estar como On
obrigatoriamente para o link agregado subir.
 Auto: a porta responde ao PAgP sem iniciar a negociação. Esse é o padrão e na outra
ponta temos que ter o desirable configurado para que haja negociação do etherchannel.
 Desirable: a porta nesse estado negocia através de mensagens do PAgP o
estabelecimento do link agregado. A outra ponta pode estar como Auto ou Desirable que
a negociação será bem sucedida.
A opção “non-silent” pode ser utilizada quando sabemos que do outro lado teremos com
certeza um switch que “fala” PAgP também, nesse caso na prática se a porta não “ouvir”
pacotes do PAgP a porta até sobe, mas ela informa ao STP que a porta está down e o tráfego
não vai passar. Com o padrão que é o “silent mode” mesmo que a porta remota não seja
capaz de entender o PAgP ela sobe e permite que o tráfego seja passado, porém sem fazer

parte do grupo. Isso permite que um servidor ou analisador de redes seja conectado naquela
porta e você pode analisar o tráfego de pacotes do protocolo PAgP.
Agora vamos às configurações do LACP:
SW(config)#lacp system-priority prioridade

SW(config)#interface tipo mód/num
SW(config-if)#channel-protocol lacp
SW(config-if)#channel-group num mode {passive | active | on}
SW(config-if)#lacp port-priority prioridade
O comando “lacp system-priority” permite alterar o padrão de quem fará a tomada de

decisões, pois por padrão a prioridade é 32.768, indo de 1 a 65.535, onde com os padrões o
switch com menor MAC vai definir as prioridades de porta e do LACP.
Depois entramos na interface e como fizemos para o PAgP iniciamos definindo o “channel-
protocol”, mas agora como “lacp”.
Na sequência vamos definir o channel-group, que vai de 1 a 64 e precisa ser o mesmo em

todas interfaces físicas do grupo, e o modo que pode ser:
 On: desabilita a negociação via LACP e deve ter a outra ponta como On
obrigatoriamente para subir.
 Active: negocia ativamente a formação do link agregado via pacotes LACP. A outra
ponta pode ser Passive ou Active.
 Passive: somente responde à mensagens LACP sem iniciar a negociação. Vai fazer
parte do link agregado somente se a outra ponta estiver como Active.
O último comando “lacp port-priority prioridade” (padrão 32.768 e vai de 1 a 65.535)

permite que você configure mais interfaces que o permitido (mais de 8 links) no etherchannel
para ter um backup caso as portas ativas falhem e você não queira reduzir a velocidade. O
valor deve ser menor para as portas ativas e maior para as que serão standby deixadas como
reserva.
2.3 Exemplo de Configuração do PAgP
Nesse exemplo termos o SW1 conectado ao SW2 via interfaces fast0/46, fast0/47 e fast0/48,
pois ambos são switches de 48 portas. Vamos configurar nesse exemplo as seguintes
características:
 Vamos utilizar o grupo 1 para criar o link agregado.
 Balanceamento através dos IPs de origem e destino.
 Como ambos os switches suportam PAgP não vamos esperar que dispositivos “silent” e
exigir uma negociação ativa na interface com o “non-silent” em ambas as pontas.
Configuração do switch SW1:
SW1(config)#port-channel load-balance src-dst-ip

SW1(config)#int range fast1/0/46 - 48
SW1(config-if-range)#channel-protocol pagp
SW1(config-if-range)#channel-group 1 mode desirable non-silent
Creating a port-channel interface Port-channel 1
SW1(config-if-range)#
FastEthernet1/0/46, changed state to down


FastEthernet1/0/48, changed state to up
Note que as interfaces físicas subiram, mas o port-channel (interface lógica) ainda não subiu.
Agora vamos ao switch SW2.
SW2(config)#port-channel load-balance src-dst-ip

SW2(config)#int range fast 0/46 - 48
SW2(config-if-range)#channel-protocol pagp
SW2(config-if-range)#channel-group 1 mode desirable non-silent
SW2(config-if-range)#
*Mar 1 00:07:20.385: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-
channel1, changed state to up
*Mar 1 00:07:22.113: %LINK-3-UPDOWN: Interface Port-channel1, changed state to
up
Após configurarmos os dois lados a porta lógica ou port-channel subiu. Vamos utilizar alguns
comandos show para verificar se a configuração está correta e operacional. O primeiro
comando é o “show etherchannel summary”, no qual podemos ver o grupo (Group - 1), a
interface lógica criada (Port-channel - Po1), o protocolo (Protocol PAgP) e as interfaces que
fazem parte do grupo (Ports - Fa1/0/46(P) Fa1/0/47(P) Fa1/0/48(P)).
SW1#show etherchannel summary

Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1

Number of aggregators: 1
Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Fa1/0/46(P) Fa1/0/47(P) Fa1/0/48(P)

Note que na porta Po1 aparece entre parênteses SU, que quer dizer que a porta é L2 (S –
Layer2) e está em uso (U – in use).
Note que nas interfaces do campo Port temos um P que significa que a porta está no grupo ou
“bundled in port-channel”. Se a porta estivesse conectada, mas fora do grupo apareceria um I
(Stand-alone). Se a porta estiver shutdown ela apareceria com um D, veja exemplo abaixo
onde demos um shut na interface fast0/48 de SW2.

###saídas omitidas ####

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Fa1/0/46(P) Fa1/0/47(P) Fa1/0/48(D)
SW1#
Agora vamos subir a interface f0/48 de SW2 como half-duplex e ver o que acontece:
SW2(config)#int f0/48
SW2(config-if)#shut
SW2(config-if)#
*Mar 1 00:20:34.610: %LINK-5-CHANGED: Interface FastEthernet0/48, changed state
to administratively down
SW2(config-if)#
SW2(config-if)#duplex half
SW2(config-if)#no shut
SW2(config-if)#
*Mar 1 00:22:29.475: %EC-5-CANNOT_BUNDLE2: Fa0/48 is not compatible with Fa0/46
and will be suspended (duplex of Fa0/48 is half, Fa0/46 is full)
*Mar 1 00:22:29.836: %LINK-3-UPDOWN: Interface FastEthernet0/48, changed state
to up
Note que a interface subiu, mas apareceu uma mensagem “%EC-5-CANNOT_BUNDLE2”

informando que a interface está como half e o outro lado full-duplex e ela não será inserida no
grupo. Vamos ver com o comando show anterior o estado dessa interface, note que ela
aparecerá com um s minúsculo, indicando que está suspensa.

###saídas omitidas ###

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Fa1/0/46(P) Fa1/0/47(P) Fa1/0/48(s)
Abaixo segue a lista de comandos show que podem ser utilizados e cobrados no exame:
 Verificar o estado do EtherChannel e as portas que são parte do grupo - show

etherchannel summary ou show etherchannel port
 Verificar quando o etherchannel foi alterado EtherChannel - show etherchannel port-
channel
 Verificar o detalhe de cada componente do EtherChannel - show etherchannel detail
 Verificar o algoritmo de hashing do Etherchannel - show etherchannel load-balance
 Verificar o índice utilizado pelo algoritmo de hashing por porta e se a porta está em
silent ou non-silent mode - show etherchannel port

 EtherChannel neighbors on each port - show {pagp | lacp} neighbor

 LACP system ID - show lacp sys-id
2.4 Exemplo de Configuração do LACP
Nesse exemplo termos os mesmos SW1 e SW2 conectados via interfaces giga 1 e 4. Vamos
configurar nesse exemplo as seguintes características:
 Vamos utilizar o grupo 2 para criar o link agregado (o 1 está sendo utilizando).
 O SW1 deve ser ter prioridade nas decisões.
 As portas devem ter prioridade 100.
 Ambos os switches devem ser capazes de iniciar a negociação via envio de pacotes
LACP.
Configuração do switch SW1:
SW1(config)#lacp system-priority 100

SW1(config)#int range gigabitEthernet 1/0/1, giga 1/0/4
SW1(config-if-range)#channel-protocol lacp
SW1(config-if-range)#channel-group 2 mode active
SW1(config-if-range)#lacp port-priority 100
Configuração em SW2:
SW2(config)#int range gigabitEthernet 0/1, giga 0/4

SW2(config-if-range)#channel-protocol lacp
SW2(config-if-range)#channel-group 2 mode active
SW2(config-if-range)#lacp port-priority 100
Agora vamos verificar a configuração vendo o resumo do etherchannel com o “show

etherchannel summary”. Note que a porta Po2 foi criada com o protocolo LACP e as portas
giga 1 e 4 de cada lado estão fazendo parte do grupo com sucesso.

###saídas omitidas ###

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Fa1/0/46(P) Fa1/0/47(P) Fa1/0/48(P)
2 Po2(SU) LACP Gi1/0/1(P) Gi1/0/4(P)
3.5 Evitando Problemas de Configuração com Etherchannel Guard
Esse recurso vem ativado por padrão nas interfaces para evitar que problemas no STP (loops)
ocorram em caso de configurações erradas em links Etherchannel.
No caso do switch detectar erro de configuração, ou seja, ambos os lados da conexão

etherchannel não estarem configurados corretamente, as portas são desativadas e entram em
error disable, evitando que loops ocorram devido ao STP ser desativado em portas que
participam de um mesmo grupo de agregação de links.
Um exemplo típico é conectar cabos em um dos lados da conexão em portas diferentes das
planejadas, por exemplo, no switch local e remoto o etherchannel deveria estar configurado nas
portas g1/0/1 e g1/0/2, porém no switch remoto as portas conectadas foram as g1/0/23 e

g1/0/24 que são portas de acesso. Nesse caso o etherchannel guard vai detectar que as portas
remotas não estão configuradas para participar do grupo de agregação de links desativando as
interfaces e avisando com uma mensagem de "%PM-4-ERR_DISABLE: channel-misconfig
(STP) error detected on Gi1/0/1, putting Gi1/0/1 in err-disable state".
Se entramos com o comando "show interface g1/0/1" poderemos confirmar que a porta está
em error disable. Outro comando útil é o "show interfaces status err-disabled" que mostra
apenas as interfaces nesse estado.
Switch#show interface status err-disabled

Port Name Status Reason Err-disabled Vlans
Gi1/0/1 err-disabled channel-misconfig (STP)
Gi1/0/2 err-disabled channel-misconfig (STP)
Po1 err-disabled channel-misconfig (STP)
Switch#
Para reativar a porta deveremos corrigir o problema de conexão e dar um "shut/no shut" na
interface "Po1" para que as interfaces do grupo voltem a funcionar e o etherchannel seja
formado.
Switch(config)#interface port-channel1
Switch(config-if)#shutdown
Switch#

3 VTP - VLAN Trunking Protocol

O VLAN Trunking Protocol (VTP) é proprietário da Cisco e tem o objetivo de sincronizar os
bancos de dados de VLAN em todos os switches de um mesmo domínio de VTP, sendo que ele
roda través dos links de trunk configurados entre os switches. Portanto, com o VTP mantemos a
consistência na criação e envio da informação de VLAN dentro do domínio.
Um domínio (VTP domain) é um grupo administrativo e todos os switches devem ter o mesmo
nome de domínio configurado para que suas bases de dados de VLAN possam ser
sincronizadas.
O VTP trabalha utilizando o conceito de números de revisão (Configuration Revision

Numbers) e anúncios (VTP advertisements). Vamos sumarizar os principais pontos abaixo:
 Os anúncios de VTP são enviados a cada 5 minutos ou quando uma alteração na base de
dados de VLAN ocorre, ou seja, uma VLAN foi criada, apagada ou renomeada.
 Os anúncios de VTP possuem um número de revisão que é acrescido a cada nova
configuração de VLAN.
 Quando um switch recebe um anúncio de VTP ele compara o número de revisão com o
número atual da sua VLAN database.
 Se o número for maior que o contido em sua base de VLANs o switch local sobrescreve a
base com as novas informações e repassa o anúncio aos seus vizinhos.
 Se o valor é igual o switch local ignora o anúncio.
 Se o número é menor o switch local responde ao vizinho com a informação
desatualizada com a versão mais atual contida na sua base de dados de VLAN.
A base de dados de VLANs utilizadas pelo VTP é o arquivo vlan.dat que fica localizado
normalmente na memória flash dos switches.
Esse é um passo importante na configuração de seus switches, o de utilizar ou não o VTP. No

CCNA R&S mais atual a recomendação é desabilitar ou deixar todos os switches no VTP modo
transparente, assim o VTP não vai influenciar na sua rede de switches.
Se você escolher utilizar o VTP deve definir um nome de domínio e é aconselhável também
utilizar uma senha para o domínio. Em seguida deve definir quem será o switch que fará o
papel de servidor, quem serão os clientes e se terão switches não participarão do VTP e serão
configurados como transparente. Vamos ver no tópico a seguir o que cada função significa.
3.1 Versões e Modo do VTP
Existem três versões de VTP suportadas atualmente pelos switches com Cisco IOS: VTP versão
1, 2 e 3. A versão 3 do VTP não é suportada por versões mais antigas de Cisco IOS.
Para utilizar a versão 2 todos os switches devem suportá-la, pois não existe compatibilidade
entre a v1 e a v2. A versão 2 do VTP tem alguns suportes adicionais à versão 1 que são:
 Suporte a VLANs Token Ring.

 Switches configurados como Transparente passam mensagens para versão 1 e 2.
 As verificações de consistência são realizadas somente quando mudanças de
configuração são realizadas através do CLI ou SNMP.
 Suportam VLANs de 1 a 1005, não suportando a faixa de VLANs estendidas.
A versão 3 do VTP já suporta a faixa de VLANs tradicional (1 a 1005) e estendida (1006 a

4094).

O VTP possui quatro modos de operação, vamos estudar mais sobre cada um deles abaixo:
 Server Mode: esse é modo padrão do VTP, o qual permite que VLANs sejam criadas,
apagadas e renomeadas. O servidor VTP deve originar anúncios periódicos e também
disparados por eventos (triggered) para sincronizar a base de dados de VLANs dos
switches do domínio. Devemos ter pelo menos um servidor no domínio configurado
como server.
 Client Mode: o cliente não pode criar, apagar ou renomear VLANs, suas funções são
sincronizar sua base de dados com o servidor e repassar informações para outros
switches, ou seja, atuar como “relay” (encaminhador) de informações.
 Transparent Mode: esse modo permite tudo que o servidor faz, porém localmente, ou
seja, o transparente cria, apaga e altera VLANs na sua base de dados local e não
sincroniza com os anúncios recebidos. Apesar disso ele pode encaminhar a outros
switches os anúncios recebidos através de seus trunks.
 Off Mode: assim como os switches em transparent mode os switches em OFF Mode não
participam do VTP, porém além de não sincronizar a base de dados de VLANs eles agora
não encaminham anúncios, ou seja, o modo VTP off desativa TODA atividade do VTP no
switch. Não é suportado por versões mais antigas de Cisco IOS.
3.2 Anúncios do VTP
Os anúncios do VTP são enviados em Multicast e apenas para as VLANs dentro da faixa normal
de 1 a 1005, a faixa de VLANs estendida não é suportada pelas versões 1 e 2 do VTP. Para
utilizar o VTP com a faixa estendida a Cisco criou o VTP versão 3.
Os anúncios sempre iniciam com o número de revisão igual a zero e os switches guardam o
último anúncio recebido com o número de revisão mais alto. Se você lembrar o início do
capítulo aqui tem um dos segredos e perigos do VTP, pois se o switch receber um número de
revisão maior que o anterior ele simplesmente apaga toda a base e reescreve com as
informações contidas no novo anúncio.
Por isso, quando um switch tiver que ser conectado à rede é preciso se preocupar com esse
fato, principalmente se ele já foi configurado em outro domínio, pois o reload ou desligar e ligar
o switch não zera o número de revisão, para fazer isso primeiro temos que seguir alguns
passos:
1) Passar o switch para o modo transparente;
2) Voltar para o modo servidor;
3) Alterar o domínio de VTP para um nome que não exista no domínio atual;
4) Reconfigurar o nome do domínio para o original.
Dessa maneira o switch que será inserido na rede terá o número de revisão zero e quando
receber a informação mais atual sincronizará sua base de dados de VLAN e não teremos
problemas de sincronização de VLAN (VLAN synchronization problem).
Os anúncios ocorrem em três formatos:

 Summary advertisements: Enviados pelos servidores por padrão a cada 5 minutos
(300 segundos) ou quando ocorre uma alteração na base de dados de VLAN. O anúncio
inclui o domínio, versão do VTP, número de revisão, time stamp (hora que foi gerado),
hash MD5 e o número de configurações que devem ser realizadas. Quando temos uma
alteração o anúncio pode conter instruções sobre o que foi alterado.
 Subset advertisements: Esse anúncio é enviado pelo servidor com informações depois
que uma alteração na configuração das VLANs ocorre. Lista o que mais especificamente
ocorreu de mudança.

 Advertisement requests from clients: O cliente utilize esse tipo de mensagem para
solicitar alguma informação faltante sobre qualquer VLAN. Pode ser enviado quando a
base de dados é apagada, por exemplo.
3.3 Configuração do VTP
A configuração do VTP é muito mais simples que sua teoria, basicamente temos que definir os
seguintes itens:
1) Nome do domínio:
SW(config)#vtp domain name
2) Modo de operação:
SW(config)#vtp {server | client | transparent | off}
3) Senha do domínio:
SW(config)#vtp password senha [ hidden | secret ]
4) Versão do VTP:
SW(config)#vtp version {1 | 2 | 3}
Para verificar a configuração utilizamos os comandos:
 Show vtp status: verificar o estado do VTP, domínio, senha, quem é o servidor e
quando a última atualização foi enviada, número de revisão, etc.
 Show vtp counters: para verificar a contagem das mensagens enviadas e erros
ocorridos.
Veja a saída do comando para verificação do estado do VTP abaixo:
SW-DlteC-Rack-01#sho vtp status

VTP Version : running VTP2
Configuration Revision : 11
Maximum VLANs supported locally : 255
Number of existing VLANs : 13
VTP Operating Mode : Server
VTP Domain Name : dltec
VTP Pruning Mode : Disabled
VTP V2 Mode : Enabled
VTP Traps Generation : Disabled
MD5 digest : 0x27 0xC4 0x4D 0xA1 0x97 0xE9 0xC1 0x2E
Configuration last modified by 192.168.1.5 at 7-24-14 20:09:01
Local updater ID is 192.168.1.5 on interface Vl10 (lowest numbered VLAN interface
found)
SW-DlteC-Rack-01#
Note que temos a versão do VTP (VTP2), o número de revisão (11), número de VLANs
configuradas (13), o modo operacional (Server), o domínio (dltec) e quem e quando foi
atualizada a última vez as informações do VTP (enviado um summary adv por 192.168.1.5 na
data/hora de 7-24-14 20:09:01). Como o switch é o server e não temos outro nessa rede ele
mesmo se atualiza, em outro switch esse IP deve ser diferente se ele for cliente.

Lembre-se que ao configurar um switch como cliente o comando “vlan x” em modo de

configuração global não vai entrar mais, pois ele só é permitido em modo servidor ou
transparente.
3.4 VTP Pruning
No início do curso fizemos uma revisão do funcionamento dos switches e lembramos que
quadros de broadcast, multicast ou com destino não encontrado na CAM table são inundados
(flooded) para todas as interfaces, menos para quem recebeu a informação. Esse flood é feito
tanto para as portas de acesso como nos trunks que tem aquela VLAN ativa e permitida.
Com o comando “switchport trunk allowed” conseguimos reduzir esse efeito especificando
que VLANs deveriam ou não passar, porém o VTP tem um recurso que permite a mesma tarefa
de filtrar o tráfego desnecessário dinamicamente com o recurso chamado VTP Pruning.
Como isso é feito você deve estar se perguntando, correto? Quando configuramos o VTP cada
vez que uma porta é alocada a uma VLAN o vizinho envia um aviso, o que permite que os
vizinhos decidam se uma informação deve ou não ser repassada via flooding aos seus outros
vizinhos.
Por exemplo, temos SW1 conectado em série com SW2, o qual está conectado a SW3. Em SW1
temos as VLANs 10 e 20 alocadas às suas portas, em SW temos as mesmas VLANs, mas em
SW3 temos apenas a VLAN10. Tem sentido SW3 receber quadros da VLAN 10? Com certeza
não, portanto SW2 vai filtrar floods destinados às VLANs 10 no trunk entre ele e SW3, simples
assim. Veja a figura abaixo com esse exemplo.
O pruning não vem ativo por padrão e para ativá-lo basta inserir o comando “vtp pruning” em
modo de configuração global pelo menos no switch VTP Server ou em todos os switches do
domínio.
Uma vez ativado ele fará o pruning para as VLANs de 2 a 1001, pois as VLANs reservadas (1 e
de 1002 a 1005) ou faixa estendida (1006 a 4098) não são elegíveis ao pruning automático.
Essa regra vale tanto para o VTP versões 1 e 2 como para o VTP v3.
Para alterar o comportamento padrão de atuação sobre a faixa de VLANs de 2 a 1001 podemos
utilizar um comando em modo de interface adicionando palavras chaves parecidas com as que
estudamos para o comando "switchport trunk allowed", veja abaixo:
- switchport trunk pruning vlan {{{add | remove | except} lista-de-vlans} | none}

Por exemplo, se quisermos mesmo assim passar a VLAN 20 para o switch SW3 do exemplo
anterior podemos utilizar o comando “switchport trunk pruning vlan add 20” na interface
de trunk do switch SW2. Para verificar o estado do VTP pruning você pode utilizar o comando
“show interface tipo mod/num pruning”.
Cuidado ao configurar o pruning em switches transparentes, pois nesse modo essa feature não
funciona e você deve utilizar o switchport trunk allowed para fazer o pruning manual.
Outra "pegadinha" com o pruning automático é a filtragem da VLAN 1, pois ela não é feita de
maneira nenhuma automaticamente como já estudamos, porém você pode configurar na
interface trunk o comando para fazer o pruning manual: "switchport trunk allowed vlan
remove 1", evitando assim que ela seja propagada no domínio. Maioria dos switches devem
aceitar esse comando, porém existem exceções como os switches Catalyst 2900XL/3500XL.
4 Dicas de Troubleshooting
Quando falamos em resolução de problemas ou troubleshooting é importante entender em que
fase estamos do ciclo de vida de nossa rede.
Por exemplo, em uma fase de projeto ou design no máximo vamos testar a topologia em
laboratório ou simulador. Já em uma fase de implantação onde nenhum usuário está utilizando
a rede vamos encontrar ajustes no projeto ou erros de configuração durante a instalação dos
equipamentos.
Após o ambiente entrar em produção podemos ter problemas com o cabeamento, energia e
configurações durante o processo de “Change Management” (Gerenciamento de
Mudanças), isso se o ambiente for controlado e tiver processos estabelecidos para
manutenção e/ou necessidades mudanças.
Portanto os problemas de configuração podem ocorrer quando o tráfego do usuário precisa

cruzar diversos switches e vamos dar dicas nesse tópico sobre os principais problemas e mais
comuns que podem ocorrer.
É aconselhável antes de iniciar o troubleshooting ter uma metodologia e criar um plano de

ação, por exemplo, verificar o plano de implementação original e procurar se nenhuma
mudança não planejada foi realizada e afetou o ambiente em produção.
Outro ponto comum de problema em ambientes em produção é a implementação de changes

(mudanças) devidamente aprovadas que geraram problemas que não foram detectados durante
a fase de validação e testes, por isso procure sempre se não houve nenhuma alteração quando
um problema foi detectado.
4.1 Conectividade de Usuários
Problemas de conectividade de usuários podem ter várias fontes, vamos citar algumas abaixo:
 Problemas físicos: verifique cabos, placas de rede (LED traseiro da placa de rede está
aceso?), portas dos switches (LED de link está aceso?), etc.
 Verificar o Switch: procure por erros de FCS e “late collisions” para detector
problemas com a configuração do duplex e velocidade. Verifique se a porta está ativa e
configurada como acesso (switchport mode access ou switchport mode host).
 Configuração de VLAN: verifique se a porta está configurada com a VLAN correta.
 VLANs Permitidas: verifique se a VLAN do usuário com problema está permitida nos
links de trunk.

Uma dica prática interessante é verificar se o computador está pegando IP dinâmico via DHCP
ou não, pois se ele não tem o IP configurado via DHCP o problema normalmente está realmente
na LAN, seja na porta ou no cabeamento.
Se o computador está pegando IP teste a conectividade com ping passando pelos principais
pontos de roteamento da sua rede. Nesse ponto é importante que você tenha uma
documentação com o design da rede, switches de distribuição, core, pontos de roteamento,
saída para a Internet e demais dispositivos com seus respectivos endereços.
Outra dica prática é se temos apenas um usuário com chamado aberto ou diversos em um
mesmo switch ou segmento de rede, pois se diversos estão abrindo chamado no seu Help Desk
ou Service Desk é sinal de um problema mais grave e com um dispositivo de rede ou cabo
entre o acesso e a distribuição.
4.2 Conexão entre Switches - Trunking
Quando vamos fazer troubleshooting em links de trunk o primeiro passo é verificar se não
existe um problema físico. Depois de analisar e ter certeza que as portas e o cabeamento estão
operacionais passe para outros pontos, tais como:
 Os dois lados do link estão configurados como trunk?

 Se o DTP está ativado o modo operacional está correto?
 O encapsulamento das portas trunk estão iguais conforme planejado?
 Se utilizando 802.1Q a VLAN native está igual dos dois lados do link? Verifique se existe
mensagens do CDP avisando esse erro.
 As mesmas VLANs estão permitidas em ambos os lados do link?
 Tem algum trunk ativo que não deveria estar estabelecido? Por exemplo, alguém
conectou um switch e entroncou com sua rede para espionar a rede.
Se os trunks são via etherchannel, verifique os parâmetros do PAgP ou LACP conforme o plano
de implantação e documentação atualizada da rede.
4.3 Problemas com VTP
Os problemas mais comuns que podem ocorrer com o VTP são listados abaixo:
 O VTP é enviado somente entre trunks, por isso se as mensagens não estão sendo
trocadas o primeiro passo é verificar os links de trunk.
 Verificar se o nome de domínio está correto em ambos os switches, sendo que ele é case
sensitive diferenciando de letras maiúsculas e minúsculas.
 Se o banco de dados do switch não está sendo atualizado verifique se ele não está em
modo transparent.
 Se estiver utilizado senha do VTP verifique se ela está correta em ambos os lados. Para
remover a senha digite “no vtp password”.
 Lembre-se que o VTP funciona apenas para a faixa padrão de VLANs de 1 a 1005.
 Verifique se a versão do VTP está correta.
 Pruning não funciona em switches transparentes e é preciso fazer manualmente a
filtragem de VLANs.
Lembre-se de zerar o número de revisão do VTP ao inserir switches que já foram configurados
anteriormente.

5 Resumo do Capítulo
Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do material
você tenha domínio dos seguintes itens:
 Funcionamento de switches camada-2

 Encaminhamento de quadros de Unicast, Broadcast e Multicast
 Conceito de VLANs
 VLANs locais e VLANs estendidas
 Implementação e testes de ambientes com VLAN
 Protocolos de trunk 802.1Q e ISL
 Configuração dos trunks entre switches
 Conceito de agregação de links
 Configuração de Etherchannels via PAgP e LACP
 Protocolo VTP – conceito e configurações
 Conceito e configurações do VTP pruning
 Comandos show utilizados para troubleshooting

Capítulo 04 - Protocolo
Spanning Tree
Nesse capítulo vamos
estudar o protocolo Objetivos do Capítulo
Spanning Tree tradicional
Ao final desse capítulo você terá estudado e
ou STP, assim como o Rapid
Spanning Tree Protocol ou  O protocolo Spanning Tree
RSTP e o Multiple Spanning Tradicional.
Tree Protocol ou MSTP.  O processo de convergência do STP
 Como alterações na topologia afetam
o STP.
 Configurações do STP.
Protocolos fundamentais  Funcionamento e configurações do
nas redes com switches que Protocolo Rapid Spanning Tree –
evitam loops de camada 2 RSTP.
que podem causar  Funcionamento e configurações do
tempestades de broadcast e Protocolo Multiple Spanning Tree -
sobrecargas nas redes LAN MSTP.
 Configurar recursos para melhorar a
e Campus. estabilidade do STP.
 Comandos show, debug aplicados no
troubleshooting.
Divirtam-se e bons estudos!

9 Mecanismos de Estabilidade e Segurança

Sumário do Capítulo do STP ___________________________ 117
9.1 BPDU Guard ___________________ 117
4 Introdução ______________________ 84
9.2 Filtragem de BPDUs – BPDU Filter _ 118
6 Protocolo Spanning Tree - STP, PVST e 9.3 Root Guard ____________________ 118
PVST+ _____________________________ 85
9.4 Unidirectional Link Detection - UDLD 119
6.1 Critérios de Eleição Utilizados pelo STP
86 9.5 Loop Guard ____________________ 120
6.2 Entendendo o Processo de Eleição no 9.6 Aplicando os Recursos ___________ 120

STP 87 10 Dicas de Troubleshooting no STP e
6.2.1 Elegendo o Root Bridge ___________ 87
Melhores Práticas __________________ 121
6.2.2 Elegendo as Root Ports ___________ 88
6.2.3 Elegendo as Portas Designadas e Não 10.1 Identificando um Loop de Camada 2
designadas _____________________________ 89 121
6.3 Bridge Protocol Data Units _________ 90 10.2 Melhores Práticas com Spanning-Tree
6.4 Alterações na Topologia ___________ 91 122
6.5 Estado das Portas com STP ________ 92 11 Resumo do Capítulo ___________ 122
6.6 Tipos de Spanning Tree - CST, PVST e
PVST+ 93
6.7 Configurando o Spanning Tree______ 93
6.8 Customizações do STP – Custo do
Caminho e das Portas __________________ 99
6.9 Alterando Parâmetros de Convergência
do STP ______________________________ 99
6.10 Melhorando a Convergência nos Links
Redundantes ________________________ 102
6.10.1 Configuração do Portfast _________ 102
6.10.2 Configuração do UplinkFast _______ 103
6.10.3 Configuração do BackboneFast ____ 103
6.11 Resumo dos Comandos Show para
Monitoração do STP __________________ 104
7 Protocolo RSTP __________________ 106
7.1 Diferenças no BPDU do RSTP ______ 106
7.2 Sincronização e Alterações na Topologia
do RSTP ____________________________ 107
7.3 Ativando o RSTP ________________ 109
8 Protocolo MSTP _________________ 110
8.1 Regiões e Instâncias do MSTP _____ 111
8.2 Configurações do MSTP __________ 112
8.3 Exemplo de Configuração do MSTP
Single Region ________________________ 113

4 Introdução
Apesar de extremamente necessário nas redes atuais a eliminação de pontos únicos de falhas
(SPOF – Single Point of Failure) quando pensamos em redes LAN utilizando protocolo Ethernet
temos que lembrar que ele não é capaz de detectar loops circulares, portanto não suportando a
existência de links redundantes sem que tais loops na camada de enlace ocorram por si só.
O que ocorre se tais caminhos redundantes existirem em redes Ethernet? Simplesmente um

tráfego inicial de broadcast ficará circulando em loop se acumulando até que toda banda
disponível se esgote e trave as interfaces ou até mesmo o processamento e memória dos
switches. Esse problema é conhecido como tempestades de broadcast.
Outro problema que pode ocorrer é a instabilidade nas tabelas de endereço MAC ou CAM table,
isso porque um mesmo endereço é aprendido por mais de uma porta de forma circular
causando um efeito de “flap” de endereço entre portas já citado no capítulo anterior. Esse
problema é descrito como instabilidade no banco de dados de endereços MAC ou instabilidade
na CAM table.
Mas como podemos então inserir um link redundante sem causar tais problemas na rede para
evitar que falhas de link possam vir a isolar um segmento de rede? Simples, impedindo que
existam loops e ao mesmo tempo permitindo links redundantes! Resumindo, o conceito é
relativamente simples: descobre os possíveis caminhos redundantes, escolhe o melhor e
desativa os demais.
Para isso foi desenvolvido o Spanning Tree Protocol ou STP pela IEEE de acordo com o
padrão 802.1D em 1998, conhecido também como STP tradicional. Ele permite o uso de links
redundantes que são automaticamente ativados quando o link principal entre dois switches fica
indisponível, permitindo que links backup sejam utilizados sem risco de ocorrer loops de
camada-2.
Em 2001 a IEEE introduziu o Rapid Spanning Tree Protocol (RSTP) no padrão 802.1W. O
RSTP é muito mais rápido que o STP convencional, tanto na convergência como em alterações
de topologia. O RSTP foi desenhado para ser compatível com o STP.
O Multiple Spanning Tree Protocol (MSTP) foi desenvolvido originalmente como a norma
IEEE 802.1S e mais tarde foi fundida no padrão IEEE 802.1Q-2005. Ela define uma extensão
do RSTP permitindo que um grupo de VLANs seja administrado por uma única instância.

Ao longo desse capítulo vamos estudar essas três versões de Spanning Tree.
6 Protocolo Spanning Tree - STP, PVST e PVST+

Os switches basicamente encaminham ou filtram quadros de camada 2, porém da maneira que
eles tomam tais decisões de encaminhar/filtrar acabam causando loops em redes com links
redundantes.
Um switch Layer 2 funciona da mesma maneira que um bridge transparente, relembre que eles
funcionam da seguinte maneira:
 Aprendem endereços MAC (Media Access Control) analisando o campo de endereço de

origem nos quadros de camada-2 para construir uma tabela que relacione o MAC por
número de porta (CAM Table).
 Encaminha broadcasts e multicasts para todas as portas menos a que recebeu o quadro
original, processo de flooding.
 Encaminha quadros de unicasts com endereço de destino desconhecido para todas as
portas menos para que recebeu o quadro original, seguindo o mesmo processo de
flooding anterior.
 Os quadros não são alterados quando encaminhados.
O Spanning Tree Protocol (STP) trabalha selecionando um bridge raiz (root bridge) e depois
um caminho livre de loop (loop-free) do root bridge até os demais switches da rede
chamados non-root ou não raízes. Para isso o Spanning Tree deve selecionar ou eleger três
componentes básicos:
1. Um root bridge (bridge raiz).

2. Uma root port (porta raiz) por non-root bridge.
3. Uma porta designada (designated port) por segmento de rede, sendo que a outra porta
será desativada para impedir os loops de camada-2.
Portanto um desenho complexo de rede com diversos caminhos redundantes vai ser analisado
pelo STP e tornar-se uma árvore simples com um caminho só de qualquer folha (switch não
root) até sua raiz (root bridge). Veja representação na figura abaixo onde antes do STP
existiam vários links redundantes e após sua convergência apenas um caminho foi deixado até
o switch eleito como raiz.
Você vai notar que o STP usa o termo bridge porque foi desenvolvido antes do surgimento dos
switches.

Você deve estar se perguntando: “Mas o que difere do CCNA?”. Na realidade nada, se você
aprendeu o STP a eleição é a mesma, porém vamos ver mais alguns detalhes a mais sobre o
processo de convergência e mensagens enviadas pelo STP que são omitidas no CCNA.
6.1 Critérios de Eleição Utilizados pelo STP
O Spanning Tree escolhe os caminhos até um ponto central (root bridge) preferencialmente
através dos links mais rápidos, porém pode haver empates e existem basicamente quatro
critérios de desempate:
1. Menor root bridge ID (BID)

2. Menor custo até o raiz (path cost)
3. Menor BID de emissor (sender bridge ID)
4. Menor ID de porta de emissor (sender port ID - PID)
Lembre-se também dos seguintes itens quando escolhendo os melhores caminhos:
 Bridge ID: Bridge priority (padrão 32.768) + MAC address do switch.

 Bridge priority: 2 bytes indo de 0 até 65.535 (0 a 0xFFFF – variando em múltiplos de
4096).
 Port ID: Port priority (prioridade da porta) + número da porta.
 Port priority: 8 bits indo de 0 a 255 com padrão 128.
 Custo do caminho (Path cost): soma dos custos dos links até o switch raiz, veja
abaixo os valores a serem considerados:
 10 Mb/s: 100
 100 Mb/s: 19
 1 Gbps: 4
 10 Gbps: 2
No comando “show spanning-tree” você verá a prioridade da VLAN 1 como 32.769, isso porque
nesse comando o número da VLAN é somando ao bridge priority padrão de 32.768. O mesmo
vale para qualquer VLAN. Veja exemplo abaixo marcado em amarelo.
Switch#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 001c.5823.6480
Cost 38
Port 37 (FastEthernet1/0/33)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 0015.6264.3300
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------
Fa1/0/8 Desg FWD 19 128.10 P2p
O comando começa mostrando as informações do root e depois do próprio switch local, se as

informações forem iguais é porque o switch local é o próprio root bridge. No exemplo acima
temos outro switch como raiz, basta comprar os MACs para descobrir (marcados em verde).

6.2 Entendendo o Processo de Eleição no STP
Para entender o STP vamos ter que aprender os três componentes a serem eleitos:
1. Um root bridge (bridge raiz).
2. Uma root port (porta raiz) por non-root bridge.
3. Uma porta designada (designated port) por segmento de rede, sendo que a outra porta
será desativada para impedir os loops de camada-2.
6.2.1 Elegendo o Root Bridge

O Spanning Tree precisa de um ponto comum onde todos os switches devem calcular como
chegar sem ter loops chamado “root” ou raiz da árvore. Portanto o primeiro passo é selecionar
quem será o switch com a função de root.
O root será quem tem o menor BID (Bridge Priority + MAC), porém como por padrão todos os
switches tem a mesma prioridade de 32.768 quem definirá o root por padrão será o switch com
menor endereço MAC na topologia.
Vamos a um exemplo, suponha que tenhamos a topologia abaixo e os seguintes switches com
seus respectivos MACs, qual será eleito como root?
 Switch A: BID = 8000.002c. 1111.0011 (32.768=0x8000 em Hexa)

 Switch B: BID = 8000.002c.4678.1010
 Switch C: BID = 8000.002c.721a.bcde
 Switch D: BID = 8000.002c.9181.1122
 Switch E: BID = 8000.002c.8c79.2222
O Switch A tem o menor BID (menor MAC) e por isso será o raiz. Só que no início todos os
switches enviam em seus BPDUs (Bridge Protocol Data Unit) que são enviados a cada 2
segundos que eles mesmos são root, ao longo do tempo cada um vai recebendo os quadros
atualizados e acabam por aceitar que o Switch A é o root, ou seja, o Switch A ganha a eleição.
Agora vamos ao Segundo passo para escolher uma root port por switch que não é raiz.

6.2.2 Elegendo as Root Ports

A root port é aquela que leva até o root, ou seja, a que vai manter um link ativo para
encaminhamento de quadros. Levando em conta a mesma topologia de 2.2.2 temos que
escolher os melhores caminhos até o Switch A. Vamos analisar cada caso:
 Switch B: tem duas opções de caminho, direto até A com custo de 19 (100 Mbps) e
outro através de B com custo de 104 (1Gbps+10Mbps). Ainda temos a opção através de
D, mas o custo será muito maior, portando a conexão de 100Mbps entre B e A será a
root port.
 Switch C: tem uma conexão com custo de 100 (Ethernet), e um link passando por B
com custo de caminho igual a 23 (1Gbps + 100Mbps), por isso a porta através de B é a
escolhida como root.
 Switch D: tem uma opção por B com custo de 119 (D-B-A) e outra por C com custo de
119 (D-B-C), porém têm mais duas opções D-C-B-A com custo de 42 e outra por D-B-C-
A com custo 204, por isso a porta escolhida é através de C.
 Switch E: tem o mesmo custo por ambas as portas através de D-C-B-A, portanto o
custo até o raiz empatou. O próximo item é o BID do emissor, porém as duas portas
estão conectadas ao D, continuamos empatados. O próximo item é o Port ID do emissor.
Como estamos com tudo padrão o que vai determinar a root port é o menor número da
porta, por isso como 0/1 é menor que 0/2 já temos a root port em E, é a que conecta à
porta 0/1 do switch D.
Veja a figura abaixo com as portas raiz e também com a regra que todas as portas do root
bridge são designadas. No próximo passo vamos determinar as portas designadas e as que
serão bloqueadas e eleitas como não designadas para evitar loops.

6.2.3 Elegendo as Portas Designadas e Não designadas

As portas designadas são portas que ficam ativas nos links redundantes que restaram na
topologia, sendo que todas as portas do root bridge são sempre designadas. Já as demais
portas foram eleitas conforme os mesmos critérios das root ports. Vamos abaixo verificar cada
segmento que restou e eleger que switch vai ter a porta designada:
 Segmento entre A-C: o switch A tem a porta designada, pois todas as portas do root
são designadas. C tem a porta não designada.
 Segmento entre B-D: o switch B tem menor custo até o raiz, por isso tem a porta
designada e D a porta não designada.
 Segmento entre D-E: o switch D tem o menor custo até o raiz, por isso tem a porta
designada.
Agora temos a topologia complete livre de loops. As portas não designadas ficam desativadas
“quebrando” os possíveis caminhos com loops. Elas serão ativadas somente se um problema no
caminho principal for detectado.
Com essa mesma metodologia você consegue resolver tanto as questões de topologia do STP
como RSTP e MSTP, pois a base para eleição do switch raiz, como root ports e portas
designadas sempre será o mesmo. As diferenças são os estados de portas e a nomenclatura,
pois o RSTP não tem portas bloqueadas como não designadas e sim portas alternativas ou
backups.
Outra dica importante é que você monte a topologia tradicional em três camadas no packet
tracer e entenda a dinâmica de eleição de root e depois das portas. Você pode fazer um
desenho e calcular a topologia livre de loops no caderno e depois fazer a mesma topologia no
packet tracer para testar.

6.3 Bridge Protocol Data Units
Os switches trocam quadros especiais chamados Bridge Protocol Data Units (BPDU).
Existem dois tipos de BPDUs: Configuration ou de Configuração e o de alteração de topologia
ou Topology Change Notification (TCN).
Os Configuration BPDUs são enviados a cada dois segundos a partir do root em direção aos
demais switches. Suas funções são:
 Utilizados durante o processo de eleição.

 Para manter a conectividade entre os switches, como um tipo de keepalive.
 Enviar informações sobre os temporizadores (timers) utilizados pelo root. O padrão dos
timers é Hello 2s, Forward Delay 15s (tempo de passar de Listening para Learning) e
Max Age 20s (tempo máximo que um BPDU fica armazenado quando um switch não
recebe updates).
Os TCN BPDUs são enviados dos switches não-root em direção ao root quando:
 Um link falha.
 Uma porta começa a encaminhar e existe outra porta designada.
 Quando recebe um TCN de um vizinho.
 Portas de acesso configuradas com o Portfast não enviam TCN BPDUs.
O BPDU de configuração inclui diversas informações em seus campos, abaixo seguem alguns
deles:
 Root bridge ID (Root ID): BID do root eleito.

 Root path cost: custo até o root a partir de quem envia o BPDU.
 Bridge ID: BID do switch que está enviando o BPDU.
 Port ID: número da porta do vizinho que está enviando o BPDU.
 Hello time: 2s por padrão - timer configurado no root.
 Forward Delay: 15s por padrão - timer configurado no root.
 Max Age (Maximum time): 20s por padrão - timer configurado no root.
 Flags: vários bits incluindo o Topology Change bit (TC-bit).
Veja o quadro completo abaixo:

6.4 Alterações na Topologia
Conforme estudamos no tópico anterior, quando ocorre um problema que gera alteração na
topologia o switch que o detectou envia para cima um TCN BPDU.
Quando um switch recebe um TCN BPDU ele reconhece enviando um Configuration BPDU com o
bit TCN Acknowledgment setado em 1. O switch que recebe o TCN BPDU também repassa
para cima e com esse processo os switches vão encaminhar o TCN BPDU para cima em direção
ao root até que ele receba a mensagem. Veja a imagem abaixo onde o link entre os switches
SWA e SWB é rompido e SWB inicia o aviso ao root enviando um TCN ao SWC.
Quando o root recebe um TCN BPDU ele inicia o envio de Configuration BPDUs com o bit TCN
ativo por um período igual ao max age mais o forward delay (20s + 15s). Veja a figura
abaixo.
Quando os switches não root recebem essas mensagens eles alteram o temporizador aging
time para o valor configurado no forward delay para todos os endereços contidos na sua tabela
MAC, o que acaba fazendo com que os endereços MAC da tabela sejam apagados mais
rapidamente, pois o valor passa de 300s para 15s por padrão. No final a alteração de topologia
pode causar uma nova eleição de root bridge, root ports e designated ports para que a
alteração na topologia gere uma nova topologia através dos links redundantes e livre de loops.

Na realidade é difícil prever o que vai acontecer, isso porque depende de cada topologia e do
tipo de alteração que aconteceu.
Por exemplo, um link entre o root bridge e um switch não bridge conectado diretamente a ele,
nesse caso o switch que está conectado ao root não tem como enviar um TCN para ele e como
o link está no próprio root ele já envia os BPDUs de configuração com o bit TC ativo para gerar
a alteração da topologia. Nesse caso a alteração vai ser direta, pois o próprio root atuou direto
sobre o problema porque o link DOWN é detectado diretamente sem depender de timers.
Outro tipo de problema que pode ocorrer é devido a um filtro que impede os BPDUs chegarem
ao vizinho, por exemplo, uma ACL ou qualquer outro tipo de filtro foi aplicado erroneamente e
impede o fluxo de BPDUs. Nesse caso a detecção que o link caiu depende dos timers, porque o
vizinho para de receber BPDUs e o timer de 20s do Max Age vai agir e somente depois disso o
root vai enviar os BPDUs de configuração com o bit TC setado para alteração da topologia.
O último exemplo é uma alteração insignificante na rede, por exemplo, a porta de um cliente
cai. Nesse exemplo o switch que detectou a falha informa ao vizinho com um TCN BPDU, o qual
chega até o root que passa a enviar BPDUs de configuração com o bit TC ativo, mas o que vai
acontecer nesse caso? A topologia precisa ser recalculada? Pense um pouco antes de ler a
resposta na sequência.
A resposta é não vai haver alteração na topologia, apenas os switches vão encurtar o timer de
aging das suas tabelas MAC e as entradas mais antigas serão apagadas, deixando os MACs das
estações que estão transmitindo na tabela. Para evitar esses tipos de mensagem cosméticas no
caso de links de hosts sendo desconectados basta ativar o Portfast nas portas de acesso.
6.5 Estado das Portas com STP
Por padrão os switches Cisco ativam o STP para cada VLAN criada e as portas antes de
passarem para um estado final como ativas (Forwarding - FWD) ou bloqueadas (Blocked - BLK)
passam por alguns estados determinados pelo STP. Veja os estados abaixo:
1. Disabled: esse é o estado da porta que está desabilitada ou em shutdown. Não

participa do processo de eleição nem transmite ou recebe quadros/BPDUs.
2. Blocking: quando a porta sobe ela fica nesse estado de acordo com o temporizador Max
Age (20s). Nesse estado a porta descarta os quadros recebidos, não prende endereços
MAC e recebe BPDUs.
3. Listening: após o Max Age a porta passa para esse estado e fica assim de acordo com o
timer chamado Forward Delay (15s). A porta em listening descarta os quadros
recebidos, não aprende endereços MAC e recebe BPDUs para fazer a eleição do root.
4. Learning: esse é o próximo estado e permanece assim de acordo com o timer de
Forward Delay também. Nesse estado a porta descarta quadros recebidos, aprende
endereços MAC para popular a tabela de endereços MAC e passa a receber e transmitir
BPDUs.
Ao todo de blocking até finalizar o estado de learning temos 50s (Max Age 20s + FWD Delay
15s + FWD Delay 15s) até que a porta passe para o estado de Forwarding ou volte ao estado
de bloqueada (Blocking), no caso de ser uma porta de um link redundante.
5. Forwarding: este é o estado final quando a porta pode encaminhar quadros, aprende
endereços MAC, recebe e transmite BPDUs.
Note que os estados de listening e learning são transitórios, pois uma porta fica por um
determinado tempo nesse estado e depois passa para forwarding ou blocking, que já são
estados estáveis das portas.

6.6 Tipos de Spanning Tree - CST, PVST e PVST+
A versão padrão do STP definida pelo IEEE assume que temos uma única instância comum de
Spanning-tree com apenas um root bridge, não importando quantas VLANs tivermos
configurado. Esse STP é chamado Common Spanning Tree ou CST. Outro detalhe é que no
CST todos os BPDUs são enviados pelos trunks utilizando a VLAN nativa sem marcação de
quadros. Trabalha com o 802.1Q nos trunks.
A principal desvantagem do CST é que os links redundantes ficam desabilitados e não

possibilita o balanceamento de cargas.
Na sequência a Cisco lançou o PVST ou Per-VLAN Spanning-Tree, uma versão do CST que
permite a operação através de instâncias separadas para cada VLAN criada no switch. Esse
padrão foi deixado de lado pela Cisco porque ele exige que os trunks utilizem o encapsulamento
proprietário da Cisco ISL e tem problemas de interoperabilidade em redes com CST.
Atualmente o padrão dos switches Cisco é a utilização do Per-VLAN Spanning-Tree Plus ou

PVST+. Nesse modelo também existe uma instância de STP para cada VLAN, além disso ele
permite interoperabilidade com o CST e PVST suportando trunks ISL e 802.1Q.
Com o PVST+ cada VLAN tem seu próprio root bridge, root port e assim por diante, permitindo
que o administrador de redes configure o balanceamento de cargas entre os links dos switches
através da eleição de diferentes root bridges para grupos específicos de VLANs.
O PVST+ é o padrão para os switches que operam com Cisco IOS.
6.7 Configurando o Spanning Tree
Para ativar e desativar o STP podemos utilizar o comando “no spanning-tree vlan num-vlan” em
modo de configuração global. Para ativar uma VLAN que foi desativada é só utilizar o mesmo
comando sem o “no” na frente. O STP também pode ser ativado e desativado dentro de uma
interface específica com o mesmo comando.
Lembre-se que estudamos até o momento o STP sendo estabelecido e formando a topologia
utilizando os valores padrões dos switches, os defaults. Mas é preciso configurar o STP? Porque
fazer isso se ele faz tudo automaticamente?
Para responder a essa questão vamos ver a topologia padrão em três camadas abaixo e
considerar que entre distribuição e acesso estamos utilizando links L2 e VLANs, já entre
distribuição e core estamos utilizando links L3:

Portanto o STP nesse exemplo suponha que o menor MAC é do switch SW-1, nesse caso ele
será eleito como root. Nesse tipo de topologia o correto seria que os switches de distribuição
SW-Dist-1 ou SW-Dist-2 fossem eleitos como root por estarem mais próximos ao Core.
Por esse motivo temos que configurar o STP para que a topologia seja definida pelo
administrador de redes e tenha previsibilidade tanto no encaminhamento normal de quadros
como em caso de falhas. Podemos, por exemplo, colocar o switch SW-Dist-1 como root bridge e
o SW-Dist-2 como um secundário que no caso de SW-Dist-1 cair ele assume como root.
Outra prática em projetos de redes com STP e VLANs é o balanceamento de cargas entre os
links de trunk, por exemplo, no acesso temos as VLANs de 1 a 10, podemos fazer com que as
VLANs de 1 a 5 tenham como root o switch SW-Dist-1 e das VLANs de 6 a 10 configuramos o
switch SW-Dist-2 como root, assim não teremos links ociosos e o tráfego será mais bem
distribuído entre os trunks.
Podemos alterar diversos parâmetros do STP, vamos iniciar com os comandos para alterar a
eleição do root bridge. Podemos fazer isso alterando a prioridade da bridge que tem por padrão
32.768 ou definindo um root primário e outro secundário, onde o valor da prioridade é alterada
automaticamente pelo Cisco IOS.
Para alterar a prioridade do bridge utilizamos o comando abaixo, sendo que os valores devem
ser múltiplos de 4096. O número da VLAN (num-vlan) pode ser especificado em faixas
utilizando traço e vírgula como fizemos no comando “switchport trunk allowed”.
Switch (config)#spanning-tree vlan num-vlan priority valor
Para definir um root primário e outro secundário sem precisar alterar manualmente os valores
da prioridade podemos utilizar o comando abaixo:
Switch (config)#spanning-tree vlan num-vlan root {primary | secondary}

[diameter diâmetro]
Com esse comando o switch configurado como root primário fica por padrão com o valor da
prioridade igual a 24.576 e o switch configurado como secundário terá prioridade igual a
28.672. Se o valor estiver configurado diferente do padrão o root primário terá seu valor 4096
a menos que o menor valor encontrado na rede.

A opção “diameter” altera o diâmetro padrão da rede definido pelo STP.
Vamos a um exemplo conforme topologia abaixo, onde os switches SW-D-1 deve ser o root
para as VLANs 1 a 5 e o switch SW-D-2 deve ser o root para as VLANs de 6 a 10. Caso um dos
switches fiquem indisponíveis o outro deve assumir como primário para todas as VLANs da
rede.
Configuração do switch de distribuição SW-D-1.
Switch#conf t
Switch(config)#hostname SW-D-1
SW-D-1(config)#vlan 1
SW-D-1(config-vlan)#vlan 2
SW-D-1(config-vlan)#exit
SW-D-1(config)#int g0/1
SW-D-1(config-if)#switchport trunk encapsulation dot1q
SW-D-1(config-if)#switchport mode trunk
SW-D-1(config-if)#int ran f0/1 - 3
SW-D-1(config-if-range)#switchport trunk encapsulation dot1q
SW-D-1(config-if-range)#switchport mode trunk
SW-D-1(config-if-range)#exit
SW-D-1(config)#
SW-D-1(config)#spanning-tree vlan 1-5 root primary
SW-D-1(config)#spanning-tree vlan 6-10 root secondary
SW-D-1(config)#

Configuração do switch de distribuição SW-D-2.
Switch#conf t
Switch(config)#hostname SW-D-2
SW-D-2(config)#vlan 1
SW-D-2(config-vlan)#exit
SW-D-2(config)#int g0/1
SW-D-2(config-if)#switchport trunk encapsulation dot1q
SW-D-2(config-if)#switchport mode trunk
SW-D-2(config-if)#exit
SW-D-2(config)#int ran fast 0/1 - 3
SW-D-2(config-if-range)#switchport trunk encapsulation dot1q
SW-D-2(config-if-range)#switchport mode trunk
SW-D-2(config-if-range)#exit
SW-D-2(config)#
SW-D-2(config)#spanning-tree vlan 6-10 root primary
SW-D-2(config)#spanning-tree vlan 1-5 root secondary
SW-D-2(config)#
Para verificar a configuração vamos utilizar o comando “show spannig-tree vlan x” nos switches
de acesso. Lembrando que o switch SW-D1 deve ser o root primário para as VLANs de 1 a 5 e
de 6 a 10 o switch SW-D-2 deve ser o primário. Para identificar os switches o MAC de SW-D-1 é
0001.C786.1242 e do switch SW-D-2 é 000B.BE0B.5580, você pode verificar o endereço
MAC dos switches com o comando “show version”.
Vamos verificar as informações do STP para as VLANs 1 e 6 no switch de acesso SW-AC-1.
SW-AC-1#show spanning-tree vlan 1

VLAN0001
Address 0001.C786.1242
Cost 19
Port 1(FastEthernet0/1)

Address 000D.BD8A.A36B
Aging Time 20

---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Root FWD 19 128.1 P2p
Fa0/2 Altn BLK 19 128.2 P2p
Note que para a VLAN 1 a prioridade do root é de 24577 (24576+1 da VLAN 1) e o endereço
MAC dele é 0001.C786.1242, o qual é o MAC de SW-D-1, conforme esperado.

SW-AC-1#show spanning-tree vlan 6

VLAN0006
Address 000B.BE0B.5580
Cost 19
Port 2(FastEthernet0/2)

Address 000D.BD8A.A36B
Aging Time 20

---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Altn BLK 19 128.1 P2p
Fa0/2 Root FWD 19 128.2 P2p
SW-AC-1#
Para a VLAN 6 a prioridade do root é de 24582 (24576+6 da VLAN 6) e o endereço MAC dele é
000B.BE0B.5580, o qual é o MAC de SW-D-2, conforme esperado.
Agora vamos entrar no switch SW-D-1 e verificar como está a prioridade para a VLAN 6, pois
ele é secundário para essa VLAN.
SW-D-1#show spanning-tree vlan 6

VLAN0006
Address 000B.BE0B.5580
Cost 4
Port 25(GigabitEthernet0/1)

Address 0001.C786.1242
Aging Time 20

---------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p
Gi0/1 Root FWD 4 128.25 P2p
SW-D-1#
Note que o root é o SW-D-2 e a prioridade do switch local SW-D-1 é 28762, conforme esperado
com o comando para torná-lo root secundário.
Outros dois comandos interessantes são o “show spanning-tree summary” e “show

spanning-tree interface tipo mod/num”. Veja exemplo dos comandos a seguir.
SW-D-1#show spanning-tree summary

Switch is in pvst mode

Root bridge for: default VLAN0002 VLAN0003 VLAN0004 VLAN0005
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is disabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------
VLAN0001 0 0 0 4 4
VLAN0002 0 0 0 4 4
VLAN0003 0 0 0 4 4
VLAN0004 0 0 0 4 4
VLAN0005 0 0 0 4 4
VLAN0006 0 0 0 4 4
VLAN0007 0 0 0 4 4
VLAN0008 0 0 0 4 4
VLAN0009 0 0 0 4 4
VLAN0010 0 0 0 4 4
---------------------- -------- --------- -------- ---------- ----------

10 vlans 0 0 0 40 40
Com o comando acima conseguimos saber o modo do STP ativo (pvst), para que VLANs o
switch é o root e a quantidade de portas por VLAN estão no estado de blocking, listening,
learning, forwarding e ativas.
No comando abaixo podemos saber por VLAN qual o estado da porta específica. Note que para
as VLANs de 1 a 5 a g0/1 é designada, pois ele é o root. Já para as VLANs de 6 a 10 as portas
estão como root ports, pois ele é secundário para essas VLANs.
SW-D-1#
SW-D-1#show spanning-tree interface g0/1
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 4 128.25 P2p
VLAN0006 Root FWD 4 128.25 P2p
SW-D-1#
Veja uma coisa interessante é que a G0/1 é a porta 25 para o switch, pois ele é um switch de
24 portas no campo “Prio.Nbr”.

6.8 Customizações do STP – Custo do Caminho e das Portas
Lembre-se que o custo da porta influencia no custo do caminho ao root e pode influenciar no
caminho final da topologia. Podemos alterar o custo de duas maneiras, para a interface como
um todo ou por VLAN no caso de trunks.
MUMBAI(config)#int f0/1
MUMBAI(config-if)#spanning-tree cost ?
<1-200000000> port path cost
MUMBAI(config-if)#spanning-tree vlan 1 cost ?

<1-200000000> Change an interface's per VLAN spanning tree path cost
MUMBAI(config-if)#spanning-tree vlan 1 cost 100

MUMBAI(config-if)#
No exemplo acima alteramos o custo da porta fast0/1 de 19 para 100.
Para alterar a prioridade padrão de 128 para outro valor podemos utilizar o comando abaixo
“spanning-tree vlan num port-priority valor”. Por exemplo, a porta fast 0/1 e fast0/2 tem
prioridade no padrão, por isso a interface conectada na fast 0/1 será escolhida como root port
ou designated. Se quisermos que a fast0/2 seja escolhida podemos alterar a prioridade com o
comando abaixo:
SW-D-1(config)#int f0/2
SW-D-1(config-if)#spanning-tree vlan 1 port-priority 64
SW-D-1(config-if)#
Vamos agora verificar a configuração abaixo.
SW-D-1#show spanning-tree interface fastEthernet 0/2

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
SW-D-1#
6.9 Alterando Parâmetros de Convergência do STP
Apesar de não muito aconselhável você pode alterar os temporizadores do STP para melhorar o
desempenho da sua rede, principalmente quando temos redes de pequeno porte. Os valores
padrões são baseados em redes de médio e grande porte.
Lembre-se que temos três timers: hello (padrão 2s – vai de 1 a 10s), forward delay (padrão
15s – vai de 4 a 30s) e aging timer (padrão 20s – vai de 6 a 40s), os quais precisam ser
alterados apenas no root bridge para que os valores sejam propagados para a rede.

Você pode configurar para todas as VLANs ou definir as VLANs específicas com a palavra chave
“vlan vlan-id” no comando, veja os comandos abaixo:
Switch(config)#spanning-tree [vlan vlan-id] hello-time tempo-segundos

Switch(config)#spanning-tree [vlan vlan-id] forward-time tempo-segundos
Switch(config)#spanning-tree [vlan vlan-id] max-age tempo-segundos
Um cuidado que se deve tomar é que baixar muito os valores pode gerar loops e afetar
negativamente o desempenho da rede.
Outra opção de ajuste dos timers do STP é com o comando abaixo, o qual utiliza fórmulas do
padrão 802.1D que leva em conta o diâmetro da rede e opcionalmente o temporizador de hello
(se não for configurado o padrão de 2s é utilizado).
Switch(config)#spanning-tree vlan vlan-list root {primary | secondary} [diameter

diâmetro [hello-time hello-time]]
O valor padrão do diâmetro é 7, ou seja, até sete switches ligados em série (sete saltos). Ao
alterar o valor os demais timers são calculados automaticamente, veja o exemplo a seguir.
Primeiro vamos ver os timers da VLAN 100 sem alterar os padrões.
Switch#show spanning-tree vlan 100
VLAN0100
Address 000f.233b.8a80
This bridge is the root

Aging Time 15

------------------- ---- --- --------- -------- --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 128.12 P2p
Fa0/15 Desg FWD 19 128.15 P2p
Fa0/19 Desg FWD 19 128.19 P2p
Fa0/23 Desg FWD 19 128.23 P2p
Fa0/39 Desg FWD 19 128.39 P2p

------------------- ---- --- --------- -------- --------------------------------
Fa0/40 Desg FWD 19 128.40 P2p

Fa0/47 Desg FWD 19 128.47 P2p
Fa0/48 Desg FWD 19 128.48 P2p
Gi0/1 Desg FWD 4 128.49 P2p

Agora vamos alterar o valor utilizando um diâmetro igual a três e hello de 1s. Com essa
configuração utilizando a fórmula automática de cálculo dos timers o Max Age foi configurado
igual a 7 segundos e o Forward Delay igual a 5 segundos. Veja na sequência os comandos de
configuração e a verificação com o show spanning-tree vlan 100.
Switch#conf t
Switch(config)#spanning-tree vlan 100 root primary diameter 3 hello-time 1
Switch(config)#do show spann vlan 100
VLAN0100

Aging Time 15

------------------- ---- --- --------- -------- --------------------------------
Fa0/11 Desg FWD 19 128.11 P2p
Fa0/12 Desg FWD 19 128.12 P2p
Fa0/15 Desg FWD 19 128.15 P2p
Fa0/19 Desg FWD 19 128.19 P2p
Fa0/23 Desg FWD 19 128.23 P2p
Fa0/39 Desg FWD 19 128.39 P2p

------------------- ---- --- --------- -------- --------------------------------
Fa0/40 Desg FWD 19 128.40 P2p

Fa0/47 Desg FWD 19 128.47 P2p
Fa0/48 Desg FWD 19 128.48 P2p
Switch(config)#

6.10 Melhorando a Convergência nos Links Redundantes
Além do que estudamos até o momento podemos melhorar o tempo de convergência dos links
redundantes com os seguintes recursos:
 PortFast: ativa rapidamente portas de switches de acesso com computadores

conectados nas pontas.
 UplinkFast: ativa o retorno rápido de links redundantes (fast-uplink failover) em
switches de acesso conectados à distribuição.
 BackboneFast: melhora a convergência no backbone ou switches de core depois que
alterações de topologia do spanning-tree ocorrem.
Com esses recursos ao invés de modificar temporizadores podemos melhorar a convergência da

rede em locais específicos da rede. Vamos agora ver as configurações de cada opção citada
acima.
6.10.1 Configuração do Portfast

O Portfast é um recurso proprietário da Cisco que atua sobre o Spanning Tree e ajuda a portas
de hosts subirem mais rápido, sem passar pelo processo normal do STP. Por isso ele se aplica
apenas a usuários conectados às portas de acesso.
O Portfast faz com que a porta passe de blocking direto para forwarding, bypassando os demais
estados do STP. O risco desse comando é que essas portas ficam sujeitas a causar loops se não
utilizadas corretamente, portanto não é aconselhado conectar outros switches ou HUBs em
portas configuradas com o portfast.
Podemos configurar o comando por porta, conforme abaixo:
SW(config-if)#spanning-tree portfast
Ou em modo de configuração global e se aplica a todas as portas configuradas como acesso:
SW(config)#spanning-tree portfast default
Para verificar o portfast utilizamos o comando abaixo:
Switch#show spanning-tree interface type mod/num portfast
A maior vantagem do portfast é que ele desabilita o envio de TCN BPDUs nas portas
configuradas com esse recurso, simplificando o envio de mensagens de TCN na rede.
Outro método é configurar a porta com o comando “switchport mode host”, já citado no
capítulo anterior. Esse comando ativa o portfast, coloca a porta como acesso (switchport
mode access) e desativa o PAgP impedindo que essas portas negociem para ativar links
agregados.
Juntamente com o portfast é recomendado o uso do recurso BPDU Guard, o qual estudaremos
em capítulo posterior.

6.10.2 Configuração do UplinkFast

Com o UplinkFast o switch identifica as portas backup da root port, as quais são chamadas
“uplink group” (grupo de links de acesso conectados com a distribuição) e quando a root port
cai uma das portas do grupo é desbloqueada imediatamente e passa direto para forwarding.
Esse comando não é permitido no root bridge.
Portanto esse recurso bypassa os estados de listening e learning e deve ser utilizado nos
switches situados no wiring closet com pelo menos uma porta de uplink bloqueada pelo STP.
O uplinkfast é ativado em modo de configuração global e afeta todas as portas e VLANs do

switch. Veja o comando abaixo.
SW(config)#spanning-tree uplinkfast [max-update-rate pkts-por-segundo]
O parâmetro max-update-rate é um opcional que limita em pacotes por segundo a largura de

banda utilizada para transmissão das informações da CAM Table através de multicasts.
Para verificar a configuração podemos utilizar o comando “show spanning-tree uplinkfast”.
6.10.3 Configuração do BackboneFast

O BackboneFast é utilizado para melhorar a velocidade de convergência quando um link que
não está diretamente conectado ao switch local, ou seja, uma falha indireta de link (indirect link
failure).
Quando um switch rodando BackboneFast recebe um BPDU inferior de uma bridge designada,
seja na root port ou em uma porta bloqueada, ele sabe que o link no caminho até o root teve
algum problema. Um BPDU inferior tem listado o mesmo switch como root bridge e designated
bridge.
Com isso o switch tenta encontrar um caminho alternativo para o root bridge enviando um
quadro chamado Root Link Query (RLQ) através de suas portas backup. O root responde ao
pedido com uma resposta RLQ e a porta que recebeu a reposta pode passar para o estado de
forwarding.
As portas backup ou alternativas são determinadas da seguinte maneira:
 Se o BPDU inferior foi recebido em uma porta bloqueada, a porta de raiz e quaisquer
outras portas bloqueadas são considerados alternativas.
 Se o BPDU inferior foi recebido na porta de raiz, todas as portas bloqueadas são
consideradas alternativas.
 Se o BPDU inferior foi recebido na porta de raiz e não há portas bloqueadas, o switch
assume que perdeu a conectividade com o root e anuncia-se como root.
Para configurar utilizamos o comando abaixo em modo de configuração global, o qual deve ser
utilizado em todos os switches da topologia para que o mecanismo do RLQ funcione com
sucesso:
SW(config)#spanning-tree backbonefast
Para verificar a configuração podemos utilizar o comando “show spanning-tree

backbonefast”.

6.11 Resumo dos Comandos Show para Monitoração do STP
 Verificar todos os parâmetros do STP para todas as VLANs, porém as informações de

porta são sumarizadas.
VLAN0001

Aging Time 300

------------------- ---- --- --------- -------- --------------------------------
Fa0/47 Desg FWD 19 128.47 P2p
Fa0/48 Desg FWD 19 128.48 P2p
Switch#show spanning-tree detail
 Mesmo do anterior, porém com detalhamento da informação das interfaces.
Switch#show spanning-tree detail
VLAN0001 is executing the ieee compatible Spanning Tree protocol

Bridge Identifier has priority 32768, sysid 1, address 000f.233b.8a80
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 8 last change occurred 00:23:01 ago
from FastEthernet0/15
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 1, topology change 0, notification 0, aging 300
Port 8 (FastEthernet0/8) of VLAN0001 is designated forwarding

Port path cost 19, Port priority 128, Port Identifier 128.8.
Designated root has priority 32769, address 000f.233b.8a80
Designated bridge has priority 32769, address 000f.233b.8a80
Designated port id is 128.8, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 3592, received 9
####Saída omitida ####

Switch#show spanning-tree [vlan vlan-id] summary
 Verificar o número total de portas do switch em cada estado do STP.
Switch#show spanning-tree vlan 1 summary

Switch is in pvst mode
Root bridge for VLAN0001 is this bridge.
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------
VLAN0001 0 0 0 11 11
Switch#show spanning-tree [vlan vlan-id] root
 Mostra o root bridge ID, a root port e o custo até o root.
sw1#show spanning-tree vlan 1 root
Root Hello Max Fwd

Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 000f.233b.8a80 19 2 20 15 Fa1/0/9
sw1#
Switch#show spanning-tree [vlan vlan-id] bridge
 Mostra o bridge ID e temporizadores do STP no switch local.
sw1#show spanning-tree vlan 1 bridge
Hello Max Fwd

Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 32769 (32768, 1) 0015.6264.3300 2 20 15 ieee
sw1#
Esses comandos também podem ser utilizados para o RSTP que vamos estudar no próximo
tópico.

7 Protocolo RSTP
O Rapid Spanning Tree (RSTP) é um protocolo aberto definido pela norma do IEEE 802.1w
que tem a função de acelerar o tempo de convergência do STP.
As portas dos switches configurados com RSTP trocam mensagens de handshake quando ocorre
um problema e elas precisam passar para o estado de forwarding, por isso o RSTP utiliza
diferentes estados de porta em relação ao STP, veja abaixo:
 Discarding: Os quadros recebidos na porta são descartados e não há aprendizado de

endereços MAC. Combina os estados do 802.1D Disabled, Blocking e Listening, sendo
que o estado de Listening não é utilizado porque o RSTP pode negociar a transição para
forwarding sem a necessidade de escutar BPDUs primeiro como no STP.
 Learning: Os quadros recebidos na porta são descartados, mas os endereços MAC
podem ser aprendidos.
 Forwarding: A porta pode encaminhar quadros e BDPUs normalmente, conforme o
processo de operação normal de um switch L2.
Abaixo veja a tabela comparando os estados do STP com o RSTP.
Estados de Portas do STP Estados de Portas Equivalentes do RSTP

Disabled Discarding
Blocking Discarding
Listening Discarding
Learning Learning
Forwarding Forwarding
Outra mudança no RSTP é com a função das portas:
 Root port: melhor caminho para o root (igual ao STP).

 Designated port: mesma função que tínhamos no STP.
 Alternate port: porta backup da root port.
 Backup port: porta backup de uma porta designada.
 Disabled port: porta não utilizada no Spanning Tree.
 Edge port: porta conectada a um host.
Apesar das mudanças de nomenclatura todo processo de eleição de root bridge, root ports e
designated ports é o mesmo que estudamos para o STP, assim como as configurações para
manipulação nas eleições de root ou do melhor caminho e comandos show também são iguais.
7.1 Diferenças no BPDU do RSTP
No STP os BPDUs são originados pelo root e encaminhados pelos demais switches, ou seja, os
switches que não são roots não geram BPDUs. Já no RSTP todos os switches da rede podem
originar BPDUs, recebendo ou não BPDUs em sua root port.
O BPDU do RSTP é definido como tipo 2 e versão 2, porém ele permite a compatibilidade com a
versão anterior 802.1d. O que ocorre é que quando um switch 802.1d (STP) recebe um BPDU
802.1w ele não reconhece o BPDU e simplesmente ignora, porém quando um switch
configurado com RSTP recebe um BPDU do STP ele responde o switch remoto utilizando
também BPDUs com protocolo 802.1d, fazendo com que o spanning-tree troque informações
via STP ao invés de RSTP.
Uma diferença importante é que se 3 BPDUs não forem recebidos em sequência o switch
considera que o vizinho caiu e imediatamente limpa a tabela MAC não esperando os 20
segundos do Max Age do STP, o que traz esse processo para 6 segundos no máximo.

Os bits de TC e TC Ack (reconhecimento do TC) ainda são utilizados, assim como os outros seis
bits são utilizados para definir a função da porta e o estado do RSTP que são utilizados no
processo de handshake da porta.
7.2 Sincronização e Alterações na Topologia do RSTP
O Rapid Spanning Tree trata as alterações de topologia e o processo de convergência muito

mais rápido que o STP, vamos analisar algumas características que permitem isso abaixo:
 O RSTP utiliza mecanismos similares ao BackboneFast e quando um BPDU inferior é

recebido o switch verifica se possui outro caminho até o root utilizando essa informação
para informar os switches de baixo que existe um novo caminho alternativo até o root.
 As Edge ports funcionam como o Portfast e passam automaticamente para forwarding,

sem esperar verificações extras.
 A informação de “Link type” (tipo de link) é utilizada e quando você conecta dois
switches em um link tipo “point-to-point” (ponto a ponto – trunks entre dois switches) a
porta local se torna uma “designated port”, trocando mensagens de handshake com a
porta vizinha para rapidamente passar para o estado de forwarding.
 Links Full-duplex são considerados “point-to-point” e “half-duplex” são considerados

como “shared” (links compartilhados – supostamente pode ter um HUB na outra ponta).
 As portas Backup e Alternate podem passar para o estado de forwarding quando

nenhum BPDU é recebido do switch vizinho, similar ao UplinkFast do STP.
Tudo começa com o processo de sincronização do RSTP, onde os switches devem decidir o
estado de suas portas. Portas de trunk ou “Nonedge ports” iniciam no estado de Discarding e
depois da troca de BPDUs o root bridge é identificado. Nos switches não root as portas que
recebem BPDUs superiores se tornam Root Ports.
Esse processo da eleição das portas é feito através da troca de “proposal-aggrements

handshakes” que são mensagens com propostas de configuração e seu aceite através do envio
de mensagens de handshake. Veja a figura a seguir para entender o processo.

Vamos analisar a sequência de sincronização ilustrada na figura anterior:

1. O switch A inicia enviando uma proposta (proposal) para o switch B e bloqueia o trunk
entre eles até que um aceite seja recebido (agreement), nesse caso A é o root
2. Quando B recebe a proposta de A o link entre ele e C também é bloqueado, na realidade
todos os links são bloqueados para evitar loops.
3. Na sequência B envia o aggreement para A e sua porta se torna uma root port e o link é
passado para o estado de forwarding. Como A é o root todas suas portas serão
designadas e ficarão ativas.
4. Agora B envia uma proposta para C, que assim como B quando recebeu a proposta de A
bloqueia todas as suas portas de trunk. A porta entre B e C continua no estado de
discarding.
5. O Switch C responde para B com seu agreement e sua porta é colocada no estado de
forwarding, sendo que A é eleito como switch designado (designated switch), pois ele
possui a porta designada.
Esse processo continua a acontecer como uma onda sincronizando todos os switches na rede e
sem os temporizadores do STP, acontecendo quase que instantaneamente.
Uma vez a rede sincronizada, se um switch rodando o RSTP detecta uma alteração na topologia
ele configura o temporizador TC para duas vezes o tempo do hello e ativa o bit TC em todos os
BPDUs enviados em suas portas designadas (designated) e root ports até que o timer expire.
Além disso, os MACs aprendidos nessas portas são apagados.
O processo de convergência frete a uma alteração de topologia é similar ao de sincronização e

ocorrerá uma onda de envio de TC se propagando pela rede até que ela tenha convergido para
a nova topologia livre de loop através dos links backup.

Com esse processo o RSTP consegue reduzir o tempo de convergência de aproximadamente

50s do STP para um tempo entre 3 e 6 segundos.
É importante lembrar que somente alterações em portas consideradas “non-Edge ports”

causam envio de notificações de TC. As portas de clientes não geram envio de TC.
7.3 Ativando o RSTP
Para ativar o Rapid STP basta utilizar o comando abaixo:
Switch(config)#spanning-tree mode rapid-pvst
Para voltar ao STP tradicional basta utilizar o comando “spanning-tree mode pvst” em modo
de configuração global.
O Rapid Spanning Tree utilizado nos switches Cisco é chamado Per-VLAN Rapid Spanning
Tree Plus (PVRST+) e o comando de ativação citado acima deve ser aplicado a todos os
switches da rede, se houver algum switch com o PVST+ ativado entre o switch com RSTP e o
STP tradicional será utilizado o processo do tradicional, portando não há ganhos nesse tipo de
conexão.
Para configurar uma porta utilizando RSTP como edge port utilize o comando “spanning-tree
portfast” nas portas de hosts (endpoints – usuários).
Os trunks full-duplex são automaticamente detectados e configurados como links “poin-to-

point”, porém se por qualquer motivo um link entre dois switches precisar ser configurado como
half-duplex o RSTP interpreta como um link compartilhado, para forçar o RSTP entender que
esse link é “poin-to-point” entre na interface e utilize o comando “spanning-tree link-type
poin-to-point”.
Para verificar o RSTP utilize os mesmos comandos show mostrados no tópico anterior relativo
ao STP tradicional. Vamos analisar o comando “show vlan spanning-tree vlan 10” com um
switch configurado com o RSTP.
SW-DlteC-Rack-01#show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp
Address 0024.5161.6a00

Address 0024.5161.6a00
Aging Time 299

------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p Edge
Gi0/1 Desg FWD 4 128.25 P2p Peer(STP)
SW-DlteC-Rack-01#

No início do comando temos que o RSTP está ativado e as informações do root e do próprio
switch são os mesmos que no STP.
Temos na sequência também (marcadas em amarelo) informações sobre as portas. Note que
nesse switch temos portas P2P Edge, as quais são portas de clientes configuradas com o
comando Portfast. Temos também uma porta P2p que é uma porta point-to-point funcionando
via RSTP. Por último temos uma porta marcada como P2p Peer(STP), o que significa que o
switch conectado à porta G0/1 está conectada como ponto a ponto, mas está rodando o STP ao
invés do RSTP.
8 Protocolo MSTP
O MSTP ou protocolo Multiple Spanning Tree (MST) é um protocolo aberto definido no
padrão IEEE 802.1S.
Seu objetivo final do é agrupar diversas VLANs e rodar apenas uma instância de Spanning Tree
para esse grupo de VLANs. Assim o número de root bridges, root ports, designated ports e
BPDUs na rede é sensivelmente reduzido quando trabalhamos com redes de médio e grande
porte.
Imagine que precisamos em nosso projeto de 500 VLANs, portanto utilizando o PVST+ (STP) ou
RPVST+ (RSTP) teremos 500 instâncias de STP, 500 eleições de root bridge e mais de 500
eleições de root ports e designated ports, pois tudo isso é feito por VLAN em ambos os
protocolos STP e RSTP. Com o MSTP podemos agrupar essas VLANs em uma ou duas instâncias
e o gasto de processamento e memória dos switches com o cálculo de 500 instâncias de STP
reduzido para uma ou duas instâncias. Veja a figura abaixo.
No final o MSTP combina o CST, o qual trata diversas VLANs com uma única instância comum
de STP, com o PVST+/802.1Q que permite separar as VLANs por trunks (802.1Q) e melhora o
design de redes redundantes com balanceamento de cargas.
Para implementar o MSTP precisamos definir o seguinte:

 O número de instâncias de STP necessárias para que a topologia funcione.
 O mapeamento das VLANs em cada instância para permitir o balanceamento de cargas
(separar VLANs por trunk).

8.1 Regiões e Instâncias do MSTP
O IEEE 802.1s introduziu o conceito de regiões no MST (MST Region), o qual é equivalente ao
raciocínio de um sistema autônomo do Border Gateway Protocol (BGP), onde um grupo de
switches é colocado sob uma administração comum.
Cada switch em uma região do MST deve ter a mesma configuração para pertencer a essa
região, seguem os três parâmetros abaixo:
1. Configuration name ou nome de configuração alfanumérico de 32 caracteres.

2. Configuration revision number ou número de revisão da configuração (dois bytes – 0 a
65.535).
3. Mapa de VLANs por instância do MST (Instance-to-VLAN Mapping Table - 4096
elementos).
Para fazer parte de uma região os switches precisam ter esses dados configurados de maneira
igual, caso não a configuração seja diferente os switches são considerados em regiões
diferentes e acabam por utilizar o STP tradicional (802.1D) para fazer a comunicação nessa
borda ou fronteira entre duas regiões.
Além das regiões, de acordo com o IEEE 802.1s o switch MST deve suportar pelo menos dois
tipos instâncias:
 Uma instância chamada Internal Spanning Tree (IST)

 Uma ou mais instâncias chamada Multiple Spanning Tree Instance (MSTI)
Uma instância interna ou IST recebe e envia BPDUs para a CST, ou seja, a IST representa toda
região MST uma bridge virtual CST (Common Spanning-Tree) para o mundo exterior. É como se
a IST fosse responsável por formar um “grande switch” com toda MST para comunicar-se com o
mundo exterior através do STP convencional em trunks 802.1Q. Veja a figura abaixo.
Já a MSTI são as instâncias que o MST pode ter que vão de zero a 16, onde a zero é reservada
para a IST e de 1 a 15 ficam disponíveis para uso. Podemos utilizar as MSTIs para fazer o
balanceamento de cargas entre trunks mapeando diferentes VLANs a cada MSTI. Por exemplo,
utilizamos a MSTI-1 para as VLANs de 1 a 10 e a MSTI-2 para as VLANs de 11 a 20 e cada uma
vai ter uma topologia diferente para o balanceamento de cargas, veja a figura abaixo para
entender melhor.

8.2 Configurações do MSTP
Abaixo seguem os comandos para configuração do MSTP:
1) Defina o modo do STP para o MSTP:
SW(config)#spanning-tree mode mst
2) Entre em modo de configuração do MSTP:
SW(config)#spanning-tree mst configuration
3) Configure o nome da região com até 32 caracteres alfanuméricos:
SW(config-mst)#name nome-da-região
4) Defina o número de revisão da configuração entre 0 e 65.535:
SW(config-mst)#revision número
5) Faça o mapeamento das VLANs por MSTI (instância do MSTP):
SW(config-mst)#instance id-da-instância vlan faixa-de-vlans
6) Saia do modo de configuração do MSTP para aplicar as configurações no switch:
SW(config-mst)#[end | exit]
Para verificar o MSTP utilizamos o comando “show spanning-tree mst” em modo privilegiado e
“show pending” em modo de configuração do MSTP.

Você pode ajustar os parâmetros gerais do MSTP assim como fizemos para o STP e RSTP, os
comandos são bem parecidos com a diferença é que devemos definir para que instância de MST
(MSTI) estamos configurando os parâmetros, veja a listagem dos comandos abaixo:
1) Definir o root bridge:

 Switch(config)#spanning-tree mst instance-id root {primary | secondary} [diameter
diameter]
2) Definir a prioridade do switch/bridge:

 Switch(config)#spanning-tree mst instance-id priority bridge-priority
3) Definir o custo das portas:

 Switch(config)#spanning-tree mst instance-id cost custo
4) Definir a prioridade das portas:

 Switch(config)#spanning-tree mst instance-id port-priority port-priority
5) Definir os timers do MSTP:

 Switch(config)#spanning-tree mst hello-time segundos
 Switch(config)#spanning-tree mst forward-time segundos
 Switch(config)#spanning-tree mst max-age segundos
8.3 Exemplo de Configuração do MSTP Single Region
Vamos a um exemplo de configuração do MSTP utilizando apenas uma região e duas instâncias.
Veja a figura abaixo com a topologia utilizada no exemplo.
Requisitos gerais de funcionamento da topologia:
 VLANs 10, 20 e 30 chegarem a SW3 por SW1.

 VLANs 40, 50 e 60 chegarem até SW3 por SW2.
 Se houver falha no link as VLANs devem ser encaminhadas pelo vizinho.

Como vamos configurar essa topologia com esses requisitos utilizando o MSTP? Vamos ver o
plano de implantação abaixo:
1) Criar dois MSTIs (1 e 2).

2) Configurar SW1 como root para a instância 1 e SW2 para a instância 2.
3) Para a IST (MSTI0) o switch SW3 será configurado como root (apesar de não
recomendado fazer isso na prática utilizando switches de acesso vamos fazer porque é
laboratório).
4) A VLAN será mapeada com a IST.
5) VLANs 10, 20 e 30 serão mapeadas na MSTI1.
6) VLANs 40, 50 e 60 serão mapeadas na MSTI2.
Vamos ver as configurações de cada switch começando pelo switch SW1:
spanning-tree mode mst

!
spanning-tree mst configuration
name REGION1
instance 1 vlan 10, 20, 30
!
! Root para MSTI1
!
spanning-tree mst 1 priority 8192
!
switchport trunk encapsulation dot1q
!
Configurações em SW2:

!
name REGION1
!
! Root para MSTI 2
!
!
!

Configurações em SW3:

!
name REGION1
!
! Root para IST
!
!
!
Vamos abaixo analisar alguns comandos show.
SW1#show spanning-tree mst configuration

Name [REGION1]
Revision 0 Instances configured 3
Instance Vlans mapped

-------- ---------------------------------------------------------------------
0 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1 10,20,30
2 40,50,60
-------------------------------------------------------------------------------
SW1#show spanning-tree mst
#####MST0 vlans mapped: 1-9,11-19,21-29,31-39,41-49,51-59,61-4094

Bridge address 0019.5684.3700 priority 32768 (32768 sysid 0)
Root address 0012.d939.3700 priority 8192 (8192 sysid 0)
port Fa0/16 path cost 0
Regional Root address 0012.d939.3700 priority 8192 (8192 sysid 0)
internal cost 200000 rem hops 19
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20

---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Desg FWD 200000 128.15 P2p
Fa0/16 Root FWD 200000 128.18 P2p
#####MST1 vlans mapped: 10,20,30

Root this switch for MST1

---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Desg FWD 200000 128.15 P2p
Fa0/16 Desg FWD 200000 128.18 P2p

#####MST2 vlans mapped: 40,50,60

Root address 001e.bdaa.ba80 priority 8194 (8192 sysid 2)
port Fa0/13 cost 200000 rem hops 19

---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Root FWD 200000 128.15 P2p
Fa0/16 Altn BLK 200000 128.18 P2p
SW1#show spanning-tree mst interface fastEthernet 0/13
FastEthernet0/13 of MST0 is designated forwarding

Edge port: no (default) port guard : none (default)
Link type: point-to-point (auto) bpdu filter: disable (default)
Boundary : internal bpdu guard : disable (default)
Bpdus sent 561, received 544
Instance Role Sts Cost Prio.Nbr Vlans mapped

-------- ---- --- --------- -------- -------------------------------
0 Desg FWD 200000 128.15 1-9,11-19,21-29,31-39,41-49,51-59
61-4094
1 Desg FWD 200000 128.15 10,20,30
2 Root FWD 200000 128.15 40,50,60
Em termos de exame, as configurações do MSTP não são importantes, pois costuma cair mais
conceitos sobre o funcionamento que comandos.
Com isso finalizamos os três tipos de STP e na sequência vamos estudar outros métodos e
recursos utilizados para manter a estabilidade da rede e do STP como um todo.

9 Mecanismos de Estabilidade e Segurança do STP

O Spanning Tree tem diversas ferramentas utilizadas para o ajuste fino e proteger a rede
contra loops e mantê-la operacional. Essas ferramentas são:
 PortFast
 UplinkFast
 BackboneFast
 BPDU Guard
 BPDU Filtering
 Root Guard
 UDLD - Unidirectional Link Detection
 Loop Guard
Os três primeiros já foram discutidos anteriormente, por isso vamos estudar os mecanismos a
partir do BPDU Guard.
9.1 BPDU Guard
O BPDU Guard ajuda a prevenir loops se outro switch for conectado a uma porta configurada
com o comando Portfast. Isso é feito porque o BPDU Guard é capaz de detector BPDUs
recebidos na interface e a coloca em “error-disabled state” (basicamente um shutdown) para
protegê-la contra eventuais loops, pois uma porta com portfast foi planejada para ser uma
porta de acesso e conectar hosts e não switches. Veja a figura abaixo.
O comando pode ser ativado em modo global ou de interface. Em modo global ele é aplicado
em todas as portas configuradas como Portfast. Veja a configuração abaixo:
SW(config)#spanning-tree portfast bpduguard default
Para ativar por interface utilize o comando abaixo:
SW(config-if)#spanning-tree bpduguard enable
Para verificar o estado do BPDU Guard utilize o comando “show spanning-tree summary
totals”.

9.2 Filtragem de BPDUs – BPDU Filter
A filtragem de BPDUs ou “BPDU Filtering” é um recurso para prevenção de loops na rede.

Apesar do Portfast passar uma porta de blocked/discarding direto para forwarding, mesmo
assim a porta pode receber e processar BPDUs. Já o recurso de BDPU filtering efetivamente
desativa os o STP na porta, pois ele faz com que a porta nem receba, processe ou envie mais
BPDUs quando ativado.
Por padrão o BPDU filter é desativado em todas as portas e pode ser ativado em modo de
configuração global ou de interface, seguem os comandos abaixo:
SW(config)#spanning-tree portfast bpdufilter default

SW(config-if)#spanning-tree bpdufilter [enable | disable]
O comando default vai ativar o BPDU filter apenas nas portas com o comando portfast, se o ele
não estiver ativado o comando não será executado na porta.
Esse comando deve ser utilizado apenas em circunstâncias especiais e com muito cuidado, pois
ele pode causar loops muito difíceis de serem detectados.
9.3 Root Guard
O recurso de Root Guard é utilizado para evitar que uma porta que nunca deveria ser root port
se torne uma e aceitem que outro switch tente se eleger como root bridge, seja por erro de
configuração ou por uma tentativa de ataque ao STP.
Ele deve ser ativado em portas de switches não root e portas que não sejam “root ports” e
nunca serão, tais como portas de hosts ou portas designadas que não tem chance de tornar-se
uma root port. Basicamente vamos fazer que as portas com o root guard ativo não permitam o
recebimento de BPDUs superiores, apenas o encaminhamento. Veja exemplo na figura abaixo.
Se um switch com Root Guard ativado em uma porta recebe um BPDU superior que tenta fazer
com que ela seja eleita root port, essa porta é colocada em um estado de “root-inconsistent”
e não deixa passar tráfego por ela enquanto o BPDU superior for recebido. Se a porta para de
receber o BPDU superior ela é automaticamente reativada.
Para ativar o Root Guard utilize o seguinte comando:

SW(config-if)#spanning-tree guard root

Para verificar se existe alguma porta bloqueada pelo root guard utilize o comando “show
spanning-tree inconsistentports”.
9.4 Unidirectional Link Detection - UDLD
O UDLD é utilizado em switches com links de fibra e é utilizado para tratar o problema de links
que trafegam dados em apenas uma direção, por isso o nome Unidirectional Link Detection ou
detecção de link unidirecional.
Lembre-se de que o switch nota que uma conexão física está com problemas através da
ausência dos keepalives na camada-1 no caso de links Ethernet. Porém algumas vezes o cabo
consegue trafegar os keepalives sem passar os dados em ambas as direções (Tx e Rx),
problema chamado de Unidirectional Link (link unidirecional). Resumindo, uma porta envia e
recebe os dados e a outra porta remota só transmite e não recebe. Por isso um dos switches
pensa que o link está UP quando deveria ser desativado, conforme figura abaixo.
O recurso de Unidirectional Link Detection (UDLD) detecta links unidirecionais enviando hellos
periódicos na saída da interface (Tx). Além disso, são enviados “probes” que precisam ser
reconhecidos pelo equipamento remoto.
O UDLD tem dois modos de operação:

 Normal: o estado do link é alterado para “Undetermined State” (indeterminado) se os
hellos não são respondidos.
 Aggressive: nesse modo a porta é colocada em error-disabled se um link unidirecional
é detectado. O aggressive mode é o mais recomendado quando utilizamos o UDLD.
Podemos ativar o UDLD em todas e apenas interfaces de fibra em modo de configuração global,
conforme abaixo:
SW(config)#udld [enable | aggressive]
Para configurar o UDLD em portas que não são de fibra ou especificando a porque que vamos
ativar o comando utilizamos o modo de configuração de interface, conforme abaixo:
SW(config-if)#udld port {aggressive | disable}
Para reabilitar todas as interfaces desativadas pelo UDLD podemos utilizar o comando “udld
reset” em modo privilegiado. Para verificar o estado do UDLD utilizamos o comando “show
udld interface”.

9.5 Loop Guard
O Loop Guard é um recurso utilizado para prevenir loops que podem ocorrer quando uma
porta que deve estar no estado de blocking acaba passando para o estado de forwarding
inadvertidamente.
Isso pode ocorrer quando uma porta para de receber BPDUs seja devido a um unidirectional
link ou problema de software/configuração no switch vizinho. Portanto quando uma porta é um
link redundante da topologia e para de receber BPDUs o STP supõe que a topologia está livre de
loops, com isso as portas em blocking tornam-se designadas e transacionam para forwarding
criando um loop.
Com o Loop Guard ativado uma verificação adicional é feita para evitar esse tipo de problema,
isso porque quando BPDUs não são recebidos em uma porta bloqueada por um período de
tempo o Loop Guard coloca a porta no estado de “loop inconsistent”, bloqueando a porta ao
invés de passar para forwarding.
O Loop Guard deveria ser ativado em todas as portas do switch que tem chance de se tornar
root port ou designated port. Ele é mais eficiente quando ativado em conjunto com o UDLD
quando temos links de fibra.
Para ativar o Loop Guard em todos os links ponto a ponto “point-to-point” no switch utilizamos
o comando abaixo em modo de configuração global:
SW(config)#spanning-tree loopguard default
Para ativar Loop Guard em uma interface específica utilizamos o seguinte comando:
SW(config-if)#spanning-tree guard loop
O Loop Guard é reativado automaticamente quando a porta volta a receber BPDUs.
9.6 Aplicando os Recursos
Se não ficou claro onde utilizar cada recurso estudado na figura abaixo temos um resumo da
aplicação de cada um deles.

10 Dicas de Troubleshooting no STP e Melhores Práticas

Durante o capítulo já estudamos vários problemas de configuração e os comandos show para
verificação, porém aqui vamos a algumas dicas práticas sobre o assunto.
Abaixo vamos listar alguns pontos importantes que devemos verificar ao fazer troubleshooting
no Spanning Tree Protocol:
 Duplex mismatch: de um lado da conexão temos uma porta half-duplex e do outro

full-duplex, causando late collisions e FCS errors (input errros) e fazendo a ponta half-
duplex fechar como um link compartilhado (shared).
 Problemas com falhas de Link Unidirecional (Unidirectional link): o link fica UP
mas não há fluxo de dados em ambas as direções, apenas um dos switches recebe e
transmite, o que pode causar loops.
 Quadros corrompidos (Frame corruption): erros físicos nos cabos podem fazer com
que BPDUs sejam perdidos e uma porta fique em forwarding erroneamente. Esse tipo de
problema pode ser causado por duplex mismatch, cabos com problemas ou muito longos
(acima dos 100m para UTP, por exemplo).
 Problemas com os Recursos do Switch: o STP é implementado em software, por isso
se o switch ficar com a carga da CPU ou uso de memória RAM acima do normal, rotinas
do STP podem ser deixadas para trás.
 Erros na Configuração do Port Fast e BPDU Filter: conectar duas portas ou switches
em portas ativadas como Port Fast ou então com BPDU Filter ativado pode causar loop.
 Ajustes no STP (tuning errors): o max age ou forward delay configurados para um
tempo muito curto pode causar loops na topologia assim como o diâmetro da rede muito
baixo pode causar perdas de BPDUs e afetar a convergência do STP.
Outro problema típico do STP é a rede trabalhar em uma topologia subótima quando não
ajustamos os parâmetros da eleição do root bridge e do root secundário, por exemplo, um
switch de acesso tornar-se root ao invés dos switches de distribuição em topologias de três
camadas.
10.1 Identificando um Loop de Camada 2
Quando devemos suspeitar de loop de camada 2 em uma rede LAN? Os sintomas abaixo
representam bem o problema:
 Uso excessivo de memória e CPU nos switches de distribuição e/ou core.

 A captura de tráfego de um link mostra o mesmo quadro de camada-2 repetido várias
vezes.
 Todos os usuários em um mesmo domínio de broadcast estão enfrentando problemas de
conexão ao mesmo tempo.
 Alta utilização das portas.
Para você analisar os fatores acima é necessário que exista uma base line (linha de base) da
sua rede e você saiba identificar o que é anormal por períodos, por exemplo, sei que em
operação normal os switches operam com 5% da CPU e 20% da memória em horário comercial.
Você pode descobrir onde está o loop rapidamente desativando portas redundantes e depois ir
ativando uma a uma e também analisando as mensagens de erro. Alguns comandos também
podem ajudar nessa análise:
 show interfaces
 show spanning tree
 show bridge
 show process cpu

 debug spanning tree

 show mac address-table aging-time vlan-num
 show spanning-tree vlan vlan-num detail
A mensagem "%MAC_MOVE-SP-4-NOTIF", conforme exemplo abaixo, também pode indicar

loop de camada-2, principalmente quando o STP foi desativado por qualquer motivo que seja.
%MAC_MOVE-SP-4-NOTIF: Host 00db.bc80.ca10 in vlan 1 is flapping between port 0/10

and port 0/20
Essa mensagem é padrão em maioria dos switches Catalyst e para desativar utilize o comando
“no mac-address-table notification mac-move” ou utilizando uma entrada estática de MAC
para a porta específica com o comando “mac-address-table static 00db.bc80.ca10 vlan 1
interface fa0/10″ no switch. O comando “mac-address-table notification mac-move” vem
desabilitado nos switches da linha 6500 e 7600 e ativado em maioria das demais séries por
padrão.
Outra mensagem que pode indicar loop de camada-2 é a "%GLBP-4-DUPADDR: Duplicate

address", nesse caso geralmente o loop é consequência de problemas na configuração do STP.
Para resolver esse problema utilize o comando "show interface" e verifique o MAC da interface é
o mesmo reportado na mensagem de erro, se ele for o mesmo MAC indica que o switch está
recebendo seus próprios pacotes de hello enviados na interface. Se o MAC for diferente então
outro dispositivo deve estar reportando a mesma mensagem de erro. Verifique a topologia do
spanning-tree para encontrar onde está ocorrendo o loop e corrigir o problema.
10.2 Melhores Práticas com Spanning-Tree
Abaixo seguem algumas melhores práticas (Best Practices) no design e configuração do

Spanning Tree:
 Configurar estaticamente com valores baixos os switches que serão os roots primário e
secundário através dos valores do bridge priority.
 Defina as interfaces que serão designated e root ports, se possível setando prioridades e
custos para que se tenha controle da topologia final tanto em operação como em caso
de falhas (links redundantes).
 Faça os ajustes finos do STP utilizando as ferramentas indicadas no capítulo.
 Ative o UDLD em “aggressive mode” nas interfaces de fibra óptica.
 Utilize de preferência PVRST+ (RSTP) ou MST para melhorar o tempo de convergência
da rede.
 O protocolo Spanning Tree Tradicional.

 O processo de convergência do STP.
 Como alterações na topologia afetam o STP.
 Configurações do STP.
 Funcionamento e configurações do Protocolo Rapid Spanning Tree – RSTP.
 Funcionamento e configurações do Protocolo Multiple Spanning Tree - MSTP.
 Entender e configurar recursos para melhorar a estabilidade do STP.
 Comandos show, debug aplicados no troubleshooting de redes com STP.

Capítulo 05 - Multilayer
Switching
estudar os switches Objetivos do Capítulo
Multicamada, também
Ao final desse capítulo você terá estudado e
chamado de switches Layer
3 ou Multilayer Switches  Funcionamento e operação dos
(MLS). Switches Multicamada.
 Tipos de interfaces de switches
Multicamada.
 Roteamento entre VLANs com
Como até o momento
switches Multicamada.
trabalhamos com VLANs  Switching utilizando CEF.
precisamos fazer com que  Ativar o servidor DHCP e DHCPv6 em
elas se comuniquem, por switches Multilayer.
isso precisamos de
dispositivos de camada-3
para tal função.
No CCNA R&S o maior foco
foi a utilização de
roteadores atuando nesse
papel, agora vamos
implementar tais recursos
em switches Multicamada.
Bons estudos.

1 Visão Geral de um Multilayer Switch 125

1.1 Modelo Funcional de um Switch L3 125
1.2 TCAM – Ternary Contend-Addressable
Memory____________________________ 127
2 Roteamento InterVLAN utilizando
Multilayer Switches _________________ 128
2.1 Processo Básico de Encaminhamento
em Switches Multilayer _______________ 128
2.2 Interfaces MLS _________________ 129
2.2.1 Configurando Portas L2 __________ 129
2.2.2 Configurando uma SVI ___________ 129
2.2.3 Configurando uma Porta Roteada – L3
Routed Port ___________________________ 130
2.2.4 Uso das Interfaces L2 e L3 em
Arquiteturas Três Camadas _______________ 131
3 Cisco Express Forwarding em Switches

Multilayer ________________________ 132
3.1 FIB – Forward Information Base ___ 133
3.2 Adjacency Table ________________ 135
3.3 Reescrevendo os Pacotes – Packet
Rewrite ____________________________ 137
3.4 Configurando o CEF _____________ 137
3.5 Verificações em Switches Multilayer 138
4 DHCP em Switches Multilayer _____ 139
4.1 Configurando o DHCP Server ______ 140
4.1 DHCP Options __________________ 141
4.2 Configuração Manual de IPs via DHCP
141
4.2 Configurando o DHCP Relay ______ 142
5 Configurando DHCP para IPv6 - DHCPv6
143
5.1 Stateless Address Autoconfiguration -
SLAAC 144
5.2 DHCPv6 Lite ___________________ 145
5.3 DHCPv6 Statefull _______________ 146
5.4 DHCPv6 Relay __________________ 147
5 Resumo do Capítulo _____________ 147

1 Visão Geral de um Multilayer Switch

Até o momento nos dedicamos aos recursos de switching que estão disponíveis em maioria das
linhas de switches camada-2 da Cisco. Switches como os da linha Catalyst Catalyst 4900,
Catalyst 3750-X, Catalyst 3750, Catalyst 3560-X, Catalyst 3560 de configuração fixa com o
software Cisco IOS apropriado podem também realizar o encaminhamento com sabe em
informações das camadas 3 e 4 do modelo OSI, operação conhecida como Multilayer
Switching ou MLS. Switches modulares como os da linha 6500 e Catalyst 4500 também
suportam recursos multicamada e outras funções avançadas.
Os switches da linha Catalyst suportam dois tipos de MLS: Route Caching e Topology Based,
porém os switches com base em Cisco IOS suportam apenas a segunda opção de MLS, a qual
representa a segunda geração de multilayer switching implementada nos switches citados no
parágrafo anterior.
No route caching, que é a primeira geração de MLS lançada, era necessário um route
processor (RP) e um switch engine (SE) para realizar as operações multicamada.
Já a segunda geração ou topolgy based é conhecida como Cisco Express Forward ou CEF, a
qual faz um “download” da tabela de roteamento para uma Forward Information Base (FIB)
que é implementada em hardware, vamos estudar esses assuntos mais para frente nesse
capítulo.
Algumas plataformas permitem desativar o encaminhamento via CEF e passar a funcionar com
o Fastswitching, porém maioria não permite tal configuração e são apenas CEF.
1.1 Modelo Funcional de um Switch L3
Assim como fizemos para os switches L2 no capítulo 3, vamos estudar os caminhos que um
quadro e um pacote podem cruzar através de um switch multicamada. Veja na figura a seguir
um típico multilayer switch e seus processos de decisão, onde os pacotes chegam em uma fila
de entrada (ingress queue), assim como nos switches L2.
Os pacotes que entram tem os endereços de destino inspecionados tanto em camada 2 como 3,
porém agora a decisão da porta que será utilizada como destino do encaminhamento tem como

base duas tabelas (CAM e FIB table), sendo que mesmo assim a decisão final de encaminhar ou
não continua sendo da ACL (Access list). Assim como para os switches L2 as decisões no MLS
podem ser também tomadas simultaneamente em hardware, conforme cada bloco funcional a
seguir:
 L2 forwarding table: O MAC de destino é utilizado como um índice para a CAM table e
para encaminhar quadros na mesma VLAN. O resultado da consulta à CAM table também
pode ser utilizado para decidir se o quadro precisa ser processado pela camada-3.
 L3 forwarding table: A FIB table é consultada através do IP de destino como um
índice. O processo de busca é através do “longest match” (endereço e mascara que
contém mais bits) para obter o endereço de camada-3 do próximo salto. Além disso, a
FIB guarda o endereço de camada-2 do próximo salto e a porta de saída (egress switch
port e VLAN ID) para evitar que novas consultas precisem ser feitas no futuro para o
mesmo endereço.
 Security ACLs: ACLs inbound e outbound são compiladas na TCAM para que decisões
de encaminhamento sejam feitas com uma única consulta (single table lookup).
 QoS ACLs: Classificações, políticas e marcações de pacote podem ser feitas também em
uma única consulta na TCAM de QoS.
A grande diferença entre um switch Layer 2 e um Layer 3 é que no primeiro ele só encaminha
quadros através das portas, se dois quadros precisam ser encaminhados entre VLANs diferentes
o switch L2 somente entrega o quadro ao dispositivo L3 assim como recebeu, ou seja, é receber
quadro de uma porta e repassar direto para outra, no máximo se for transmitir através de um
trunk o switch L2 coloca a “tag” ISL ou 802.1Q antes do encaminhamento.
Agora com o switch L3 podem chegar pacotes que necessitam ser “roteados” durante o
processo, nesse caso o próximo salto é obtido da FIB table, assim como um roteador tira o
endereço do próximo salto da sua tabela de roteamento. Esse processo é diferente do switching
L2 porque envolve uma decisão de roteamento, portanto no MLS precisamos para esse caso:
 Com o endereço de camada-3 de destino determinar o próximo salto.
 O MAC de origem será o da porta de saída e o de destino será o MAC do próximo salto
que precisa ser determinado pelo ARP.
 O Time-To-Live (TTL) do pacote de camada-3 precisa ser decrementado em 1.
 Como o pacote IP original foi alterado no passo anterior, precisaremos recalcular
chaecksum do cabeçalho do IP.
 Como o cabeçalho do IP, endereço MAC de origem e destino foram alterados será
necessário recalcular o FCS do quadro ethernet antes de enviá-lo à fila de saída (egress
queue).
Todo esse processo é feito em hardware, por isso é mais eficiente que em um roteador que faz
essas atividades em software normalmente.
Um detalhe importante é que para que o processo simultâneo de encaminhamento dos pacotes
ocorra ele precisa ser “MLS-ready” (não precisa de decisões adicionais). Por exemplo, o
encaminhamento de pacotes entre hosts com endereços (MAC e IP) conhecidos sem nenhum
outro parâmetro que precise ser manipulado acontece de forma simultânea.
Porém existem processos que não podem ser tratados direto pela CEF e são marcados e
enviados ou apontados (punted) para a CPU do switch processar, tais como:
 Requisições ARP.
 Pacotes IP com TTL expirado, MTU excedido, que necessita de fragmentação e assim por
diante, pois precisam de uma resposta do roteador remoto.
 Broadcasts que serão encaminhados como unicast, tais como requisições DHCP e
funções do IP helper-address.
 Updates de protocolos de roteamento.
 Pacotes do CDP.

 Protocolos de roteamento do IPX.

 Pacotes que precisam de criptografia.
 Pacotes que serão tratados pelo NAT.
 Protocolos especiais como AppleTalk, DECnet, etc.
Portanto nos casos citados acima o switch L3 não pode tratar o pacote em uma única consulta e
depende de outros processos para depois finalizar o encaminhamento ou a tomada de decisão
do que fazer com o pacote.
1.2 TCAM – Ternary Contend-Addressable Memory
A TCAM é utilizada para compilar as ACLs e permitir que em uma única consulta o switch já
saiba se aquele pacote deve ou não ser encaminhado (permit ou deny), possibilitando que essa
consulta seja implementada e hardware e seja simultânea (em paralelo) com os demais
processos que estudamos anteriormente.
Cada declaração ou statement de uma ACL é chamada de ACE (Access Control Entities)
configurada no switch é compilada (ou misturado – merge) pelo Feature Manager (FM)
dentro da TCAM, possibilitando que essa tabela seja consultada sem processamento como no
caso dos routers, mas sim ao mesmo tempo em que o pacote é encaminhado (frame-
forwarding speed).
Em modo geral a TCAM é uma extensão do conceito da tabela CAM. Na CAM o MAC de destino é
utilizado como índice para uma consulta que geralmente resulta em uma porta/VLAN. Essa
consulta está baseada na verificação exata (match) de dois valores chaves que são compostos
de bits (zeros e uns). Resumindo:
1. Chega um quadro em uma porta;
2. Switch usa o MAC de destino como índice;
3. Consulta na CAM se tem uma entrada igual  compara os dois valores em binário 
MAC de destino do quadro com MACs de origem gravados na CAM;
4. Tem um endereço igual na CAM? Encaminha para a porta/VLAN de destino mapeada na
tabela;
5. Não tem? Processo de Flooding.
A TCAM faz uma operação parecida através da consulta da tabela através de índices, porém
além dos zeros e uns ela tem um terceiro parâmetro “X” que é o “não importa”, por isso o
nome ternária ou ternary.
A TCAM é composta por várias combinações de valor, máscara e resultado (VMR – Value, Mask
and Result). O valor são 134 bits que representam fundamentalmente endereços de origem e
destino. As máscaras também têm 134 bits e servem para selecionar os bits de interesse que
devem ser verificados (match) ou não precisam ser verificados. Por último, o resultado é um
valor numérico que representa uma ação depois que a busca na TCAM é finalizada.
O resultado do valor pode ser um permit, deny, um valor de índice para uma política de QoS,
um ponteiro para o próximo salto na tabela de roteamento, etc, ou seja, é a ação que será
tomada após a consulta finalizada.
Note que a CAM e a TCAM existem tanto nos switches L2 como L3, sendo que a TCAM não é
utilizada para o processo de “chaveamento” e sim para compilar as ACLs e políticas de QoS
para que esse processamento possa ser realizado em hardware e simultaneamente com os
demais processos do switch.

2 Roteamento InterVLAN utilizando Multilayer Switches

Um switch multilayer pode fazer encaminhamento dos quadros em camada-2 e também rotear
entre VLANs. Vamos estudar nesse tópico a sequência tomada pelo encaminhamento que
facilitarão a compreensão do funcionamento dos switches L3, verificação de erros, access-lists,
VLAN access-lists, routing e QoS.
2.1 Processo Básico de Encaminhamento em Switches Multilayer
Um multilayer switch faz encaminhamento camada-2 (L2) quando o MAC de destino está
mapeado em uma de suas interfaces. Os passos do encaminhamento L2 são (considerando que
os switches são Store-and-forward – passo 2):
Entrada do quadro:
1. Recebe o quadro e coloca na fila de entrada;
2. Verifica a integridade do quadro através do FCS;
3. Aplica a VLAN ACL (VLAN Access Control List) de entrada (inblound);
4. Faz a busca da porta/VLAN de saída através do MAC de destino.
Envio pela porta de saída:

1. Aplica a VLAN ACL de saída (outbound);
2. Aplica a ACL de QoS de saída (outbound);
3. Seleciona a porta de saída;
4. Coloca o quadro na fila da porta de saída;
5. Encaminha o quadro.
Já o encaminhamento camada-3 é feito pelo switch multilayer quando o MAC de destino é o seu
próprio endereço MAC, pois é sinal que o quadro é para o próprio switch ou precisa ser
encaminhado para outra rede porque o switch é o gateway padrão dos hosts em cada VLAN. Os
passos gerais envolvidos nesse processo de encaminhamento layer-3:
Entrada do quadro/pacote:
1. Recebe o quadro e coloca na fila de entrada;
2. Verifica a integridade do quadro;
3. Aplica a VLAN ACL de inbound;
4. Busca o MAC de destino.
Roteamento L3:
1. Aplica a ACL de entrada;
2. Faz o processo de roteamento (estudaremos em tópicos posteriores);
3. Aplica a ACL de saída.
Saída do quadro/pacote:
1. Aplica a VLAN ACL de saída (outbound);
2. Aplica a QoS ACL de saída (outbound);
3. Seleciona a porta de saída;
4. Reescreve o pacote IP (decrement o TTL e recalcula o checksum do cabeçalho) e monta
o quadro de camada-2 com o MAC de origem sendo o do próprio switch e o MAC de
destino conforme próximo salto determinado anteriormente;
5. Coloca o quadro na fila de saída;
6. Encaminha o quadro.

A aplicação das regras das VLAN ACLs e ACLs depende do administrador ter configurado ou
não, se não existe VACL/ACL criada e aplicada esses passos são ignorados pelos switches.
Essas listas de acesso ficam compiladas na TCAM para que todo esse processo seja realizado
em uma única consulta.
Lembre-se que Multilayer switches utilizam Application Specific Integrated Circuits (ASIC)
para encaminhar tanto quadros como packets em “wire speed” (sem delay de processamento
via software – processos realizados em hardware). Por isso o processo de encaminhamento
para endereços conhecidos é muito mais rápido em comparação a roteadores.
2.2 Interfaces MLS
Um switch multilayer pode ter os seguintes tipos de interfaces:
 Layer 2 Interface: pode ser uma porta de acesso ou de trunk com o comando
“switchport” habilitado.
 Switched Virtual Interface (SVI): interface virtual ou de software utilizada para
representar uma VLAN, ou seja, ela tem o endereço IP do domínio de broadcast virtual
que abrange todas as portas alocadas na VLAN. Pode ser Layer 2 ou Layer 3.
 Routed Interface: nesse caso a porta física atuará como uma porta roteada (como
uma interface de um roteador) e poderá ter um ou mais endereços de camada-3
vinculados à ela, porém não poderá ter VLAN associada. Tem o comando “no switchport”
habilitado.
Vamos estudar algumas configurações e características de cada tipo de porta a seguir.
2.2.1 Configurando Portas L2
As portas camada-2 (L2 ou Layer-2) são as portas que trabalhamos até o momento, as quais o
comando “switchport” está habilitado. Essa é a configuração padrão em todas as portas dos
switches Multilayer.
Podemos associar essas portas à VLANs e utilizar os comandos “switchport” para fazer o ajuste
fino das configurações. Podem ser portas de acesso, trunk e etherchannels.
2.2.2 Configurando uma SVI

As interfaces comutadas virtuais ou SVI (Switched Virtual Interface) são interfaces lógicas
utilizadas para configuração do endereço IP de uma VLAN, para que o switch possa ser utilizado
como Gateway dos hosts alocados naquela VLAN, possibilitando que o roteamento entre VLANs
seja realizado pelo próprio switch multicamadas local.
Elas são representadas como “interface vlan num-vlan” no Cisco IOS.
Tanto switches L2 como multilayers já tem uma interface SVI criada por padrão
automaticamente, é a “interface VLAN 1”, porém ela não tem IP configurado e fica shutdown
por padrão. A diferença é que para os switches L2 apenas uma SVI ficará ativa e ela responde
como a interface virtual de gerenciamento do switch (tem o IP de gerenciamento) e
normalmente é a VLAN nativa também. Já nos switches multicamadas podemos ter diversas
SVIs, uma por VLAN criada.
Para adicionar mais SVIs basta criar a VLAN (recomendado) e utilizar o comando “interface vlan
num-vlan”, lembrando que ao configurar um endereço IP na SVI automaticamente a torna uma
interface L3. As SVIs são utilizadas para:
 Roteamento entre VLANs.

 Fornecer o “default gateway” para os usuários naquela VLAN.

 Rotear o tráfego para for a da VLAN.

 Fornecer conectividade IP para gerenciamento do switch (todos os IPs configurados na
SVI respondem como IPs de gerenciamento).
 São interfaces que podem ser utilizadas no processo de roteamento estático e dinâmico.
A SVI é considerada “up” enquanto o switch tiver portas associadas à VLAN. Se todas as portas
alocadas na VLAN ficarem down a interface também fica down, evitando “buracos de
roteamento” (routing black hole). Para evitar esse efeito alguns switches Cisco permitem o uso
do comando abaixo para manter a SVI ativa mesmo que todas as portas estejam indisponíveis:
Switch(config-if)#switchport autostate exclude
Para configurar o roteamento InterVLAN você deve seguir os passos abaixo:
 Ativar o roteamento IP.
Switch(config)#ip routing
 Criar as VLANs (a criação da SVI não cria a VLAN).
 Criar as SVIs, configurar o endereço IP e ativar a interface.
Switch(config)#interface vlan 3
Switch(config-if)#ip address 10.3.3.3 255.255.255.0
Switch(config-if)#no shut
 Configurar rotas estáticas ou protocolo de roteamento dinâmico conforme necessidade

do projeto. Os comandos são os mesmos estudados no CCNA R&S.
Para verificar as configurações utilize os comandos tradicionais:

 Show running-config interface vlan 3
 Show interfaces vlan 3
 Show ip interface brief
2.2.3 Configurando uma Porta Roteada – L3 Routed Port

Para configurar uma interface de um switch multilayer como “routed port” (porta camada-3) é
necessário remover a funcionalidade “Layer 2” com o comando “no switchport” dentro da
interface. Com isso a porta aceita a configuração de endereço IP e se comporta como a porta
de um roteador, veja exemplo de configuração abaixo:
sw1(config)#int fa 1/0/5
sw1(config-if)#no switchport
sw1(config-if)#ip address endereço máscara [secondary]
Se você tiver um etherchannel essa configuração deve ser realizada na interface port-
channel e não nos links individuais, conforme já citado em capítulos anteriores.

2.2.4 Uso das Interfaces L2 e L3 em Arquiteturas Três Camadas

As portas L2 (switchports) são utilizadas para os hosts (computadores, servidores, etc) e nos
trunks entre switches. Já as SVIs são configuradas para o roteamento entre as VLANs criadas
no próprio switch L3.
As interfaces roteadas servem para conectar switches de distribuição ao Core utilizando links
camada-3 ou entre os switches de Core, por exemplo. Veja a figura a seguir com essa
representação.
Na figura acima podemos entender o fluxo de pacotes em uma rede com multilayer switches
em três camadas. Vamos analisar três situações básicas:
1. Dois hosts na mesma VLAN se comunicando: Os quadros são tradados em camada-
2, não existe roteamento entre VLAN envolvido.
2. Dois hosts em VLANs diferentes que pertencem à mesma estrutura de
distribuição: os pacotes são inseridos em quadros que são marcados e enviados via
trunk até os switches de distribuição (gateway dos hosts) para que eles façam o
roteamento entre VLANs. Normalmente não envolve roteamento estático ou dinâmico
para encontrar as rotas, pois as SVIs são interfaces diretamente conectadas.
3. Dois hosts em distribuições diferentes se comunicando (passando pelo Core):
nesse caso os pacotes originados no acesso são encaminhados à distribuição via trunks
e os switches de distribuição precisarão encaminhar os pacotes através dos links L3
entre eles e o Core para que o Core encaminhe esses pacotes até a outra estrutura de
distribuição. Nesse caso é necessário roteamento estático ou dinâmico para que o switch
saiba a interface de saída para as redes remotas.
Procure entender bem essa dinâmica, pois ela vai ajudar muito a compreensão do conteúdo
daqui para frente.

3 Cisco Express Forwarding em Switches Multilayer

Switches multilayers podem utilizar diversos métodos para encaminhar pacotes com base nas
informações das camadas 3 e 4 do modelo OSI, mas a linha atual dos switches Catalyst utilizam
por padrão o CEF devido a sua rapidez e eficiência. Veja a figura abaixo com os componentes
gerais do CEF.
Você já deve ter lido em outras bibliografias e até mesmo em nosso material do CCNP ROUTE
que diversas plataformas de roteadores utilizam CE, porém apenas switches multilayer ou
roteadores de grande porte como ASR 1000, 12000 ou CRS podem fazer o CEF switching
baseado em hardware.
Em roteadores como da família ISR-G1 (1800/2800/3900), ISR-G2 (1900/2900/3900) e 7200

fazem o CEF em software.
Switches mais antigos como Catalyst 5000 e 6000 utilizam o método anterior de CEF utilizando
um route processor (RP) e uma switch engine (SE), conforme já citamos anteriormente. Nessa
tecnologia a ideia básica é “roteie uma vez e comute o máximo na sequência” (em inglês –
“route once switch as many”). Essa técnica é chamada Netflow Switching ou Route Cache
Switching.
Pela sua eficiência e rapidez o CEF tomou lugar do Netflow Switching e atualmente é realizada
por várias linhas de switches através de hardware, tais como:
 Catalyst 6500 com placa supervisora (Supervisor Module) SUP720 com MSFC3
integrada.
 Catalyst 6500 com Supervisor 2 combinada com MSFC2.
 Catalyst 4500 com Supervisor III, IV, V e 6-E.
 Catalyst 4500-E com Supervisor 7-E e 8-E.
 Switches de configuração fixa Catalyst 4500-X, 3750, 3750-X, 3560, 3550, 2960 e
2950.
Em resumo o Cisco Express Forwarding (CEF) tem as seguintes funções:

 Separa o control plane do data plane de hardware.
 O control plane roda em software e monta em hardware a FIB e adjacency table
(tabela de adjacências).
 O data plane utilize o hardware para encaminhar quase todo tráfego IP de unicast, com
exceção de (são apontados para o processador tratar):
o Pacotes com opções marcadas no cabeçalho do IP.

o Tráfego tunelado.
o Protocolo IPX ou outros tipos de protocolos de camada-3.
o Pacotes com TTL expirado.
o Pacotes que precisam ser fragmentados.
 Utiliza tabela TCAM.
 Pode ser centralizado ou distribuído (dCEF).
Vamos estudar na sequência os integrantes dos blocos funcionais do CEF que são:
 Layer-3 Engine: utilizada para construir a informação de roteamento. Responsável pela
tabela de roteamento e a tabela ARP.
 Layer-3 Forward Engine: utilizada para comutar os pacotes em hardware.
Responsável pela FIB e a tabela de adjacências.
3.1 FIB – Forward Information Base
Vamos começar esse tópico melhorando um pouco a figura com os blocos do CEF abaixo
conforme livro oficial do CCNP SWITCH da Cisco.
O primeiro bloco do CEF é o L3 Engine, o qual é basicamente um roteador com a função de

manter as informações de roteamento, sejam elas rotas diretamente conectadas, estáticas ou
aprendidas via protocolos de roteamento dinâmico. Com essas informações é montada a tabela
de roteamento (Routing Table).
Essa tabela de roteamento é então reformatada e reorganizada por sub-rede de destino do

maior prefixo para o menor, ou seja, os prefixos mais longos (mais específicos) vem antes dos
menos específicos. Esse novo formato é chamado FIB ou Forward Information Base – Base
de Informações de Roteamento. Além disso, a FIB contém o endereço do próximo salto (next-
hop) para cada entrada aprendida, assim quando a sub-rede é encontrada pelo prefixo mais
específico o endereço de camada-3 do próximo salto também já está definido.
Esse processo é dinâmico e quando a tabela de roteamento sofre uma alteração ela já atualiza
a FIB automaticamente.

Para visualizar a FIB relacionada com uma VLAN específica podemos utilizar o comando:
- show ip CEF [tipo mod/num] [vlan vlan-num] [detail]
Veja exemplo abaixo para a VLAN20 que tem uma SVI configurada com o IP 10.0.0.1 e rede
10.0.0.0/24. Note que o IP da SVI aparece no comando como uma rede de host com máscara
/32.
SW2#show ip cef vlan 20

10.0.0.0/24
attached to Vlan20
10.0.0.1/32
attached to Vlan20
A opção detail traz informações detalhadas sobre as rotas incluídas na FIB, veja abaixo.
SW2#show ip cef vlan 20 detail

IPv4 CEF is enabled for distributed and running
VRF Default:
13 prefixes (13/0 fwd/non-fwd)
Table id 0
Database epoch: 2 (13 entries at this epoch)
10.0.0.0/24, epoch 2, flags attached, connected, cover dependents, need deagg

Covered dependent prefixes: 4
need deagg: 3
notify cover updated: 1
attached to Vlan20
10.0.0.1/32, epoch 2, flags attached
Adj source: IP adj out of Vlan20, addr 10.0.0.1 0492EE00
Dependent covered prefix type adjfib cover 10.0.0.0/24
attached to Vlan20
SW2#
Podemos também analisar a FIB utilizando prefixo e máscara, sendo que a opção detail dá
informações detalhadas das entradas, vamos ver exemplos abaixo do mesmo switch e VLAN
anteriores.
SW2#show ip cef 10.0.0.0 255.0.0.0 longer-prefixes

Prefix Next Hop Interface
10.0.0.0/24 attached Vlan20
10.0.0.2/32 receive Vlan20
10.0.0.255/32 receive Vlan20
SW2#
A opção longer-prefixes mostra entradas de /16 e mais longas, assim podemos analisar todas
as entradas. Vamos ao segundo comando com a opção detail.
SW2#show ip cef 10.0.0.0 255.255.255.0 detail

10.0.0.0/24, epoch 2, flags attached, connected, cover dependents, need deagg
Covered dependent prefixes: 4
need deagg: 3
notify cover updated: 1
attached to Vlan20
Se a entrada for atualiza aparecerá após a rede/máscara na primeira linha da saída uma
informação chamada “Version” com o número de vezes que a entrada foi atualizada na FIB.

Além disso, o “epoch” representa o número de vezes que a tabela CEF foi apagada e remontada
por completo, nesse exemplo foram apenas duas vezes.
Esses números são importantes porque podem mostrar instabilidades na tabela, pois se estiver
montando e remontando muito é sinal que algo está errado em um ambiente estável.
Uma vez montada a FIB o encaminhamento de pacotes segue a linha pontilhada da figura com
a estrutura do CEF, sendo que esse processamento é realizado por hardware.
Caso o pacote não possa ser tratado dessa maneira ele é enviado para o L3 Engine (segue a
linha pontilhada de cima - “CEF Punt”) e será tratado em software. As principais condições que
impedem um pacote de ser tradado em hardware são:
 Não tem entrada na FIB para o destino.
 A FIB está cheia.
 TTL do pacote IP expirou.
 O MTU foi excedido e é necessário fragmentar o pacote.
 Uma mensagem de ICMP Redirect foi recebida.
 O encapsulamento não é suportado.
 Pacotes tunelados que necessitam de compressão ou criptografia.
 ACL com a opção “log” no final.
 NAT precisa ser realizado, com exceção da linha 6500 com SUP 720 que trata do NAT
em hardware.
O CEF pode rodar centralizado em um único hardware ou estar distribuído. O que estudamos
até o momento é chamado de CEF centralizado, porém existem outros dois tipos de CEF:
 Accelerated CEF (aCEF): o CEF é distribuído entre múltiplos L3 Engines que são
normalmente localizados em placas de tributário do Catalyst 6500 (line cards). Como
essas placas não conseguem armazenar a FIB inteira normalmente uma parte dela é
enviada, o que é chamado de FIB Cache. Se não existe entrada para um destino nesse
cachê uma requisição para o L3 Engine é enviada pedindo por mais informações da FIB,
por isso o processo é acelerado, porém algumas vezes não é “wire-speed”.
 Distributed CEF (dCEF): nesse caso o CEF é distribuído por completo por diversos L3
Fwd Engines e gera um ganho real de performance. Alguns módulos do 6500 suportam
dCEF e tem sua própria FIB e L3 Fwd Engine, sendo que nesse caso uma L3 Engine
central (MSFC3, por exemplo) mantém a tabela de roteamento, gera a FIB e
dinamicamente replica a por completo para os módulos.
A seguir vamos estudar a tabela de adjacências, que faz parte ainda da L3 Fwd Engine.
3.2 Adjacency Table
As tabelas de roteamento com as redes de destino e próximo salto são mantidas separadas das
informações de mapeamento entre o endereço de camada-3 do próximo salto e seu MAC
(endereço de camada-2), pois essa informação é mantida pela tabela ARP (ARP Table) que faz
parte do L3 Engine.
Como a FIB tem um endereço de próximo salto precisa também do MAC desse endereço, por
isso existe a tabela de adjacências ou vizinhos (adjacency table), ela guarda as informações
sobre o MAC desses vizinhos, possibilitando que em uma única consulta seja resolvido IP, MAC
e porta de saída do vizinho que podem ser alcançados em apenas um salto via camada-2.
Portanto, a adjacency table guarda as informações de endereço IP e MAC do vizinho,

informações que são obtidas através da ARP Table do L3 Engine.

Para verificar a tabela de adjacências podemos utilizar os seguintes comandos:

- Show adjacency [type mod/num | vlan num-vlan ] [summary | detail]
Se a entrada para determinado próximo salto existe a tabela de adjacência é atualizada, caso
não exista é marcada como “CEF Glean” na FIB. Mas o que isso significa?
Nesse caso a informação não pode ser enviada diretamente por hardware pela L3 Fwd Engine,
por isso é enviada uma solicitação a L3 Engine fazer um ARP Request e esperar por um ARP
Reply para resolver o endereço. Esse estado é chamado de CEF Glean e significa que a L3
Engine precisa resolver o MAC do próximo salto.
Podemos verificar se existe algum endereço em “glean” com os seguintes comandos:

- Show ip CEF adjacency glean
- Show ip CEF ip mask-/32 detail
No segundo comando deve aparecer a mensagem de “valid glean state” para confirmar que o
estado de “glean”, além disso, no “show ip arp ip-testado” não deve mostrar nenhuma
resposta, pois o IP não deve ter MAC vinculado a ele.
Durante o tempo que a FIB está em CEF Glean aguardando a resolução ARP os pacotes que
seriam enviados ao destino são simplesmente descartados para que a fila de entrada do L3
Engine não seja lotada com solicitações ARPs iguais. Esse processo é chamado de “ARP
Throttling” ou “Throttling Adjacency”.
Se a resposta à requisição ARP não é recebida em 2 segundos o throttling é liberado e outra

requisição é passada. Caso uma resposta ARP seja recebida o throttling é liberado e a entrada
na FIB é completada, possibilitando o envio de pacotes ao destino.
Podemos encontrar na tabela de adjacência vários tipos de entradas listadas, seguem alguns
exemplos abaixo:
 Null adacency: pacotes endereçados à interface nula (null interface).
 Drop adjacency: pacotes que serão “dropados” (descartados) pelo switch porque não
podem ser encaminhados, por exemplo, por falha no encapsulamento ou o protocolo não
foi reconhecido. Podemos ver os pacotes descartados com o comando “show CEF
drop”.
 Discard adjacency: pacotes marcados para descarte devido a ACL ou política
configurada no switch.
 Punt adjacency: pacotes que precisam ser enviados para o L3 Engine tratar. Podemos
listar essa quantidade por razão de apontamento para a L3 Engine no comando “show
CEF not-switched” ou “show (ip|ipv6) cef switching statistics [feature]” (para
IPv4 “show ip CEF switching statistics”.
No próximo tópico vamos estudar o último bloco faltante: “Packet Rewrite”.

3.3 Reescrevendo os Pacotes – Packet Rewrite
No final de tudo, quando o switch multicamada com CEF encontra uma entrada válida na FIB e
tabela de adjacência o pacote está quase pronto para ser enviado pela porta de saída em
direção ao seu vizinho.
Portanto o switch faz uma consulta rápida e encontra o IP do vizinho (próximo salto) e a porta
de saída na FIB, além disso da tabela de adjacências ele tira o MAC desse vizinho para quem o
pacote deve ser enviado, porém antes de enviar algumas ações devem ser tomadas:
1) O pacote IP precisa ter seu TTL decrementado em 1 (1 salto);
2) Devido ao passo 1 o checksum do cabeçalho do IP precisa ser recalculado;
3) Agora o switch precisa montar o quadro de camada-2 com:
a. MAC de origem – MAC do switch;
b. MAC de destino – MAC do vizinho retirado da tabela de adjacência;
4) Falta somente recalcular o FCS (checksum de camada-2) e o quadro pode ser reescrito e
enviado pela interface de saída.
Mas você deve estar pensando: “Ok, mas o router faz tudo isso? O que eu ganho com o
switch?”. O router faz em software, mas o switch tem um hardware dedicado para reescrever o
quadro e obter essas informações rapidamente através das consultas que estudamos até aqui
nas tabelas FIB e de adjacência, o que torna o processo de encaminhamento L3 tão rápido
como o de encaminhamento de quadros L2 nos switches.
3.4 Configurando o CEF
Felizmente configurar o CEF é muito mais simples que entender o seu funcionamento, pois ele
já vem ativado em maioria dos switches multicamadas e em alguns nem pode ser desativado.
Além disso, por padrão o CEF suporta balanceamento de cargas por destino (per destination
load sharing) se o balanceamento de cargas for ativado em um protocolo de roteamento no
switch.
Para desativar o CEF existem os comandos abaixo, porém dependendo da versão de hardware e
Cisco IOS alguns modelos não deixarão desativar o CEF ou mudar para route-cache.
 4500: SW(config)#no ip cef.
 3500/3700: SW(config-if)#no ip route-cache cef
 6500 com PFC, distributed FC e multilayer switch FC não podemos desabilitar o CEF.
A recomendação é sempre utilizar o CEF, a não ser que para fazer um debug você precise
desabilitar.
Para verificar o CEF podemos utilizar o comando geral “show ip cef”, veja abaixo um exemplo:
Switch#sho ip cef
0.0.0.0/0 no route
0.0.0.0/8 drop
0.0.0.0/32 receive
127.0.0.0/8 drop
224.0.0.0/4 drop
224.0.0.0/24 receive
240.0.0.0/4 drop
255.255.255.255/32 receive

Nesse exemplo temos a interface VLAN1 configurada com o IP 10.0.0.1/24. Vamos analisar
algumas entradas:
 0.0.0.0/0 (no route): não existe rota padrão configurada no switch. Agora vamos
configurar a rota “ip route 0.0.0.0 0.0.0.0 10.0.0.2” e dar o mesmo comando, veja a
diferença abaixo após configurarmos a rota padrão ao invés de “no route” teremos um
próximo salto (10.0.0.2) e uma interface de saída (vlan 1):
Switch#sho ip cef
0.0.0.0/0 10.0.0.2 Vlan1
###saídas omitidas###
 10.0.0.0/24 (attached): é a sub-rede configurada na interface VLAN 1 que aparece

marcada como “attached” porque está diretamente conectada à VLAN1.
 10.0.0.1/32 (receive): é o IP da própria VLAN 1, o qual é um endereço que deve ser
tratado internamente pelo switch, por isso aparece marcado como “receive”.
 127.0.0.0/8 (drop): essa é a rede reservada para loopback em hosts, por isso está
marcada como “drop”, ou seja, qualquer IP dessa rede será descartado pelo switch e
não será encaminhado. Note que o mesmo ocorre para os endereços de broadcast
10.0.0.255 e para o 255.255.255.255.
3.5 Verificações em Switches Multilayer
Além dos comandos específicos do CEF que estudamos até o momento, outros comandos
podem ser utilizados para verificar um ambiente MLS, por exemplo:
 Show ip interface: para verificar as configurações do protocolo IP das interfaces L3 e

ver se não existe ACL aplicada à elas.
 Show ip interface brief: verificar os IPs configurados nas interfaces que devem ser L3
e SVIs.
 Show interface switchport: permite verificar se a interface está configurada como L2
ou L3, veja um exemplo de saída para interfaces L3 abaixo.
Switch#show interfaces f1/0/1 switchport

Name: Fa1/0/1
Switchport: Disabled
 Show running-config interface vlan num-vlan: para verificar as configurações de

uma SVI.

4 DHCP em Switches Multilayer

O serviço de DHCP ou Dynamic Host Configuration Protocol é utilizado para que os
usuários obtenham dinamicamente sua configuração de IP, tais como endereço, máscara,
gateway, servidor DNS e outras opções.
Ele é definido na RFC 2131, trabalha no modelo cliente/servidor e roda em UDP nas portas 67
(requisições de clientes) e 68 (respostas dos servidores). Sua mensagem inicial de um cliente
solicitando suas configurações ao servidor é enviada em broadcast. Abaixo seguem as
mensagens trocadas entre o cliente e o servidor para a aquisição da configuração.
1) DHCPDISCOVER: Cliente envia um broadcast para localizar um servidor disponível.

2) DHCPOFFER: Servidor para cliente em resposta ao DHCPDISCOVER oferecendo os
parâmetros de configuração.
3) DHCPREQUEST: Cliente requer os parâmetros oferecidos de um servidor e
implicitamente nega a oferta de outros servidores. Também usado para solicitar uma
reinicialização e uma relocação. Enviado em broadcast.
4) DHCPACK: Servidor para cliente em broadcast. Dá o aceite dos parâmetros de
configuração incluindo o endereço IP alocado.
O serviço de DHCP pode estar localizado de duas maneiras em uma rede:

 Distribuída: servidor DHCP na mesma sub-rede que os hosts e normalmente temos
diversos servidores, um para cada domínio de broadcast ou VLAN.
 Centralizada: servidor DHCP está em um ponto remoto em sub-rede distinta dos hosts,
nesse caso os gateways precisarão atuar como “relay” e encaminhar a requisição até o
servidor, pois broadcasts não são encaminhados entre diferentes domínios.
Os switches multicamada Cisco podem atuar das duas maneiras, tanto como um servidor DHCP
local, fornecendo IP para os hosts conectados às suas VLANs através das SVIs, ou como
“relay” também encaminhando solicitações DHCP a um servidor remoto centralizado com o
comando “ip helper-address”.
Você vai notar que as configurações são as mesmas que você aprendeu para configurar o DHCP
em roteadores no CCNA R&S, porém esse capítulo está no CCNA SWITCH para lembrá-lo que os
switches L3 podem fazer o DHCP também e não é preciso servidor ou router para esse serviço.

4.1 Configurando o DHCP Server
Para configurar o DHCP devemos seguir alguns passos básicos:
1) Definir os endereços IPs que serão excluídos do pool com o comando “ip dhcp
excluded-address end-inicial end-final” em modo de configuração global.
Normalmente esses endereços são definidos pelo administrador de redes para alocação
estática nos dispositivos de rede, impressoras e servidores.
2) Configurar um pool (escopo DHCP) com o comando “ip dhcp pool nome-do-pool”.
3) Dentro do pool configurar os parâmetros mínimos de configuração dos hosts:
a. Rede a ser atribuída e máscara (network rede máscara);
b. Gateway padrão (default-router ip-da-SVI) – IP da VLAN definido na SVI;
c. Servidor DNS (dns-server ip-do-DNS).
4) Definir o tempo de aluguel dos IPs do pool (lease {infinite | {dias [horas
[minutos]]}}).
Se o switch for fornecer IP localmente uma de suas interfaces deve estar na mesma rede que a
definida no passo 3, pois no DHCP não há vinculação com a interface LAN via comando, o
vínculo é automático quando configuramos uma interface SVI com o IP de uma das faixas do
DHCP pool.
Veja exemplo de configuração abaixo. Nesse exemplo o administrador reservou a faixa dos
endereços de 10.0.0.1 a 10.0.0.10 para alocações estáticas, já os demais endereços devem ser
utilizados no escopo do DHCP (pool) para os clientes.
Sw4(config)#int vlan 1
Sw4(config-if)#ip add 10.0.0.1 255.255.255.0
Sw4(config-if)#no shut
Sw4(config-if)#exit
Sw4(config)#ip dhcp excluded-address 10.0.0.1 10.0.0.10
Sw4(config)#ip dhcp pool ccnp-switch
Sw4(dhcp-config)#network 10.0.0.0 255.255.255.0
Sw4(dhcp-config)#default-router 10.0.0.1
Sw4(dhcp-config)#dns-server 8.8.8.8 4.4.4.2
Sw4(dhcp-config)#lease 30
Sw4(dhcp-config)#end
Sw4#
Nessa configuração o switch vai começar a responder requisições DHCP que chegarem para a
VLAN1 e passará os IPs de 10.0.0.11 a 10.0.0.254 com máscara /24, gateway 10.0.0.1, DNSs
públicos do Google e tempo de aluguel do IP de 30 dias.
Com o comando “show ip dhcp binding” você pode verificar os endereços que o servidor já
forneceu aos clientes. Você pode limpar a alocação no servidor com o comando "Switch#clear
ip dhcp binding { * | endereço-IP }" em modo privilegiado, assim é possível limpar uma
alocação específica pelo endereço IP que ficou presa antes do tempo de aluguel (lease time)
expirar. Se a opção "*" for utilizada TODAS as alocações serão apagadas da base de dados do
servidor DHCP.
A mesma configuração pode ser utilizada se o switch for utilizado como DHCP Server
centralizado, a diferença é que não teremos as SVIs configuradas nas faixas de IP dos pools e
nos switches remotos precisaremos definir o IP do servidor centralizado com o “ip helper-
addres” que vamos estudar a seguir.

4.1 DHCP Options
Tipos de opção ou Options são outros parâmetros de configuração do cliente que um servidor
DHCP pode atribuir aos clientes. Por exemplo, algumas opções usadas com frequência incluem
endereços IP para o gateway padrão (roteadores) e servidores DNS (Domain Name System).
Geralmente, esses tipos de opção são ativados e configurados para cada escopo com os
comandos que vimos no exemplo de configuração.
A maioria das opções são pré-definidas através da RFC 2132, porém algumas não tem os
comandos como vimos anteriormente, sendo necessário definir a opção via seu número padrão,
por exemplo, os telefones IP precisam do endereço do servidor TFTP onde eles conseguem
fazer download do firmware e configurações, essa informação é passada pela opção ou option
150 inserindo na configuração o comando: "option 150 ip end-do-TFTP-Server". Veja
exemplo de pool com option 150 para telefonia IP onde o roteador CME tem o endereço IP
10.1.1.10.
SW-Distr(config)#int vlan 10
SW-Distr(config-if)#ip address 10.1.1.1 255.255.255.0
SW-Distr(config-if)#exit
SW-Distr(config)#ip dhcp excluded-address 10.1.1.1 10.1.1.10
SW-Distr(config)#ip dhcp pool meu-pool
SW-Distr(dhcp-config)#network 10.1.1.0 255.255.255.0
SW-Distr(dhcp-config)#option 150 ip 10.1.1.10
SW-Distr(dhcp-config)#default-router 10.1.1.1
SW-Distr(dhcp-config)#dns-server 10.100.0.1 10.100.0.2
SW-Distr(dhcp-config)#exit
Existem outras opções que podem ser configuradas como 43 para definir o IP de uma WLC para
os Access Points, 69 para o endereço do servidor SMTP e 70 para definir o endereço de um
servidor POP3.
4.2 Configuração Manual de IPs via DHCP
Para clientes que precisam ter sempre o mesmo IP é possível configurar um pool específico com
apenas um host para que toda vez que ele solicite alocação o servidor forneça um IP
especificado na configuração. Com isso o host terá um IP fixo, porém sem precisar configurar
manualmente sua placa de rede, pois o próprio servidor irá controlar esse endereçamento.
Antes de configurar o pool é preciso definir o IP a ser atribuído para o host e também seu
client-identifier ou identificador de cliente. Você pode descobrir o client-identifier utilizando o
comando "debug ip dhcp server" depois vá até o host e libere e volte a solicitar o IP (ipconfig
/release e renew no Windows), com isso você conseguirá ver o MAC e poderá montar o client-
identifier que é geralmente um número de 12 dígitos em Hexa iniciando com 01 (clientes
utilizando Ethernet) e separados de 4 em 4 dígitos, por exemplo, se o MAC do cliente for
0051.0171.baba normalmente seu client identifier será 0100.5101.71ba.ba.
Se mesmo inserindo esse valor o host não pegar o IP conforme configuração, através do MAC e
IP do host que foi alocado verifique com o comando "show ip dhcp binding" o valor correto e
anote para realizar a configuração.
Com o endereço IP e o client identifier é só criar o pool conforme comandos abaixo utilizando as
opções host (para definir IP e máscara) e client-identifier.
Switch(config)#ip dhcp pool Host-1

Switch(dhcp-config)#host 192.168.1.100 255.255.255.0
Switch(dhcp-config)#client-identifier 0100.5101.71ba.ba
Switch(dhcp-config)#

4.2 Configurando o DHCP Relay
Algumas empresas ao invés de adotarem uma solução de DHCP distribuída, como a que
configuramos no exemplo anterior, onde cada switch L3 ou router remoto administraria sua
própria faixa de IPs, preferem uma arquitetura centralizada por questões de administração e
segurança.
Nesse tipo de arquitetura o servidor DHCP segue o exemplo da figura abaixo e pode não estar
situado na mesma sub-rede dos hosts locais, portanto quando um cliente enviar um DHCP
Request em broadcast solicitando o aluguel de um IP o roteador local ou switch multicamada irá
bloquear essa mensagem, pois os roteadores não encaminham broadcasts (255.255.255.255).
Para solucionar esse problema os roteadores podem ser configurados como agente relay, ou
seja, um agente que irá encaminhar requisições DHCP pela rede, porém não em broadcast, mas
em unicast diretamente para o endereço IP do servidor DHCP remoto com o comando “ip
helper-address”.
Veja abaixo a configuração necessária para o roteador R3 conforme topologia anterior. A

configuração é a mesma para roteadores e switches multicamada, com a diferença que no
switch o comando seria aplicado dentro da interface SVI de cada VLAN.
R1(config)#interface FastEthernet0
R1(config-if)#ip address 10.150.49.1 255.255.255.0
R1(config-if)#ip helper-address 10.150.40.1
R1(config-if)#^Z
R1#
Com essa configuração, quando o roteador R1 receber o DHCPDISCOVER de um cliente DHCP

que esteja conectado à sua rede LAN ele enviará a mensagem para o servidor 10.150.40.1 e
ficará como intermediário na troca de informações entre o cliente e o servidor até que a
negociação seja finalizada.
Portanto, sem o comando “ip helper-address” ou sem o serviço de DHCP configurado, quando
um roteador ou switch multicamadas recebe uma mensagem de DHCP Discover em broadcast
ele “dropa” ou deleta essa mensagem, pois ele não pode encaminhar mensagens de broadcast
de camada 3 (255.255.255.255).
Por padrão esse comando encaminha tráfego UDP das portas 69 (TFTP), 67 (BOOTP/DHCP
Client), 68 (BOOTP/DHCP Server), 37 (Time Protocol), 49 (TACACS), 53 (DNS), 137 (NetBios)
e 138 (NetBios Datagram). Para limitar as portas UDP encaminhadas utilize o comando "no ip
forward-protocol udp num-porta" em modo de configuração global, por exemplo, para

desativar o reenvio para o servidor remoto do DNS o comando seria "no ip forward-protocol
udp 53".
Por exemplo, para que SW1 envie como Relay apenas as requisições DHCP a configuração deve
ser a seguinte:
SW1(config)#no ip forward-protocol udp 37

SW1(config)#int f0/0
SW1(config-if)#ip helper-address 10.150.40.1
SW1(config)#
5 Configurando DHCP para IPv6 - DHCPv6

Apesar desse conteúdo ter sido explorado em nosso material do CCNP ROUTE 300-101 você
também pode encontrar suporte ao DHCPv6 nos switches Multilayer da Cisco, por isso vamos
também explorar o assunto mostrando quatro recursos que você pode utilizar para fornecer
IPv6 aos clientes utilizando switches MLS:
 SLAAC: a famosa auto-configuração stateless.
 DHCPv6 Statefull básico: similar ao DHCP para IPv4.
 DHCPv6 Lite: uso do SLAAC para alocação de IPs automaticamente pelos Hosts e o
DHCPv6 para atribuição dos demais parâmetros como DNS e domínio.
 DHCPv6 Relay: configuração para encaminhamento de requisições DHCPv6 dos clientes
para servidores remotos.
Os conceitos do IPv6 são alvo de estudo do CCNA R&S, mais especificamente no CCENT os
conceitos básicos de funcionamento são estudados e no ICND-2 o foco é resolução de
problemas com IPv6.
Lembre-se que é necessário ativar o IPv6 nos roteadores Cisco com o comando "ipv6 unicast-
routing" em modo de configuração global antes de aplicar os demais comandos de
configuração.
No IPv4 a alocação de IPs é feita de maneira estática ou dinâmica com uso do DHCP. Existe
uma opção de autoconfiguração chamada pela Microsoft de Automatic Private IP Addressing
(APIPA) ou auto-IP que usa a rede de uso privativo 169.254.0.0/16 (RFC 3330), porém
esses endereços são utilizados somente quando o servidor DHCP falha e o host não consegue
seu "IP real" da rede local.
Já um host configurado com IPv6, em maioria dos sistemas operacionais, inicia sua
configuração automaticamente atribuindo um endereço de "link local" utilizando o prefixo
FE80::/64 e o host-ID (porção de host do endereço IPv6) utilizando o EUI-64. Esse endereço
(como nome já diz) é usado apenas localmente, na própria LAN ou VLAN onde o host está
conectado, portanto ele ainda não pode falar com outras LANs, VLANs ou com a Internet, pois
para isso ele precisa de um endereço de "Unicast Global".
Se compararmos com o IPv4 o endereço de Unicast Global seria aquele aprendido via DHCP ou
configurado manualmente na placa de rede, com a diferença que no IPv6 não existe mais o
conceito de IP Privativo até o momento que esse material foi escrito.
Para alocação do IPv6 em um host ou interface do roteador temos mais opções. A alocação do
endereço IPv6 pode ser feita de maneira manual ou dinâmica através do SLAAC, DHCPv6
Stateful, DHCPv6 Lite (SLAAC+DHCPv6 Stateless), SLAAC com Recursive DNS Server (RDNSS)

e DNS Search List (DNSSL) mais utilizado com sistemas Unix/Linux e SLAAC com configuração
do servidor DNS manual.
Na prática o administrador de redes precisará escolher um método, aquele que melhor se

adéqua a sua rede e hosts de rede, ativar em um roteador, switch L3 ou servidor DHCP e
configurar seus hosts para que eles não aceitem outros tipos de alocação de endereço ou
utilizar filtros nos switches para evitar confusões, isso porque maioria dos hosts aceitam
configuração via SLAAC, DHCPv6 Lite e DHCPv6 Stateful, mas esse assunto está além do
cobrado no CCNP R&S.
Você pode utilizar duas opções: DHCPv6 Stateful ou só DHCPv6 e o DHCPv6 Lite que ambas
funcionam muito bem. Vamos ver as configurações a seguir.
5.1 Stateless Address Autoconfiguration - SLAAC
O SLAAC ou autoconfiguração de endereços IPv6 nos roteadores e switches L3 precisam

primeiro do protocolo IPv6 ativado em modo de configuração global com o comando "ipv6
unicast-routing" e por padrão assim que você configura um IPv6 na interface com o comando
"ipv6 address" a interface inicia o envio de RA's (router advertisement) ou a responder pedidos
de RS's (router solicitation) vindos dos hosts com seu prefixo e algumas informações adicionais.
Nesse anúncio chamado RA o roteador ou switch L3 passa um prefixo de 64 bits para que o
cliente utilize o EUI-64 e gere seu interface ID. Se você não lembra do EUI-64 ele gera um
host-ID ou Interface-ID de 64 bits utilizando o endereço MAC da placa de rede do host ou
interface do dispositivo (48 bits) inserindo a string FFFE (16 bits+48 bits=64 bits) bem na
metade do endereço MAC (após o 24º bit - entre o OUI e o serial do MAC). Além disso, o sétimo
bit do primeiro octeto é invertido (sétimo bit do OUI).
Portanto, com as informações recebidas na mensagem de RA o host conseguiu montar seu

próprio endereço global único de IPv6, já sabe o endereço do default gateway e o MTU desse
link. Esse processo todo é também chamado de "stateless autoconfiguration or serverless client
configuration", serverless porque não utiliza servidor e nem depende do DHCP.
Veja o exemplo abaixo onde o switch L3 vai passar na VLAN 10 (switch virtual interface - SVI) o
prefixo 2001:cc:baba::/64, pois sua SVI vai ser configurada com o endereço IPv6 estático
2001:cc:baba::1/64.
Switch(config)#ipv6 unicast-routing
Switch(config-if)#ipv6 address 2001:cc:baba::1/64
Para descontrair: percebeu o "trocadilho" no prefixo? "cc:baba"... Pode rir, não faz mal um
pouco de diversão quando estudar IPv6, você pode usar sua criatividade ao criar seus prefixos
com os algarismos em Hexa!
A partir desse momento os hosts conectados na VLAN 10 utilizarão endereços iniciando com o
prefixo 2001:cc:baba::/64, interface-ID via EUI-64, gateway 2001:cc:baba::1/64 e MTU 1500
que é o padrão utilizado pelas SVIs.
Ante de passar para a próxima página pense um pouco sobre o seguinte:

 "O que está faltando para que os hosts da VLAN 5 naveguem com sucesso tanto na
Intranet como na Internet?"
 "Só com esses dados passados pelo SLAAC os hosts conseguirão comunicação completa
fora da VLAN 10?"

5.2 DHCPv6 Lite
Se você pensou sobre as perguntas da página anterior e chegou a conclusão que o SLAAC não é
tão eficiente assim parabéns! Pois somente com ele os hosts não aprenderão o endereço do seu
servidor de resolução de nomes ou DNS, vital para que eles possam navegar tanto na Internet
como na Intranet, pois com endereços de 128 bits vai ser complicado decorar o IPv6 dos
servidores como fazíamos para o IPv4!
O DHCPv6 Lite ajuda a resolver esse problema, principalmente se a sua rede possuir hosts que
não suportam o DHCPv6 Stateful, pois ele usa o SLAAC para alocação dos parâmetros que
estudamos anteriormente e passa via DHCPv6 as demais informações que o SLAAC não
suporta, por exemplo, o endereço IPv6 do servidor DNS.
Os passos para ativação do DHCPv6 Lite são:

1. Ativar o roteamento IPv6 (caso necessário);
2. Configurar o pool DHCPv6 stateless com as opções adicionais a serem passadas para os
hosts;
3. Configurar os parâmetros a serem passados (DNS, domínio, etc.) dentro do pool;
4. Configurar o endereço de Unicast Global na interface roteada ou SVI do switch L3;
5. Ativar o flag que informa aos clientes que existem mais informações a serem aprendidas via
DHCPv6 Stateless na interface configurada anteriormente;
6. Vincular o pool criado no passo 2 dentro da interface.
Veja exemplo de configuração abaixo, onde vamos configurar o pool DHCPv6 chamado "hosts-
v6-vlan10" e passar o endereço do servidor DNS 2001:cc:baba::5 aos hosts. Também estamos
passando o nome do domínio como dltec.com.br aos clientes.
Switch(config)#ipv6 dhcp pool hosts-v6-vlan10
Switch(config-dhcpv6)#dns-server 2001:cc:baba::5
Switch(config-dhcpv6)#domain-name dltec.com.br
Switch(config-dhcpv6)#exit
Switch(config-if)#ipv6 nd other-config-flag
Switch(config-if)#ipv6 dhcp server hosts-v6-vlan10
Note que não utilizamos comando para definir prefixos ou endereços no pool DHCPv6, pois
quem fará isso será o SLAAC. Outro ponto importante é que tanto no SLAAC puro como agora
com DHCPv6 stateles o roteador ou switch L3 não saberão a lista de hosts alocados como o
DHCP para IPv4 mostra com o comando "show ip dhcp binding", pois ambos os recursos são
sem estado (stateless) e não registram informações dos hosts solicitantes, afinal o próprio host
que configura seu host-ID.
Você pode utilizar o comando "show ipv6 dhcp pool" para verificar as configurações.
Se há necessidade de guardar o estado da alocação e registrar os hosts com seus endereços

será preciso o DHCPv6 Stateful, o qual vamos estudar a seguir.

5.3 DHCPv6 Statefull
O DHCPv6 ou DHCPv6 Stateful funciona de forma parecida com o DHCP que estudamos para o
IPv4, alocando endereços e mantendo uma base de dados local ou até mesmo remota com a
relação dos hosts que solicitaram endereços ao servidor, por isso o termo "stateful" ou "com
estado".
A configuração é praticamente a mesma que realizamos para o DHCPv6 Lite, com a diferença
que agora vamos definir o prefixo que o servidor DHCPv6 vai passar para os clientes com o
sub-comando "address prefix" no pool. Além disso, não é preciso setar o flag que informa os
hosts a procurar o servidor DHCPv6 por mais informações, pois agora o servidor DHCPv6
stateful vai responder às requisições dos clientes.
Veja exemplo de configuração abaixo, onde vamos configurar o pool DHCPv6 chamado "hosts-
v6-vlan10" e utilizar o prefixo 2001:cc:baba::/64 para gerar os endereços IPv6, utilizar o
endereço do servidor DNS 2001:cc:baba::5 e nome do domínio dltec.com.br.
Switch(config)#ipv6 dhcp pool hosts-v6-vlan10
Switch(config-dhcpv6)#address prefix 2001:cc:baba::/64
Switch(config-dhcpv6)#dns-server 2001:cc:baba::5
Switch(config-dhcpv6)#domain-name dltec.com.br
Switch(config-dhcpv6)#exit
Switch(config-if)#ipv6 dhcp server hosts-v6-vlan10
Você pode utilizar os comandos "show ipv6 dhcp pool" e "show ipv6 dhcp binding" para
verificar as configurações e monitorar as alocações.
Switch#sho ipv6 dhcp pool

DHCPv6 pool: hosts-v6-vlan10
Address allocation prefix: 2001:CC:BABA::/64 valid 300 preferred 250 (1 in use,
0 conflicts)
DNS server: 2001:CC:BABA::5
Domain name: dltec.com.br
Active clients: 1
Switch#sho ipv6 dhcp binding

Client: FE80::CA9C:1DFF:FE01:9560
DUID: 00030001C89C1D019560
Username : unassigned
IA NA: IA ID 0x00030001, T1 125, T2 200
Address: 2001:CC:BABA:0:51CE:51:E3CE:4FA2
preferred lifetime 250, valid lifetime 300
expires at Jun 10 2015 05:10 PM (178 seconds)
Com o comando "clear ipv6 dhcp binding { * | ipv6-address }" é possível limpar todas as
alocações realizadas (*) ou de apenas um endereço específico (digitando o ipv6-address).
Note que diferente da configuração do protocolo DHCP para IPv4 o DHCPv6 não permite
exclusão de endereços do pool nem configuração de hosts manuais.

5.4 DHCPv6 Relay
No caso do uso de um servidor DHCPv6 centralizado que não esteja na LAN ou VLAN dos hosts
podemos utilizar o switch L3 como um agente Relay, ou seja, o switch irá encaminhar as
solicitações de DHCPv6 recebidas em sua SVI para um servidor DHCPv6 remoto.
Para isso utilize o comando "Switch(config-if)#ipv6 dhcp relay destination ipv6-global-

do-servidor-DNS" em modo de configuração de interface (dentro da interface roteada ou SVI
do switch).
Por exemplo, para configurar a VLAN 10 para encaminhar as solicitações DHCPv6 dos clientes
para o servidor remoto "2001:cce:b0b0::10" utilizamos o comando abaixo:
Switch(config-if)#ipv6 dhcp relay destination 2001:cce:b0b0::10
 Conceito de MLS.
 Funcionamento e operação dos Switches Multicamada.
 Tipos de interfaces de switches Multicamada.
 Configurar os diferentes tipos de interfaces MLS.
 Roteamento entre VLANs com switches Multicamada utilizando SVIs.
 Entender e configurar o CEF.
 Ativar o servidor DHCP e DHCPv6 em switches Multilayer.
 Ativar o DHCP e DHCPv6 Relay.

Capítulo 06 - Recursos de
Alta Disponibilidade
estudar conceitos e recursos Objetivos do Capítulo
para tornar uma rede Ao final desse capítulo você terá estudado e
altamente disponível. deverá compreender:
 Conceitos de alta disponibilidade.
Alta disponibilidade  Entender os modelos de switches
depende de vários fatores, modulares da família Catalyst 4500 e
desde processos, pessoas, 6500.
desenho da topologia até  Entender a função dos módulos
tecnologias aplicadas aos supervisores.
equipamentos.  Entender os recursos de alta
disponibilidade das placas
supervisoras.
 Configurar o RPR, RPR+ e SSO.
Aproveite o capítulo e bons  Entender e configurar o NFS com
estudos! SSO.
 Ferramentas de gerenciamento para
alta disponibilidade: Syslog, SNMP e
IP SLA.
1 Conceito de Alta Disponibilidade ...... 150

1.1 Redundância ................................... 150
1.2 Tecnologia ....................................... 151
1.3 Pessoas ........................................... 151
1.4 Processos ........................................ 152
1.5 Ferramentas .................................... 152
1.6 Resiliência e Alta Disponibilidade ..... 152
2 Switches Modulares e Placas
Supervisoras ........................................... 153
3 Redundância de Supervisora e Route
Processor................................................ 155
3.1 Modos de Redundância ................... 156
3.2 Configurações .................................. 157
3.3 Nonstop Forwarding - NSF ............... 157
6 Outros Recursos de Redundância ...... 158
6.1 StackWise e StackWise Plus ............. 158
6.1.1 Comandos Básicos do StackWise ......160
6.2 VSS - Virtual Switching System ......... 161

4 Ferramentas de Gerenciamento ........ 162

4.1 Syslog .............................................. 162
4.1.1 Verificando e Configurando Time-
stamps nas Mensagens de Log ......................... 163
4.2 SNMP .............................................. 164
4.2.1 Configurações do SNMP v1 e v2c ...... 166
4.2.2 Configurações do SNMP v3 ............... 166
4.3 IP SLA .............................................. 167
4.3.1 Configurando e Verificando o IP SLA
Básico 167
5 Resumo do Capítulo .......................... 169

1 Conceito de Alta Disponibilidade

Em termos gerais alta disponibilidade (em inglês - High Availability) é uma meta de todo
administrador de redes ou engenheiro de redes, significa ter os serviços de rede disponíveis
para os clientes quando eles necessitam utilizar.
Normalmente a disponibilidade de um serviço é medida em porcentagem, por exemplo, 99,99%

de disponibilidade significam que sua rede em um ano de 365 dias terá menos de uma hora de
indisponibilidade no horário de funcionamento da empresa, para ser mais exato serão apenas
52,56 minutos de indisponibilidade no ano. Essa é a disponibilidade que uma rede em três
camadas pode chegar se bem estruturada e configurada corretamente.
Temos cinco componentes principais para conseguir atingir a alta disponibilidade:

 Redundância.
 Tecnologia.
 Pessoas.
 Processos.
 Ferramentas.
As duas primeiras podem ser obtidas através do projeto/design de rede bem estruturado. Já as
três últimas são mais difíceis de implementar e controlar, porém existem diversas metodologias
como ITIL que facilitam a gestão da infraestrutura de TI como um todo.
O mais importante é que o conceito de disponibilidade deve estar alinhado com os objetivos do
negócio da empresa, pois atualmente os serviços de TI, como o próprio serviço de interconexão
de rede aos usuários finais e sistemas corporativos, devem estar sempre em sincronia com as
necessidades e objetivos do negócio da empresa.
Vamos estudar na sequência alguns conceitos de disponibilidade citados aqui.
1.1 Redundância
Redundância ou Redundancy tenta identificar e eliminar “Single Points of Failure” (SPOF)

através do uso de caminhos/links backup, fontes de alimentação alternativas, dispositivos ou
módulos duplicados nos dispositivos de rede, servidores redundantes, etc.
É claro que esse tipo de design envolve um custo financeiro mais elevado, porém deve ser
avaliado o retorno e os benefícios para o negócio e não somente o valor financeiro de tal
solução. Por isso um ponto importante é “onde devemos adicionar redundância”? Normalmente
onde há mais impacto sobre a disponibilidade, por exemplo, na distribuição e core da rede, no
data Center, servidores que possuem módulos de e-commerce ou o ERP da empresa, conexões
críticas da WAN ou Internet, etc.
Em termos de switches Cisco da linha Catalyst temos algumas opções de redundância:

 Energia Elétrica:
o Fontes redundantes em equipamentos como das linhas modulares Catalyst 6500
e 4500.
o Em switches não modulares como as linhas Catalyst 2950, 2960, 3350, 3560,
3760 temos a opção de uso das RPSs ou Redundant Power System.
o Nos switches mais novos como os da linha Catalyst 2960-X, 2960-S, 3750-E e
3560-E podemos utilizar a Cisco RPS modelo 2300.
 Links redundantes utilizando mais de uma porta para conectar acesso à distribuição e
depois distribuição ao acesso. Nesse processo o STP e links etherchannel podem ajudar
com a tecnologia.

 Em switches modulares como os da linha 6500 e 4500 é possível a utilização de placas

superviras redundantes.
 Equipamentos redundantes, ou seja, colocar dois chassis na distribuição para que se um
switch inteiro fique indisponível o outro assuma a rede de acesso, assim como a conexão
com o Core como um todo. O mesmo pode ser feito no Core como propõe o modelo de
projeto em três camadas.
Ao longo desse capítulo e do próximo vamos estudar vários recursos e tecnologias que auxiliam
a redundância.
1.2 Tecnologia
A Cisco oferece diversos recursos e tecnologias em routers e switches Layer 3 para melhorar a
disponibilidade através de continuidade no roteamento, detecção e recuperação rápida de
falhas e aceleração no processo de roteamento. Abaixo segue uma lista, dos quais alguns são
focos do exame atual e serão estudados na sequência:
 Cisco Nonstop Forwarding (NSF)

 Stateful Switchover (SSO)
 Tecnologia Stackwise para cascateamento de Switches
 Virtual Switch System (VSS)
 Ferramentas de monitoração como SNMP, Syslog e Netflow
 IP Service Level Agreement (SLA)
Outras tecnologias que podem melhorar a disponibilidade envolvem balanceamento de cargas

de servidores, firewall stateful failover e fast routing convergence (convergência rápida do
processo de roteamento).
1.3 Pessoas
Normalmente nem todas as pessoas envolvidas no processo de garantia da disponibilidade

estão vinculadas ou são responsabilidade do administrador ou engenheiro de redes, mas
mesmo assim são parte fundamental da equação como um todo. Vamos a alguns fatores da
disponibilidade que envolve pessoas:
 A equipe deve desenvolver hábitos para garantir a disponibilidade da rede, tais como
prestar atenção nos detalhes e ter uma metodologia para facilitar o troubleshooting em
caso de paradas.
 A equipe deve estar treinada e ter os conhecimentos necessários para cuidar dos
equipamentos e tecnologias aplicados na rede.
 Manter a boa comunicação e interação entre os diversos times de TI, tais como redes,
segurança, servidores e aplicações e todos devem trabalhar para garantir o desempenho
do negócio, evitando competições e “jogos de empurra” (o problema não é meu).
 A documentação deve ser precisa e atualizada.
 Prever tempo suficiente para realizar uma atividade, lembrando que um bom
planejamento e design sempre são muito melhores que “adequações” ou “soluções
temporárias”.
 Definir responsabilidades e garantir que cada pessoa de cada time de TI saiba
exatamente o que fazer e quem procurar em casos de emergências.
Claro que esse tópico fala em maneiras gerais, pois cada empresa aplica uma metodologia
própria ou então utilizando melhores práticas de mercado, por exemplo, através do ITIL, para
gerenciar processos e pessoas.

1.4 Processos
Existem várias atividades, necessidades, funções e requisitos para a administração de uma

rede, por isso simplesmente “sair fazendo” nem sempre é uma boa opção, é necessário mapear
os processos e implementar metodologias para manter, executar, avaliar e melhorar esses
processos.
A Cisco tem o PPDIO ou outras metodologias como o ITIL definem os processos para gerenciar
o ciclo de vida de serviços de TI, por isso o importante aqui é ter em mente que não importa o
tamanho da empresa que você trabalhe existem processos e recursos voltados para TI e
administração de redes que podem ajudar muito nesse mapeamento e gerenciamento de
processos.
Alguns pontos que a administração de redes inclui são:
 Auditorias de capacidade ou Capacity para verificar se os recursos estão realmente

dimensionados para atender os requisitos dos clientes e negócio.
 Gerenciamento da versão de IOS, pois várias ameaças e problemas são detectadas e
muitas vezes corrigidas apenas com um Upgrade de IOS.
 Padrões de projeto corporativo ou “Design Compliance” visando manter uma linha de
projeto padronizada, a qual vai manter sua rede organizada e eficiente. Imagine se cada
um decide fazer as coisas do seu jeito?
 Planos de “Disaster Recovery” e “Business Continuity”.
 Processo de gerenciamento mudança (Change Management).
 Processo de tratamento de incidentes e problemas.
Esses são apenas alguns processos fundamentais e existem muitos outros que podem ser
inseridos conforme a complexidade de cada rede, negócio ou corporação.
1.5 Ferramentas
Após desenhar e implementar uma rede altamente disponível é necessário monitorá-la para
garantir que os recursos e tecnologias utilizadas estão sendo eficientes, além disso se temos,
por exemplo, dois caminhos redundantes em fibra entre dois switches e um deles tem
problemas o outro assume, mas e se o outro falhar? Teremos vários usuários sem acesso a
rede, por isso temos que monitorar e arrumar os problemas que vão acontecendo para manter
a estrutura planejada.
Existem ferramentas no próprio Cisco IOS como Syslog e SNMP que ajudam a monitoração
através de aplicações externas, tais como HP Openview, Zabbix, Whatsup Gold e outros
softwares de gerenciamento de mercado.
1.6 Resiliência e Alta Disponibilidade
Você encontra em diversas bibliografias que redes de alta disponibilidade devem ser redes
resilientes (Resilient Network). Isso significa que vários métodos devem ser aplicados ao design
para permitir que ela se recupere de uma falha e continue a operar normalmente ou pelo
menos atingindo um mínimo definido pelo negócio.
A resiliência envolve principalmente os seguintes componentes no caso de ambientes de rede:
 Resiliência na Camada de Rede: Links, tecnologias como o FHRP (próximo capítulo) e

dispositivos para garantir a alta disponibilidade e resiliência.

 Resiliência no Sistema: Redundância de hardware, por exemplo, fontes de

alimentação redundantes e spare parts (peças de reposição), incluindo recursos de
hardware para ativar o “fast failover” (recuperação de falhas).
 Gerenciamento de Rede e Monitoração: É preciso ser capaz de detectar e atuar

sobre um incidente, por isso é necessário monitorar e gerenciar ativamente a rede.
No restante desse capítulo vamos tratar da redundância de placas supervisoras.
2 Switches Modulares e Placas Supervisoras

Já citamos anteriormente que os switches podem ser modulares ou não.
Os switches não modulares são os que normalmente trabalhamos no dia a dia, eles tem a placa
mãe, portas, switch fabric, processador, memória e todos demais componentes em um único
chassi. As linhas atuais, em julho de 2014 quando escrevemos esse material incluem os
switches das linhas Catalyst 2960-X, 2960-S, 3750-E e 3560-E.
Os switches modulares possuem um chassi ou caixa e vários módulos, não possuem portas
fixas como nos não modulares. Você precisa popular esse chassi basicamente com cinco tipos
de módulos:
 Placa supervisora ou Supervisory.
 Placas de tributário ou Line Cards (saídas via UTP, fibra e demais conexões).
 Módulos de serviço ou Service Modules.
 Fonte de alimentação (dependendo do chassi pode ser uma ou duas para redundância).
 Sistema de ventilação ou Fan Trail.
A placa supervisora é o “cérebro” dos switches modulares, ela guarda e inicializa o software
Cisco IOS, são responsáveis pelo control plane e muitas vezes pelo forward plane (controle e
encaminhamento) dos switches.
No switch 6500, por exemplo, a Supervisor Engine (outro sinônimo para supervisora) é
composta pelo Multilayer Switch Feature Card (MSFC) e pela Policy Feature Card (PFC).
A MSFC é responsável pelos processos de software como protocolos de roteamento. Já a PFC
toma as decisões de encaminhamento em hardware. Além disso, as supervisoras controlam
todo hardware e se comunicam com as demais placas do chassi.

Switches como os da linha Catalyst 6500 e 4500 possuem algumas opções de chassis com
diferentes capacidades de módulos. Por exemplo, a família 6500 tem os modelos de chassi com
3, 4, 6, 9 e 13 chamados Catalyst modelo 6503, 6504, 6506, 6509 e 6513 respectivamente.
Já a família 4500-E (nome atual da família 4500) possui opções de chassi com 3 slots (4503-E),
6-slots (4506-E), 7-slots (4507R+E) e 10-slots (4510R+E). Como facilidade de resiliência a
família Cisco Catalyst 4500E inclui redundância 1 + 1 de supervisor engine (apenas nas opções
de 10-slots e 7-slots), fans redundantes, recursos de tolerância a falhas via software e
redundância 1 + 1 de power supply (fonte de alimentação).
Veja abaixo a foto da família 6500.
Veja abaixo uma foto com a família 4500E.
Portanto, dependendo do chassi escolhido, tanto switches 6500 como 4500 aceitam dois
módulos supervisores em um único chassi. Por padrão um módulo inicializa e o outro fica em
espera para assumir a operação caso o principal falhe.
Mas o que isso tudo tem haver com resiliência e redundância? A resposta é simples: tempo de
convergência. Em redes de médio e grande porte, as quais utilizam esses modelos de
equipamento precisam de tempos de retorno à operação baixos e a Cisco disponibiliza recursos
para redundância de supervisoras chamados RPR, RPR+ e SSO que vamos estudar na
sequência.

3 Redundância de Supervisora e Route Processor

Redundâncias como as de link, FHRP, rotas balanceadas em protocolos de roteamento fornecem
alternativas para problemas nas camadas entre 1 e 3, porém o que acontece quando uma placa
supervisora de um switch falha? Você pode pensar: “Fácil, a placa redundante assume!”, porém
não é tão simples assim.
Por padrão quando temos duas placas supervisoras uma delas é inicializada por completo e
assume todas as funções do switch, porém a segunda não inicializa completamente e vai só até
certo passo da inicialização. Somente quando o módulo ativo falha que o que está de reserva
(stanby) finaliza a inicialização e assume o papel da placa principal.
As placas supervisoras podem ser configuradas de várias formas quando em conjunto para
formar redundância. Cada modo representa até que ponto da inicialização a placa reserva vai
realizar, portanto quanto tempo vai levar para ela assumir o controle quando a placa principal
falhar. Quanto mais longe no processo de inicialização a placa standby for mais rápida será a
sua inicialização e failover. O processo de falha da principal e a reserva assumir é chamado de
“failover”.

3.1 Modos de Redundância
No conteúdo do CCNP SWITCH temos que entender como funcionam três tipos de redundância
de supervisoras:
 Route processor redundancy (RPR): A placa supervisor redundante é parcialmente

ligada (em inglês o termo utilizado é “booted”) e inicializada. Se o modulo ativo falhar, o
módulo standby precisa reinicializar todos os outros módulos do switch para depois
inicializar as funções como nova placa supervisor ativa. Um tempo ótimo de switchover
para a standby assumir tudo é de aproximadamente 2 minutos.
 Route processor redundancy plus (RPR+): A supervisora redundante é inicializada

(booted) permitindo que tanto a supervisor como o route engine inicializem, porém as
funções de Layer 2 ou Layer 3 não são inicializadas. Se o modulo ativo falha o standby
finalize a inicialização sem reinicializar os demais módulos do switch. Com isso as portas
do switch conseguem manter o estado inicial e o tempo de switchover cai para
aproximadamente 30 segundos.
 Stateful switchover (SSO): Vamos começar dessa vez com o tempo de switchover no
SSO: aproximadamente “1 segundo”. Mas como isso é possível? No SSO a placa
redundante é totalmente inicializada e os conteúdos das memórias startup e running
configuration são sincronizados entre os módulos supervisores. Além disso, as
informações de camada 2 são mantidas em ambas as supervisoras, permitindo que o
switching realizado em hardware continue normalmente durante o processo de failover.
O estado das interfaces também é mantido nas duas supervisoras para que os links não
caiam e subam (flap) durante o processo de failover. Veja figura a seguir.
Algumas vezes você pode encontrar também os termos Single-Router Mode (SRM) e Dual-
Router Mode (DRM) junto com os modos de redundância.
SRM significa que a supervisora tem dois route processors integrados, porém só um ativo. Já no
DRM dois route processors estão ativos o tempo todo. Normalmente o HSRP (vamos estudar no
próximo capítulo) é utilizado para prover a redundância com DRM.
O SRM é utilizado com o SSO, o qual inicializa o route processor, por isso você pode encontrar
os dois termos juntos: “SRM com SSO”, porém é a mesma funcionalidade. O SRM não é
compatível com o RPR ou RPR+.

É importante saber que nem todos os modos são suportados por todos os modelos de
supervisora, é preciso consultar o datasheet (especificações técnicas) de cada módulo para
saber qual tipo é possível configurar.
3.2 Configurações
Para configurar é preciso entrar em modo de redundância:
Router(config)#redundancy
Selecionar o modo de operação com o comando:
Router(config-red)#mode {rpr | rpr-plus | sso}
O RPR funciona mesmo as supervisoras estando com versões de IOS diferentes, já o RPR+
ambas as placas precisam estar com o mesmo release de software Cisco IOS, senão o switch
utiliza o RPR e não sobe o RPR+.
Na primeira vez é preciso entrar com os comandos em ambas as supervisoras, após executado
os comandos acima as alterações são feitas apenas na supervisora ativa, a qual faz a
sincronização com a standby.
Por padrão apenas a startup config e os registros de configuração são sincronizados, para
alterar o padrão utilize os comandos abaixo:
Router(config-red)#main-cpu
Router(config-r-mc)#auto-sync {startup-config | config-register | bootvar}
Para voltar à configuração original utilize o comando “auto-sync standard” em modo de

configuração de redundância. Para verificar o estado utilize o comando “show redundancy
states” em modo privilegiado.
Abaixo segue um exemplo de ativação do SSO.
Router> enable
Router#configure terminal
Router(config)#mode sso
Router(config-red)#end
Router#copy running-config startup-config
Router#
3.3 Nonstop Forwarding - NSF
O SSO estudado anteriormente é um modo de redundância que garante que até a camada-2
(FIB) tudo estará funcionando quando ocorrer um switchover, porém a camada de rede com os
protocolos de roteamento e seu processo de convergência não foram inicializados.
O NSF é um protocolo proprietário da Cisco que tem a função de remontar a RIB (Routing
Information Base) rapidamente após um switchover. Mas como isso é feito? Através de vizinhos
que também tem o NSF ativos capazes de fornecer informações ao módulo standby, com isso
as tabelas de roteamento são montadas rapidamente.
Esse recurso é suportado pelos protocolos de roteamento BGP, OSPF, EIGRP e IS-IS, porém é
preciso verificar se o módulo do 6500 ou 4500 suporta esse recurso. Normalmente no 6500 ele

é suportado na SUP 720 com MSFC3 e no 4500 antigo com as supervisors III, VI e V (IOS
12.2(20)EWA ou superior). Os novos modelos de 4500E também suportam esses recursos.
Os comandos de configuração seguem abaixo.
BGP
Router(config)#router bgp as-number

Router(config-router)#bgp graceful-restart
EIGRP
Router(config)#router eigrp as-number

Router(config-router)#nsf
OSPF
Router(config)#router ospf process-id

Router(config-router)#nsf
IS-IS
Router(config)#router isis [tag]

Router(config-router)#nsf [cisco | ietf]
Router(config-router)#nsf interval [minutes]
Router(config-router)#nsf t3 {manual [seconds] | adjacency}
Router(config-router)#nsf interface wait seconds
6 Outros Recursos de Redundância

Já estudamos recursos de redundância onde uma placa supervisora pode assumir em caso de
falha as operações que estavam sendo executadas pela principal, porém até o momento cada
switch funciona de forma isolada uns dos outros, de forma "stand alone".
Nesse tópico vamos estudar como podemos transformar múltiplos switches para atuar como um
único switch local, facilitando o gerenciamento, configuração e troubleshooting, além disso,
proporcionando economia de cabos evitando o cascateamento entre switches que fazem parte
da mesma infraestrutura de acesso através da configuração de pilhas ou "stacks".
Vamos estudar o StackWise, VSS e vPC, sendo que o último é um bônus, pois não faz parte do
conteúdo do exame 300-115, mas vale a pena saber o funcionamento básico.
6.1 StackWise e StackWise Plus
Normalmente os switches de acesso são independentes e se você necessita diversos switches

em um mesmo ambiente é preciso conectar links entre eles, por exemplo, trunks via
Etherchannel com duas portas entre cada switch. Porém essa conexão em cascata ocupa cabos
que poderiam ser utilizados para uplink e até conectar mais hosts.
Para resolver esse tipo de situação a Cisco disponibiliza as tecnologias StackWise e StackWise
Plus, permitindo que vários switches sejam "empilhados" e atuem como um só dispositivo. A
feature de StackWise está disponível nos switches modelos Catalyst 3750-E, 3750-X e 3850.
Na prática, os switches empilháveis possuem entradas especiais para conexão dos cabos de
empilhamento (stacking cables), os quais são conectados formando um loop (daisy-chain), por
exemplo, para conectar 4 switches começamos conectando a porta de stack 2 do primeiro
switch com porta de stack 1 do segundo, depois porta 2 do segundo com porta 1 do terceiro, na

sequência porta 2 do terceiro com a porta 1 do quarto e fechando o loop porta 2 do quarto com
a porta 1 do primeiro. Veja foto a seguir com o esquema de conexão.
Obs.: Os cabos de stacking não acompanham o chassis do switch!
Quando conectados corretamente, os cabos formam um anel que possibilita que os switches
trabalhem com uma taxa de 32Gbps full-duplex, porém se uma das conexões (cabos de
stacking) for rompida a largura de é reduzida em 50% fazendo com que a pilha passe a operar
com 16Gbps.
Principais vantagens do StackWise:

 Possibilidade de empilhar até 9 switches em um mesmo stack, por exemplo, com
switches de 48 portas temos 432 portas em uma só pilha lógica de switches.
 Você pode abrir o loop para inserir ou retirar switches sem que os demais parem de
funcionar, tanto para manutenções como changes na topologia.
 Não é preciso fazer nenhuma configuração para inserção de um novo switch na pilha.
 A pilha vai funcionar como um único dispositivos, tendo apenas um IP de gerenciamento
único para todos os switches da pilha e sendo configurada a partir do switch definido
como "mestre".
 Portas de diferentes switches configurados em uma pilha podem ter suas interfaces
configuradas em um link multichassis EtherChannels (MECs).
 Quando os switches precisam enviar quadros entre si eles utilizam o cabo de stacking,
ou seja, ao invés de trocar quadros entre portas da maneira convencional é como se os
cabos de stacking fossem uma extensão do backplane dos switches.
 Elimina o problema de escalabilidade do diâmetro do protocolo Spanning Tree.

6.1.1 Comandos Básicos do StackWise

A "primeira coisa" que devemos saber é: Quem é o mestre? Pois é nele que vamos fazer todas
as configurações. O usuário pode configurar um valor de prioridade para cada switch para
definir qual deles irá assumir o papel de mestre. Caso não exista essa configuração o critério
para seleção do mestre será:
1. O switch que tiver o IOS com suporte a recursos mais avançados.
2. O switch que estiver há mais tempo em operação (uptime).
3. O switch que tiver o menor MAC.
Portanto, de acordo com os critérios acima geralmente o primeiro switch a ser energizado será
o mestre. Para visualizar quem é o mestre na pilha utilize o comando "show switch",
conforme saída a seguir.
SW-Mestre#show switch
Current
Switch#Role Mac Address Priority State
--------------------------------------------------------
1 Master 0016.9d50.ac11 5 Ready
2 Slave 0016.4746.bc12 1 Ready
É importante selecionar a prioridade de todos os switches manualmente para ter mais controle
do ambiente de produção, por isso defina o mestre com a maior prioridade e o menor SwitchID.
Abaixo segue exemplo para configurar o Switch1 (SW-Mestre) com prioridade 5 e o Switch2
com prioridade 4. Se existirem mais switches na pilha faça a configuração conforme
necessidade, lembrando que se o mestre ficar indisponível a segunda maior prioridade assumirá
a pilha.
SW-Mestre(config)#switch 1 priority 5
SW-Mestre(config)#switch 2 priority 4
Uma informação importante que pode ajudar no dia a dia é que o SwitchID é um número que
identifica a unidade do empilhamento e referencia as portas físicas de um determinado switch.
Por exemplo, se os dois switches das configurações anteriores tiverem 48 portas gigabit-
ethernet, as portas físicas do SwitchID#1 estarão no intervalo de g1/0/1 até g1/0/48, já as
portas físicas do SwitchID#2 estarão no intervalo de g2/0/1 até g2/0/48. Cuidado com esses
índices para evitar que as configurações das interfaces fiquem incorretas no caso de mudança
no ID dos membros do empilhamento.

6.2 VSS - Virtual Switching System
O VSS (Virtual Switching System) é uma tecnologia desenvolvida especificamente para

equipamentos das camadas superiores (núcleo e distribuição) que permite combinar pares de
switches físicos redundantes ou VSS Pairs (pares de VSS), criando um único switch lógico do
ponto de vista de gestão e operação, conforme figura abaixo.
Em plataformas como Cisco Catalyst 4500, 4500-X, 6500 e 8500 é possível configurar dois
chassis idênticos para trabalharem como um único switch lógico ou VSS.
Se uma placa supervisora do chassis configurado como mestre falhar, outro módulo supervisor
pode assumir, mesmo que esteja instalada fisicamente em outro chassis. Além disso, para
construir o switch lógico (logical switch), os dois chassis devem estar conectados entre si
através de várias interfaces configuradas para atuar como um Virtual Switch Link (VSL).
Os VSLs podem ser configurados com até 8 links entre o par de switches utilizando diferentes
combinações entre line cards ou placas supervisores para fornecer redundância. Em um caso
raro de TODOS os Virtual Switching Link (VSL) conectados entre o par de switches da VSS
caiam ou fiquem shutdown por qualquer motivo (mas os switches continuam ativos - isolados
mas funcionando), o VSS faz a transição para um modo chamado "Dual Active Recovery
Mode".
Com o switch em dual active recovery mode todas as interfaces são desligados no antigo switch
virtual ativo, porém o novo switch virtual ativo continua encaminha tráfego em todos os links.
Ou seja, quando o VSS passa a operar em dual active recovery mode, apenas o novo switch
virtual ativo continua a encaminhar o tráfego.
Assim como estudamos para os switches StackWise, com o VSS ou par de switches VSS
passam a ser vistos pelos switches de acesso como uma única entidade lógica, independente da
interligação física dos cabos, possibilitando o uso do recurso MEC (Multichassis Ether-Channel)
para associar portas físicas em diferentes switches a um único etherchannel. Nesse caso a
tecnologia VSS fará o gerenciamento do balanceamento de carga e da disponibilidade entre
essas conexões físicas em switches diferentes.
A maior vantagem do uso da tecnologia VSS é eliminar a necessidade do uso de tecnologias

FHRP (HSRP, VRRP e GLBP), o que acaba simplificando a rede como um todo e reduzindo a
sobrecarga de gerenciamento dos switches em quase 50%.

4 Ferramentas de Gerenciamento
As ferramentas de gerenciamento da infraestrutura de redes podem ser utilizadas para diversos
fins, inclusive a verificação da disponibilidade da rede. Seguem algumas tarefas que os
administradores de rede podem executar com tais ferramentas:
 Verificar o desempenho da rede.
 Caracterizar o desempenho da rede através da definição de um “baseline”.
 Entender as quantidades e direções dos fluxos de tráfego da rede.
 Realizar troubleshoot de problemas de rede.
O mais interessante é que o Syslog e SNMP foram inseridos na nova revisão do CCNA Routing
and Switching e o IP SLA é assunto estudado no CCNP ROUTE, porém é muito comum essa
repetição de assuntos entre exames de certificação, pois eles trazem outros enfoques das
mesmas ferramentas utilizadas em cursos e certificações anteriores.
4.1 Syslog
O Syslog é um padrão criado pela IETF para a transmissão de mensagens de log em redes IP. O
termo é geralmente usado para identificar tanto o protocolo de rede quanto para a aplicação ou
biblioteca de envio de mensagens no protocolo syslog, o qual fica armazenado em um servidor
de Syslog que pode ser instalado em qualquer computador. As mensagens enviadas tem o
seguinte formato:
%FACILTY-SUBFACILITY-SEVERITY-MNEMONIC: Texto da Mensagem
 FACILITY-SUBFACILITY: Indica o protocolo, modulo ou processo que gerou a

mensagem. Por exemplo, SYS para o sistema operacional, OSPF, IF para interface e IP.
 SEVERITY: Um número de 0 a 7 que determina a importância da ação reportada. Os
níveis são:
o Emergency: 0
o Alert: 1
o Critical: 2
o Error: 3
o Warning: 4
o Notice: 5
o Informational: 6
o Debugging: 7
 MNEMONIC: Um código que identifica a ação que está sendo reportada.
 Texto da Mensagem: um texto que explica a mensagem gerada.
Para habilitar o Sysylog basta utilizar o comando em modo de configuração global:

“Router(config)#logging ip_do_servidor”, abaixo segue um exemplo no qual o servidor de
syslog tem o IP 10.0.0.10:
Router#config term
Router(config)#logging 10.0.0.10
Para configurar a amplitude do log entre com o comando em modo de configuração global:
router(config)#logging trap nível
O nível pode ser o número ou o nome contido na lista acima. O nível 7 ou debug é o mais alto e
o emergency o mais baixo, ou seja, menos rico em detalhes. Abaixo segue um exemplo
alterando o nível do log para informacional:
Router(config)#logging trap informational ! ou

Router(config)#logging trap 6

Com o comando acima o roteador enviará ao syslog mensagens de nível 6 até zero, se
configurássemos como nível 4 o roteador enviaria mensagens de 4 a zero.
Lembre-se que essas mensagens são armazenadas nos roteadores e switches mesmo que não
configuremos um servidor, pois o syslog é utilizado internamente também para:
 O logging buffer  armazenamento interno em memória RAM das mensagens nos
roteadores e switches, portanto é apagado se reinicializarmos os equipamentos.
 Enviada mensagem para console (logging console)  ativada por padrão, são as
mensagens que aparecem na console enquanto estamos monitorando localmente os
dispositivos.
 Na VTY podemos monitorar essas mensagens com o “terminal monitor”  por padrão
as mensagens de syslog não são enviadas quando estamos conectados através de SSH
ou Telnet, temos que ativar o recebimento das mensagens.
 Através de um servidor de syslog como estudamos anteriormente com o comando
“logging ip-do-servidor”.
Para desabilitar o padrão de envio das mensagens de log para o console ou para o buffer na
memória RAM podemos utilizar os comandos “no logging console” e “no logging buffered”
respectivamente. Se ativamos a monitoração das mensagens em uma sessão de SSH ou Telnet
e queremos desabilita-la podemos utilizar o comando “terminal no monitor”.
4.1.1 Verificando e Configurando Time-stamps nas Mensagens de Log

Para verificar as mensagens geradas pelos dispositivos e armazenadas no buffer de registros
podemos utilizar o comando “show logging”. Veja saída do comando em um roteador com a
configuração padrão.
R1#show logging
Syslog logging: enabled (0 messages dropped, 2 messages rate-limited,0 flushes, 0
overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 10 messages logged, xml disabled, filtering
disabled
Monitor logging: level debugging, 0 messages logged, xml disabled, filtering
disabled
Buffer logging: level debugging, 10 messages logged, xml disabled,filtering
disabled
Logging Exception size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level informational, 13 message lines logged
As mensagens são mostradas por padrão conforme abaixo:
DlteC-FW-GW#conf t
DlteC-FW-GW(config)#exit
DlteC-FW-GW#
070101: Sep 24 2013 03:04:25.389 BR: %SYS-5-CONFIG_I: Configured from console by
dltec on vty0 (187.112.176.128)
DlteC-FW-GW#
 Um timestamp (marcação de data e hora que o registro ocorreu): Sep 24 2013

03:04:25.389 BR
 O recurso no roteador que gerou o registro (facility): %SYS

 Nível de severidade (severity level): 5

 Um mnemônico da mensagem: CONFIG_I
 Descrição breve da mensagem (description): Configured from console by dltec on vty0
(187.112.176.128)
Podemos mudar o formato de exibição do log de data e hora para um número de sequência
com os comandos abaixo:
DlteC-FW-GW(config)#no service timestamps

DlteC-FW-GW(config)#service sequence-numbers
DlteC-FW-GW(config)#exit
DlteC-FW-GW#
070102: %SYS-5-CONFIG_I: Configured from console by dltec on vty0
(187.112.176.128)
DlteC-FW-GW#
Veja a diferença da mensagem com a nova configuração através de números de sequência.
 Número de sequência (sequence number): 070102

 Facility (recurso): %SYS
 Severity level (nível de severidade): 5
 Mnemônico: Config_I
 Descrição: Configured from console by console
Existem outras opções que você pode configurar no comando “Service timestamp”, por
exemplo, utilizando “Service timestamp log datetime msec” você define que as mensagens
de data e hora sejam mostradas com os milissegundos na mensagem (03:04:25.389).
4.2 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 nas portas 161 e 162.

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.
Através da porta 161 os servidores SNMP podem solicitar informações escritas na MIB dos
equipamentos gerenciados utilizando os comandos GET, assim como configurar um parâmetro
com o comando SET. Ambas as opções GET e SET são enviadas via UDP na porta 161. As
mensagens podem ser:
 Get Request: solicita um valor específico da MIB.
 Get Next Request: solicita o valor subsequente do request inicial.
 Get Bulk Request: solicita toda a tabela ou list na MIB de uma variável específica.
 Set Request: especifica uma variável que precisa ser escrita na MIB.
Os agentes SNMP também podem enviar mensagens não solicitadas aos gerentes,
normalmente alarmes e informações importantes conforme configuração. Para isso podem ser
utilizadas as seguintes mensagens:
 SNMP Trap: notifica um evento e não necessita de reconhecimento se o trap foi ou não
recebido pelo gerente. Normalmente o evento é um problema, alteração de estado de
interface ou falha.
 Inform Request: notifica um evento ao servidor, porém requer um reconhecimento da
mensagem.
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 configuração e operação da versão 1 (RFC 1157) é bem similar com a versão 2, porém ela
utiliza apenas uma versão simples de mensagens GET/SET e apenas envio de traps simples,
sem necessidade de confirmação. Quando o administrador desejava ler ou escrever algo na MIB
no SNMPv1 era só enviar a community string (nome da comunidade) em texto claro como parte
da mensagem, o roteador ou switch verificava se essa comunidade era igual a sua e pronto, o
acesso está permitido para leitura ou escrita. Por isso essa versão é tão insegura.
A versão 2c (RFC 1901) também é implementada através de nomes de comunidade ou

community strings, as quais podem ser somente leitura (Read Only – RO) ou de leitura e
escrita (Read Write – RW). Isso traz uma fraqueza grande às implementações porque uma vez
descoberta a comunidade qualquer um pode ler as informações via SNMP ou até enviar
comandos de configuração ao switch ou roteador configurado como leitura e escrita.
Em relação à versão 1, a versão 2 traz contadores de 64 bits, estendendo os 32 bits da versão

anterior, além disso foram inseridas as opções de Bulk Request e Inform Request que não
existiam na versão 1. Os contadores maiores permitem que a v2 consiga manter informações
de interfaces mais velozes, por exemplo.
Já a versão 3 do SNMP (RFCs de 3410 até 3415) possui recursos extras como autenticação,
garantia da integridade das mensagens e criptografia. Ele é capaz de solicitar informações de
autenticação através de nomes de usuário e senhas e implementar políticas de segurança
através de nomes de grupos (Group Names).

4.2.1 Configurações do SNMP v1 e v2c

Abaixo segue um exemplo de configuração onde vamos definir um host específico para
monitoração e limitar acesso à comunidade de leitura e escrita com uma ACL, o endereço desse
host é 192.168.1.1. A comunidade de leitura é “dltec123” e a de leitura/escrita é
“dltecsafe123”. Veja a configuração abaixo.
Switch#conf t
Switch(config)#access-list 1 permit 192.168.1.1
Switch(config)#snmp-server community dltec123 ro
Switch(config)#snmp-server community dltecsafe123 rw 1
Switch(config)#snmp-server host 192.168.1.2 traps admin
O último comando define o endereço 192.168.1.2 como o servidor que receberá os traps ou
alarmes gerados via SNMP e enviados pelo switch em caso de problemas.
4.2.2 Configurações do SNMP v3

A configuração do SNMPv3 tem três opções a mais que estudamos para a versão anterior:
 noAuthNoPriv  opção no comando noauth e utiliza um usuário e senha para
autenticação, porém sem criptografia.
 authNoPriv  usa a opção auth no comando e implementa Message Digest 5 (MD5) ou
Secure Hash Algorithm (SHA) para autenticação, porém ainda sem criptografia.
 authPriv  opção priv no comando, implemente autenticação e integridade com
Message Digest 5 (MD5) ou Secure Hash Algorithm (SHA) e criptografia através do DES
ou DES-56.
Os comandos para configuração do SNMPv3 seguem abaixo:

1) Definir o grupo do SNMP v3 para definir as políticas de segurança:
snmp-server group groupname v3 {auth | noauth | priv}
2) Definir o usuário e a autenticação para monitoração via SNMP v3:
snmp-server user username groupname v3 auth {md5 | sha} auth-password [priv

des56 priv password] [access access-list]
3) Definir o servidor que receberá as mensagens (traps e informs) dos equipamentos

gerenciados via SNMPv3:
snmp-server host end-do-host [informs] version 3 {auth | noauth | priv}

username [tipo-de-trap]
Na configuração abaixo vamos utilizar a versão 3 do SNMP com um grupo chamado GrupoOps
utilizando a opção “priv” (com autenticação e criptografia). Também vamos definir como
usuário para monitoração “operador” utilizando autenticação através do SHA e criptografia AES
com 128 bits. A senha a ser utilizada será “MyPassword”. Veja as configurações abaixo.
SW1(config)#snmp-server group GrupoOps v3 priv

SW1(config)#snmp-server user operador GrupoOps v3 auth sha MyPassword priv aes
128 MyPassword
SW1(config)#snmp-server host 192.168.1.1 informs version 3 priv operador

4.3 IP SLA
O IP SLA (Service Level Agreement – acordos de níveis de serviço) é um recurso que permite
um roteador ou switch Cisco simule tráfegos específicos e enviem a um receptor chamado
“responder”.
Esse recurso melhora a precisão da medição de detalhes da rede que outras ferramentas não
possibilitam, portando o IP SLA permite uma monitoração ativa e mais realista da rede!
O tráfego é simulado através de pacotes chamados “probes” (sondas) as quais podem simular
tráfegos com os protocolos HTTP, FTP, DHCP, UDP jitter, UDP echo, HTTP, TCP connect, ICMP
echo, ICMP path echo, ICMP path jitter e DNS. Por exemplo, com probes de ICMP echo (ping)
poderíamos monitorar se um determinado servidor está ativo ou não e tomar uma ação através
dessa monitoração, chaveando as requisições para um servidor reserva.
O IP SLA é um recurso muito utilizado para:

 Medir o desempenho de serviços e aplicações fim a fim através da rede.
 Verificar o alcance de redes ou hosts remotos.
 Utilizado em conjunto com o HSRP para alterar dinamicamente a prioridade ativando
interfaces backup em caso de falhas.
 Em redes com VoIP ele pode ser utilizado para medir o delay e jitter, itens importantes
para determinar a qualidade da voz em redes IP.
4.3.1 Configurando e Verificando o IP SLA Básico

Para o exame atual do CCNP SWITCH é pouco provável que sejam cobradas configurações
dessa parte de monitoração, as questões que podem cair serão sobre os conceitos apenas.
A ativação do IP SLA requer que uma origem envie o tipo de dados definidos através de probes
para um receptor ou destino, o qual pode ser um computador, servidor ou outro
roteador/switch Cisco.
O receptor não precisa obrigatoriamente ter o IP SLA configurado nele. Caso a monitoração
exija que o responder participe ativamente no processo a ativação é simples, basta ativar em
modo de configuração global o comando “ip sla responder”. O responder pode ser utilizado
quando a medição exige informações de temporização como medidas de latência e jitter.
A configuração da origem do IP SLA, ou seja, de quem está gerando os probes é mais

complexa. Será preciso definir o seguinte:
 Criar uma sessão de monitoração (monitor session).
 Definir o tipo de tráfego a ser gerado.
 Endereço IP do responder.
 Demais variáveis como valores de DSCP.
 Fazer o agendamento do envio das probes.
 Opcionalmente configurar um “tracking” utilizando uma sessão de IP SLA.
Abaixo segue um exemplo de configuração de uma sessão de IP SLA para medir o jitter relativo
ao UDP em uma porta de voz para ser utilizado nas medições de qualidade de VoIP. O tráfego
será gerado a cada 120 segundos e com essa configuração precisará ser parado manualmente.
sw1(config)#ip sla 1
sw1(config-ip-sla)#udp-jitter 10.1.1.3 65422 codec g729a
sw1(config-ip-sla-jitter)#frequency 120
sw1(config-ip-sla-jitter)#exit
sw1(config)#ip sla schedule 1 life forever start-time now

Vamos a outro exemplo de configuração onde vamos testar se o servidor 200.200.200.10 está
ativo utilizando ping enviado a cada 5 segundos. As probes devem ser enviadas assim que o
comando de agendamento for inserido e será repetido sem fim. Veja abaixo as configurações e
depois o comando “show ip sla configuration”, onde os parâmetros configurados estão
destacados em amarelo.
SW2#conf t
SW2(config)#ip sla 2
SW2(config-ip-sla)#icmp-echo 200.200.200.10
SW2(config-ip-sla-echo)#frequency 5
SW2(config-ip-sla-echo)#exit
SW2(config)#ip sla schedule 2 life forever start-time now
SW2(config)#end
SW2#sho ip sla configuration
IP SLAs, Infrastructure Engine-II
Entry number: 2
Owner:
Tag:
Type of operation to perform: echo
Target address: 200.200.200.10
Source address: 0.0.0.0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 5
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
Com o comando “show ip sla statistics” podemos verificar as informações coletadas pelas
probes e suas estatísticas. Veja exemplo abaixo, onde tivemos 14 sucessos (number of
success) nas 41 probes enviadas (number of failures) conforme configuração do exemplo
anterior.
SW2#sho ip sla statistics
Round Trip Time (RTT) for Index 2

Type of operation: icmp-echo
Latest RTT: 1 ms
Latest operation start time: 11:40:06.475 UTC Sat Aug 9 2014

Latest operation return code: OK

Number of successes: 14
Number of failures: 41
Operation time to live: Forever
 Conceitos de alta disponibilidade.

 Entender os modelos de switches modulares da família Catalyst 4500 e 6500.
 Entender a função dos módulos supervisores.
 Entender os recursos de alta disponibilidade das placas supervisoras.
 Configurar o RPR, RPR+ e SSO.
 Entender e configurar o NFS com SSO.
 Conceitos de gerenciamento voltado para manter a alta disponibilidade.
Ferramentas de gerenciamento: Syslog, SNMP e IP SLA.

Capítulo 07 - First Hop

Redundancy Protocols -
Nesse capítulo vamos FHRP
continuar estudando
conceitos e recursos para Objetivos do Capítulo
tornar uma rede altamente
disponível na Camada de Ao final desse capítulo você terá estudado e
Rede (L3).  As opções de compartilhamento de
Links.
 O conceito de topologias de alta
Mais especificamente vamos disponibilidade.
estudar tecnologias para  O conceito de pontos únicos de
falhas.
redundância entre os hosts
 O conceito do FHRP e os protocolos
e seu gateway padrão, HSRP, VRRP e GLBP.
chamado de primeiro salto  O conceito de funcionamento do
ou, em inglês, First Hop, por HSRP e VRRP.
isso o nome First Hop  O conceito de Failover e
Redundancy Protocols. Balanceamento de Cargas via HSRP.
 Ativação e verificação do HSRP e
VRRP básicos.
 O conceito, configuração e
O CCNP SWITCH cobra três verificação do GLBP.
protocolos FHRP: HSRP,
VRRP e GLBP.
Aproveite o capítulo e bons

estudos!

Sumário do Capítulo 5.1.3 Balanceamento de Cargas por Pesos

Entre AVFs ____________________________ 200
6 Resumo do Capítulo _____________ 202

1 Revisão do Encaminhamento de Pacotes
172
2 Conceito do FHRP – Redundância no
Primeiro Salto ______________________ 173
3 Entendendo e Configurando o HSRP _ 175
3.1 Entendendo o Failover com HSRP __ 176
3.2 Balanceando Cargas com HSRP ____ 177
3.3 Ativando e Verificando o HSRP ____ 178
3.4 Configurando a Eleição do Roteador
HSRP Ativo/Standby __________________ 178
3.5 Configurando a Autenticação do HSRP
180
3.6 Definindo o Endereçamento do
Gateway HSRP _______________________ 181
3.7 Configurando o Balanceamento de
Cargas com HSRP _____________________ 183
3.8 Reelegendo um Roteador HSRP – Falha
de Links ____________________________ 186
3.9 Tracking Utilizando o IP SLA _______ 187
3.10 Utilizando o comando Debug Standby
188
3.10.1 Exemplo 1 – Inicialização do HSRP sem
Standby Presente _______________________ 188
3.10.2 Exemplo 2 – Roteador não Inicializa o
HSRP 189
3.10.3 Exemplo 3 – Router HSRP Active com
Preempt 190
4 Entendendo e Configurando o VRRP _ 192

4.1 Configurações do VRRP __________ 192
4.2 Exemplo de Configuração do VRRP _ 193
5 Entendendo e Configurando o GLBP _ 195
5.1 Configurações e Verificações Básicas do
GLBP 196
5.1.1 Exemplo de Configuração Básica do
GLBP 197
5.2 Configurações Avançadas do GLBP _ 199
5.1.1 Temporizadores de Redirect e Timeout
199
5.1.2 GLBP Weighting ________________ 200

1 Revisão do Encaminhamento de Pacotes

Em redes mais simples, por exemplo, em topologias ROAS (Router on a Stick) o
encaminhamento de tráfego local fica restrito aos switches de acesso que são normalmente L2,
já para VLANs ou redes/sub-redes diferentes o tráfego deve ser encaminhado para o roteador
que atua como gateway L3 nesse tipo de topologia, ou seja, o router faz o intermédio dos
pacotes entre redes/sub-redes diferentes, veja a figura abaixo.
Já em redes MLS podemos ter três casos mais encontrados de encaminhamento de pacotes:
4. Dois hosts na mesma VLAN/Sub-Rede se comunicando: Os quadros são tradados

em camada-2, não existe roteamento entre VLAN envolvido.
5. Dois hosts em VLANs/Sub-Redes diferentes que pertencem à mesma estrutura
de distribuição: os pacotes são inseridos em quadros que são marcados e enviados via
trunk até os switches de distribuição (gateway dos hosts) para que eles façam o
roteamento entre VLANs. Normalmente não envolve roteamento estático ou dinâmico
para encontrar as rotas, pois as SVIs são interfaces diretamente conectadas aos
switches.
6. Dois hosts em distribuições diferentes se comunicando (passando pelo Core):
nesse caso os pacotes originados no acesso são encaminhados à distribuição via trunks
e os switches de distribuição precisarão encaminhar os pacotes através dos links L3
entre eles e o Core para que o Core encaminhe esses pacotes até a outra estrutura de
distribuição. Nesse caso é necessário roteamento estático ou dinâmico para que o switch
saiba a interface de saída para as redes remotas.
Portanto, nos encaminhamentos 2 e 3 os hosts precisarão enviar um pacote para o gateway,

que no caso de redes MLS é o endereço MAC da SVI configurada no switch L3 para a VLAN onde
o host está conectado.
Esse é o primeiro salto que o pacote dá em redes MLS (pensando em camada-3): do host
conectado a um switch L2 para o switch L3 de distribuição.
Essa situação pode variar um pouco se tivermos VLANs estendidas, pois nesse caso os hosts
podem se comunicar com hosts remotos na mesma VLAN cruzando o Core em camada-2!
Mas o que ocorre se o roteador ou o switch L3 que está configurado como gateway padrão dos
hosts falhar? Pense um pouco...
Normalmente para resolver o problema de link colocamos um segundo link que pode ser
tratado como backup através do STP ou então balancear carga entre eles através do
Etherchannel, correto? Então vamos fazer a mesma coisa nesse caso, vamos colocar outro
switch de reserva e quando o primeiro falhar o segundo assume a rede.

A resposta é simples, porém vamos estudar na sequência que em camada 3 essa solução não é
tão simples assim, pois lembrem-se que os computadores permitem configurar um gateway e
não podemos configurar o mesmo IP em dois roteadores diferentes.
2 Conceito do FHRP – Redundância no Primeiro Salto

Vamos agora analisar um pouco mais a fundo a questão anterior sobre inserir o segundo
dispositivo L3 para tratar a queda do gateway padrão.
Veja a figura abaixo em uma topologia ROAS onde inserimos o segundo roteador (chamado R2)
para resolver o problema caso o primeiro (R1) fique indisponível. Nesse exemplo R1 é o
roteador original e está configurado nos computadores dos usuários como gateway padrão, ou
seja, pacotes para outras sub-redes ou para a Internet serão encaminhados para R1.
Mesmo com toda essa redundância o que vai acontecer, por exemplo, quando o roteador R1
cair, com os computadores que tem seu endereço IP como gateway padrão? As opções que
conhecemos até o momento seriam:
1. Ao cair R1, entrar nos computadores locais ou no servidor DHCP e alterar manualmente
o endereço do gateway padrão para o endereço “192.168.1.129” referente à R2.
2. Quando R2 for reestabelecido teremos que fazer o processo contrário, ou seja, voltar à
condição anterior do gateway configurando os computadores, um a um, manualmente
ou através da alteração do gateway no servidor DHCP.
3. Outra opção seria deixar R2 no comando até que ele caia e só aí voltamos a
configuração dos hosts para R1 como gateway.
4. A última possibilidade seria inserir um segundo gateway na configuração da placa de
rede dos clientes, porém essa solução não funciona na maioria dos sistemas
operacionais e o host acaba tendo problemas de conectividade.
Esse procedimento deveria ser realizado toda vez que R1, seu link com a LAN ou com a WAN
ficasse indisponível.
Para tratar todos esses problemas foram criados os protocolos classificados como FHRP ou
First Hop Redundancy Protocol. Esses protocolos tratam o problema que pode ocorrer no
primeiro salto dos hosts, ou seja, entre o computador do usuário final e seu gateway padrão.
Além disso, eles podem ajudar no balanceamento de cargas.
Mas como isso pode ser feito? Simplificando o assunto ao máximo, imagine que pudéssemos
configurar um mesmo endereço IP para R1 e R2, porém somente um deles irá responder ao
usuário final fazendo com que esse problema de queda do link ou do equipamento ficasse
transparente o usuário final? Resolveria o problema, concorda?
Vamos então simplificar o que um protocolo FHRP faria no caso da queda de R1 ou sua
conectividade com a rede de maneira generalizada:

1. Os hosts não sofrem nenhuma alteração, continuam como o esperado com um gateway
configurado em sua placa de rede.
2. Os roteadores padrão R1 e R2 compartilham um endereço IP virtual para a sub-rede
19.168.1.0/24, o qual é definido nas configurações do protocolo FHRP ativado em ambos
os roteadores.
3. Os hosts utilizam o endereço IP virtual definido no FHRP como seu default gateway.
4. Os roteadores trocam mensagens do protocolo FHRP para definir qual dos dois atuará e
como será essa atuação durante a operação normal de rede, por exemplo, R1 será o
principal e R2 fica como standby até R1 falhar.
5. Quando ocorre um problema na rede os roteadores trocam mensagens através do
protocolo FHRP para escolher quem assumirá as responsabilidades do roteador que
falhou.
Com isso conseguiremos fazer a redundância no primeiro salto, ou seja, entre os computadores
dos usuários e seu gateway de maneira transparente, pois nada precisará ser feito na
configuração da placa de rede dos computadores.
Os três protocolos principais da família FHRP que estudaremos nesse capítulo são:
 HSRP (Hot Standby Router Protocol Cisco): protocolo definido pela Cisco, trabalha
com um roteador ativo e outro em standby (Active/standby). Permite balanceamento de
cargas por sub-rede.
 VRRP (Virtual Router Redundancy Protocol): protocolo aberto definido pela IETF
(RFC 5798), assim como HSRP um dos roteadores ficará ativo e os demais em standby
(Active/standby). Permite balanceamento de cargas por sub-rede.
 GLBP (Gateway Load Balancing Protocol): protocolo definido pela Cisco, permite
que ambos os roteadores trabalhem simultaneamente (ativo/ativo - Active/active).
Permite balanceamento de cargas por host.
A seguir vamos estudar os conceitos e implementação de cada um dos três protocolos citados
acima.

3 Entendendo e Configurando o HSRP

O HSRP trabalha com um conceito de Ativo/Standby que pode ser chamado também como
Ativo/Passivo em algumas bibliografias. Isso quer dizer que por sub-rede apenas um roteador
ficará ativo enviando o tráfego, o outro roteador ficará como passivo ou standby até que o
primeiro roteador falhe.
O roteador HSRP ativo possui configurado um endereço IP virtual vinculado também a um

endereço MAC virtual. Essa configuração faz parte do processo de ativação do HSRP nos
roteadores, porém o roteador continua tendo o seu endereço IP configurado com o comando “ip
address” em sua interface. O IP virtual é um endereço na mesma sub-rede da interface ou
subinterface, porém diferente. Já o MAC virtual é criado automaticamente pelo roteador.
Como a arquitetura do HSRP é ativo/passivo (ou standby), todos os roteadores participando do

processo conhecem o endereço IP virtual, mas o único que responde as requisições enviadas é
o roteador ativo (principal). Veja a figura abaixo.
Os computadores agora não utilizam nem o endereço 192.168.1.9 ou 192.168.1.129 como

gateway, mas sim um endereço IP virtual 192.168.1.1 como gateway (GW). Além disso, as
requisições ARP solicitando o MAC do gateway 192.168.1.1 não são mais respondidas utilizando
o MAC físico de R1 e sim um MAC virtual (VMAC) definido automaticamente pelo roteador.
Note também que mensagens do HSRP são trocadas entre R1 (ativo ou active) e R2 (passivo ou
stanby). Portanto, nos passos de configuração do HSRP ambos os roteadores precisam de
configurações específicas, por exemplo, definir o IP virtual, definir quem será o ativo e quem
será o passivo ou standby.
O HSRP tem duas versões (1 e 2) e em ambas a configuração do IP virtual é tarefa do

administrador de redes. Já o MAC virtual (VMAC) é definido através de uma regra básica
dependendo da versão que o HSRP está utilizando e o grupo configurado pelo administrador de
redes.
O HSRP versão 1 utiliza a faixa de endereços 0000.0C07.ACxy como MAC virtual dos
roteadores, onde xy é o número do grupo do HSRP em hexadecimal configurado na interface.
Por exemplo, se o HSRP for configurado no grupo 1 o virtual MAC será 0000.0C07.AC01.
Portanto, computadores naquele segmento de rede terão as suas requisições do Address
Resolution Protocol (ARP) respondidas com esse endereço MAC 0000.0C07.AC01 independente
do MAC real da interface de LAN do roteador ativo.
A versão 2 do HSRP permite a configuração de um número de grupo estendido de 0 a 4095 e

utiliza um novo range de MACs virtuais, os quais podem ir de 0000.0C9F.F000 até
0000.0C9F.FFFF. Em hexadecimal 0 pode ser escrito como 000 e 4095 é FFF, por isso os
valores do range de MACs virtuais no HSRP-v2 tem nos três últimos algarismos o valor do

grupo HSRP configurado pelo administrador de redes convertido em hexadecimal, assim como
no HSRP v1, porém com três dígitos ao invés de dois apenas.
O HSRP envia mensagens em multicast no endereço 224.0.0.2 através da porta UDP 1985. A
versão 2 do HSRP utiliza o endereço 224.0.0.102 ao invés do anterior.
Porque os MACs virtuais são importantes? Porque em necessidades de troubleshooting é

através deles que podemos verificar nos switches o mapeamento das portas utilizadas para
encaminhamento até o gateway, pois agora ele é um endereço virtual.
Além disso, visualizando a tabela ARP dos hosts poderemos saber quem eles estão utilizando
como gateway. Essa informação no HSRP e VRRP até não é tão relevante, pois todos os hosts
devem utilizar o mesmo MAC de destino para o gateway, não importando o roteador que esteja
ativo momentaneamente, porém para o GLBP você aprenderá que a situação é um pouco
diferente.
Quando tratamos especificamente da configuração do HSRP em switches Layer 3 temos que

saber que ele pode ser ativado em três tipos de interfaces (todas L3):
 Routed port: porta física com o comando "no switchport" dentro da interface.
 SVI: interface VLAN, pois por padrão ela é uma interface Layer 3.
 Etherchannel port channel (Layer 3 mode): uma interface lógica port-channel
criada com o comando "interface port-channel num-port-channel" com o comando "no
switchport" dentro da interface tornando-a uma interface L3.
3.1 Entendendo o Failover com HSRP
Quando os roteadores têm o HSRP configurado há uma troca inicial de pacotes entre eles e é
decidido quem será ativo e passivo. Após essa troca inicial o roteador ativo responde às
solicitações ARP dos clientes utilizando o IP virtual (igual para todos os roteadores HSRP/VRRP)
e seu MAC virtual (também o mesmo).
Caso haja um problema em R1, através de mensagens do HSRP ou de temporizadores de

timeout (não recebimento de mensagens) R2 será colocado como ativo e R1 passará a ser
o standby, porém nada mudará para os clientes, ou seja, o endereço IP e MAC virtuais
continuarão os mesmos. Esse processo é chamado de Failover.
Mas espera um pouco, as entradas das tabelas MAC dos switches SW-1 até SW-4 vinculam o
MAC virtual à porta que conecta ao roteador R1, como esse problema é resolvido pelo HSRP?
De uma maneira bem simples, quando R2 assume como ativo ele envia mensagens em
broadcast avisando que o IP virtual e o MAC virtual agora pertencem a ele. Essas mensagens
são chamadas de Gratuitous ARP, nada mais é que um ARP Reply para que os switches de
SW-1 a SW-4 apaguem o vínculo do MAC virtual com a porta que conecta R1 e estabeleçam um
novo vínculo com a porta que conecta o roteador R2.
Lembre-se que essa é uma das regras que estudamos nos switches, quando ele recebe uma
informação nova sobre o mesmo MAC a antiga é apagada e o endereço é vinculado à nova
porta.
Portanto, todas as ações para R2 assumir como ativo estão restritas a ele mesmo e aos
switches de acesso, não envolvendo em nenhum momento os computadores dos usuários
finais, ou seja, o processo é transparente aos computadores. Veja figura a seguir com um
resumo do processo de Failover do HSRP.

1. Via mensagens e/ou temporizadores do HSRP, R2 descobre que houve falha em R1 e é

passado para o estado de ativo.
2. Gratuitous ARP são enviados por R2 para ensinar aos switches que o MAC virtual VMAC1
está agora com o roteador R2.
3. Os hosts da sub-rede 192.168.1.0/24 não são alterados, porém os switches passam a
encaminhar quadros com destino o VMAC1 para a porta onde R2 está conectado.
3.2 Balanceando Cargas com HSRP
O HSRP é tratado por sub-rede, por isso para fazer balanceamento de cargas através dele
precisamos fazer uma configuração com a mesma filosofia que estudamos para compartilhar
cargas entre VLANs em switches de distribuição, ou seja, um roteador assume algumas sub-
redes como ativo e o outro roteador assume as demais. Assim, basta criar dois grupos HSRP e
dividir as VLANs entre eles.
Vamos a um exemplo prático utilizando switches camada-3 ao invés de roteadores como

gateway para os computadores dos usuários finais. Veja topologia a seguir.

Nesse exemplo, SW-D1 está encaminhando pacotes das sub-redes das VLANs pares, assim
como está ativo no HSRP para essas sub-redes. Caso SW-D1 tenha problemas o switch SW-D2
assume as sub-redes das VLANs pares.
O mesmo conceito pode ser utilizado quando temos roteadores como dispositivos de camada-3
em uma topologia Router-on-a-Stick (ROAS). Um dos roteadores pode ser definido como ativo
para parte das sub-redes e o segundo roteador ficaria ativo para o restante das sub-redes,
sendo que um ficaria como passivo do outro assumindo todas as sub-redes caso haja
problemas com um deles.
3.3 Ativando e Verificando o HSRP
A ativação do HSRP é relativamente simples e os comandos são aplicados em modo de

configuração de interface, onde nos switches L3 será normalmente uma interface SVI.
Por padrão o HSRP é configurado com um número de grupo que vai de 0 a 255 (total de 256
standby groups), porém maioria dos switches Cisco suportam apenas 16 grupos, por isso se
você utilizar um número de grupo por VLAN em cada SVI pode acabar não entendendo seu
projeto.
Uma alternativa é agrupar várias VLANs em um mesmo grupo, por exemplo, as VLANs de 1 a
10 terão suas SVIs no grupo 1 e de 11 a 20 no grupo 2, assim você não terá problemas de
configuração.
O primeiro comando que podemos utilizar (opcional) é o “standby group num-do-grupo

name nome-do-grupo”. Esse comando define o grupo que a SVI está participando do HSRP e
permite inserir um nome, apenas um nome para lembrar o que representa o grupo.
Também podemos configurar a versão do HSRP, por padrão é versão 1. Veja exemplo abaixo.
Switch(config-if)#standby 1 name VLANs-1-a-10
Switch(config-if)#standby version 2
Mesmo inserindo várias VLANs e suas respectivas SVIs em um mesmo grupo, podemos definir
IPs virtuais distintos por interface.
3.4 Configurando a Eleição do Roteador HSRP Ativo/Standby
O HSRP permite que tenhamos um roteador/switch L3 ativo (active - principal) e um standby

(reserva). Para isso um valor de prioridade é utilizado na definição, o router que possui a maior
prioridade é eleito como ativo.
Podemos definir a prioridade com o comando “standby num-do-grupo priority valor-

prioridade”, sendo que o valor padrão é 100, porém ela vai de 0 a 255 e a maior prioridade
assume como ativo. Se esse comando não for configurado o maior IP entre as interfaces do
grupo se torna o roteador ativo.
Veja exemplo abaixo onde o switch anterior vai ser definido como ativo utilizando a prioridade
200.
Switch(config-if)#standby 1 name VLANs-pares
Switch(config-if)#standby 1 priority 200

Quando configuramos o HSRP na interface ele passa por uma série de estados até se tornar
ativo, pois como temos mais de um roteador envolvido no processo de eleição é preciso que
eles “escutem” os pacotes do HSRP para definir os papéis de ativo e standby. Basicamente são
seis estados:
1. Initial: Estado inicial do roteador HSRP. O processo está iniciando e ainda não está
ativo.
2. Learn: O roteador HSRP está aguardando “escutar” pacotes do roteador ativo.
3. Listen: Escuta mensagens de hello dos roteadores HSRP ativo e standby.
4. Speak: Participa na eleição do roteador active ou standby.
5. Standby: O roteador HSRP se torna o backup do ativo.
6. Active: O roteador HSRP está encaminhando pacotes, ou seja, ele é o ativo.
Mesmo que existam vários equipamentos com o HSRP configurado, somente o standby fica
“escutando” os hellos do HSRP que são enviados por padrão de 3 em 3 segundos. Caso ele não
receba hellos por 10 segundos (padrão do timer de Holdtime – 3xHello) o roteador ativo é
considerado ausente e o standby assume o IP Virtual para servir como gateway dos hosts para
as VLANs daquele grupo. Veja figura abaixo.
Podemos alterar os valores dos timers do HSRP com o comando “standby num-do-grupo
timers [msec] hello [msec] holdtime”. A opção MSEC permite você definir o valor em
milissegundos, se você não colocar essa opção o valor entra em segundos. O Hello entra com
valores de 1 a 254 segundos ou de 15 a 999 milissegundos. Já o Holdtime entra com valores de
1 a 255 segundos ou de 50 a 3000 milissegundos.
Cuidado ao alterar esses valores, pois valores muito baixos podem fazer com que pequenas
falhas sejam detectadas e o tráfego de mensagens de HSRP aumente muito entre as interfaces.
Além disso, os routers podem acabar em um estado de constante troca de papéis.
O último comando para configuração da eleição do roteador HSRP é o que define “o que vai
ocorrer quando o principal voltar no caso de falhas?”. Por padrão, quando acontece uma falha o
standby assume e fica nesse estado mesmo que o principal volte.

Com o comando “standby num-do-grupo preempt [delay [minimum segundos] [reload

segundos]]” podemos fazer com que o principal volte a assumir como ativo, ou seja, o
roteador HSRP com maior prioridade vai voltar a ser ativo quando voltar a funcionar. Esse
recurso é chamado de preempt ou preemption.
Se o comando “standby num-do-grupo preempt” for utilizado o roteador com maior

prioridade assume imediatamente a função de ativo. A opção delay permite configurar um
atraso entre o roteador com maior prioridade subir e assumir o papel de ativo veja as opções
de configuração abaixo:
 A opção “minimum” força o roteador HSRP aguardar entre 0 a 3600 segundos antes de
tentar tomar o lugar do roteador ativo com prioridade mais baixa. Esse tempo começa a
contar assim que o roteador com prioridade mais alta tem condições de assumir o papel,
ou seja, sua interface está ativa.
 A opção “reload” força o roteador a aguardar entre 0 e 3600 segundos depois que ele foi
reinicializado, seja pelo comando reloaded ou por um cold restar (reinicialização por
desligamento). Esse comando é bem útil, pois após o uma reinicialização o roteador leva
um tempo até que tudo suba e os protocolos de roteamento finalizem o processo de
convergência, portanto evita que o roteador com prioridade mais alta suba antes de
poder realmente encaminhar os pacotes.
Vamos agora complementar o exemplo que fizemos anteriormente com os demais comandos
estudados.
Switch(config-if)#standby 1 timers msec 200 msec 600
Switch(config-if)#standby 1 preempt delay minimum 3 reload 120
Nesse exemplo alteramos o hello para 200ms e o holdtime para 600ms (3xhello). Além disso, o
switch local que tem maior prioridade vai assumir caso volte de uma falha como ativo após 3
segundos e em caso de reinicialização após 2 minutos (120 segundos).
3.5 Configurando a Autenticação do HSRP
O HSRP também permite o uso de autenticação para prevenir o spoofing ou que dispositivos
não autorizados participem do grupo HSRP. Os métodos permitidos são através de texto claro
(plain text) ou utilizando hash MD5 (criptografado).
Utilizando autenticação exige que todos os roteadores no mesmo grupo precisem ter a mesma
chave e método de autenticação configurado neles.
Para configurar a autenticação em texto claro utilize o comando “standby group

authentication chave-de-autenticação”. A mesma chave deve ser configurada em todos os
roteadores do grupo de standby.
Para utilizar a autenticação com MD5 temos duas opções, direto na interface ou primeiro
configurando uma key-chain e depois a vinculando ao grupo de standby na interface. Veja a
configuração do primeiro método direto na interface.
Switch(config-if)#standby group authentication md5 key-string [0 | 7] palavra-

chave

Na opção [0 | 7] o zero significa que a chave vai ser inserida sem criptografia (em texto claro)
na configuração, já o 7 significa que você vai inserir uma chave encriptada e não a senha em
texto claro.
No segundo método da configuração com MD5 será preciso configurar a chave de criptografia e
depois ativar a autenticação na interface. Veja exemplo abaixo:
Switch(config)#key chain chain-name

Switch(config-keychain)#key key-number
Switch(config-keychain-key)#key-string [0 | 7] palavra-chave
Switch(config)#interface type mod/num
Switch(config-if)#standby group authentication md5 key-chain chain-name
O segundo método é mais flexível e permite a configuração de várias chaves, as quais podem
ser vinculadas ao grupo HSRP.
3.6 Definindo o Endereçamento do Gateway HSRP
Cada roteador HSRP em um grupo tem seu endereço IP único em sua interface, ou seja, no
comando “ip address endereço máscara” continua como fazemos sempre, cada interface precisa
de um endereço único.
Porém, além do endereço da interface, cada roteador HSRP vai ter um endereço de gateway
virtual que será o mesmo para todo o grupo e representa o roteador virtual HSRP. Esse
endereço virtual é chamado de endereço HSRP ou endereço de standby (standby address).
Quando falamos que o endereço HSRP deve ser o mesmo devemos lembrar que se o grupo
possuir diversas VLANs esse endereço será o mesmo por VLAN ou por sub-rede, pois não tem
como utilizar o mesmo endereço em VLANs distintas.
O comando de configuração do endereço é “standby num-do-grupo ip endereço-ip-virtual

[secondary]”. Se a interface possuir um IP secundário configurado a opção “secondary” faz
com que o HSRP forneça um IP virtual secundário como gateway para essa rede/sub-rede.
Agora podemos completar nossa configuração e analisar uma topologia com o HSRP. Vamos
inserir a configuração abaixo no switch-1 para a VLAN 1 com as seguintes exigências:
 Ele deve ser ativo.
 Deve assumir como ativo em caso de retorno de problemas após 3 segundos
 Em caso de reload após 2 minutos.
 Utilizar autenticação com criptografia MD5 e chave dLt3c.
 O endereço virtual a ser utilizado é o primeiro IP da sub-rede atual.
 O switch-2 deve ser o standby.
Vamos às configurações do switch-1:
Switch1(config)#interface vlan 1
Switch1(config-if)#ip address 192.168.1.10 255.255.255.0
Switch1(config-if)#standby 1 name VLANs-pares
Switch1(config-if)#standby 1 priority 120
Switch1(config-if)#standby 1 timers msec 200 msec 600
Switch1(config-if)#standby 1 preempt delay minimum 3 reload 120
Switch1(config-if)#standby 1 authentication md5 key-string 0 dLt3c
Switch1(config-if)#standby 1 ip 192.168.1.1
*Mar 1 02:40:03.211: %HSRP-5-STATECHANGE: Vlan1 Grp 1 state Standby -> Active
Note que aparece uma mensagem informando que o switch1 assumiu como ativo para a VLAN
1 (%HSRP-5-STATECHANGE: Vlan1 Grp 1 state Standby -> Active).

Agora vamos configurar o switch-2 como standby. Como o switch-1 tem prioridade 120 se não
configurarmos nada no switch-2 sua prioridade será 100 e naturalmente ele será o standby.
Switch2(config)#interface vlan 1
Switch2(config-if)#ip address 192.168.1.11 255.255.255.0
Switch2(config-if)#standby 1 name VLANs-pares
Switch2(config-if)#standby 1 timers msec 200 msec 600
Switch2(config-if)#standby 1 authentication md5 key-string 0 dLt3c
Switch2(config-if)#standby 1 ip 192.168.1.1
Veja a topologia abaixo sobre como será a comunicação dos hosts com o gateway com a
configuração aplicada e em operação normal (switch-1 ativo).
Com o comando “show standby” podemos ver se as configurações estão conforme planejado,
veja saída do switch-1.
Switch1#show standby
Vlan1 - Group 1  VLAN 1 ativa no grupo 1
State is Active  Switch 1 está como ativo
8 state changes, last state change 00:01:19
Virtual IP address is 192.168.1.1  endereço IP virtual
Active virtual MAC address is 0000.0c07.ac01  MAC virtual
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 200 msec, hold time 600 msec  temporizadores de hello e holdtime
Next hello sent in 0.064 secs
Authentication MD5, key-string  indica que a configuração MD5 está ativada
Preemption enabled, delay min 3 secs, reload 120 secs  informações do preempt
Active router is local  indica que o roteador local é o ativo
Standby router is 192.168.1.11, priority 100 (expires in 9.184 sec) 
informações do roteador standby
Priority 120 (configured 120)  prioridade do roteador local
Group name is "VLANs-pares" (cfgd)

Como temos configurada apenas a VLAN 1 com HSRP o comando “show standby” trouxe
somente as informações dela, se tivéssemos mais VLANs podemos utilizar o comando “show
standby vlan 1” para trazer apenas as informações da VLAN 1.
Como configuramos o HSRP versão 1 (padrão) seu MAC virtual inicia com 0000.0c07.ac e tem
o final 01, o qual é o número do grupo que configuramos no comando “standby 1 ip
192.168.1.1” em hexadecimal.
Podemos também utilizar a opção “show standby brief” (mostra todas as VLANs e grupos) ou
“show standby vlan 1 brief” (mostra as informações da VLAN 1), veja abaixo.
Switch1#show standby vlan 1 brief

P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Vl1 1 120 P Active local 192.168.1.11 192.168.1.1
Switch#
Portanto temos o HSRP configurado na interface Vlan1 (campo Interface), ele está no grupo
HSRP 1 (campo Grp), seu estado está como ativo (Campo State - Active), o endereço IP do
roteador passivo está no campo Stanby como 192.168.1.11, ou seja, o IP do switch-2. O
endereço virtual está mostrado no campo “Virtual IP” e configurado como 192.168.1.1.
Note que no campo “Active” ele mostra a informação “local”, ou seja, o próprio R1 é o roteador
ativo. Também no campo “Pri” temos a prioridade de R1 que foi configurada como 110 para
que ele pudesse ser escolhido como ativo, pois o padrão é 100.
3.7 Configurando o Balanceamento de Cargas com HSRP
O HSRP não suporta balanceamento de cargas automático, ou seja, esse tipo de configuração
exige configuração manual através da definição de que VLANs serão encaminhas por que trunk
pelo STP e depois definir o switch que é primário no STP como ativo para o HSRP. Veja a figura
abaixo com esse desenho.
Em termos de configuração para essa topologia é a mesma que fizemos no exemplo anterior,
porém precisaremos configurar o SW-D1 como ativo nas interfaces VLAN 2, 4, 6 e 8 e standby
para as interfaces VLAN 1, 3, 5 e 9. Para o switch SW-D2 é só fazer ao contrário, para as

interfaces VLANs pares ficam com a configuração de standby e para as ímpares com a
configuração de ativo.
Veja exemplo abaixo com as configurações das VLANs 1 e 2 dos switches SW-D1 e SW-D2.
Vamos às configurações do SW-D1.
SW-D1(config)#interface vlan 2
SW-D1(config-if)#ip address 192.168.2.10 255.255.255.0
SW-D1(config-if)#standby 1 name VLANs-pares
SW-D1(config-if)#standby 1 priority 120
SW-D1(config-if)#standby 1 preempt delay minimum 3 reload 120
SW-D1(config-if)#standby 1 authentication md5 key-string 0 dLt3c
SW-D1(config-if)#standby 1 ip 192.168.2.1
SW-D2(config)#exit
SW-D1(config-if)#standby 1 name VLANs-impares
Agora vamos configurar o switch-2 como standby para VLAN 1 e ativo para a 2.
SW-D2(config-if)#standby 1 name VLANs-impares
SW-D1(config-if)#standby 1 priority 120
SW-D1(config-if)#standby 1 preempt delay minimum 3 reload 120
SW-D2(config)#exit
SW-D2(config-if)#standby 1 name VLANs-pares
Outro modelo de configuração é fazer o balanceamento de cargas em uma mesma VLAN,

porém nesse exemplo os hosts devem ser configurados com endereços IPs estáticos, pois o
serviço de DHCP não conseguiria por padrão atribuir dois gateways diferentes para a mesma
VLAN, não que seja impossível, mas não faz parte do conteúdo do CCNP SWITCH.
Para isso vamos considerar a topologia do exemplo em 2.3.3 e fazer com que metade dos
computadores tenha como gateway principal o switch-1 e em caso de falhas o switch-2
assume. Por outro lado, a outra metade deve sair pelo switch-2 e em caso de falhas o switch-1
assume. A seguir você tem a topologia e as configurações.

Configurações no switch-1.
Switch-1(config)#interface vlan 1
Switch-1(config-if)#ip address 192.168.1.10 255.255.255.0
Switch-1(config-if)#standby 1 priority 120
Switch-1(config-if)#standby 1 preempt
Switch-1(config-if)#standby 1 ip 192.168.1.1
Switch-1(config-if)#standby 1 authentication dltec
Configurações no switch-2.
Switch-2(config)#interface vlan 1
Switch-2(config-if)#ip address 192.168.1.11 255.255.255.0
Switch-2(config-if)#standby 2 preempt
Note que a interface VLAN 1 continua com a mesma configuração utilizando o endereço
192.168.1.1 como IP virtual e foi inserido o segundo IP virtual com o endereço 192.168.1.2 em
outro grupo HSRP e com prioridade maior no switch-2.
Essa configuração não é muito usual em redes LAN com DHCP, porém para ambientes de
servidores que possuem endereços IP fixos ela pode ser encontrada na prática.

3.8 Reelegendo um Roteador HSRP – Falha de Links
Até o momento o HSRP protegeu a rede contra a queda de um switch L3 ou roteador que para
de funcionar por completo. Agora imagine que o link ou a comunicação como um todo entre o
roteador HSRP ativo e o core falha, o que vai acontecer nesse caso? Pense um pouco sobre o
assunto antes de continuar a leitura.
Nesse caso o roteador ativo vai continuar nessa função que ele foi eleito inicialmente, porém os
pacotes dos clientes não serão mais roteados para fora da distribuição, pois eles chegam ao
switch-1 e não conseguem passar para o Core. Já a comunicação local InteVLAN vai continuar
acontecendo normalmente, pois as SVIs ainda estão ativas.
Para tratar esse tipo de situação indesejada o HSRP tem um mecanismo que é capaz de
detectar falhas em links e refazer a eleição para passar o switch standby para ativo mesmo que
ele ainda esteja respondendo.
Isso é feito através de um “track” e pela redução da prioridade do HSRP no switch que tem a
interface monitorada apresente problemas nela. Isso pode ser feito em uma ou várias
interfaces. No exemplo anterior podemos configurar o switch-1 para monitorar a interface que
está conectada ao Core e definir um valor que diminuindo da prioridade atual ele fique menor
que a prioridade no switch-2.
O comando segue abaixo:
Switch(config-if)#standby group track tipo mod/num [decremento-na-prioridade]
O valor padrão do decremento na prioridade é 10 e algumas condições são necessárias para

ativar esse recurso:
1. O roteador HSRP só monitora interfaces dele mesmo.
2. Normalmente são links entre o roteador HSRP e outras regiões da rede e não interfaces
que o conectam a rede como gateway.
3. O roteador HSRP stanby deve ter prioridade maior que a do roteador ativo menos o
valor que será diminuído da prioridade atual dele.
4. O roteador standby deve estar utilizando o comando “preempt” para conseguir tomar o
papel de ativo.

Vamos a um exemplo. Suponha que o switch1 ativo tem prioridade 110 e o switch2 standby
tem prioridade padrão 100. O switch1 é conectado ao Core através da interface giga1/0/1 e
queremos monitorar essa interface para caso ela caia o switch2 assuma. Vamos às
configurações levando em conta que tudo já está configurado e precisamos apenas configurar o
track. Abaixo segue a configuração do switch1.
Switch1(config-if)#standby 1 track gig 1/0/1 25
Supondo que estamos configurando a rede como nos exemplos anteriores precisamos
configurar o preempt no switch2 que não foi ativado devido a ele ser um switch standby.
Switch2(config-if)#standby 1 preempt
Com essa configuração, quando a interface gig1/0/1 do switch1 cair a prioridade dele vai cair
de 120 para 95 (prioridade 120 – decremento 25 = 95), com isso sua prioridade será menor
que a do switch2 que é 100, por isso o switch2 será eleito como ativo.
O valor 25 foi arbitrário, poderíamos ter configurado como 21 que já funcionaria, pois 120-21
ficaria 99 a nova prioridade com a gig1/0/1 down.
Com isso finalizamos o HSRP e você pode praticar utilizando o packet tracer, porém nem todos
os comandos são suportados, ou o GNS3 utilizando roteadores, pois o princípio do HSRP com
roteadores e switches é o mesmo.
A seguir vamos estudar o VRRP que basicamente é a versão aberta do HSRP que é proprietário
da Cisco.
3.9 Tracking Utilizando o IP SLA
O mesmo processo descrito anteriormente por ser realizado em conjunto com o IP SLA
estudado no capítulo anterior.
Por exemplo, podemos decrementar a prioridade do HSRP de um switch ou roteador caso um

determinado destino não responda mais ao ping monitorado através de um IP SLA configurado.
Isso pode ser feito vinculando o tracking do HSRP a um número de operação de IP SLA
configurado no dispositivo, veja o comando abaixo.
(config)#track num-obj ip sla num-oper {state | reachability}
Para vincular o objeto ao HSRP utilizamos o mesmo comando estudado no tópico anterior.
Resumindo, precisaremos configurar as seguintes etapas:
1. Criar a operação do IP SLA.
2. Definir o tracking object vinculado ao IP SLA.
3. Configurar o decremento em modo de interface.
Veja exemplo abaixo onde ser o servidor 200.200.200.10 para de responder ao ping o switch-2
terá sua prioridade decrementada em 20. Veja a configuração abaixo, considerando que a
interface VLAN 2 e o HSRP já estavam operacionais.
SW2(config)#ip sla 2
SW2(config-ip-sla)#icmp-echo 200.200.200.10
SW2(config-ip-sla-echo)#frequency 5
SW2(config-ip-sla-echo)#exit
SW2(config)#ip sla schedule 2 life forever start-time now
SW2(config)#track 1 ip sla 2 reachability

SW2(config)#int vlan 2
SW2(config-if)#standby 1 priority 110
SW2(config-if)#standby 1 track 1 decrement 20
3.10 Utilizando o comando Debug Standby
Para minitorar a inicialização ou as mensagens trocadas pelo HSRP temos o comando “debug
standby” com algumas opções conforme exemplo abaixo.
Switch#debug standby ?
errors HSRP errors
events HSRP events
packets HSRP packets
terse Display limited range of HSRP errors, events and packets
<cr>
Switch#debug standby
HSRP debugging is on
Switch#
3.10.1 Exemplo 1 – Inicialização do HSRP sem Standby Presente
Veja exemplo a seguir com o comando “debug standby” ativo. Nesse exemplo vamos
configurar o HSRP na interface VLAN 1, sendo que o standby não está conectado, portanto o
próprio switch local vai subir como ativo. Note que em amarelo está marcada cada fase que o
HSRP passa até ficar como ativo (active) depois ele envia hellos em multicast de 3 em 3
segundos (marcado em verde).
A palavra STANDBY nas saídas do comando identifica que esse é um debug do HSRP. Vamos à
saída do comando.

Switch(config-if)#standby 1 preempt
Switch(config-if)#standby 1 authentication md5 key-string 7 dLt3c
Invalid encrypted keystring: dLt3c
Switch(config-if)#standby 1 ip 192.168.1.1
*Mar 1 00:21:35.939: HSRP: Vl1 Grp 1 Priority 100 -> 120

*Mar 1 00:21:38.539: HSRP: Vl1 API 192.168.1.1 is not an HSRP address
*Mar 1 00:21:38.539: HSRP: Vl1 Grp 1 Disabled -> Init
*Mar 1 00:21:38.539: HSRP: Vl1 Grp 1 Redundancy "VLANs-pares" state Disabled -> Init
*Mar 1 00:21:38.539: HSRP: Vl1 Grp 1 API fhrp mac, reserved 0000.0c07.ac01, type 1
*Mar 1 00:21:45.915: HSRP: Vl1 Interface UP
*Mar 1 00:21:45.915: HSRP: Vl1 Starting minimum interface delay (1 secs)
*Mar 1 00:21:46.915: HSRP: Vl1 Interface min delay expired
*Mar 1 00:21:46.915: HSRP: Vl1 Grp 1 Init: a/HSRP enabled
*Mar 1 00:21:46.915: HSRP: Vl1 Grp 1 Init -> Listen
*Mar 1 00:21:46.915: HSRP: Vl1 Redirect adv out, Passive, active 0 passive 1
*Mar 1 00:21:46.915: HSRP: Vl1 Grp 1 Redundancy "VLANs-pares" state Init -> Backup
*Mar 1 00:21:56.915: HSRP: Vl1 Grp 1 Listen: c/Active timer expired (unknown)
*Mar 1 00:21:56.915: HSRP: Vl1 Grp 1 Listen -> Speak
*Mar 1 00:21:56.915: HSRP: Vl1 Grp 1 Redundancy "VLANs-pares" state Backup -> Speak
*Mar 1 00:21:56.915: HSRP: Vl1 Grp 1 Hello out 192.168.1.10 Speak pri 120 vIP
192.168.1.1

192.168.1.1
192.168.1.1
192.168.1.1
*Mar 1 00:22:06.915: HSRP: Vl1 Grp 1 Speak: d/Standby timer expired (unknown)
*Mar 1 00:22:06.915: HSRP: Vl1 Grp 1 Standby router is local
*Mar 1 00:22:06.915: HSRP: Vl1 Grp 1 Speak -> Standby
*Mar 1 00:22:06.915: %HSRP-5-STATECHANGE: Vlan1 Grp 1 state Speak -> Standby
*Mar 1 00:22:06.915: HSRP: Vl1 Grp 1 Redundancy "VLANs-pares" state Speak -> Standby
*Mar 1 00:22:06.915: HSRP: Vl1 Grp 1 Hello out 192.168.1.10 Standby pri 120 vIP
192.168.1.1
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Standby: c/Active timer expired (unknown)
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Active router is local
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Standby router is unknown, was local
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Standby -> Active
*Mar 1 00:22:07.415: %HSRP-5-STATECHANGE: Vlan1 Grp 1 state Standby -> Active
*Mar 1 00:22:07.415: HSRP: Vl1 Redirect adv out, Active, active 1 passive 0
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Redundancy "VLANs-pares" state Standby -> Active
*Mar 1 00:22:07.415: HSRP: Vl1 Grp 1 Hello out 192.168.1.10 Active pri 120 vIP
192.168.1.1
192.168.1.1
*Mar 1 00:22:10.415: HSRP: Vl1 Grp 1 Redundancy group VLANs-pares state Active -> Active
192.168.1.1
*Mar 1 00:22:13.415: HSRP: Vl1 Grp 1 Redundancy group VLANs-pares state Active -> Active
192.168.1.1
192.168.1.1
192.168.1.1
192.168.1.1
192.168.1.1
192.168.1.1
3.10.2 Exemplo 2 – Roteador não Inicializa o HSRP

Vamos a mais um exemplo no qual o roteador HSRP está com problemas e não consegue subir
nem chegar a nenhum estado final.
Fev 11 09:00:42.623: %STANDBY-6-STATECHANGF. Standby: 49: Vlan70 state Standby ->

Active
Fev 11 09:00:56.011: %STANDBY-6-STATECHANGF. Standby: 49: Vlan70 state Active ->
Speak
Fev 11 09:01:03.011: %STANDBY-6-STATECHANGF. Standby: 49: Vlan70 state Speak ->
Standby
Fev 11 09:01:29.427: %STANDBY-6-STATECHANGF. Standby: 49: Vlan70 state Standby ->
Active
Fev 11 09:01:36.808: %STANDBY.6-STATECHANGF. Standby: 49: Vlan70 state Active ->
Speak

Fev 11 09:01:43.808: %STANDBY-6-STATECHANGF. Standby: 49: Vlan70 state Speak ->

Standby
Note nas saídas que o roteador HSRP pula de Standby para Ativo, depois Ativo para Speak,
Speak para Standby e assim prosseguindo em loop sem convergir para nenhum estado final.
Nesse exemplo podemos notar que o HSRP não está inicializando normalmente e nem trocando
as mensagens de hello padrões.
3.10.3 Exemplo 3 – Router HSRP Active com Preempt

Nesse exemplo vamos ver o que ocorre com as mensagens de debug quando um roteador
ativo, configurado com preempt e estava com problemas, volta a funcionar. Nesse exemplo o
roteador standby assumiu a rede e deve “devolver o posto de ativo” quando o roteador com
maior prioridade retornar.
O endereço atual do standby é 10.0.0.11 e do router ativo que está down é 10.0.0.10. O
endereço HSRP é 10.0.0.1. Todos os timers estão configurados no padrão. Veja a saída das
mensagens de debug abaixo.
10.0.0.1
*Mar 1 00:23:56.207: HSRP: Vl1 REDIRECT adv in, Passive, active 0, passive 1,
from 10.0.0.10
Nessa primeira mensagem o roteador standby recebe um hello de 10.0.0.10.
*Mar 1 00:23:56.211: HSRP: Vl1 API active virtual MAC 0000.0c07.ac0a found
*Mar 1 00:23:56.211: HSRP: Vl1 API active virtual MAC 0000.0c07.ac0a found
*Mar 1 00:23:56.211: HSRP: Vl1 REDIRECT adv in, Active, active 1, passive 1,
from 10.0.0.10
*Mar 1 00:23:56.211: HSRP: Vl1 Grp 10 Coup in 10.0.0.10 Listen pri 120 vIP
10.0.0.1
*Mar 1 00:23:56.211: HSRP: Vl1 Grp 10 Active: j/Coup rcvd from higher pri router
(120/10.0.0.10)
Depois com a troca de mensagens o roteador 10.0.0.11 nota que 10.0.0.10 tem prioridade 120
e é maior que a atualmente configurada nele.
*Mar 1 00:23:56.211: HSRP: Vl1 Grp 10 Active router is 10.0.0.10, was local
*Mar 1 00:23:56.211: HSRP: Vl1 Grp 10 Active -> Speak
*Mar 1 00:23:56.211: %HSRP-5-STATECHANGE: Vlan1 Grp 10 state Active -> Speak
O roteador 10.0.0.11 passa de ativo para Speak, pois ele não é mais a prioridade mais alta na
rede, agora o roteador configurado como ativo voltou e com certeza o preempt está
configurado nele, senão o roteador atual não deixaria de ser ativo.
*Mar 1 00:23:56.211: HSRP: Vl1 Redirect adv out, Passive, active 0 passive 1
*Mar 1 00:23:56.211: HSRP: Vl1 Grp 10 Redundancy "hsrp-Vl1-10" state Active ->
Speak
10.0.0.1
*Mar 1 00:23:56.215: HSRP: Vl1 REDIRECT adv in, Active, active 1, passive 0,
from 10.0.0.10
*Mar 1 00:23:56.215: HSRP: Vl1 Grp 10 Hello in 10.0.0.10 Active pri 120 vIP
10.0.0.1
10.0.0.1

10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
Note nas mensagens acima que o roteador 10.0.0.10 enviou as mensagens de hello e escutou a
rede, assim como 10.0.0.11 fez o mesmo, por isso 10.0.0.10 assume como ativo e na
sequência o timer de speak para standby finaliza e 10.0.0.11 assume como standby
oficialmente.
*Mar 1 00:24:06.211: HSRP: Vl1 Grp 10 Speak: d/Standby timer expired (unknown)
*Mar 1 00:24:06.211: HSRP: Vl1 Grp 10 Standby router is local
*Mar 1 00:24:06.211: HSRP: Vl1 Grp 10 Speak -> Standby
*Mar 1 00:24:06.211: %HSRP-5-STATECHANGE: Vlan1 Grp 10 state Speak -> Standby
*Mar 1 00:24:06.211: HSRP: Vl1 Grp 10 Redundancy "hsrp-Vl1-10" state Speak ->
Standby
Como já citado 10.0.0.11 assume como standby e na sequência somente hellos são trocados a
cada 3 segundos.
10.0.0.1
10.0.0.1
10.0.0.1
10.0.0.1
O debug pode ser cobrado na prova e basicamente essas são as principais situações que podem
ser cobradas. Utilize os debugs em seus laboratórios para acostumar com a sequência de
mensagens e reconhecer os padrões que estudamos nos exemplos.

4 Entendendo e Configurando o VRRP

O VRRP ou Virtual Router Redundancy Protocol é um protocol aberto que serve como
alternativa ao HSRP definido pela IETF na RFC 2338. Ele pode ser utilizado em roteadores e
switches L3 Cisco que precisam fazer FHRP com equipamentos de outros fabricantes.
O VRRP e o HSRP são tão parecidos que você precisa aprender apenas as diferenças de
nomenclatura entre os dois, por isso vamos estudar essas diferenças rapidamente nesse tópico
do capítulo 7.
O VRRP fornece redundância do gateway para um grupo de roteadores. O roteador ativo ou

active do HSRP é chamado de “virtual master router” ou roteador mestre no VRRP, já os
roteadores standby do HSRP são chamados de “backups” no VRRP, portanto eles ficam em
estado de backup (backup state) ao invés de ficar no estado de standby como estudamos para
o HSRP.
O “master router” é aquele com maior prioridade no grupo VRRP, a qual varia de 0 a 255,
porém os roteadores VRRP podem utilizar a faixa de 1 a 254. O valore padrão também é 100 no
VRRP.
O VRRP utiliza o endereço de multicast 224.0.0.18, porém não utiliza nem o UDP nem o TCP
para transmissão de mensagens, pois elas são montadas diretamente no pacote IP e
identificadas com o número de protocolo 112 no cabeçalho do pacote IP.
O virtual MAC utilizado pelo VRRP está no range de 00-00-5e-00-01-00 até 00-00-5e-00-01-FF,
sendo que seu formato é 00-00-5e-00-01-<num-VRRP-group> em hexadecimal. Por exemplo,
se o VRRP foi configurado no grupo 1 seu MAC virtual será 00-00-5e-00-01-01.
O suporte ao VRRP deve ser verificado antes do planejamento da sua configuração em

switches, pois nem todas as versões de Cisco IOS ou modelos de switches L3 suportam esse
recurso.
4.1 Configurações do VRRP
A configuração básica do VRRP é bem semelhante a que realizamos para o HSRP, veja a lista de
comandos abaixo.
 vrrp grupo priority prioridade  define a prioridade do roteador VRRP (padrão 100),
sendo que o maior valor será o master.
 vrrp grupo timers advertise [msec] valor  configura o tempo de anúncio do VRRP
(similar ao hello do HSRP). Padrão é 1 segundo.
 vrrp grupo timers learn  aprende os valores dos timers a partir do roteador VRRP
master.
 no vrrp grupo preempt  padrão do VRRP é utilizar o preemt e esse comando

desabilita o recurso.
 vrrp grupo preempt [delay segundos]  configura o delay para o roteador master
retomar sua função após um problema.
 vrrp group authentication palavra-chave  define a autenticação em texto claro.
 vrrp group ip endereço-IP [secondary]  configura o IP virtual dos roteadores

VRRP.

 show vrrp [brief]  comando para verificar o estado do VRRP
4.2 Exemplo de Configuração do VRRP
Vamos configurar o mesmo exemplo inicial do HSRP, mas agora com VRRP. Veja topologia
abaixo.
Switch-1:
interface vlan 1
ip address 192.168.1.10 255.255.255.0
vrrp 1 ip 192.168.1.1
! Configurando o grupo VRRP 1 com o endereço IP virtual 192.168.1.1
vrrp 1 priority 120
! Configurando a prioridade de R1 para 120 para que
! ele assuma o estado de mestre ou master
vrrp 1 authentication dltec123
! Configurando a autenticação do grupo VRRP 1 com a chave dltec123
Switch-2:
interface vlan 1
ip address 192.168.1.11 255.255.255.0
vrrp 1 ip 192.168.1.1
! Configurando o grupo VRRP 1 com o endereço IP virtual 192.168.1.1
! Vamos deixar a prioridade do switch-2 no padrão 100 para que
! ele fique no estado backup
vrrp 1 authentication dltec123
! Configurando a autenticação do grupo VRRP 1 com a chave dltec123
Note que um comando a mais foi inserido para definir uma autenticação simples entre os
roteadores utilizando a palavra chave dltec123 (vrrp 1 authentication dltec123).

Para verificar o estado do VRRP podemos utilizar o comando “show vrrp brief” ou “show
vrrp”. Veja saída dos comandos abaixo.
Switch-1#show vrrp brief

Interface Grp Pri Time Own Pre State Master addr Group addr
Vl1 1 120 3570 Y Master 192.168.10.10 192.168.10.1
R1#
Switch-2#sho vrrp brief

Interface Grp Pri Time Own Pre State Master addr Group addr
Vl1 1 100 3609 Y Backup 192.168.10.10 192.168.10.1
R2#
Note que agora a nomenclatura utilizada no comando não é mais Active/Standby, mas sim
Master para o ativo e Backup para o standby ou passivo.
Com o comando “show vrrp” abaixo podemos verificar o MAC virtual utilizado.
Switch-1#show vrrp
GigabitEthernet0/0 - Group 1
State is Master
Virtual IP address is 192.168.10.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Authentication text, string "dltec123"
Master Router is 192.168.10.10 (local), priority is 120
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

5 Entendendo e Configurando o GLBP

Os protocolos HSRP e VRRP tiveram seu desenvolvimento e lançamento anteriores ao GLBP
(Gateway Load Balancing Protocol). Ele não é suportado em todas as linhas de switches
Catalyst, assim como o VRRP, por isso antes de planejar a implementação verifique no
datasheet do protoduto se ele suporta e em que condições (tipos de módulo supervisor, versão
de IOS, modelo, etc.).
Isso se deve ao fato de que ele é um protocolo definido pela Cisco para suprir a necessidade de
um melhor balanceamento de cargas do que o realizado pelos anteriores, pois o fluxo de uma
sub-rede é quase que imprevisível e torna o HSRP e o VRRP mais difíceis para o administrador
de redes prever qual a melhor distribuição dessas sub-redes por roteador ou switch camada-3.
O GLBP faz o balanceamento de cargas por destino (padrão) utilizando uma arquitetura
ativo/ativo para encaminhamento dos pacotes, ou seja, você utiliza os dois roteadores
para envio de informações por isso o nome ativo/ativo sem a necessidade de fazer o
esquema mostrado de balanceamento por sub-redes do HSRP e VRRP.
A grande diferença do GLBP é que um roteador atua em um papel especial chamado Active
Virtual Gateway (AVG – Gateway Virtual Ativo). Os demais roteadores utilizam o mesmo
endereço IP virtual, porém cada um possui um MAC virtual próprio, sendo que o AVG pode
responder aos ARP Requests com um MAC virtual diferente para cada host solicitante.
Qual o resultado final desse tipo de operação? Alguns computadores enviarão informações para
o MAC virtual de um roteador e outros para o MAC virtual do segundo roteador, permitindo o
balanceamento de cargas por destino, conforme mencionado no início das explicações.
Os roteadores que fazem parte do GLBP e farão o encaminhamento dos pacotes são chamados
de forwarders ou encaminhadores, inclusive o próprio roteador escolhido como AVG pode
ser um dos encaminhadores.
Os roteadores forwarders podem ser chamados de AVF ou Active Virtual Forwarder.
Portanto, diferente dos protocolos da família FHRP anteriores, os computadores que estão
utilizando roteadores configurados via GLBP enviarão seus pacotes para um único endereço IP
virtual, porém cada host de rede receberá o MAC de destino de um dos dois roteadores
forwarders, conforme distribuição feita pelo AVG.
Por exemplo, temos os roteadores R1 e R2 configurados com o protocolo GLBP, onde R1 é o

AVG e forwarder e R2 é apenas forwarder. Quando o computador-1 enviar um pacote para o IP
virtual do GLBP ele receberá o VMAC-1 configurado em R1, porém quando o computador-2
enviar uma requisição ARP na sequência ele receberá o VMAC-2 configurado em R2. Veja a
figura a seguir com a ilustração sobre a operação do GLBP.

No exemplo da figura anterior os computadores A, B, C e D enviam quadros um após do outro,

portanto o AVG (R1) envia seu próprio VMAC-1 na resposta à requisição ARP do computador A.
Depois ele envia o VMAC-2 de R2 como resposta ao ARP Request do computador-B, na
sequência de novo seu VMAC-1 como resposta ao ARP Req do computador C e por último envia
o VMAC-2 como resposta à solicitação do roteador D. No final A e C estão enviando pacotes por
R1 (utilizando o VMAC-1) e B e D através de R2 (utilizando o VMAC-2).
Esse processo mostrado acima ilustra como o GLBP faz o balanceamento de cargas, porém
existe ainda o processo de assumir o tráfego do outro roteador caso ele caia. O GLBP troca
mensagens entre os roteadores para verificar se eles estão ativos, caso um forwarder falhe o
que estiver funcionando deve assumir o virtual MAC daquele que caiu para que o tráfego
continue normalmente e os usuários finais não percebem que ocorreu um problema na rede,
pois o GLBP também deve ser transparente para os usuários finais.
Por padrão o GLBP utiliza o endereço de multicast 224.0.0.102 para enviar suas mensagens de
hello a cada 3 segundos através da porta UDP 3222.
O roteador definido como Active Virtual Gateway (AVG) em um determinado grupo é quem
define o endereço MAC virtual que cada roteador do grupo irá utilizar. O formato segue o
padrão 0007.B400.xxyy, onde xx é o número do grupo que o GLBP foi configurado e yy é um
sequencial diferente para cada AFV, por exemplo 01, 02, 03, etc.
Se tomarmos como exemplo a topologia da figura anterior, o roteador R1 será escolhido como
AVG e será o primeiro forwarder do GLBP, já o roteador R2 será o segundo forwarder. Se o
grupo configurado for o número 1 teremos os seguintes MACs virtuais:
 Forwarder 1 e AVG será R1 com o MAC virtual 0007.B400.0101.

 Forwarder 2 será R2 com o MAC virtual 0007.B400.0102.
Você pode visualizar na tabela ARP dos hosts quem eles estão utilizando como gateway
(forwarder) e identificar o roteador que está sendo utilizado como forwarder se entender bem a
regrinha acima.
Um grupo GLBP pode ter até 4 AVFs, ou seja, quatro MACs virtuais ativos. Caso sejam
configurados mais de 4 gateways no grupo GLBP os dispositivos excedentes ficam como
Standby Virtual Forwarder (SVF), os quais podem ser utilizados em caso de falha de um dos
AVFs.
5.1 Configurações e Verificações Básicas do GLBP
A configuração básica do GLBP é bem parecida com a que realizamos para o HSRP e VRRP,
basta trocar o início do comando de “standby” para “glbp”. Veja o resumo de comandos abaixo.
 glbp grupo priority prioridade  no GLBP os grupos vão de 1 a 1023, sendo que a
prioridade pode variar entre 1 e 255, sendo que 100 é a prioridade padrão.
 glbp grupo preempt [delay minimum segundos]  o preempt do GLBP tem a

mesma função que nos outros dois protocolos que estudamos. Você pode também
definir um delay para o AVG assuma suas funções ao voltar da falha como a opção
delay.
 glbp grupo ip [end-IP [secondary]]  esse comando define o IP virtual que o GLBP
vai utilizar e deve ser o mesmo para todo grupo em uma mesma sub-rede.

 glbp group timers [msec] hellotime [msec] holdtime  o timer de hello é de 3

segundos, podendo variar de 1 a 60 segundos ou 50 a 60.000 milissegundos. O holdtime
padrão de 10 segundos, podendo variar até 180 segundos ou 180.000 milissegundos. O
valor mínimo recomendado do holdtime deve ser três vezes o hello configurado. Você
pode configurar esses valores apenas no AVG, pois se os AVFs não tiverem esse
comando explícito o AVG repassa essas configurações a eles.
 glbp grupo load-balancing [round-robin | weighted | host-dependent]  por

padrão o balanceamento de cargas entre os links do GLBP é feito através do “round-
robin”, ou seja, cada ARP Request recebe o MAC do próximo roteador AVF disponível,
quem responde e controla esse processo é o AVG. Já a opção “weighted” vai distribuir
o tráfego de acordo com a configuração do peso de cada interface, vamos aprender a
configurar mais para frente. Na opção “host-dependent” cada ARP Request recebe o
mesmo MAC de AVF como resposta (algumas aplicações precisam ser vinculadas sempre
ao mesmo MAC, se for o caso utilize essa opção).
 Os próximos comandos são utilizados no processo de weighting (definições de pesos

para as interfaces que serão estudadas posteriormente):
 track num-objeto interface tipo mod/num {line-protocol | ip routing}  esse

comando deve ser dado em modo de configuração global.
 glbp grupo weighting maximum [lower menor-valor] [upper maior-valor]
 glbp grupo weighting track num-objeto [decrement valor]
Existem alguns comandos diferentes que vamos estudar nas configurações avançadas do GLBP.
Na sequência vamos estudar as configurações básicas com dois roteadores GLBP, um AVG/AVF
e um AVF.
5.1.1 Exemplo de Configuração Básica do GLBP

Veja a seguir como fica a configuração da mesma topologia que utilizamos para o HSRP e VRRP
configurada com GLBP, porém agora para a VLAN 2.
Nesse exemplo o switch-1 será o AVG e AVF-1 e o switch-2 será o AVF-2, além disso, o switch-
1 deve voltar como ativo em caso de retorno de quedas (preemption).
Switch-1#show running-config
interface vlan 2
ip address 192.168.1.9 255.255.255.0
glbp 1 ip 192.168.1.1
glbp 1 priority 110
glbp 1 preempt
glbp 1 name GLBP-test
Switch-2#show running-config
interface vlan 2
ip address 192.168.1.129 255.255.255.0
glbp 1 ip 192.168.1.1
glbp 1 name GLBP-test

Para verificar as configurações podemos utilizar os comandos “show glbp brief” e “show
glbp”. Veja a saída dos comandos abaixo.
Switch-1#show glbp brief

Interface Grp Fwd Pri State Address Active router Standby router
Vl2 1 - 110 Active 192.168.1.1 local 192.168.1.129
Vl2 1 1 - Active 0007.b400.0101 local -
Vl2 1 2 - Listen 0007.b400.0102 192.168.1.129 -
Como o switch-1 está com a prioridade mais alta na configuração ele será o AVG e também
forwarder ou AVF. Essas informações são mostradas nas duas primeiras linhas do comando
respectivamente marcadas em azul (campo State como Active). Logo abaixo temos a linha
indicando o roteador que está apenas como forwarder (campo State como Listen).
Note que na primeira linha, a qual indica o AVG, temos a prioridade indicada como 110 (campo
Pri), o campo Active Router como local (o próprio switch-1) e o campo Standby router
apontando para o endereço do switch-2 192.168.1.129.
Agora note as diferenças na saída de switch-2 que está apenas como forwarder na saída do
comando abaixo. Ele mostra na primeira linha que sua prioridade é 100, o endereço IP virtual é
o mesmo de switch-1 192.168.1.1, porém o roteador ativo não está mais como local, pois
switch-2 não é mesmo o ativo. Quem está nesse estado é switch-1 e por isso seu IP é mostrado
nesse campo (Active router). Já no campo Standby aparece escrito local, pois switch-2 é um
roteador standby.
Switch-2#show glbp brief

Interface Grp Fwd Pri State Address Active router Standby router
Vl2 1 - 100 Standby 192.168.1.1 192.168.1.9 local
Vl2 1 1 - Listen 0007.b400.0101 192.168.1.9 -
Vl2 1 2 - Active 0007.b400.0102 local -
Agora vamos analisar o comando show glbp no switch-1. Podemos ver algumas opções que
analisamos anteriormente, por exemplo, o endereço IP virtual, quem são os membros do grupo
e informações dos forwarders 1 e 2 conforme destacado em azul.
Switch-1#show glbp
VLAN 1 - Group 1
State is Active
1 state change, last state change 00:09:29
Hello time 3 sec, hold time 10 sec
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is local
Standby is 192.168.1.129, priority 100 (expires in 8.800 sec)
Priority 110 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
IP redundancy name is "GLBP-test"
Group members:
ca00.2344.0008 (192.168.1.9) local
ca01.2344.0008 (192.168.1.129)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
MAC address is 0007.b400.0101 (default)

Owner ID is ca00.2344.0008
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is ca01.2344.0008
Redirection enabled, 597.760 sec remaining (maximum 600 sec)
Time to live: 14397.760 sec (maximum 14400 sec)
Active is 192.168.1.129 (primary), weighting 100 (expires in 9.440 sec)
5.2 Configurações Avançadas do GLBP
Nesse tópico vamos estudar duas configurações avançadas que podemos realizar no GLBP:
 Temporizadores de Redirect e Timeout
 Encaminhamento por Peso das Interfaces
5.1.1 Temporizadores de Redirect e Timeout

No HSRP e no VRRP quando o roteador ativo ou mestre falha simplesmente o standby ou
backup assume como ativo, simples assim. No GLBP se o roteador com maior prioridade ou
AVG falha, o roteador com a segunda maior prioridade assume como AVG e começa a
responder as solicitações MAC.
Mas o que o GLBP faz se um AVF ativo cai? Como o AVG trata esse problema se no GLBP
TODOS os roteadores podem ser AVFs e encaminhar quadros? Lembre-se que nesse caso vários
computadores poderiam ter feito requisições ARP e recebido o MAC do AVF que falhou.
No GLBP existe um parâmetro extra chamado “redirect timer” que por padrão dura 600
segundos (10 minutos). Quando um AVF falha o AVG assume o MAC do router GLBP que falhou
pelo tempo do “redirect timer”. O AVG também pode determinar que outro AVF assuma o MAC
do roteador que falhou.
Em conjunto com o redirect existe outro timer chamado “timeout” que tem a função de definir
quando os demais roteadores apagarão o MAC e as informações do AVG que falhou
definitivamente, ou seja, o AVF que falhou não tem mais chance de voltar a operação e deve
ser apagado em definitivo. Por padrão o timeout dura 14.400 segundos (4 horas). Veja abaixo
a sintaxe do comando.
Switch(config-if)#glbp grupo timers redirect valor-redirect valor-timeout

5.1.2 GLBP Weighting

O GLBP weighting é utilizado para determinar se um roteador pode atuar como AVF ou não
dinamicamente. Cada roteador recebe um valor máximo que vai de 1 a 254, quando as
interfaces monitoradas caem um valor de decremento é configurado para reduzir o valor do
weighting. Quando o peso cai abaixo de um valor especificado, o roteador não poderá mais ser
um AVF. Se o valor do peso sobe acima do valor mínimo especificado o roteador pode retomar
seu papel como AVF. Essa configuração tem basicamente a mesma função do tracking do HSRP.
Por padrão o peso máximo dos roteadores é 100. Para configurar o weighting devemos seguir
três passos básicos:
1. Definir a interface que será utilizada como referência para o tracking (será monitorada)
com o comando “track num-objeto interface tipo mod/num {line-protocol | ip
routing}” em modo de configuração global.
2. Definir o peso máximo e os limiares com o comando “glbp grupo weighting
maximum [lower menor-valor] [upper maior-valor]”.
3. Definir que tracking object (definido no passo 1) o GLBP deve utilizar para ajustar o peso
com o comando “glbp grupo weighting track num-objeto [decrement valor]”.
No exemplo abaixo o switch-1 está configurado para verificar ou fazer o “tracking” do estado da
interface giga 1/0/1, na sequência os limiares superiores e inferiores do weighting foram
configurados e o decremento em caso da interface monitorada cair será igual a 5.
track 2 interface gig 1/0/1 line-protocol

interface vlan 1
glbp 10 weighting 110 lower 95 upper 105
glbp 10 weighting track 2 decrement 5
5.1.3 Balanceamento de Cargas por Pesos Entre AVFs

Importante: Para essa configuração funcionar não podemos utilizar o “tracking” de interface
configurado no tópico anterior (4.2.2).
Até o momento utilizamos o mesmo peso entre os AVFs, ou seja, se temos três AVFs ativos, por
padrão cada ARP request recebido o AVG encaminha para o MAC de um dos AVFs do grupo,
seguindo o round Robin.
Mas podemos também ativar o balanceamento de cargas com pesos diferentes entre os
diversos AVFs utilizando o weighting, conforme abaixo:
1. Configure o load-balancing como weighting no AVG.
2. Configure o peso dentro de cada AVF com o comando “glbp grupo weighting peso”.
Veja exemplo de configuração abaixo onde o switch-1 será o AVG/AVF e os switches 2 e 3 serão
AVFs. O AVG suportará 50% do tráfego enquanto os switches 2 e 3 suportarão 30% do restante
do tráfego cada.
Switch-1:
interface vlan 1
ip address 10.0.0.1 255.255.255.0
glbp 1 ip 10.0.0.254
glbp 1 preempt
glbp 1 weighting 50
glbp 1 load-balancing weighted
Como o comando “glbp 1 load-balancing weighted” foi executado apenas no switch-1, caso
ele caia o switch-2 assume como AVG, porém utilizando round-robin.

Switch-2:
interface vlan 1
ip address 10.0.0.2 255.255.255.0
glbp 1 ip 10.0.0.254
glbp 1 priority 50
glbp 1 preempt
glbp 1 weighting 30
Switch-3:
interface vlan 1
ip address 10.0.0.3 255.255.255.0
glbp 1 ip 10.0.0.254
glbp 1 priority 25
glbp 1 preempt
glbp 1 weighting 20
Veja a saída do comando “show glbp” abaixo no switch-1 após a configuração.
Rack1R1#show glbp
VLAN 1 - Group 1
State is Active
2 state changes, last state change 03:12:05
Hello time 3 sec, hold time 10 sec
Redirect time 600 sec, forwarder time-out 14400 sec
Active is local
Standby is 10.0.0.2, priority 50 (expires in 8.936 sec) <-- Standby AVG
Priority 100 (default)
Weighting 50 (configured 50), thresholds: lower 1, upper 50
Load balancing: weighted
Group members:
ca00.0156.0000 (10.0.0.1) local
ca01.0156.0000 (10.0.0.2)
cc02.0156.0000 (10.0.0.3)
There are 3 forwarders (1 active)
Forwarder 1
State is Listen
MAC address is 0007.b400.7b01 (learnt)  Virtual MAC
Owner ID is ca01.0156.0000  Este é o switch-2
Arp replies sent: 1
Forwarder 2
State is Active  ativo é o switch-1
MAC address is 0007.b400.7b02 (default)
Owner ID is ca00.0156.0000  Este é o switch-1
Redirection enabled
Active is local, weighting 50
Arp replies sent: 1
Forwarder 3

State is Listen
MAC address is 0007.b400.7b03 (learnt)
Owner ID is cc02.0156.0000  Este é o switch-3
Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você
tenha domínio dos seguintes itens:
 Entender as opções de compartilhamento de links.

 Entender o conceito de topologias de alta disponibilidade.
 Entender o conceito de pontos únicos de falhas.
 Entender o conceito do FHRP e os protocolos HSRP, VRRP e GLBP.
 Entender e Configurar o HSRP e VRRP.
 Entender o conceito de Failover e Balanceamento de Cargas via HSRP.
 Ativar e verificar o HSRP e VRRP básicos.
 Entender, configurar e verificar o GLBP.

Capítulo 08 - Segurança no
Campus
estudar diversos riscos de
segurança em redes que
Objetivos do Capítulo
utilizam switches e como Ao final desse capítulo você terá estudado e
mitigá-los utilizando deverá compreender:
recursos disponíveis na  Funcionamento e mitigação do
linha de switches Cisco ataque de MAC address flooding.
Catalyst.  Como funciona e combate os
principais ataques à VLANs, tais
como VLAN hopping e ataques a
switches na mesma VLAN.
Riscos como MAC Address  Funcionamento e combate de
Table Overflow, diversos ataques de Spoofing: DHCP spoofing,
tipos de spoofing MAC spoofing, Address Resolution
(falsificações), ataques à Protocol (ARP) spoofing e ataques ao
Spanning Tree.
VLANs/Trunks e muito mais  Riscos diretos aos switches e como
serão estudados e combatê-los: ataques ao Cisco
aprenderemos como Discovery Protocol (CDP)
combatê-los. manipulation, Telnet e Secure Shell
(SSH).
Aproveitem bem o material e

bons estudos!

Sumário do Capítulo 9 Autenticação por Porta – IEEE 802.1X 235

9.1 Configurações da Autenticação via
1 Introdução a Segurança no Campus .. 205 802.1x ....................................................... 236
2 Mitigando Ataques Baseados em MAC 10 Espelhamento de Portas para

206 Monitoração .......................................... 238
2.1 MAC Address Flooding ..................... 206 10.1 Espelhamento de Portas - SPAN e
RSPAN 238
2.2 Port Security.................................... 207
10.2 RSPAN ou SPAN Remoto............... 240
2.3 Verificando o Port Security .............. 209
2.3.1 Como Tratar Portas Restritas, Protegidas 11 Recomendações Finais - Reforçando a
e em Error Disable ............................................ 211 Segurança dos Switches .......................... 243
3 Mitigando Ataques às VLANs e Trunks 12 Conclusão ..................................... 246
211
3.1 Switch Spoofing ............................... 211
3.2 802.1Q Double-Tagging e VLAN Hoping
212
3.3 Private VLANs .................................. 213
3.3.1 Configurando Private VLANs ............. 214
3.3.2 Exemplo de Configuração de Private
VLAN 215
4 Mitigando Ataques de Spoofing ........ 217

4.1 DHCP Snooping ................................ 217
4.1.1 Exemplo de Configuração do DHCP
Snooping 218
4.2 IP Spoofing - IP Source Guard ........... 219
4.2.1 Exemplo de Configuração ................. 220
4.3 ARP Spoofing – Dynamic ARP Inspection
220
4.3.1 Configurando o DAI ........................... 221
4.3.2 Exemplo de Configuração do DAI ...... 222
7 Configurando o Storm Control ........... 223

8 Controle de Acesso com Cisco IOS AAA
226
8.1 Protocolos TACAS+ e RADIUS ........... 226
8.2 Autenticação com servidor TACACS+ e
RADIUS...................................................... 229
8.2.1 Exemplo 2 - Utilizando a opção Group
Server 230
8.3 Autorização (Authorization) e Auditoria
(Accounting) Baseada em Servidor ............. 232
8.3.1 Configurando a Autorização
(Authorization) Baseada em Servidor ............... 232
8.3.2 Configurando a Auditoria (Accounting)
Baseada em Servidor ........................................ 234

1 Introdução a Segurança no Campus

Ainda hoje é dada muita atenção para segurança do perímetro através do uso de firewall, IPS,
IDS e mitigando ataques ao Layer 3 (camada de rede). Porém as redes LANs e Campus,
tipicamente Layer 2 precisam de tanta atenção quanto a borda de Internet, por exemplo, pois
sabemos que muitos ataques iniciam-se dentro das redes locais e são muito difíceis de mitigar.
Os ataques internos são realizados através da inserção de equipamentos intrusos (rogue

devices) ou comprometendo um dispositivo legítimo da rede. Equipamentos que não são da
rede (piratas ou intrusos) podem ser inseridos para fins escusos ou simplesmente ampliar o
número de portas físicas ou ter acesso sem fio. Equipamentos como roteadores Wireless ou
Access Points, switches de acesso ou Hubs são frequentemente utilizado por usuários para
garantir acesso a um laptop pessoal, tablet ou smarphone.
Esse tipo de situação é tratável com o uso de técnicas disponíveis nos switches.
Temos tipicamente quarto tipos de ataques que podem ser realizados contra redes que utilizam
switches (LANs ou Campus):
 Ataques baseados em Endereços MAC: MAC address-table flooding.

 Ataques às VLANs: VLAN hopping e ataques a dispositivos na mesma VLAN.
 Ataques de Spoofing (falsificações): DHCP snooping, IP spoofing, MAC spoofing,
Address Resolution Protocol (ARP) spoofing e ataques ao Spanning Tree.
 Ataques contra os Switches: manipulação do Cisco Discovery Protocol (CDP), ataques
ao Telnet e Secure Shell (SSH).

Nesse capítulo vamos estudar esses ataques e riscos de segurança, bem como utilizar recursos
do Cisco IOS para a família Catalyst que ajudam a prevenir e agir contra essas ameaças.
2 Mitigando Ataques Baseados em MAC

O ataque realizado utilizando o MAC mais comum é realizado através do flooding de endereços
causando o esgotamento da CAM table. Esse ataque pode ser mitigado utilizando os recursos
de port security e autenticação baseada em porta (em inglês, Port-based Authentication).
2.1 MAC Address Flooding
No ataque de flooding de endereços MAC o atacante lota a Content Addressable Memory (CAM)
do switch com endereços MAC falsos gerados aleatoriamente para transformar o switch em um
HUB.
Mas porque isso acontece? As tabelas MAC tem uma capacidade máxima, por isso quando a
tabela está cheia o switch não consegue mais aprender endereços legítimos e passa a fazer
flooding em todas as interfaces, permitindo que o atacante capture e “espione” os quadros
trafegados pelo switch utilizando um sniffer.
Além disso, o ataque tem outros efeitos colaterais, por exemplo, mais tráfego é gerado na LAN
e sobrecarregando os links e switches (memória e processamento elevados). Esse processo
pode ser utilizado para gerar o mesmo efeito em switches vizinhos e possibilitar que o atacante
capture e espione o tráfego deles, principalmente quando temos são utilizadas VLANs
estendidas.
Depois que o ataque cessa, as entradas falsas na CAM são apagadas quando o timer “aging
time” se esgota e tudo volta ao normal. Já o atacante vai realizar sua lição de casa analisando o
tráfego coletado atrás de informações relevantes, nomes de usuários, senhas em texto claro,
etc.
Esse ataque desmistifica a frase de que “nos switches não tem como fazer sniffing tão
facilmente como nos HUBs”, o processo é mais simples que você pensa. Softwares como Macof
e Wireshark realizam essa tarefa com extrema facilidade. Outra opção é o Dsniff do Linux que
já tem integrado o Macof e um sniffer.

Vamos estudar o Port security e a autenticação por porta para mitigar esse tipo de ataque,
lembrando que o primeiro deles é também assunto do CCNA R&S atual.
2.2 Port Security
O objetivo do port security é impedir que hosts não autorizados acessem a rede,
restringindo o número máximo de endereços MAC por porta do switch. Caso haja uma violação
da regra uma ação é tomada conforme configuração realizada.
Seguem alguns pontos importantes para reforçar a importância do uso do Port Security:
 Existem muitos ataques que são simples de executar na Camada 2.
 A necessidade de segurança na camada 2 tende a ser minimizada na maioria das
empresas.
 Pode proteger contra diversos tipos de ataques, tais como inundações MAC (MAC
Flooding) e dispositivos conectados em portas não permitidas, dentre outros.
Existem três tipos de configurações básicas do Port Security:

1. Endereços MAC seguros estáticos (Static) - Configurados manualmente dentro da
configuração de interface. Esse endereço é armazenado na tabela de endereços e se
outro computador for conectado a essa porta ela pode ser bloqueada, conforme
configuração.
2. Endereços MAC seguros dinâmicos (Dynamic) - Estes são configurados
dinamicamente, armazenados apenas na tabela de endereços na memória RAM e
removidos na reinicialização do switch. Esse é o padrão ativado pelos switches.
3. Endereços MAC seguro fixos (Sticky) - Podem ser aprendidos dinamicamente ou
configurados manualmente, são armazenados na tabela de endereços. Se os endereços
estão salvos na NVRAM, quando o switch é reinicializado, a interface não tem
necessidade de ser reconfigurada dinamicamente, mas para isso você deve especificar o
MAC.
Abaixo seguem os passos para configuração da segurança de portas:

1. Colocar a porta em modo de acesso (switchport mode access);
2. Habilitar port security (switchport port-security);
3. Definir o limite de endereços MAC na porta (padrão 1 – switchport port-security
maximum);
4. Especificar como o switch aprenderá os endereços MACs a serem protegidos (padrão
dinâmico);
5. Definir ações em caso de violação (padrão shutdown).
Sobre o item 1 é preciso ter em mente que podemos ativar o port security em um trunk desde
que ele seja configurado como estático com o comando "switchport mode trunk". Além disso,
somente portas L2 suportam o port security (comando switchport).
Com o comando “switchport port-security” o padrão de segurança é implementado com as

seguintes características:
 Limite de MACs aprendidos por porta 1.
 Modo de aprendizagem dos MACs dinâmico sem gravar o MAC aprendido na NVRAM, ou
seja, com um reload o switch apaga o MAC da tabela e terá que aprender novamente.
 Ação em caso de violação shutdown, ou seja, derruba a porta e coloca em estado e
“error-disable” ou desabilitada por erro para indicar que a porta está em shutdown por
um motivo diferente do tradicional.

Switch(config)#int fast 0/1

Switch(config-if)#switchport port-security ?
aging Port-security aging commands
mac-address Secure mac-address
maximum Max secure addrs
violation Security Violation Mode
<cr>
Switch(config-if)#switchport port-security
Switch(config-if)#
Em modo de Interface no switch teremos as seguintes opções para configurar o Port Security,
acompanhe abaixo.
Switch(config-if)#switchport port-security ?
aging Port-security aging commands
mac-address Secure mac-address
maximum Max secure addrs
violation Security Violation Mode
<cr>
Portanto, podemos alterar a maneira que os switches aprendem endereços MAC (opção mac-
address), qual o limite de endereços que a porta pode aprender (opção maximum) e
também qual ação o switch deve tomar se uma violação for detectada (opção violation), ou
seja, se o máximo de MACs seguros permitidos for ultrapassado.
A opção aging define o tempo que um MAC seguro ficará mantido na tabela quando há
aprendizado dinâmico, caso ele não seja detectado é apagado da tabela de MACs seguros, por
padrão ele é infinito.
Para alterar o padrão de aprendizado de dinâmico para sticky ou manual utilizamos o comando
“switchport port-security mac-address” definindo a seguir o padrão a ser configurado.
A primeira opção de configuração que vamos estudar é através do parâmetro “sticky” (em
português “pegajoso”), o comando fica “switchport port-security mac-address sticky”.
Esse parâmetro faz com que o switch escreva na NVRAM o endereço que ele aprendeu, com
isso mesmo que você reinicialize o switch ele manterá em sua configuração o MAC que ele
aprendeu quando você ativou o Port Security.
Com a opção “sticky” podemos definir um MAC estático, por exemplo, com o comando
switchport port-security mac-address sticky aaaa.bbbb.cccc”. Essa opção permite definir
um MAC específico para porta e mesmo assim ter um máximo de MACs seguros maior que um.
Você pode também definir manualmente o MAC digitando o endereço no formato H.H.H, por
exemplo, “switchport port-security mac-address aaaa.aaaa.aaaa”. Com esse comando o
switch considera que o host com o MAC aaaa.aaaa.aaaa está conectado na porta e o máximo
de MACS seguros para essa porta é definido para um automaticamente, ou seja, a contagem de
MACs é incrementada.
Por exemplo, com os comandos “switchport port-security” e “switchport port-security

mac-address aaaa.bbbb.cccc” em uma das portas do switch, se um computador com MAC
diferente de aaaa.bbbb.cccc se conectar à porta ela será colocada em “error-disable” e será
desabilitada, gerando uma mensagem de erro para a console e para um servidor SNMP, caso
tenha sido configurado.
A configuração da violação tem três padrões de ação no port security, veja a saída do comando
abaixo.

SW-DlteC(config-if)#switchport port-security violation ?

protect Security violation protect mode
restrict Security violation restrict mode
shutdown Security violation shutdown mode
O padrão é o shutdown, o qual desabilita a porta e coloca ela em um estado chamado “error-
disable” e gera um alarme para o gerenciamento via snmp trap e mensagem de syslog.
Se a violação estiver configurada como “protect” ou protegido, caso haja uma violação o
switch bloqueia os quadros dos hosts com os MACs que ultrapassaram o máximo permitido no
comando “switchport port-security maximum” e o switch continua operando normalmente
para os MACs permitidos, sem gerar avisos.
Na opção “restrict” ou “restringir” o switch faz a mesma operação do protect, porém envia
uma mensagem para o gerenciamento do switch avisando que o máximo de portas configurado
foi excedido via snmp trap e mensagem de syslog.
Conforme já citado, o máximo de MACs seguros padrão do port security é 1, porém pode ser
alterado com o comando “switchport port-security maximum”, por exemplo, se a porta
precisa ter até 3 MACs seguros podemos utilizar o comando “switchport port-security
maximum 3”.
2.3 Verificando o Port Security
No exemplo a seguir vamos analisar a configuração do port security para fazer com que no
máximo 2 MACs sejam aprendidos dinamicamente e em caso de violação a porta seja colocada
em shutdown.
Switch(config-if)#interface fast0/1
Switch(config-if)#switchport port-security
!
! comando habilita o port-security
!
Switch(config-if)#switchport port-security mac-address sticky
!
! comando para fazer o switch aprender dinamicamente o MAC do micro conectado
! na porta fast 0/1
!
Switch(config-if)#switchport port-security maximum 2
!
! define o número máximo de endereços permitidos em 2
! o valor 1 é o default
!
Switch(config-if)#switchport port-security violation shutdown
!
! A ação de violação foi definida para colocar a interface em shutdown,
! ou seja, caso um terceiro dispositivo tente se conectar nesta interface
! a porta será colocada em shutdown.
!
end

Para mostra informações sobre o Port Security podemos utilizar o comando “show port-
security”, conforme abaixo.
Switch#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
-------------------------------------------------------------------------------
Fa0/1 2 0 0 Shutdown
-------------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port) : 0
Max Addresses limit in System (excluding one mac per port) : 1024
No comando “show port-security” é possível as principais informações para realizar o

troubleshooting em switches com essa função habilitada, veja o que significa cada campo:
 Secure Port: número da porta com o port security habilitado.
 MaxSecureAddr: máximo de MACs que podem ser aprendidos pela porta (nesse
exemplo são 2).
 CurrentAddr: quantos endereços a porta aprendeu (nesse exemplo a porta ainda não
aprendeu nenhum endereço).
 SecurityViolation: quantas violações de segurança aconteceram na porta (nesse
exemplo nenhuma violação de segurança aconteceu).
 Security Action: qual a ação de segurança configurada na porta (nesse caso é
shutdown).
Caso uma violação seja detectada com o modo de operação “shutdown” a porta entra em “error
disable”. Para voltar a porta em operação é preciso tirar o computador que causou a violação e
em modo de interface dar “shut” e depois “no shut” respectivamente.
O comando “show port-security interface fast 0/x” mostra informações mais detalhadas do
port security, veja um exemplo abaixo onde estão mostradas informações referentes à porta 19
do switch (fast 0/19). Com esse comando temos todas as informações do comando anterior,
porém com o detalhamento específico da porta 0/19.
SW-DlteC#show port-security interface fast0/19

Port Security : Enabled -> Indica se o port security está habilitado
Port Status : Secure-up -> Indica se a porta está protegida
Violation Mode : Shutdown -> Tipo de ação de violação configurada
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled -> Indica se existe MAC estático seguro
Maximum MAC Addresses : 1 -> Número máximo de MACs aprendidos
Total MAC Addresses : 1 -> Número de MACs aprendidos
Configured MAC Addresses : 0 -> Número de MACs estáticos configurados
Sticky MAC Addresses : 0 -> Número de MACs gravados na NVRAM
Last Source Address:Vlan : 001d.7060.d31b:30 -> Último MAC aprendido
Security Violation Count : 0 -> Quantidade de violações ocorridas
SW-DlteC#
Perceba acima que no campo “Last Source Address:Vlan” é mostrado o último MAC
aprendido com a VLAN a qual ele pertence, nesse exemplo é o 001d.7060.d31b que está na
VLAN 30.
Outro detalhe interessante é que se estivermos utilizando os modos de violação shutdown ou

restrict o campo de contagem de violações (Security Violation Count) será incrementado,
mas no caso do protect esse campo não é incrementado.

2.3.1 Como Tratar Portas Restritas, Protegidas e em Error Disable

Se uma porta ultrapassou o número de MACs permitidos quando utilizamos as opções restrict
ou protect você precisará limpar o endereço MAC aprendido para o host específico possa utilizar
aquela porta do switch. Para limpar os endereços MAC específicos ou o cachê completo de
endereços aprendidos pela porta utilizamos o comando:
Switch#clear port-security dynamic [address mac-addr | interface type mod/num]
Se a opção “shutdown” está configurada como ação de violação a porta será desativada e
entrará em error-disable. Para verificar se existem portas nessa condição podemos utilizar o
comando “show interfaces status erro-disable”, se aparecer o motivo no campo Reason
“psecure-violation” é sinal que houve a violação de segurança.
Você pode confirmar com os comandos show estudados anteriormente. Nessa condição a porta
pode ser reestabelecida automaticamente via configuração prévia ou então você pode desativar
e reativar a porta para reabilitá-la.

Switch(config-if)#shutdown
Se o número de MACs conectados à porta continuar excedendo o máximo ela voltará a error-
disable, nesse caso você precisará analisar o que está acontecendo e porque existem hosts em
excesso conectados a ela.
Lembre-se que é possível também configurar o processo automático de volta da porta com o
comando estudado no capítulo-2: "Switch(config)#errdisable recovery cause psecure-
violation". Assim a porta em error disable pelo Port Security vai automaticamente tentar voltar
ao normal sem intervenção da equipe de suporte de redes em 5 minutos (300 segundos) por
padrão, diminuindo a sobrecarga de trabalho.
3 Mitigando Ataques às VLANs e Trunks

Ataques às VLANs e trunks incluem o VLAN hopping, onde um host tenta acessar outra VLAN
diferente, o “switch spoofing”, onde um switch não legítimo da rede é colocado para dar
acesso às VLANs, e através do “802.1Q double-tagging”.
Vamos estudar nesse tópico como esses ataques podem ocorrer e também como mitigá-los
para evitar que nossa rede sofra esses tipos de ataque.
3.1 Switch Spoofing
O Switch spoofing é realizado com um switch que não pertence à rede ou então um computador
configurado para negociar um link de trunk entre ele e o switch legítimo da rede. Com isso o
atacante tem acesso às demais VLANs da rede e pode enviar pacotes a qualquer usuário ou
servidor da LAN ou Campus.
Lembre-se que por padrão os switches negociam dinamicamente o trunking utilizando o

Dynamic Trunking Protocol (DTP). Por isso um computador ou switch pode utilizar o DTP
para negociar o estabelecimento do trunk e ter acesso a todas as VLANs, que por padrão
também é o padrão de configuração dos trunks: “todas as VLANs são permitidas”.
Portanto, para mitigar esse ataque basta desabilitar o DTP nas portas do switch. As portas de
trunk devem ser configuradas com o comando “switchport nonegotiate” e as portas de
acesso com o “switchport mode access”. Adicionalmente você pode desativar o CDP nas

portas de acesso e desativar (shutdown) portas não utilizadas. Desativar o CDP depende do seu
projeto, pois com telefones IP Cisco o CDP normalmente é necessário.
Abaixo segue a configuração da porta de acesso sem o DTP ativado:
Switch(config)#interface fast 0/1 - 24

Switch(config-if)#no cdp enable
Switch(config-if)#spanning-tree portfast
Switch(config-if)#spanning-tree bpduguard enable
Para verificar se o DTP está ativo utilize o comando “show interfaces switchport”, veja
abaixo.
SW8#show interfaces f1/0/48 switchport

Name: Fa1/0/48
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
###Saídas omitidas ###
3.2 802.1Q Double-Tagging e VLAN Hoping
O ataque de double-tagging é possível porque os trunks 802.1Q não marcam os quadros da

VLAN. Nesse tipo de ataque o computador do atacante negocia um trunk com o switch e depois
gera quadros com dois tags 802.1Q.
O primeiro tag tem o número da VLAN nativa configurada na porta de trunk port e o segundo
tag é igual ao número da VLAN do host que ele deseja atacar, conforme figura a seguir, onde a
VLAN nativa é a 100 e o host alvo do ataque está na VLAN 200.
O primeiro switch que recebe o quadro marcado tira a primeira tag 802.1Q tag e encaminha
para o próximo switch vizinho. O próximo switch que recebe o quadro retira a tag e repassa a
informação para o host de destino que é o alvo do ataque.
Portanto com o double-tagging o atacante realize o ataque de VLAN hopping.
Esse ataque muitas vezes funciona mesmo que a porta não seja trunk se a porta do atacante
estiver mapeada na VLAN nativa.

Para mitigar esse ataque podemos seguir os seguintes passos:

1. Configurar a VLAN nativa diferente do VLAN-ID 1 e não utilizada.
2. Filtrar a VLAN nativa em ambas as pontas do switch.
Veja exemplo de configuração a seguir.
Switch(config-vlan)#name nativa-fake
Switch(config)#interface gigabitethernet 1/0/1
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport trunk native vlan 171
Switch(config-if)#switchport trunk allowed vlan remove 171
Switch(config-if)#switchport nonegotiate
Outra alternativa é fazer com que a VLAN nativa também receba marcação com tag 802.1Q,
fazendo com que o tráfego de controle também seja marcado, utilizando o comando:
Switch(config)#vlan dot1q tag native
3.3 Private VLANs
As Private VLANs (PVLAN) permite que grandes empresas ou provedores de serviço isolem
usuários em domínios multiacesso isolados. Utilizar uma VLAN para cada grupo não é escalável,
por exemplo, o número máximo de VLANs dos switches limitaria o número de clientes que um
ISP poderia ter. Outro ponto é que cada VLAN necessita de uma sub-rede IP própria, o que
seria outro ponto limitante para redes com grandes volumes de usuários.
As PVLANs conseguem dividir uma VLAN primária em diversas VLANs secundárias, permitindo
que você isole grupos de portas dentro da mesma VLAN. Existem dois tipos de VLANs
secundárias:
 Community VLANs: As portas podem se comunicar umas com as outras dentro da
mesma “community VLAN” e com a VLAN primária.
 Isolated VLANs: As portas não podem se comunicar umas com as outras, somente
com a VLAN primária.

Portanto um host em uma VLAN secundária pode conversar com a VLAN primária, mas não
podem se comunicar com outros hosts nas VLANs secundárias.
Além disso, as portas nas VLANs secundárias podem ser configuradas como:
 Host: portas que conectam hosts em VLANs isoladas ou comunitárias.
 Promiscuous: se comunica com todas as portas, normalmente conecta a um gateway
ou firewall.
Para configurar PVLANs é preciso desativar o VTP ou configurá-lo como transparente, pois o
VTP não suporta PVLANs.
3.3.1 Configurando Private VLANs

Basicamente utilizar private VLANs é definir uma VLAN primária e várias VLANs secundárias que
podem ser do tipo isolada (isolated) ou comunitária (community). Além disso, se as portas
conectam hosts ou trunks (promiscuous).
Abaixo segue a lista de comandos de configuração das private VLANs:
 Configurando VLANs secundárias.

 vlan vlan-id  entrar em modo de configuração da VLAN que será configurada
como secundária.
 private-vlan {community | isolated }  define a VLAN como private VLAN
secundária se utilizarmos as opções community ou isolated.
 Configurando a VLAN primária.

 vlan primary-vlan-id  entrar no modo de configuração da VLAN primária.
 private-vlan primary  define a VLAN como primária.
 private-vlan association { lista-de-vlans-secundárias | add lista-de-vlans-
sec | remove lista-vlans-sec  associa VLANs secundárias a uma primária. As
opções ADD e REMOVE são utilizadas para administrar a lista adicionando e
removendo VLANs da lista respectivamente.
 Associando portas às private VLANs. Esses comandos são aplicados em modo de

configuração de interface.
 switchport mode private-vlan {host | promiscuous}  configure a porta
como host (para VLANs secundárias community ou isolated) ou promiscuous para
portas para o entroncamento com o gateway.
 Switchport private-vlan host-association primary_vlan_ID
secondary_vlan_ID  faz a associação de portas configuradas como host com
sua VLAN primária e secundária.
 switchport private-vlan mapping vlan-ID-primária lista-vlans-secundárias |
{add lista-vlans-sec} | {remove lista-vlans-sec}  faz a associação de
portas promíscuas com sua VLAN primária e as secundárias.
O último comando pode ser utilizado dentro das interfaces em redes puramente, pois quando
temos ambientes L2 normalmente o trunk é a porta promíscua e quem faz o roteamento
InterVLAN é um gateway externo.
Podemos também ter ambientes com switches L3 utilizando SVIs (interface L3) para
roteamento entre VLANs, nesse caso o comando vai ser dado na própria SVI, porém ele varia
um pouco conforme abaixo.
Switch(config-if)#private-vlan mapping {lista-vlan-sec | add lista-vlan-sec |

remove lista-vlan-sec}
Veja exemplo a seguir onde a VLAN 40 deve ser isolada, a VLAN 50 comunitária e a VLAN 200
será a primária e está vinculada a uma SVI.

Switch(config-vlan)#private-vlan isolated
Switch(config-vlan)#private-vlan community
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#private-vlan association 40,50
Switch(config-if)#ip address 192.168.199.1 255.255.255.0
Switch(config-if)#private-vlan mapping 40,50
Para verificar as configurações utilize os comandos abaixo:
 show interfaces interface switchport

 show interfaces private-vlan mapping
3.3.2 Exemplo de Configuração de Private VLAN

Vamos configurar as private VLANs conforme topologia abaixo.
Nesta configuração, a sub-rede 192.168.20.0/24 será segmentada em 3 VLANs privadas,

conforme requisitos abaixo:
 VLAN 10: PVLAN primária das PVLANs 20, 30 e 40.
 VLAN 20: PVLAN secundária do tipo isolada conectada ao host 192.168.20.1 (Fa0/1).
 VLAN 30: PVLAN secundária do tipo comunidade conectada aos hosts 192.168.20.30
(Fa0/3) e 192.168.20.40 (Fa0/2).
 VLAN 40: PVLAN secundária do tipo comunidade conectada aos hosts 192.168.20.10
Fa0/5) e 192.168.20.20 (Fa0/4).
 O Gateway da rede (192.168.20.254) está conectado a porta promíscua Fa0/24.

Configuração do switch:
Switch(config)#vtp mode transparent

Setting device to VTP Transparent mode for VLANS.
Switch(config)#
Switch(config-vlan)#private-vlan isolated
Switch(config)#!
Switch(config)#!
Switch(config)#!
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#private-vlan association add 20,30,40
Switch(config)#!
Switch(config)#interface FastEthernet 0/1
Switch(config-if)#switchport private-vlan host-association 10 20
Switch(config-if)#switchport mode private-vlan host
Switch(config)#!
Switch(config)#interface range FastEthernet 0/2 - 3
Switch(config-if-range)#switchport private-vlan host-association 10 30
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#exit
Switch(config)#!
Switch(config)#interface range FastEthernet 0/4 - 5
Switch(config-if-range)#switchport private-vlan host-association 10 40
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#exit
Switch(config)#!
Switch(config)#interface FastEthernet 0/24
Switch(config-if)#switchport private-vlan mapping 10 20,30,40
Switch(config-if)#switchport mode private-vlan promiscuous

4 Mitigando Ataques de Spoofing

Algumas vezes usuários mal intencionados podem tentar enganar os switches e usuários da
rede utilizando seus computadores como gateway. Essa técnica permite a realização de
diversos tipos de ataque de Man-in-the-middle (MITM), possibilitando que o atacante copie
ou altere informações dos pacotes originais antes de encaminhá-los ao destino.
Ataques de Spoofing incluem o DHCP snooping, MAC address spoofing e ARP spoofing.
Nesse tópico vamos estudar esses ataques e aprender a configurar recursos para mitigá-los.
4.1 DHCP Snooping
O DHCP fornece aos clientes informações como gateway e servidor DNS, portanto se um
atacante conseguir colocar um servidor DHCP próprio na rede e responder à requisições de
clientes ele pode passar o endereço de sua própria máquina como gateway e também
responder às consultas de DNS pelos clientes que eventualmente caiam nessa armadilha.
Após inserir um servidor DHCP falso, o atacante é capaz de fazer ataques do tipo “man-in-the-
middle”, pois todo tráfego “off-net” (para outras sub-redes) passarão por ele. Além disso, ele
pode configurar um servidor DNS falso em seu computador e hospedar páginas falsificadas
(clonadas) para capturar usuários e senhas dos clientes de rede sem que eles percebam nada.
Esse tipo de ataque pode colocar não só os dados corporativos em risco, mas também os dados
pessoais dos usuários de rede que podem eventualmente utilizar os recursos para acessar
páginas de Internet Banking ou acessar contas de e-mail, redes sociais e demais recursos
pessoais de Internet que são liberados pela empresa.
O DHCP snooping é o recurso para mitigar esse tipo de ataque.
Com o DHCP snooping apenas portas de uplink conectadas a um servidor DHCP autorizado são
permitidas a enviar todos os tipos de mensagem DHCP, essas portas são chamadas de “trusted
ports” ou portas confiáveis. As demais portas do switch são “untrusted” ou não confiáveis e
podem apenas enviar “DHCP requests” e mensagens típicas de clientes, por isso se uma
mensagem de “DHCP offer”, por exemplo, for encontrada em uma porta “untrusted” ela é
desligada (shutdown).

As configurações do DHCP snooping são configuradas em modo de configuração global e as

portas confiáveis ou “trusted ports” são configuradas individualmente em modo de configuração
de interface. Veja os comandos abaixo.
1. Ative o DHCP Snooping em modo de configuração global.
Switch(config)#ip dhcp snooping
2. Identifique as VLANs que o DHCP snooping deve atuar. Podemos definir por VLAN ou por
faixas de VLANs, aí o primeiro número de VLAN é o inicial e na sequência entramos com
o valor final da faixa.
Switch(config)#ip dhcp snooping vlan num-vlan [num-vlan-final-da-faixa]
3. Entre na interface confiável e a configure como trusted.
Switch(config-if)#ip dhcp snooping trust
4. Você pode definir opcionalmente a taxa de requisições DHCP por segundo que pode ser
recebido nas interfaces untrusteds, por padrão esse valor é ilimitado e pode ser
configurado de 1 a 1024 pacotes por segundo.
Switch(config-if)#ip dhcp snooping limit rate pacotes-por-seg
Para verificar as configurações utilize o comando abaixo.
Switch#show ip dhcp snooping [binding]
Outra opção é configurar o switch para enviar a opção DHCP número 82. Essa opção é utilizada
para enviar informações do DHCP Relay definidas na RFC 3046.
Com essa configuração quando uma requisição DHCP é recebida em uma porta untrusted o
switch insere seu endereço MAC e o port-ID no campo de opção 82 do DHCP. Assim quando o
servidor DHCP remoto responder ele repassa essa mesma informação para o switch poder
identificar exatamente o cliente que enviou essa solicitação.
Veja a configuração abaixo que é feita em modo de configuração global.
Switch(config)#ip dhcp snooping information option
4.1.1 Exemplo de Configuração do DHCP Snooping
Nesse exemplo as interfaces Fast Ethernet 1/0/3 até 1/0/6 são portas de acesso alocadas na
VLAN 10 e consideradas untrusted. Essas portas precisam ter a taxa de pacotes DHCP limitada
a 5 pacotes por segundo. O DHCP server está conectado à porta de uplink Gigabit Ethernet
1/0/1. Veja a configuração abaixo.
Switch(config)#ip dhcp snooping

Switch(config)#ip dhcp snooping vlan 10
Switch(config)#interface range fastethernet 1/0/3 - 6
Switch(config-if-range)#ip dhcp snooping limit rate 5
Switch(config-if-range)#interface gigabitethernet 1/0/1
Switch(config-if)#ip dhcp snooping trust
A seguir veja a saída do comando “show ip dhcp snooping”.

Switch#show ip dhcp snooping

Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled

circuit-id default format: vlan-mod-port
remote-id: 000f.f72c.c600 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)

----------------------- ------- ------------ ----------------
FastEthernet1/0/3 no no 5
Custom circuit-ids:
Custom circuit-ids:
Custom circuit-ids:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
Custom circuit-ids:
GigabitEthernet1/0/1 yes yes unlimited
Custom circuit-ids:
Switch#
4.2 IP Spoofing - IP Source Guard
O IP Source Guard trata de um problema muito difícil de mitigar que é a falsificação do

endereço IP de origem, ou seja, um host utilizando o endereço de outro host válido da rede
para tentar disfarçar sua origem ou realizar ataques de negação de serviço.
O IP Source Guard rastreia os endereços IP dos hosts conectados em cada porta e impede que
tráfego originado por outro endereço que não o original entre na porta. O rastreio ou “tracking”
pode ser feito através do endereço IP ou do conjunto IP e MAC.
Para aprender os endereços nas portas o Source Guard utiliza as informações aprendidas pelo
DHCP Snooping. O teste se o IP de origem é válido é feito através dos endereços IP aprendidos
pelo DHCP Snooping, com essa informação o switch cria uma ACL dinâmica deixando passar
apenas o endereço de origem aprendido na porta. Outra opção é validar o MAC de origem pelos
endereços aprendidos pelo DHCP Snooping, porém a filtragem é feita através do port-security.
Portanto, para ativar o IP Source Guard é preciso ativar o DHCP Snooping estudado no tópico
anterior. Se for preciso validar também endereços MAC de origem será necessário ativar o port-
security. Veja os comandos de configuração abaixo.

Switch(config-if)#ip verify source [port-security]
Com o comando “ip verify source” o switch faz a verificação apenas do IP de origem, sendo
que se for preciso verificar IP e MAC insira a opção “port-security” no final.

É possível também configurar o mapeamento estático para hosts que não utilizam o DHCP com
o comando abaixo.
Switch(config)#ip source binding endereço-MAC vlan num-vlan end-IP interface tipo

mod/num
Para verificar as configurações utilize os comandos abaixo.
 Switch#show ip verify source [interface tipo mod/num]  utilizado para verificar

o status do ip source guard.
 Switch#show ip source binding [ip-address] [mac-address] [dhcp-snooping |

static] [interface type mod/num] [vlan vlan-id]  utilizado para verificar
informações mais específicas do banco de dados de endereços IP de origem.
4.2.1 Exemplo de Configuração
Vamos ativar o source guard nas portas configuradas no tópico anterior para o DHCP Snooping.
Veja abaixo.
Switch(config)#int ran f1/0/3 - 6

Switch(config-if-range)#switchport port-security
Switch(config-if-range)#switchport port-security maximum 3
Switch(config-if-range)#ip verify source port-security
Switch(config-if-range)#end
Switch#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- ----------------- ----
Fa1/0/3 ip-mac inactive-no-snooping-vlan
Switch#
Note que o comando indica as portas configuradas, que o tipo de filtragem é por IP e MAC
(Filter-type / ip-mac).
4.3 ARP Spoofing – Dynamic ARP Inspection
No ataque de ARP spoofing um atacante envia mensagens de “gratuitous ARP” (ARPs

gratuitos – enviados sem ninguém solicitar) com o endereço IP do default gateway local
vinculado ao seu próprio endereço MAC. Esse ataque á também conhecido como ARP
Poisoning.
Os equipamentos da rede local que recebem essas mensagens sobrescrevem a informação do

gateway que está correta com o endereço MAC falsificado em sua tabela ARP. Com isso todo
tráfego off-net ao invés de ser enviado para o gateway é enviado para o computador do
atacante, possibilitando um ataque de “Man-in-the-Middle” (MITM).
Esse ataque pode ser utilizado para outros endereços de rede também além do gateway, por
exemplo, o atacante pode enviar ARPs gratuitos vinculando o endereço de um servidor interno
ao seu MAC para que os clientes ao invés de acessar o serviço legítimo acabam caindo em uma
armadilha e acessando o computador do atacante que possui um “clone” da aplicação, por
exemplo.

Para não ser detectado o atacante copia ou altera os pacotes e encaminha para o destino
correto, fazendo com que o host comprometido nem suspeite que sofreu um ataque ou teve
seu tráfego desviado.
O Dynamic ARP Inspection (DAI) atua em conjunto com o DHCP snooping para mitigar o
ARP spoofing. O DAÍ também define portas trusted e untrusted, ou seja, confiáveis e não
confiáveis respectivamente. Nas portas configuradas como untrusted as mensagens ARP são
interceptadas e o endereço IP/MAC é comparado com o banco de dados de informações do
DHCP snooping, se as informações batem o tráfego é encaminhado, senão o switch faz a
filtragem.
4.3.1 Configurando o DAI

Devemos configurar as portas de acesso como untrusted e as portas que conectam outros
switches de distribuição ou a um roteador devem ser portas configuradas como trusted.
Para ativar o DAI podemos fazer por VLAN específica ou para uma faixa de VLANs, na sequência
devemos definir as interfaces trusted. Veja os comandos abaixo.
Switch(config)#ip arp inspection vlan faixa-de-vlans
Por padrão todas as portas do switch são consideradas não confiáveis, por isso precisamos
definir as portas que conectam outros switches ou o roteador que será o gateway como trusted.
Switch(config)#interface tipo mód/num

Switch(config-if)#ip arp inspection trust
Para os hosts configurados estaticamente e não via DHCP você deverá listá-los em uma ARP
ACL permitindo o tráfego, pois eles não serão encontrados na base do DHCP Snooping, veja a
configuração abaixo.
Switch(config)#arp access-list nome-da-ACL

Switch(config-acl)#permit ip host end-IP-do-Host mac host MAC-do-host [log]
Switch(config-acl)#exit
Na sequência aplique a ARP access list ao DAI conforme comando abaixo.
Switch(config)#ip arp inspection filter nome-da-ACL vlan faixa-de-VLANs [static]
Quando uma requisição ARP é recebida ela é verificada se existe alguma entrada na ARP ACL e
se não tem o switch verifica se tem alguma entrada na tabela do DHCP Snooping. A opção
“static” faz com que se não exista entrada na ACL o switch não verifique mais o banco de dados
do DHCP Snooping, gerando um “deny implícito” no final da ACL.
Outra configuração possível é estender as validações no DAÍ, pois por padrão ele valida o MAC
e IP de origem dentro da mensagem do ARP (ARP Reply), porém não valida o MAC do quadro
ethernet onde a mensagem do ARP está encapsulada. Para fazer essa verificação extra utilize o
comando abaixo.
Switch(config)#ip arp inspection validate {[src-mac] [dst-mac] [ip]}
É preciso configurar pelo menos uma das opções listadas abaixo:

 src-mac: verifica se o MAC de origem do quadro Ethernet é igual ao MAC contido no
ARP reply.
 dst-mac: verifica se o MAC de destino do quadro Ethernet é igual ao endereço MAC de
destino da mensagem de ARP reply.

 Ip: verifica o endereço IP de quem enviou o ARP request e também se o endereço de

quem enviou a requisição é o mesmo contido nos ARP replies.
Para verificar as informações do DAÍ utilize o “show ip arp inspection”.
4.3.2 Exemplo de Configuração do DAI

Nesse exemplo vamos fazer com que todas as portas do switch de acesso configuradas na VLAN
10 sejam untrusted a não ser a interface gig1/0/1 que é o uplink conectado aos switches de
distribuição. Além disso, vamos configurar um mapeamento estático do servidor 192.168.1.10
com MAC 0006.10ba.baca. Veja as configurações abaixo.
Switch(config)#ip arp inspection vlan 10

Switch(config)#arp access-list CCNP-SWITCH-DAI
Switch(config-acl)#permit ip host 192.168.1.10 mac host 0006.10ba.baca
Switch(config-acl)#exit
Switch(config)#ip arp inspection filter CCNP-SWITCH-DAI vlan 10
Switch(config)#interface gigabitethernet 1/0/1
Switch(config-if)#ip arp inspection trust
Switch#
Switch#sho ip arp inspection
Source Mac Validation : Disabled

Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL

---- ------------- --------- --------- ----------
10 Enabled Inactive CCNP-SWITCH-DAI No
Vlan ACL Logging DHCP Logging Probe Logging

---- ----------- ------------ -------------
10 Deny Deny Off
Vlan Forwarded Dropped DHCP Drops ACL Drops

---- --------- ------- ---------- ---------
10 0 0 0 0
Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
10 0 0 0 0
Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data

---- ----------------- ---------------------- ---------------------
Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data

---- ----------------- ---------------------- ---------------------
10 0 0 0
Switch#

7 Configurando o Storm Control

Pacotes de broadcast e multicast são comuns em todas as redes e utilizados por diversos
protocolos, tais como ARP, DHCP, DNS e outros, porém um nível excessivo desse tipo de
tráfego pode causar degradação na rede podendo diminuir o tráfego para os usuários ou até
parar completamente a transmissão impossibilitando o uso dos recursos de rede.
Esse excesso de broadcasts pode ser causado por problemas de configuração, placas de rede
defeituosas ou por um ataque de negação de serviço ou DoS que esteja sendo realizado por um
atacante.
No caso de um ataque, pacotes de multicast e/ou broadcast são enviados excessivamente em

uma mesma VLAN, o que causará um uso excessivo da CPU do switch levando a 100% do
processamento, podendo prejudicar a performance substancialmente e até mesmo, no limiar,
causar a interrupção dos serviços de rede.
Nos switches da Cisco existe a facilidade do “storm control” ou controle de tempestade de

broadcast, o qual monitora os quadros de broadcast e quando o nível atingir um limiar pré-
determinado o switch bloqueará o tráfego para evitar a sobrecarga em sua CPU. Essa
monitoração é efetuada em um determinado período de tempo, se entre esse período o tráfego
excede o limiar ele é bloqueado, conforme mostrado a seguir.

A configuração do storm control é bastante simples, precisando definir o nível de uso pelo
broadcast ou multicast que será considerando como limiar de corte e a ação que a interface
deve tomar, as quais podem ser shutdown (desligar a interface) ou trap (informar a gerência).
Vamos ao passo a passo a seguir.
1) Entre em modo de config global.
2) Entre nas interfaces de 5 a 10 simultaneamente e defina o limiar do storm control para 70%
tanto para broadcast como para multicast e unicast (comando storm-control broadcast level).
Switch(config)#int range fast 0/5 - 10

Switch(config-if-range)#storm-control ?
action Action to take for storm-control
broadcast Broadcast address storm control
multicast Multicast address storm control
unicast Unicast address storm control
Switch(config-if-range)#storm-control broadcast ?
level Set storm suppression level on this interface
Switch(config-if-range)#storm-control broadcast level ?

pps Enter suppression level in packets per second
<0 - 100> Enter Integer part of level as percentage of bandwidth
Switch(config-if-range)#storm-control broadcast level 70

Switch(config-if-range)#storm-control multicast level 70
Switch(config-if-range)#storm-control unicast level 70
Note que no comando acima você poderia definir pela porcentagem de uso da Interface ou pelo
PPS ou pacotes por segundo. Quando utilizado o PPS você deve definir um parâmetro de
máximo e quanto o tráfego deve cair para ser encaminhado novamente, por exemplo, “storm-
control broadcast level pps 2k 1k”, se o nível de broadcast chegar a 2000 pps ele será
bloqueado até que caia a 1000 pps. Se você não definir nada ele deve cair a 2000 pps para
voltar a ser encaminhado.
3) Opcionalmente defina a ação que o switch irá tomar caso o limiar definido no item anterior
seja excedido. Por padrão os quadros que excedem a taxa definida são descartados, mas você
pode configurar para desativar a interface (opção shutdown) ou avisar o SNMP via trap (opção
trap).
Switch(config-if-range)#storm-control action shutdown

Switch(config-if-range)#end
Switch#
4) Verifique o estado do storm control com o comando “show storm-control”.
Switch#show storm-control
Interface Filter State Trap State Upper Lower Current Traps Sent
--------- ------------- ------------- ------- ------- ------- ----------
Fa0/1 inactive inactive 100.00% 100.00% N/A 0
Fa0/5 Forwarding inactive 70.00% 70.00% 0.00% 0
... Saída omitida...

A ativação do storm control é feita por interface, porém com o comando range você pode ativar
em várias interfaces simultaneamente. No exemplo vamos configurar as interfaces de 5 a 10
com limiar de corte para o switch em 70% da utilização da interface para quadros de
Broadcast, Multicast ou Unicast e caso o limiar seja excedido a interface será desligada.
Vamos a mais um exemplo de configuração com opções diferentes. Neste exemplo, foram
configurados três níveis distintos de supressão de tempestade, usando três diferentes tipos de
medições. No primeiro foi definido o nível de controle unicast tempestade a 80,5%. No
segundo, o nível de controle de tempestade multicast foi definido para 3000 bits por segundo,
com um nível de supressão de queda de 1.000 bits por segundo.
Switch1(config)#interface gigabitethernet 0/4

Switch1(config-if)#storm-control unicast level 80.5
Switch1(config-if)#storm-control multicast level bps 3k 1k
Switch1(config-if)#storm-control broadcast level pps 100k
Switch1(config-if)#storm-control action shutdown
Isso significa que o tráfego deve cair abaixo de 1.000 bits por segundo para ser encaminhado
novamente. Se você não definir um nível de supressão de queda, o nível de supressão de
queda é definido como 3000 bits por segundo. E por último o nível de broadcast foi criado
usando 100.000 pacotes por segundo.
Dica prática: quando o storm control é ativado em um EtherChannel a configuração é

replicada para as interfaces físicas, pois não é possível configurar o storm control
individualmente por interface física que compõe o EtherChannel lógico.

8 Controle de Acesso com Cisco IOS AAA

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. Veja imagem abaixo com um esquema do
processo de autenticação via servidor externo AAA.
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.
2. 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.
3. 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, porém 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.
8.1 Protocolos TACAS+ e RADIUS
O protocolo RADIUS (Remote Authentication Dial-In User Service) hoje faz parte dos padrões
da IETF e 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.
Na figura a seguir você pode verificar as etapas de autenticação para acesso remoto em um
roteador utilizando o RADIUS.
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.
Na figura a seguir você pode verificar o mesmo processo para acesso remoto em um roteador
utilizando agora o TACACS+ como protocolo de autenticação.

Portanto, ambos TACACS + e RADIUS são protocolos de autenticação, porém cada um suporta
diferentes recursos e funcionalidades.
Escolher entre o TACACS + ou RADIUS depende das necessidades da organização. Por

exemplo, um grande provedor de acesso pode selecionar RADIUS porque suporta um billing
detalhado (contabilidade) necessárias para o faturamento dos usuários. Já uma organização
com vários grupos de usuários pode preferir utilizar o TACACS +, porque possibilita a
implementação de políticas de autorização que pode ser aplicada por usuário ou por grupo. Veja
na tabela a seguir um resumo da comparação entre o TACACS+ e o RADIUS.

8.2 Autenticação com servidor TACACS+ e RADIUS
Para configurar a autenticação baseada em servidores com TACACS+ ou RADIUS o processo é

semelhante, basta seguir os 4 passos básicos abaixo:
1. Habilitar o AAA (aaa new-model)

2. Especificar o endereço IP do servidor de autenticação externo
3. Configurar a chave secreta
4. Configurar a autenticação para usar um servidor RADIUS ou TACACS + (aqui podemos
configurar a redundância para autenticação)
Vamos mostrar um exemplo de configuração conforme figura a seguir onde existem dois
servidores:
1. Servidor TACACS+ (ACS) com IP 172.16.41.151

2. Servidor RADIUS (ACS) com IP 172.16.41.186
A primeira opção para login será o TACACS+, a segunda o RADIUS e a terceira o usuário local
case-sensitive. Veja a configuração abaixo.
R2#conf t
R2(config)#username dltec secret dltec123
R2(config)#aaa new-model
R2(config)#tacacs-server host 172.16.41.151 single-connection
R2(config)#tacacs-server key CHAVE-TACACS
R2(config)#radius-server host 172.16.41.186
R2(config)#radius-server key CHAVE-RADIUS
R2(config)#aaa authentication login ADMIN group tacacs+ group radius local-case
R2(config)#line vty 0 15
R2(config-line)#login authentication ADMIN
R2(config-line)#
Portanto para o TACACS+ o comando “tacacs-server host” define o IP do servidor ACS que
está suportando o serviço do TACACS. O subcomando single-connection colocado no final
evita que a sessão seja fechada e aberta toda vez que haja um novo acesso, ficando uma
conexão aberta sempre para melhorar a performance da conexão. Já o comando “tacacs-
server key” define a senha para acesso ao servidor.

O mesmo princípio serve para o RADIUS, porém para o RADIUS não existe o subcomando
“single-connection”, pois ele trabalha com UDP que não é orientado a conexão.
O comando para definir o método de autenticação foi o mesmo utilizado para o AAA local,
sendo que o início do comando é o “aaa authentication login ADMIN”, logo após definidos os
métodos:
1. Primeiro via TACACS+ com o group tacacs+

2. Segundo via RADIUS com o group radius
3. Terceiro via usuário/senha locais com o local-case (distingue letras maiúsculas e
minúsculas no usuário) que é o fallback caso o TACACS+ e o RADIUS fiquem
indisponíveis para que o administrador consiga logar com um usuário local.
Com a configuração realizada o usuário que tentar se logar no roteador primeiro vai ser
encaminha para um servidor TACACS+ com endereço 172.16.41.151, caso esse servidor esteja
indisponível o roteador tentará com o Servidor RADIUS (ACS) com IP 172.16.41.186 e caso
esse servidor também esteja "fora do ar" ele tentará buscar correspondência no banco de
dados local que são os comandos "username" como fallback.
O comando "login authentication ADMIN" aplicado na line VTY vincula a lista de métodos de
autenticação criada a autenticação do Telnet/SSH feita via VTY "amarrando" todo processo de
autenticação com o AAA.
Você também pode utilizar as opções local e none para autenticação. A opção local permite
login com usuário local para fallback sem distinguir maiúsculo e minúsculo como na local-case.
Já a opção none não pede autenticação nenhuma. Veja exemplo abaixo e tente dizer como
será o login na console e VTY. Que usuários e senhas serão pedidos? (Responda sozinho!!!
Resposta na próxima página)
username cisco secret cisco !

! line vty 0 15
aaa new-model login authentication login
! password linepass
aaa authentication login login local line console 0
aaa authentication loging no-auth none login authentication no-auth
Resposta da pergunta da página anterior:

 VTY: utilizará para o login o usuário local (comando username) cisco com a senha cisco,
conforme lista de método de autenticação nomeada como "login".
 Console: não solicitará nenhum usuário e senha, pois está com a lista de métodos
chamada no-auth que tem a opção "none" que não exige autenticação.
Em Cisco IOSs mais novos você pode receber a mensagem "This cli will be deprecated soon.
Use new server cli", isso porque existe uma nova forma de configurar os servidores, veja
exemplo abaixo do TACACS+ no novo padrão.
tacacs server AUTH

address ipv4 172.16.41.151
key CHAVE-TACACS
Lembre-se mais uma vez que mostramos um exemplo de configuração como adendo, porém a
prova irá cobrar o conceito de AAA, TACACS+ e RADIUS.
8.2.1 Exemplo 2 - Utilizando a opção Group Server

Se houver mais de um servidor AAA externo, o que é muito comum para ter redundância, você
pode utilizar a opção de configurar um grupo de servidores ao invés de listar apenas um
servidor como mostrado anteriormente.

Para isso é preciso configurar os hosts como fizemos no exemplo anterior e depois criar um
"group server", veja os comandos abaixo.
Switch(config)#radius-server host { hostname | ip-do-servidor } [ key-string ]

Switch(config)#tacacs-server host { hostname | ip-do-servidor } [ key-string ]
Switch(config)#aaa group server { radius | tacacs+ } nome-do-grupo
Switch(config-sg)#server ip-do-servidor
Para uso do hostname ao invés do IP do servidor AAA remoto é preciso que o switch ou
roteador tenha um endereço de DNS (ip name-server) e o comando "ip domain-lookup"
ativado, pois ele precisará resolver o nome do servidor (hostname) antes de autenticar.
Vamos ao exemplo abaixo onde vamos ter na rede dois servidores Cisco ACS com TACACS+ por
questões de redundância, sendo que o endereço dos servidores são 192.168.1.9 e
192.168.1.10 ambos utilizando a chave dltec123. O desafio aqui é simples, analise a
configuração e descreva como será a autenticação via VTY e o que vai acontecer em caso de
falha dos servidores externos.
Switch(config)#aaa new-model
Switch(config)#username dltec password dltec123
Switch(config)#tacacs-server host 192.168.10.9 key dltec123
Switch(config)#tacacs-server host 192.168.10.10 key dltec123
Switch(config)#aaa group server tacacs+ grupo-tacacs
Switch(config-sg)#server 192.168.10.9
Switch(config-sg)#server 192.168.10.10
Switch(config-sg)#exit
Switch(config)#aaa authentication login auth-tacacs group grupo-tacacs local
Switch(config)#line vty 0 15
Switch(config-line)#login authentication auth-tacacs
Switch(config-line)#end
Switch#
Resolva sozinho e a resposta está na próxima página!

Resposta da pergunta da página anterior:

 A autenticação será feita conforme lista chamada auth-tacacs que define o grupo de
servidores TACACS+ configurados no group server chamado "grupo-tacacs" utilizando.
 Se o servidor 192.168.1.9 e 192.168.1.10 não responderem às solicitações a base de
dados de usuário local será utilizada como fallback.
8.3 Autorização (Authorization) e Auditoria (Accounting) Baseada em Servidor
Após a autenticação do usuário, o AAA pode controlar também tanto em um roteador como
para um switch quais os comandos que um 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.
O protocolo TACACS + permite a separação entre a autenticação e autorização. Um roteador ou

switch pode ser configurado para restringir o usuário de executar determinados comandos após
a autenticação. A autorização pode ser configurada para o modo de caracteres (autorização
exec) e em modo pacote (autorização de rede). Já o RADIUS não separa a autenticação do
processo de autorização, eles acabam fazendo parte do mesmo pacote de facilidade de
configuração.
Outro aspecto importante da autorização é a capacidade de controlar o acesso a serviços

específicos. Controlando o acesso aos comandos de configuração simplifica a infraestrutura de
segurança em redes corporativas de grande porte.
TACACS + por padrão estabelece uma nova sessão TCP para cada solicitação de autorização,
que pode gerar atraso quando o usuário digitar os comandos. O Cisco Secure ACS (Access
Control Server) suporta sessões TCP persistentes para melhorar o desempenho desse serviço.
8.3.1 Configurando a Autorização (Authorization) Baseada em Servidor

Para configurar a autorização no roteador Cisco você deve utilizar o comando “aaa authorization
{network | exec | commands level} {default | list-name} method1...[method4]”.
Vamos agora analisar cada parte do comando. Primeiro vamos começar com as opções de
serviços que podemos autorizar:
R1(config)#aaa authorization ?
auth-proxy For Authentication Proxy Services
cache For AAA cache configuration
commands For exec (shell) commands.
config-commands For configuration mode commands.
configuration For downloading configurations from AAA server
console For enabling console authorization
exec For starting an exec (shell).
ipmobile For Mobile IP services.
network For network services. (PPP, SLIP, ARAP)
reverse-access For reverse access connections
template Enable template authorization
As três opções mais utilizadas são:
Commands: autoriza em nível de comandos EXEC

Exec: para iniciar o modo privilegiado EXEC
Network: para serviços de rede (PPP, SLIP, ARAP)
Após definido o que você deseja autorizar você pode criar uma lista de métodos, similar ao
capítulo anterior, ou então utilizar a padrão ou default, conforme saída do comando a seguir.

R1(config)#aaa authorization exec ?

WORD Named authorization list.
default The default authorization list.
Vamos fazer uma lista de método default, onde as lines e interfaces serão configuradas por
padrão nessa lista de autorização, conforme abaixo.
R1(config)#aaa authorization exec default ?

group Use server-group.
if-authenticated Succeed if user has authenticated.
local Use local database.
none No authorization (always succeeds).
Dentro de uma lista (default ou criada pelo usuário) você pode ter ela definida por um grupo, if-
authenticated, local ou none. Para configurar com um servidor externo ACS ou qualquer outro
tipo, seja TACACS+ ou RADIUS, entre com a opção group e escolha uma lista, radius ou
tacacs+.
R1(config)#aaa authorization exec default group ?

WORD Server-group name
radius Use list of all Radius hosts.
tacacs+ Use list of all Tacacs+ hosts.
Agora a configuração está finalizada para o tacacs+. Veja abaixo.
R1(config)#aaa authorization exec default group tacacs+

R1(config)#
Assim como na autenticação, na autorização também podemos ter redundância com até 4
métodos.
Veja a seguir mais um exemplo utilizando o conceito de autenticação e autorização baseados

em servidor. Analise a configuração mostrada.
Router(config)#aaa new-model
Router(config)#aaa authentication login VIEW_AUTHEN group tacacs+
Router(config)#aaa authorization commands 15 VIEW_AUTHOR group tacacs+
Router(config)#line con 0
Router(config-line)#login authentication VIEW_AUTHEN
Router(config-line)#authorization commands 15 VIEW_AUTHOR
Router(config)#line vty 0 4
Router(config-line)#login authentication VIEW_AUTHEN
Router(config-line)#authorization commands 15 VIEW_AUTHOR
No exemplo anterior criamos um método para autenticação e um para autorização definidos
pelo usuário. Esses métodos direcionam o usuário para um servidor TACACS+, onde tanto a
autenticação como a autorização deverão ser autenticadas e autorizadas por esse servidor.

8.3.2 Configurando a Auditoria (Accounting) Baseada em Servidor

Para a configuração da Auditoria ou Accounting no AAA com um servidor externo ou um Cisco
Secure ACS você deve utilizar o comando “aaa accounting { network | exec | connection}
{default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4]”.
O objetivo da auditoria no AAA é que o roteador ou switch envie dados sobre cada comando
executado pelo usuário durante uma sessão. Com este recurso, é possível identificar e controlar
todas as atividades de configuração e monitoramento efetuadas no roteador por usuário
cadastrado, tendo um nível de controle eficaz em caso de problemas de segurança ou
auditorias futuras.
Seguindo os mesmos preceitos para “Method Lists”, as seguintes “Method Lists” estão
disponíveis para a auditoria:
 Network: Informa detalhes sobre todas as sessões PPP, SLIP ou ARAP, inclusive
fornecendo contadores sobre pacotes e bytes.
 EXEC: Fornece informações sobre todas as sessões de usuários no access server.
 Commands: Fornece informações sobre todos os comandos digitados no EXEC mode,
incluindo os comandos inseridos no global configuration mode.
 Connection: Fornece informações sobre todas as conexões inbound e outbound feitas
para o access server, incluindo telnet, local-area transport (LAT), TN3270, packet
assembler/disassembler (PAD), e rlogin.
 System: Provê informações sobre os eventos do sistema.
 Resource: Provê registros “start” e “stop” para todas as chamadas por onde a
autenticação do usuário foi bem sucedida. Além disto, informa os registros “stop” para
as chamadas cujas autenticações não foram bem sucedidas.
Os métodos que estão disponíveis para a auditoria (accounting) são TACACS+ e RADIUS. Veja
ao lado um exemplo de configuração da auditoria colocando o TACACS+ como método principal
e o RADIUS como reserva. Vamos coletar informações sobre sessões estabelecidas via rede
(network) e sobre as sessões de usuários (EXEC).
O parâmetro “start-stop” é o trigger ou gatilho que dispara o registro ou gravação na base
sobre a ação do usuário. Aqui todo início e fim gerará um registro na base da auditoria. Veja
exemplo a seguir.
R1(config)#aaa accounting network default start-stop group tacacs+ group radius

R1(config)#aaa accounting exec default start-stop group tacacs+ group radius
Os seguintes comandos poderão ser utilizados para monitorarmos o accouting: show

accounting, debug aaa accounting.

9 Autenticação por Porta – IEEE 802.1X

O padrão aberto IEEE 802.1x combinado com o AAA possibilita implementar autenticação por
porta de switch para os computadores (chamados de cliente ou client) antes que eles possam
acessar a LAN.
A autenticação por porta pode ser utilizado em conjunto com o port security para permitir que
apenas endereços MAC permitidos possam acessar as portas dos switches e enviar tráfego
através da LAN.
O processo exige que o computador tenha um cliente 802.1X instalado, caso ele tenha e o
switch não tem o 802.1X ativado em suas portas o computador abandona o processo e acessa a
rede normalmente. Por outro lado, quando o switch tem o 802.1X ativado e o computador não
tem um cliente instalado ele não vai conseguir acessar a rede e ficará bloqueado.
Quando um computador se conecta a um switch configurado com autenticação 802.1x os

seguintes passos ocorrem até que ele possa acessar a rede:
1. A porta entra em um estado não autorizado (unauthorized state), permitindo apenas

tráfego 802.1x EAP através da LAN (EAPOL - Extensible Authentication Protocol over
LANs).
2. O cliente se conecta à porta e na sequência o switch solicita autenticação ou o cliente
envia quadros EAPOL para iniciar o processo de autenticação.
3. O switch envia as informações sobre a autenticação recebidas do cliente para um
servidor RADIUS, o qual fará a verificação dos dados para autenticar ou não o acesso
através daquela porta do switch.
4. Se a autenticação teve sucesso a porta passa para o estado de autorizada (authorized
state) e o tráfego pode ser enviado normalmente pela LAN.
Se o servidor não reconhecer as informações de autenticação a porta não sobe e volta ao

estado de não autorizada. Após a autenticação o switch pode manter a conexão permanente ou
o administrador pode configurar um tempo máximo de conexão, forçando ao cliente
reautenticar de tempos em tempos. Todo esse processo ocorre em camada-2.

9.1 Configurações da Autenticação via 802.1x
A configuração do 802.1X envolve um servidor externo RADUIS para fazer a validação das
credenciais do usuário, porém essa configuração do servidor não faz parte do conteúdo do
curso. Vamos aqui estudar as configurações necessárias no switch e considerar que o servidor
está presente e devidamente configurado. Veja os comandos necessários a seguir.
 SW(config)#aaa new-model  ativa o AAA no switch. Esse comando influencia as

configurações do Telnet e SSH necessitando configurar um usuário e senha local no
switch para acesso remoto.
 SW(config)#radius-server host {hostname | endereço-IP} [key chave-do-

radius]  define os dados do servidor RADUIS que será utilizado na autenticação.
 SW(config)#aaa authentication dot1x default group radius  cria uma lista de

método AAA padrão que diz para utilizar na autenticação 802.1x o servidor RADIUS
configurado no comando anterior.
 SW(config)#dot1x system-auth-control  ativa a autenticação 802.1x globalmente

no switch.
 SW(config-if)#dot1x port-control [auto | force-authorized | force-

unauthorized]  ativa a autenticação 802.1x na interface do switch e define o estado
padrão da porta. Podemos ter os seguintes estados padrões:
o Force-authorized: esse é o estado padrão e permite que qualquer cliente
sempre seja autorizado sem necessidade de autenticação.
o Force-unauthorized: força a porta a ficar sempre não autorizada e o cliente
não conseguirá trafegar dados por essa porta.
o Auto: a porta usa o 802.1X e se o cliente for autorizado ele pode trafegar dados,
ou seja, a porta passa de não autorizada para autorizada. O cliente deve suportar
802.1X.
 SW(config-if)#dot1x host-mode multi-host  comando opcional que pode ser

utilizado para permitir que vários hosts se conectem à mesma porta utilizando 802.1X.
 show dot1x [all]  comando utilizado para verificar a autenticação 802.1x.
Vamos a um exemplo de configuração de um switch Catalyst 3750 de 48 portas onde os

clientes serão conectados das portas fast1/0/1 a fast1/0/20. Todos os clientes que devem
suportar autenticação 802.1X e será permitido apenas um host por porta. O servidor
autenticador RADIUS tem o endereço 192.168.1.100 e utiliza a chave (key) “d1t3c123”. Veja
os comandos abaixo.
Switch(config)#aaa new-model
Switch(config)#radius-server host 192.168.1.100 key d1t3c123
Switch(config)#aaa authentication dot1x default group radius
Switch(config)#dot1x system-auth-control
Switch(config)#interface range FastEthernet1/0/1 - 20
Switch(config-if)#dot1x port-control auto
Switch#
Switch#show dot1x
Sysauthcontrol Enabled
Dot1x Protocol Version 3
Sswitch#show dot1x all
Sysauthcontrol Enabled

Dot1x Protocol Version 3
Dot1x Info for FastEthernet1/0/1

-----------------------------------
PAE = AUTHENTICATOR
PortControl = AUTO
ControlDirection = Both
HostMode = SINGLE_HOST
QuietPeriod = 60
ServerTimeout = 0
SuppTimeout = 30
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
Dot1x Info for FastEthernet1/0/2

-----------------------------------
PAE = AUTHENTICATOR
PortControl = AUTO
ControlDirection = Both
HostMode = SINGLE_HOST
QuietPeriod = 60
ServerTimeout = 0
SuppTimeout = 30
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
###Saídas Omitidas###

10 Espelhamento de Portas para Monitoração
10.1 Espelhamento de Portas - SPAN e RSPAN
O SPAN – Switched Port Analyzer - também conhecido como Port Mirroring ou Port
Monitoring é a capacidade de espelhar o tráfego de uma porta (ou portas, ou VLAN) para outra.
Não confunda o SPAM de e-mails com o port SPAN ou espelhamento de portas, pois são
conceitos totalmente diferentes!
Cuidado ao utilizar o SPAN e o RSPAN, pois se o tráfego a ser monitorado for muito alto você
pode causar o aumento do uso do processamento e/ou memória do ou dos switches
participantes dessa monitoração, podendo até gerar indisponibilidade na rede.
Entre outras aplicações, esta funcionalidade é muito utilizada em conjunto com equipamentos
de análise de rede, que deve receber o tráfego espelhado. Veja a figura a seguir, onde vamos
monitorar o tráfego das portas onde os computadores A e B estão conectados utilizando um
sniffer.
Vamos analisar os comandos na prática com duas situações, no primeiro exemplo vamos
monitorar uma porta e na segunda todo o tráfego de uma VLAN. O tráfego gerado na porta fast
0/24 será espelhado na porta 0/1, onde pode ser conectado um analisador de protocolos ou um
IDS, por exemplo, para verificar questões de segurança ou troubleshooting.
S1(config)#monitor session 1 source interface fast 0/24

S1(config)#monitor session 1 destination interface fast 0/1 encapsulation
replicate
No segundo exemplo vamos monitorar todo o tráfego da VLAN 10 através da porta 0/24. A
opção both indica que será monitorado transmissão (tx) e recepção (rx), você poderia
especificar uma direção específica para monitorar. A opção "encapsulate replicate" pode ou
não ser utilizada, ela permite capturar informações de marcação (VLAN tagging) ou pacotes de
protocolos de camada-2, como BPDUs, por exemplo.
S1(config)#monitor session 2 source vlan 10 both

S1(config)#monitor session 2 destination interface FastEthernet 0/24
Note que em ambos os casos o comando source define a origem, o que será monitorado, e o
destination define a porta que será utilizada para realizar a monitoração ou espelhamento.
Com o comando “show monitor session numero” você pode verificar o status da
monitoração.

Um exemplo prático de uso do SPAN é na colocação de um IDS (Intrusion Detection System) na

rede para mitigar riscos de segurança vindos de uma rede externa, onde o tráfego a ser
analisado deve ser espelhado para a porta onde o IDS será conectado. Veja a figura a seguir.
É importante saber que por padrão a interface de destino do SPAN transmite apenas o tráfego
espelhado, ou seja, tráfego enviado para a interface de destino simplesmente é descartado.
Normalmente esse tráfego em apenas uma via (one-way traffic) é o suficiente para os
analisadores de rede para a captura e análise dos pacotes, porém se for preciso que o
analisador envie informações na rede é preciso configurar o comportamento padrão do SPAN
incluindo no comando a opção "ingress { dot1q vlan vlan-id | isl | untagged vlan vlan-id }".
Veja o exemplo abaixo onde foi configurada a sessão de SPAN 2 para monitorar somente o
tráfego recebido na porta Giga0/1 e enviar na porta de destino Giga0/2 com o mesmo tipo de
encapsulamento recebido na porta de origem. Além disso, foi ativado o encaminhamento de
quadros de entrada com protocolo de encapsulamento IEEE 802.1Q e VLAN 6 como VLAN
padrão de entrada.
Switch(config)#monitor session 2 source gigabitethernet0/1 rx

Switch(config)#monitor session 2 destination interface gigabitethernet0/2
encapsulation replicate ingress dot1q vlan 6
Switch(config)#
Como a interface de destino do SPAN não tem vínculo com nenhum encapsulamento
precisamos definir como esse tráfego será tratado, a opção dot1Q define que estamos
utilizando, porém se o trunk for ISL devemos utilizar a opção "isl" ou se não houver
encapsulamento de trunk utilizamos a opção "untagged" seguido da VLAN para onde o tráfego
será encaminhado, conforme mostrado no exemplo.
Se a porta de origem monitorada pelo SPAN for um trunk podemos filtrar VLANs específicas
para deixar passar apenas as informações das VLANs que realmente devem ser monitoradas
com o comando:
Switch(config)# monitor session num-sessão filter vlan vlan-range
Lembre-se que ao ativar o SPAN o STP é desativado na porta de destino, o que permite
minitorar BPDUs, porém também gera a possibilidade de loops. Por isso nunca conecte uma
sessão de SPAN de destino em uma porta de rede ativa, se for preciso monitorar portas
cruzando switches utilize o RSPAN (próximo tópico).

10.2 RSPAN ou SPAN Remoto
O RSPAN ou SPAN Remoto tem todas as características do SPAN, porém permite a monitoração
de portas de origem e destino distribuídas através de vários switches, permitindo a monitoração
de qualquer porta de destino localizada na VLAN de RSPAN.
Na prática permite ao administrador monitorar o tráfego em um switch usando uma porta de

destino localizada em outro switch. Veja os exemplos das figuras a seguir.
Na figura acima temos o mesmo exemplo visto no SPAN anteriormente, porém com o IDS
localizado em um ponto único da rede e analisando o tráfego remoto que pode vir de outros
switches dentro da VLAN definida para RSPAN.

Para configurar o RSPAN todos os switches que participarão deverão ter a mesma VLAN de
monitoração configurada e devem suportar o RSPAN. Acompanhe o exemplo de configuração a
seguir de acordo com a topologia.
Switch1(config)#vlan 250
Switch1(config-vlan)#remote-span
Switch1(config-vlan)#exit
O mesmo deve ser realizado no ou nos switches remotos e essa VLAN terá que atravessar a
rede. Depois de criada e definida a VLAN de monitoração, defina o tráfego a ser monitorado no
switch remoto.
Switch1(config)#monitor session 1 source interface fastethernet0/1 both

Switch1(config)#monitor session 1 destination remote vlan 250
Agora no switch de monitoração defina a porta que será utilizada o IDS, Sniffer ou qualquer
outro aparelho de monitoração, mas lembre de criar a VLAN de monitoração antes de definir a
monitoração remota para ser a fast 0/9.
Switch2(config)#vlan 250
Switch2(config-vlan)#remote-span
Switch2(config-vlan)#exit
Switch2(config)#monitor session 1 source remote vlan 250
Switch2(config)#monitor session 1 destination interface fastethernet0/9
Lembre-se de que a VLAN que foi utilizada para o espelhamento remote deve passar do switch
de origem até o de destino, verifique se a VLAN não está sendo bloqueada manualmente ou via
VTP Prunning com o comando “show interfaces trunk”. Para verificar a monitoração utilize o
comando “show monitor”, o mesmo utilizado para o SPAN. Veja saídas abaixo.
Switch1# show monitor

Session 1
---------
Type : Remote Source Session
Source Ports :
Both : Fa0/1
Dest RSPAN VLAN : 250
Switch2#show monitor
Session 1
---------
Type : Remote Destination Session
Source RSPAN VLAN : 250
Destination Ports : Fa0/9
Encapsulation : Native
Ingress: Disabled

Note também que a interface de destino no switch2 fica em Up/Down indicando que ela está
em um estado de "monitoring", ou seja, está reservada para monitoração, por isso não
funcionará como uma porta normal. O mesmo ocorre para o SPAN.
Switch2#show interfaces f0/9

FastEthernet0/9 is up, line protocol is down (monitoring)
Hardware is Fast Ethernet, address is 0014.6937.e549 (bia 0014.6937.e549)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Tome muito cuidado ao utilizar o RSPAN, pois apesar de usar uma VLAN específica para envio
das informações o trunk utilizado para chegar ao switch remoto é o mesmo utilizado pelas
demais VLANs. Se o tráfego extra gerado pela monitoração mais o tráfego da rede em produção
exceder a largura de banda disponível pelo trunk o resultado pode ser que certos tráfegos ou
aplicações podem sofrer atrasos e até cortes conforme configuração do QoS.
Outro ponto importante é que o RSPAN permite que o STP rode na VLAN de monitoração para
evitar loops de camada-2, por isso os BPDUs são enviados e recebidos normalmente, impedindo
que BPDUs remotos sejam monitorados via RSPAN.

11 Recomendações Finais - Reforçando a Segurança dos Switches

Esse tópico traz algumas medidas de segurança e reforço na configuração geral dos switches
que você provavelmente já estudou até mesmo no CCNA R&S. De nada vale implementar
recursos avançados de segurança 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.
 Configurar senhas seguras: 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.
 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)#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: 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.

12 Conclusão
Parabéns, se você chegou até aqui é porque concluiu seus estudos!
Tenha certeza de que compreendeu todos os conceitos aqui mostrados. Dê uma repassada na
matéria e tome notas dos pontos que não entendeu muito bem.
Agradecemos pela sua confiança e para quem vai fazer o exame de certificação desejamos boa
sorte!
Equipe DlteC do Brasil
Agora, se quiser complementar seus estudos com exercícios, labs,

simulados e tirar suas dúvidas com nossos tutores não deixe de
verificar o curso online da DlteC do Brasil.
Curso CCNP SWITCH Online (em fase de desenvolvimento).

ApostilaCursoCCNPSWITCH300115v11 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ApostilaCursoCCNPSWITCH300115v11 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

tel (41) 3045.7810 - info@dltec.com.br - www.dltec.com.

DLTEC DO APOSTILA/E-BOOK DO CURSO CCNP SWITCH

Apostila/E-Book do Curso CCNP SWITCH 300-115

Apostila/E-Book do Curso CCNP SWITCH Página 1

O presente material traz conteúdo teórico, comandos e configurações exigidos

Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com

Apostila/E-Book do Curso CCNP SWITCH Página 2

Esse material é de propriedade da DlteC do Brasil Ltda. e é protegido pela lei

É expressamente proibida cópia física ou em meio digital, reprodução parcial,

Seu uso pessoal e intransferível é somente para o cliente que adquiriu o

A cópia e distribuição são expressamente proibidas e seu descumprimento

Apostila/E-Book do Curso CCNP SWITCH Página 3

Capítulo 01 - Introdução .............................................................................................................. 5

Apostila/E-Book do Curso CCNP SWITCH Página 4

Essa apostila/E-Book é uma adaptação em

Alguns itens dessa nova revisão 300-115

A seguir você tem uma relação dos tópicos

Esperamos que você aproveite o material e

Apostila/E-Book do Curso CCNP SWITCH Página 5

Blueprint do CCNP SWITCH 300-115

Tópico do Exame Apostila/E-Book

1.0 Layer 2 Technologies - 65%

1.1 Configure and verify switch administration

Apostila/E-Book do Curso CCNP SWITCH Página 6

Tópico do Exame Apostila/E-Book

2.1 Configure and verify switch security features

Tópico do Exame Apostila/E-Book

3.1 Configure and verify first-hop redundancy protocols

Apostila/E-Book do Curso CCNP SWITCH Página 7

Capítulo 02 - Redes com

1 Operação de Switches Layer 2 ______ 10

3 Modelos de Design de Rede ________ 29

Apostila/E-Book do Curso CCNP SWITCH Página 8

1.6 Modelo Hierárquico em Três Camadas

Apostila/E-Book do Curso CCNP SWITCH Página 9

1 Operação de Switches Layer 2

Apostila/E-Book do Curso CCNP SWITCH Página 10

Em um próximo passo foram criadas as brigdes multiporta (Multiport Bridges), os reais

Apostila/E-Book do Curso CCNP SWITCH Página 11

Em termos práticos, o que caracteriza um switch ser L2 ou L3 é o suporte ao roteamento IP que

Apostila/E-Book do Curso CCNP SWITCH Página 12

1.1 Encaminhamento de Quadros em Switches L2

As três funções básicas de um switch camada-2 são:

Ao receber um quadro, o switch aprende o MAC pelo campo de endereço de origem do

Na fase de encaminhamento o switch pode tomar três ações básicas:

Os MACs de broadcast enviados pelos dispositivos conectados ao switch não são

Apostila/E-Book do Curso CCNP SWITCH Página 13

4. O MAC de destino é de Unicast e está listado na mesma porta que o MAC de

Com as regras acima podemos prever o comportamento normal do switch ao encaminhar

1.2 Funcionamento de um Switch Cisco Catalyst L2

Apostila/E-Book do Curso CCNP SWITCH Página 14

SW-DlteC-Rack-01(config)#mac address-table aging-time ?

SW-DlteC-Rack-01(config)#mac address-table aging-time 299

No caso de loops de camada-2 onde um endereço MAC é aprendido alternadamente em duas ou

Apostila/E-Book do Curso CCNP SWITCH Página 15

1.3 Comandos para Verificar a CAM Table

SW-DlteC-Rack-01#show mac address-table

Vlan Mac Address Type Ports

Apostila/E-Book do Curso CCNP SWITCH Página 16

Os endereços podem ser estáticos (STATIC) ou dinâmicos (DYNAMIC), ou seja, alguns

SW-DlteC-Rack-01#show mac address-table ?

A opção dynamic permite analisar somente MACs aprendidos dinamicamente e podemos

SW-DlteC-Rack-01#show mac address-table dynamic interface gigabitEthernet 0/1