Este capítulo trata de alguns serviços utilizados pela Cisco nos Roteadores, assim como o

conceitos sobre SDN (Software Defined Network).

Tais serviços são: Listas de Controle de Acesso (ACLs), NAT (Network Address Translator),
DHCP (Dynamic Host Configuration Protocol), HSRP (Hot Standby Router Protocol), NTP
(Network Time Protocol), AAA (Authentication, Authorization, Accounting), IP-SLA (IP-
Service Level Agreement) e Gerenciamento. Este capítulo também trata das configurações
destes serviços, e do Licenciamento dos IOS dos roteadores, parte integrante do exame
CCNA.

1
Estudo das ACLs (Access Control Lists)

2
Os arquitetos de rede utilizam firewalls para proteger redes do uso não autorizado. Os
firewalls são soluções em hardware ou software que aplicam políticas de segurança de rede.
Considere uma trava na porta de um quarto dentro de um edifício. A trava só permite que
usuários autorizados com uma chave ou cartão de acesso abram a porta. Da mesma forma,
um firewall filtra pacotes não autorizados ou potencialmente perigosos para que não entrem
na rede. Em um roteador Cisco, você pode configurar um firewall simples que forneça
recursos de filtragem de tráfego básicos utilizando ACLs (Access Control Lists).

As ACLs fornecem uma forma eficiente de controlar o tráfego dentro e fora da sua rede.
Você pode configurar as ACLs para todos os protocolos de rede roteados.

A razão mais importante para configurar as ACLs é fornecer segurança para a sua rede.

3
As ACLs permitem controlar o tráfego dentro e fora da sua rede. Esse controle pode ser tão
simples quanto permitir ou negar hosts de rede ou endereços. No entanto, as ACLs também
podem ser configuradas para controlar o tráfego da rede com base na porta TCP e UDP
utilizada.

Uma ACL é uma lista sequencial de instruções de permissão ou negação que se aplicam a
endereços IP ou protocolos de camada superior. A ACL pode extrair informações do
cabeçalho do pacote, testá-lo em relação às suas regras e tomar decisões "permitir" ou
"negar" com base em:

• Endereço IP de origem;
• Endereço IP de destino;
• O Protocolo Utilizado;
• Tipos de Mensagens ICMP;
• Portas de origem/destino TCP/UDP.

4
ACL é um script de configuração de roteador que controla se um roteador permite ou nega a
passagem a pacotes com base nos critérios encontrados no cabeçalho de pacote. As ACLs
estão entre os objetos mais utilizados no software IOS Cisco. As ACLs também são
utilizadas para selecionar tipos de tráfego a ser analisado, encaminhado ou processado de
outras formas.

As ACLs inspecionam pacotes de rede com base em critérios, como endereço de origem,
endereço de destino, protocolos e números de porta. Além de permitir ou negar tráfego, uma
ACL pode classificar o tráfego para habilitar o processamento por prioridades na linha. Esse
recurso é semelhante a ter uma passagem VIP para um show ou evento esportivo. A
passagem VIP oferece privilégios a convidados selecionados não oferecidos a proprietários
de entradas, como poder entrar em uma área restrita e ser escoltado até seus assentos.

A decisão de qual tipo de pacote filtrar e onde inserir as ACLs é uma decisão do
administrador, porém existem as boas práticas como veremos.

5
A figura mostra a lógica do roteamento e dos processos ACL em um roteador. Quando um
pacote chega a uma interface do roteador, o processo do roteador é o mesmo,
independentemente das ACLs serem utilizadas ou não. À medida que um quadro entra em
uma interface, o roteador verifica se o endereço da Camada 2 de destino corresponde ao seu
ou se o quadro é de broadcast.

Se o endereço do quadro for aceito, as informações do quadro serão removidas e o roteador

verificará se há uma ACL na interface de entrada. Se houver uma ACL, o pacote agora será
testado em relação às instruções na lista.

Se o pacote corresponder a uma instrução, ele será aceito ou rejeitado. Se for aceito na
interface, o pacote será verificado em relação às entradas da tabela de roteamento para
determinar a interface de destino e comutado para essa interface.

Em seguida, o roteador verifica se a interface de destino tem uma ACL. Se houver uma
ACL, o pacote será testado em relação às instruções na lista.

Se corresponder a uma instrução, o pacote será aceito ou rejeitado.

Se não houver nenhuma ACL ou o pacote for aceito, o pacote será encapsulado no novo
protocolo da Camada 2 e encaminhado pela interface para o próximo dispositivo de rede.

6
Algumas Regras Importantes para utilizar ACLs:

As instruções ACL funcionam em ordem sequencial. Elas avaliam pacotes em relação à

ACL, de cima para baixo, uma instrução por vez.

Se o cabeçalho de um pacote corresponder a uma instrução ACL, as demais instruções na

lista serão ignoradas e o pacote será permitido ou negado conforme determinação da
instrução correspondente. Se o cabeçalho de um pacote não corresponder a uma instrução
ACL, o pacote será testado em relação à próxima instrução da lista. Esse processo de
comparação continua até o término da lista.

Uma instrução incluída no final abrange todos os pacotes para os quais as condições não se
mostraram verdadeiras. Essa condição de teste final corresponde a todos os demais pacotes
e resultados em uma instrução "negar“.

Ao final de toda lista de acesso, há uma instrução implícita do critério "negar todo o
tráfego". Ela também é conhecida às vezes como a instrução "deny any implícito". Por isso,
se não corresponder a nenhuma das entradas ACL, um pacote será bloqueado
automaticamente. "negar todo o tráfego" implícito é o comportamento padrão das ACLs,
não podendo ser alterado.

7
Uma regra geral para aplicar as ACLs em um roteador pode ser lembrada, basta memorizar
os três Ps. Você pode configurar uma ACL por protocolo, por direção, por interface:

Uma ACL por protocolo – para controlar o fluxo de tráfego em uma interface, uma ACL
deve ser definida para cada protocolo habilitado na interface.
Uma ACL por direção – as ACLs controlam o tráfego em uma direção por vez em uma
interface. Duas ACLs separadas devem ser criadas para controlar os tráfegos de entrada e de
saída.
Uma ACL por interface – as ACLs controlam o tráfego de uma interface, por exemplo, Fast
Ethernet 0/0.

Caso sejam feitas novas inclusões após a estruturação das listas estas serão acrescentadas ao
final da atual ACL.

8
Durante a configuração de uma ACL, as instruções são adicionadas na ordem em que são
inseridas no final da ACL. No entanto, não há nenhum recurso de edição interno que
permita editar uma alteração em uma ACL. Você não pode inserir ou excluir linhas de
maneira seletiva.
É altamente recomendável que qualquer ACL seja criada em um editor de texto, como o
Bloco de Notas da Microsoft. Isso permite a você criar ou editar a ACL e, em seguida, colá-
la no roteador. Em relação a uma ACL existente, você poderia utilizar o comando show
running-config para exibir a ACL, copiar e colá-la no editor de texto, fazer as alterações
necessárias e recarregá-la.

A lista de acesso não terá função até que ela seja aplicada a uma interface.

Lembre-se de que, ao entrar no roteador, o tráfego é comparado com instruções ACL com
base na ordem em que ocorrem as entradas no roteador. O roteador continua processando as
instruções ACL até que haja uma correspondência. Por essa razão, você deve ter a entrada
ACL mais utilizada na parte superior da lista. Se nenhuma correspondência for encontrada
quando o roteador chegar ao final da lista, o tráfego será negado porque as ACLs têm uma
negação implícita para todo o tráfego que não atenda a nenhum dos critérios testados. Uma
ACL única com apenas uma entrada de negação tem o efeito de negar todo o tráfego. Você
deve ter pelo menos uma instrução de permissão em uma ACL, ou todo o tráfego será
bloqueado.

9
As ACLs são configuradas para se aplicar ao tráfego de entrada ou ao tráfego de saída.

ACLs de entrada – os pacotes de entrada são processados antes de serem roteados para a
interface de saída. Uma ACL de entrada será eficiente porque evita a sobrecarga das
pesquisas de roteamento se o pacote for descartado. Se for permitido pelos testes, o pacote
será processado para roteamento.

ACLs de saída – os pacotes de entrada são roteados para a interface de saída e, em seguida,
processados pela ACL de saída.

10
Há basicamente dois tipos de ACLs Cisco, padrão e estendida.

ACLs padrão

As ACLs padrão permitem a você permitir ou negar tráfego de endereços IP de origem. O

destino do pacote e as portas envolvidas não importam.

ACLs estendidas

As ACLs estendidas filtram pacotes IP com base em vários atributos, por exemplo, tipo de
protocolo, endereço IP de origem, endereço IP de destino, portas TCP e UDP de origem,
portas TCP e UDP de destino e informações do tipo de protocolo opcionais para maior
granularidade de controle.

O intervalo para as ACLs numeradas são definidos conforme abaixo:

IP Padrão: 1-99 e 1300-1999

IP Estendido: 100-199 ou 2000 a 2699

11
Uma ACL padrão é uma coleção sequencial de condições para permitir e negar que se
aplicam a endereços IP. O destino do pacote e as portas envolvidas não são abordados.

O software IOS Cisco testa endereços em relação às condições individualmente. A primeira

correspondência determina se o software aceita ou rejeita o endereço. Como o software para
de testar condições depois da primeira correspondência, a ordem das condições é essencial.
Se nenhuma condição corresponder, o endereço será rejeitado.

As duas tarefas principais envolvidas na utilização das ACLs são as seguintes:

Etapa 1. Criar uma lista de acesso, especificando um número da lista de acesso ou nome e
condições de acesso.

Etapa 2. Aplicar a ACL a interfaces ou linhas de terminal.

12
Para configurar ACLs padrão numeradas em um roteador Cisco, você deve primeiro criar a
ACL padrão e ativar a ACL em uma interface.

Nesse exemplo de uma ACL Padrão (30), todo o tráfego cuja origem for o host
192.168.1.200 será negado.

Perceba que na ACL padrão não é definido o destino do tráfego, apenas a origem.

13
Entre as instruções ACLs estão máscaras, também chamadas de máscaras curinga. Máscara
curinga é uma string de dígitos binários que informam ao roteador que partes do número da
subrede observar. Embora não tenham nenhuma relação funcional com máscaras de sub-
rede, as máscaras curinga fornecem uma função semelhante. A máscara determina a
proporção de um endereço IP de origem ou de destino a ser aplicada à correspondência de
endereço. Os números 1 e 0 na máscara identificam como tratar os bits de endereço IP
correspondentes. No entanto, eles são utilizados para fins diferentes, seguindo regras
diferentes.

As máscaras curinga e de sub-rede têm 32 bits e utilizam 1s e 0s binários. As máscaras de

subrede utilizam 1s e 0s binários para identificar a rede, a sub-rede e a porção de host de um
endereço IP. As máscaras curinga utilizam 1s e 0s binário para filtrar endereços IP
individuais ou grupos e permitir ou negar acesso a recursos com base em um endereço IP.
Definindo máscaras curinga com cuidado, você pode permitir ou negar um ou vários
endereços IP

As máscaras curinga e de subrede são diferentes quanto à forma com que comparam 1s e 0s
binários. As máscaras curinga utilizam as seguintes regras para comparar 1s e 0s binários:

Bit da máscara curinga 0 – comparar o valor do bit correspondente no endereço

Bit da máscara curinga 1 – ignorar o valor do bit correspondente no endereço

No exemplo, a máscara curinga para a máscara de sub-rede 255.255.255.0 é 0.0.0.255,

subtraindo-se cada octeto da máscara de subrede do valor 255.

14
A Figura exibe diversas máscaras de subrede e suas respectivas máscaras curinga.

Nota: as máscaras curinga costumam ser conhecidas como máscaras inversas. A razão é
que, diferentemente de uma máscara de subrede na qual o 1 binário é igual a uma
correspondência e 0 binário, não, o inverso é verdadeiro.

15
No exemplo, temos um máscara curinga 0.0.0.7 para uma máscara de subrede
255.255.248.0.

Nesse caso, foi criada uma lista de acesso padrão para negar todo tráfego pertencente à
subrede 10.85.8.0/21.

Portanto, os endereços pertencentes à lista de acesso definida serão de 10.85.8.0 a

10.85.15.255.

16
Dando continuidade à lista de acesso padrão criada, ao definir a lista com um deny, é
importante permitir o restante, para evitar que todo o tráfego seja negado devido ao deny
implícito.

Escreve a palavra any é similar a escrever o endereço 0.0.0.0 com máscara curinga
255.255.255.255

Depois de ser configurada, a ACL padrão é vinculada a uma interface utilizando-se o

comando ip access-group {access-list-number | access-list-name} {in | out}

17
A localização apropriada de uma ACL para filtrar tráfego indesejável faz a rede operar com
mais eficiência. As ACLs podem agir como firewalls para filtrar pacotes e eliminar o
tráfego indesejável.

Onde você coloca as ACLs pode reduzir o tráfego desnecessário. Por exemplo, o tráfego a
ser negado em um destino remoto não deve utilizar recursos de rede ao longo da rota até
esse destino.

Toda ACL deve ser colocada onde tenha o maior impacto em termos de eficiência. As regras
básicas são:

Localize as ACLs estendidas mais próximas da origem do tráfego negado. Dessa forma, o
tráfego indesejável é filtrado sem atravessar a infraestrutura de rede.

Como as ACLs padrão não especificam endereços de destino, coloque-as o mais próximo
possível do destino.

18
As ACLs estendidas filtram pacotes IP com base em vários atributos, por exemplo, tipo de
protocolo, endereço IP de origem, endereço IP de destino, portas TCP e UDP de origem,
portas TCP e UDP de destino e informações do tipo de protocolo opcionais para maior
granularidade de controle.

A Lista de acesso estendida é muito mais granular que a lista padrão, podendo inclusive
checar número de protocolo e opções do mesmo.

As Listas de acesso estendidas criam uma poderosa lógica de combinação examinando

várias partes de um pacote. Na Figura vários campos dos cabeçalhos dos pacotes podem ser
combinados.

Você pode especificar todos os pacotes IP, ou aqueles com cabeçalhos TCP, cabeçalhos
UDP, ICMP, e assim por diante, verificando o campo Protocolo. É possível também
verificar os endereços IP da fonte e do destino.

19
Comparando as Listas de Acesso Padrão e Estendida, temos:

Ambas verificam endereço IP de origem e porções do endereço de origem.

Apenas a lista de acesso estendida verifica endereço IP de destino, porções do endereço IP

de destino usando máscara coringa, tipo do protocolo (TCP, UDP, ICMP, IGRP, IGMP e
outros), portas de origem, portas de destino, IP ToS e IP Precedence.

20
A lista de acesso estendida (101) acima, nega todo tráfego TCP de origem 192.168.40.0/24
para o host 192.168.30.1 na porta 21.
Ou seja, a lista de acesso não permite que quaisquer hosts 192.168.40.0/24 façam um FTP
ao endereço 192.168.30.1.

Obs.: Embora possamos escrever o nome do protocolo, ao invés da porta, é importante

memorizar o número padrão das portas bem conhecidas.

21
Alguns exemplos de ACLs estendidas e sua lógica:

access-list 101 deny ip any host 10.1.1.1

Qualquer IP de origem, com endereço IP de destino 10.1.1.1

access-list 101 deny tcp any gt 1023 host 10.1.1.1 eq 23

Pacotes com um cabeçalho TCP, qualquer IP de origem, com uma porta de origem maior
que 1023, um IP de destino 10.1.1.1 e uma porta de destino igual a 23.

access-list 101 deny tcp any host 10.1.1.1 eq 23

O mesmo exemplo anterior, mas qualquer porta de origem combina, porque o parâmetro foi
omitido.

access-list 101 deny tcp any host 10.1.1.1 eq telnet

O mesmo exemplo anterior. A palavra telnet é usada ao invés da porta 23.

access-list 101 deny udp 1.0.0.0 0.255.255.255 lt 1023 any

Um pacote com uma origem na rede 1.0.0.0, usando UDP com uma porta de origem menor
que 1023, com qualquer IP de destino.

22
Algumas opções das ACL são importantes para manter registros de tentativas de acesso e
até mesmo poder enviar estas informações para um servidor de Syslog.

Para manter registros do número de pacotes permitidos ou negados em uma linha da ACL:
Router(config)#access-list 101 deny ip 172.18.0.0 0.0.255.255 172.16.0.0 0.0.255.255 log

Para incluir informações mais detalhadas de login, incluindo o MAC Address de origem e
em qual interface o pacote foi recebido:

Router(config)#access-list 101 permit ip any any log-input

23
Seguindo as boas práticas, localize as ACLs estendidas mais próximas da origem do tráfego
negado. Dessa forma, o tráfego indesejável é filtrado sem atravessar a infraestrutura de rede.

Nesse caso, todo tráfego FTP para a rede 172.16.1.0/24 originado do host 172.16.3.10 será
negado.

Perceba que a lista foi aplicada na entrada da porta Ethernet0 do Roteador R3, evitando uma
sobrecarga maior, caso fosse inserida mais próximo ao destino.

24
Nomear uma ACL facilita a compreensão de sua função. Por exemplo, uma ACL para negar
FTP poderia se chamar NO_FTP. Quando você identifica a sua ACL com um nome em vez
de um número, o modo de configuração e a sintaxe do comando são um pouco diferentes.

As ACLs nomeadas têm uma grande vantagem sobre as ACLs numeradas por serem mais
fáceis de editar. Começando pelo software IOS Cisco release 12.3, as ACLs IP nomeadas
permitem excluir entradas individuais em uma ACL específica. Você pode usar números de
sequência para inserir instruções em qualquer lugar da ACL nomeada. Se estiver utilizando
uma versão anterior do software IOS Cisco, você só poderá adicionar instruções na parte
inferior da ACL nomeada. Como pode excluir entradas individuais, você pode modificar a
sua ACL sem ter que excluir e, em seguida, reconfigurar toda a ACL.

25
Para criar uma ACL nomeada siga os passos abaixo:

Etapa 1. Começando no modo de configuração global, utilizar o comando ip access-list

para criar uma ACL nomeada. Os nomes de ACL são alfanuméricos, devendo ser exclusivos
e não começar com um número.

Etapa 2. No modo de configuração da ACL nomeada, utilizar as instruções permit ou deny

para especificar uma ou mais condições e determinar se um pacote foi encaminhado ou
ignorado.

Etapa 3. Retornar ao modo EXEC privilegiado com o comando end.

Nesse exemplo, foi criada uma ACL nomeada estendida com as seguintes regras:
Todo o tráfego WWW do host 10.1.1.2 para quaisquer destinos serão permitidos.
Todo o tráfego UDP do host 10.1.1.1 para a rede 10.2.0.0/24 será negado.
Todo o tráfego IP da rede 10.1.3.0/24 para a rede 10.1.2.0/24 será negado.
Todo o tráfego restante será permitido.

O comando ip access-group [nome da lista] [in/out] aplica o comando em uma interface

específica.

26
A partir da versão 12.3 do IOS, a Cisco introduziu várias outras opções de configuração de
ACLs – opções que se aplicam a ACLs IP nomeadas e numeradas. Essas opções aproveitam
o número de sequência da ACL que é acrescentado a cada sentença permit ou deny da ACL,
onde os números representam a sequência de sentenças da ACL.
Vantagens das ACLs usando número de sequência:

• Permite uma lista individual ser deletada apenas fazendo referência ao número de
sequência;

• Novas listas podem ser adicionadas com um número de sequência, informando assim a
localização da lista junto às demais;

• Novas listas podem ser adicionadas sem um número de sequência, com o IOS criando um
número de sequência e colocando o comando no final da ACL.

27
O Exemplo mostra o poder do número de sequência de uma ACL para editar.

A ACL numerada 24 é configurada, usando esse novo estilo de configuração, com três
comandos permit.

O comando show ip access-list 24 mostra os três comandos permit, com os números

sequência 10,20 e 30.

O Engenheiro exlui somente o segundo comando permit, usando o subcomando ACL no

20, que simplesmente se refere ao número de sequência 20.

O comando show ip access-list 24 confirma que a ACL agora tem duas linhas (número de
sequência 10 e 30).

O Engenheiro acrescenta um comando deny ao começo da ACL, usando o subcomando

ACL 5 deny 10.1.1.1.

O comando show ip access-list 24 novamente confirma as alterações, desta vez listando três
comandos permit, os números de sequência 5,10 e 30.

28
O IOS oferece uma opção fácil para proteger o acesso de entrada e de saída das portas de
linha vty (virtual terminal, ou terminal virtual). Em roteadores, os usuários Telnet e SSH se
conectam a linhas vty e, portanto, para proteger esse acesso, pode-se aplicar uma ACL IP a
essas linhas vty. Você pode usar ACLs para limitar os hosts IP que podem entrar no roteador
através de Telnet e também para limitar os hosts aos quais o usuário do roteador pode se
conectar atráves do Telnet.

Neste exemplo, qualquer trafego não pertencente à rede 10.1.1.0/24 é negado o acesso
Telnet ao roteador.

O comando para criar a ACL é o mesmo já aprendido.

Para aplicar a ACL na line vty o comando é: access-class [número da ACL criada] in/out

29
As ACLs padrão e estendidas podem se tornar a base para ACLs complexas, que fornecem
funcionalidade adicional.

ACLs Reflexiva:
Permite o tráfego de saída e limita o tráfego de entrada em relação a sessões com origem
dentro do roteador

ACLs Dinâmica:
Os usuários que desejam atravessar o roteador são bloqueados até utilizarem Telnet para se
conectar ao roteador e serem autenticados.

ACLs Baseada em Tempo:

Permite o controle de acesso baseado na hora do dia e da semana.

30
Comandos Úteis para verificação das ACLs:

show access-list
Mostra todas as listas de acesso e como estão configuradas, porém não mostra em qual
interface está aplicada.

show access-list 101

Mostra apenas a lista de acesso de número 101.

show ip access-list
Mostra apenas as listas de acesso IP aplicadas ao roteador.

show running-config
Mostra as listas de acesso e em que interface está aplicada.

show ip interface
Mostra quais interfaces tem lista de acesso.

31
Apenas listas de acesso estendidas são suportadas pelo IPv6.

IPv6 ACLs filtra tráfego baseado nestas informações:

- Endereço IPv6 de origem e destino.
- Protocolo de Camada 4.
- Porta de Origem e Destino (No caso de UDP ou TCP).

Wildcard masks não são utilizadas para combinar endereços IPs individuais ou subnets.
Uma notação de prefixo é usado.

A configuração é feita em dois passos (o mesmo que o IPv4):

- Crie uma access list e especifique as declarações.
- Aplique a lista de acesso para uma interface.

32
Exemplo do uso de uma ACL IPv6, para permit tráfego a um servidor WEB.

33
Para verificar a ACL IPv6 use o comando:
show access-lists ipv6

Para verificar se determinada interface possui lista de acesso IPv6 aplicada a ela, utilize o
comando:
show ipv6 interface interface

34
Este capítulo trata do mecanismo utilizado para tradução de endereços de rede - NAT
(Network Address Translation). O capítulo inclui explicação dos principais recursos e da
operação do NAT e da sobrecarga do NAT, explicação das vantagens e das desvantagens do
NAT, configuração do NAT e da sobrecarga de NAT para conservar o espaço de endereço IP
em uma rede, configuração do encaminhamento de porta, bem como comandos para
verificação, identificação e solução de problemas das configurações de NAT.

35
A Internet e as tecnologias relacionadas ao IP passaram por um rápido crescimento. Uma
razão para o crescimento deve-se, em parte, à flexibilidade do design original. Entretanto,
este design não previu a popularidade da Internet e a demanda resultante por endereços IP.
Por exemplo, cada host e cada dispositivo na Internet exige um endereço do exclusivo IP
versão 4 (IPv4). Devido ao drástico crescimento, o número de endereços IP disponíveis está
se esgotando.

Para lidar com o esgotamento dos endereços IP, foram desenvolvidas diversas soluções de
curto prazo. As duas soluções de curto prazo são os endereços privados e a Tradução de
Endereço de Rede (NAT, Network Address Translation).

36
O NAT permite que os hosts de rede internos obtenham temporariamente um endereço IP de
Internet legítimo enquanto acessam os recursos da Internet.

Quando o tráfego solicitado retorna, o endereço IP legítimo é adaptado e disponibilizado

para a solicitação seguinte da Internet feita por um host interno.

Usando a NAT, os administradores de rede precisam somente de um ou poucos endereços

IP para serem fornecidos aos hosts pelo roteador, em vez de um endereço IP exclusivo para
cada cliente que entra na rede. Embora pareça ineficiente, o processo é, na verdade, muito
eficiente, porque o tráfego do host acontece de forma muito rápida.

37
O NAT usa um endereço IP válido e registrado para representar o endereço privativo para o
resto da Internet. A função do NAT muda os endereços IP privativos para endereços IP
registrados publicamente dentro de cada pacote IP.

Observe que o roteador executando NAT, muda o endereço IP origem do pacote quando o
pacote sai da organização privada. O roteador executando NAT também altera o endereço
de destino de cada pacote encaminhado de volta para dentro da rede privada.

38
Na terminologia Cisco, a rede da empresa que usa endereços privativos e, sendo assim,
precisa do NAT, é a parte interna (ou inside) da rede. O lado Internet da função NAT é a
parte “externa” (ou “outside”) da rede.
Portanto:

Inside Network: o conjunto de endereços IPs que estão sujeitos a ser traduzidos.

Outside Network: rede que não está afiliada e nem pertence à rede interna. Uma rede
qualquer externa.

39
Terminologias NAT:

Inside Local: Em um projeto NAT típico, o termo interno (inside) se refere a um endereço
usado por um host dentro de uma empresa. Um local interno é o endereço IP atribuído a um
host dentro na rede privada da empresa.

Inside Global: O NAT usa um endereço global interno para representar um host interno
quando o pacote é enviado para a rede externa, tipicamente a Internet. Um roteador NAT
altera o endereço IP de origem de um pacote enviado por um host interno com um endereço
local interno, para um endereço global interno, quando o endereço vai de dentro para fora
da rede.

Outside Global: Em um projeto NAT típico, o termo externo (outside) se refere a um

endereço usado por um host fora da empresa – em outras palavras, na Internet. Um endereço
global externo é o endereço IP real atribuído a um host que fica na rede externa, tipicamente
na Internet.

Outside Local: O NAT pode traduzir o endereço IP externo - o endereço IP que representa
o host fora da rede da empresa – embora esta não seja uma opção muito usada. Quando um
roteador NAT encaminha um pacote de dentro para fora da rede, quando estiver usando o
NAT para alterar o endereço externo, o endereço IP que representa o host externo na forma
do endereço IP destino no cabeçalho do pacote é chamado de endereço IP local externo.

40
A Figura mostra o uso das terminologias do NAT: Inside Local, Inside Global, Outside
Global e Outside Local.

41
O software IOS da Cisco suporta diversas variações de NAT, conforme abaixo:

NAT Estático: Mapeamento de um para um, ou seja, um IP não válido para um IP válido na
Internet.

Dinâmico: Mapeamento de um IP não válido para um válido dentro de um conjunto de

válidos.

Overloading: Também conhecido como PAT (Port Address Translation), nesse caso vários
endereços IPs não válidos podem sair com apenas um válido, mudando apenas a porta de
saída.

Overlapping: Usado em caso de interoperabilidade entre redes que utilizam a mesma faixa
de endereçamento.

42
NAT estático é um mapeamento exclusivo entre um endereço interno e um endereço
externo. O NAT estático permite conexões iniciadas por dispositivos externos para
dispositivos internos. Por exemplo, você pode desejar mapear um endereço global interno
para um endereço local interno específico que está atribuído ao seu servidor web.

A configuração das traduções de NAT estáticos é uma tarefa simples. É necessário definir os
endereços a serem traduzidos e, em seguida, configurar a NAT nas interfaces apropriadas.

Os pacotes que chegam em uma interface do endereço IP definido estão sujeitos à tradução.
Os pacotes que chegam em uma interface externa, destinados para o endereço IP
identificado, estão sujeitos à tradução.

43
A figura explica os comandos para configuração de um NAT estático.

Você digita as traduções estáticas diretamente na configuração. Diferentemente das

traduções dinâmicas, essas traduções sempre estão na tabela de NAT.

A figura é uma configuração de NAT estático simples aplicada em ambas as interfaces. O

roteador sempre traduz os pacotes do host dentro da rede com o endereço privado de
10.1.1.2 em um endereço externo de 200.38.1.5.

44
Enquanto o NAT estático fornece um mapeamento permanente entre um endereço interno e
um endereço público específico, o NAT dinâmico mapeia os endereços IP privados para
endereços públicos. Esses endereços IP públicos vêem de um conjunto de NAT.

45
A configuração de NAT dinâmica é diferente da NAT estática, mas também apresenta
algumas semelhanças. Assim como a NAT estática, ela exige que a configuração identifique
cada interface como uma interface interna ou externa. Entretanto, em vez de criar um mapa
estático para um único endereço IP, utiliza-se um conjunto de endereços globais internos.

Para configurar a NAT dinâmica, você precisa de uma ACL para permitir somente os
endereços que devem ser traduzidos. Ao desenvolver sua ACL, lembre-se de que há um
“negar todos” implícito no final de cada ACL. Uma ACL muito permissiva pode levar a
resultados imprevisíveis. A Cisco não aconselha configurar as listas de controle de acesso
indicadas pelos comandos NAT com o comando permit any. O uso do comando permit any
pode fazer com que a NAT consuma muitos recursos do roteador, o que pode levar a
problemas de rede.

Essa configuração permite a tradução para todos os hosts na rede 10.1.1.0 quando elas
gerarem o tráfego que entrar em F0/0 e sair de S0/0. Esses hosts são traduzidos para um
endereço disponível no intervalo de 200.1.1.1 a 200.1.1.14.

46
Algumas redes precisam ter a maioria, senão todos os hosts acessando a Internet. Se esta
rede usar endereços IP privativos, o roteador NAT precisará de um conjunto grande de
endereços registrados. Com o NAT estático, para cada host com IP privativo que precisar
acessar a Internet, você precisará de um endereço IP registrado publicamente, destruindo
completamente o objetivo de reduzir o número de endereços IPs públicos necessários a esta
organização. O NAT dinâmico reduz o problema e até certo ponto, porque raramente todos
os hosts de uma rede precisariam se comunicar com a Internet ao mesmo tempo. Porém, se
um grande percentual dos hosts IPs de uma rede precisar de acesso à Internet ao longo do
horário comercial normal da empresa, o NAT ainda precisará de um grande número de
endereços IP registrados, falhando novamente em reduzir o consumo de endereços IP.

O recurso de sobrecarga de NAT (Overloading) também chamado de PAT (Port Address

Translation, ou tradução de endereços de porta) resolve este problema. A sobrecarga permite
que o NAT seja escalado para suportar vários clientes com apenas poucos endereços IPs
públicos.

Quando o PAT cria o mapeamento dinâmico, ele seleciona não apenas o endereço IP global
interno, mas também um número de porta único a ser usado com este endereço. O roteador
NAT mantém uma entrada na tabela NAT para cada combinação única entre o endereço IP
local interno e porta, com a tradução para o endereço global interno e um número de porta
único associado a este endereço global interno.

47
A configuração é semelhante à NAT dinâmica. A diferença é que, em vez de um conjunto de
endereços, a palavra-chave interface é usada para identificar o endereço IP externo.
Portanto, nenhum conjunto de NAT foi definido. A palavra-chave sobrecarga (overloading)
permite adicionar o número da porta à tradução.

Neste exemplo, os endereços privados permitidos na ACL 1 (10.1.1.0) serão traduzidos

para o endereço IP da serial 0/0 (200.1.1.249).

O NAT overloading também pode ser configurado também para usar um conjunto de
endereços públicos. Nesse caso, ao invés de usar o nome da interface de saída, usa-se um
pool de endereços previamente fornecidos pelo provedor de serviços.

48
Uma outra variação de NAT, permite a tradução tanto do endereço IP de origem quanto do
endereço IP de destino. Esta opção é particularmente útil quando duas redes utilizam faixas
de endereços IP que se sobrepõem, por exemplo, quando uma organização não está usando
endereçamento privativo, mas ao invés disso, está usando um número de rede registrado,
pertencente a outra empresa.

Se uma empresa usa inapropriadamente um número de rede que está corretamente

registrado para outra empresa, e ambas se conectam à Internet, o NAT pode ser usado para
permitir que ambas as empresas se comuniquem com hosts na Internet, e uma com a outra.
Para fazer isso, o NAT traduz tanto os endereços IP de origem quanto os endereços IPs de
destino.

49
Um dos comandos mais úteis ao verificar a operação de NAT é o comando show ip nat
translations. O mesmo exibe os detalhes das duas atribuições de NAT.
O comando exibe todas as traduções estáticas que foram configuradas, além das traduções
dinâmicas que foram criadas pelo tráfego. Cada tradução é identificada através do protocolo
e através dos endereços locais e globais, internos e externos.

Antes de usar os comandos show para verificar a NAT, você deve apagar as entradas de
tradução dinâmica que ainda estejam presentes porque, por padrão, as traduções dinâmicas
de endereço expiram da tabela de tradução NAT após um período de falta de uso.

O comando show ip nat statistics exibe informações sobre o número total de traduções
ativas, os parâmetros de configuração de NAT, quantos endereços estão no conjunto e
quantos foram alocados.

50
Você pode especificar qual tradução apagar ou pode apagar todas as traduções da tabela
usando o comando global clear ip nat translation *.

Use o comando debug ip nat para verificar a operação do recurso de NAT exibindo as
informações sobre os pacotes que são traduzidos pelo roteador.

51
Este capítulo trata das configurações básicas do DHCP, sendo implementada no roteador,
tópico importante e exigido no exame CCNA.

52
Os comandos definem como configurar o roteador para fazer função de um servidor DHCP.
Embora essa não seja uma prática recomendável, poderá ser útil em algumas situações.

Define um pool para o DHCP:

Roteador(config)#ip dhcp pool cursoccna
Define a faixa de endereços do pool DHCP:
Roteador(dhcp-config)#network 192.168.5.0 255.255.255.0
Define o gateway que será fornecido às estações:
Roteador(dhcp-config)#default-router 192.168.5.1
Define o endereço do DNS fornecido às estações:
Roteador(dhcp-config)#dns-server 192.168.5.3
Define a duração do lease:
Roteador(dhcp-config)#lease 30
* 30 = Trinta dias (24h é o default)
Define os endereços que serão excluídos da faixa DHCP:
Roteador(config)#ip dhcp excluded-address 192.168.5.1 192.168.5.10

Para verificação:
Roteador#show ip dhcp binding

Para exibir endereços duplicados:

Roteador#show ip dhcp conflict

53
Este capítulo ilustra soluções para problemas de roteamento em uma rede local com
topologia redundante. Uma solução para esses problemas pode ser explicada pelo processo
de redundância do roteador. Este capítulo identifica o protocolo HSRP (protocolo de
roteamento em espera ativa) e também descreve como configurar o HSRP básico, assim
como usar os comandos show adequados para confirmar a funcionalidade apropriada.

54
Com o tipo de redundância do roteador exibida na figura, um conjunto de roteadores
funcionam em conjunto para criar a ilusão de um único roteador aos olhos dos hosts na
LAN. Ao compartilhar um endereço IP (camada 3) e um endereço MAC (camada 2), dois
ou mais roteadores podem atuar como um único roteador "virtual".

O endereço IP do roteador virtual é configurado como gateway padrão para as estações de

trabalho em um segmento IP específico. Quando os quadros são enviados da estação de
trabalho para o gateway padrão, a primeira usará o ARP para resolver o endereço MAC que
está associado ao endereço IP do gateway padrão. A resolução ARP retorna o endereço
MAC do roteador virtual. Os quadros enviados para o endereço MAC do roteador virtual
podem então ser fisicamente processados por qualquer ativo ou roteador em standby que
faça parte do grupo virtual do roteador.

Utiliza-se um protocolo para identificar dois ou mais roteadores como os dispositivos

responsáveis pelo processamento dos quadros enviados para o MAC ou para o endereço IP
de um único roteador virtual. Os dispositivos host enviam o tráfego para o endereço do
roteador virtual. O roteador físico que encaminha esse tráfego é transparente para as
estações finais.

O protocolo de redundância fornece o mecanismo para determinar qual roteador deve

assumir a função ativa de encaminhar o tráfego, além de determinar quando tal função deve
ser executada por um roteador em standby. A transição de um roteador de transmissão para
outro é transparente para os dispositivos finais.

55
Estas são as etapas que ocorrem quando um roteador ou um switch de camada 3 falha:

1. O roteador em standby para de visualizar mensagens hello do roteador de

encaminhamento.
2. O roteador em standby assume a função do roteador de encaminhamento.
3. Como o novo roteador de encaminhamento assume os endereços IP e de MAC do
roteador virtual, as estações terminais não observam nenhuma interrupção de serviço

56
HSRP define um grupo de roteadores em espera, com um roteador nomeado como roteador
ativo. HSRP fornece redundância de gateway ao compartilhar os endereços IP e MAC entre
gateways redundantes. O protocolo consiste em endereços virtuais MAC e IP que são
compartilhados entre dois roteadores de um mesmo grupo HSRP.

Terminologia HSRP

Roteador ativo: É o roteador que está encaminhando pacotes para o roteador virtual

Roteador em standby: É o roteador de backup principal

Grupo de espera: É o conjunto de roteadores participantes no HSRP que, juntos, imitam um

roteador virtual

A função de roteador em standby HSRP é monitorar o status operacional do grupo HSRP e

assumir rapidamente a responsabilidade de encaminhamento de pacotes se o roteador ativo
se tornar inoperante.

HSRP é um protocolo propriedade da Cisco, e VRRP é um protocolo padrão. Além disso, as

diferenças entre HSRP e VRRP são muito pequenas.

57
O roteador ativo responde às solicitações de gateway padrão ARP com o endereço MAC do
roteador virtual e se apropria do encaminhamento de pacotes para o roteador virtual. O
roteador ativo envia mensagens de hello e conhece o endereço IP virtual do roteador.

O roteador em standby procura ouvir mensagens de hello periódicas e apropria-se do

encaminhamento de pacotes ativos se não receber nenhuma mensagem do roteador ativo.

58
O endereço de multicast utilizado pelo HSRPv1 é 224.0.0.2 e MAC Virtual
0000.0C07.Acxy, onde xy é o grupo que o HSRP foi configurado em Hexadecimal.

O endereço de multicast utilizado pelo HSRPv2 é 224.0.0.12 e MAC Virtual

0000.0C9F.Fxyz, onde xyz é o grupo HSRP em hexadecimal que vai de 000 a FFF (0 a 4095
em decimal).

59
Exemplos da formação do endereço MAC Virtual, para o HSRP versão 1 e versão 2.

60
Após configurar o endereço IP na interface, use o comando standby group-number ip ip-address
para reconfigurar o HSRP.

Em HSRPv1, o número de grupo pode ser qualquer valor entre 0 e 255, mas deve ser o mesmo em
ambos os roteadores vizinhos. Em HSRPv2, o número de grupo pode ser qualquer valor entre 0 e
4095.

O endereço IP é o endereço IP do roteador virtual para o grupo HSRP. Ele deve ser idêntico em
todos os roteadores de um mesmo grupo HSRP.

Cada grupo de espera tem seus próprios ativos e roteadores standby. Um engenheiro de rede pode
atribuir um valor de prioridade a cada roteador de um grupo de espera, controlando, dessa forma, a
ordem na qual os roteadores ativos do grupo serão selecionados. O valor padrão é 100, mas pode ser
de 0 a 255.

Durante o processo de seleção, o roteador com maior prioridade em um grupo HSRP se torna o
roteador ativo. Se um vínculo ocorrer, o roteador com o maior endereço IP configurado se tornará
ativo.

Se os roteadores não estão configurados com preempt, um roteador que se inicializar de modo
significativamente mais rápido do que os outros do grupo de espera, se tornará o roteador ativo,
independentemente da prioridade configurada. O antigo roteador ativo pode ser configurado para
retomar a função de roteador de encaminhamento ao assumir o lugar de um roteador com prioridade
mais baixa.

61
Para exibir informações do HSRP, use o comando show standby no modo EXEC
privilegiado.

A saída de exemplo mostra o estado HSRPv2 no roteador A. O endereço do roteador virtual

é 10.1.10.1 e o roteador A está enviando o tráfego ativamente. Por padrão,o tempo de
saudação é de 3 segundos e o tempo de espera é de 10 segundos.

62
Para verificação do HSRP utilize o comando “show standby brief”

63
Este capítulo trata de tópicos relacionados ao Gerenciamento de uma rede. O CCNA como
um todo cobra o conceito do gerenciamento de um dispositivo e da rede utilizando o Syslog,
SNMP e o Netflow.

Além disso, no final do capítulo abordaremos de forma superficial os principais

software/ferramentas gratuitas de uso local disponibilizados pela Cisco para administração
Web de roteadores e switches:

• Security Device Manager (SDM)

• Cisco Configuration Professional (CCP)

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

Com o SNMP, os administradores podem gerenciar e configurar elementos de rede de um

servidor localizado centralmente em vez de ter que executar o software de gerenciamento de
rede.

Também é possível usar o SNMP para monitorar o desempenho da rede, detectar problemas
de rede e acompanhar quem usa a rede e como ela é usada. O SNMP trabalha por padrão
com o protocolo UDP na porta 161.

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

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

MIB (Management Information Base): base de dados padronizada que é lida por um
gerente SNMP.
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.

65
Um Dispositivo Gerenciado é um nó de rede que possui um agente SNMP instalado e se
encontra numa rede gerenciada. Estes dispositivos coletam e armazenam informações de
gestão e mantêm estas informações disponíveis para sistemas NMS através do protocolo
SNMP. Dispositivos geridos, também às vezes denominados de dispositivos de rede,
podem ser roteadores, servidores de acesso, impressoras, computadores, servidores de rede,
switches, dispositivos de armazenamento, dentre outros.

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

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

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

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

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

Através de um sistema de gerenciamento (gerente SNMP) podemos ler essas informações e

apresentá-las de forma mais intuitiva para que um analista de suporte, por exemplo, tenha
informação de quanta CPU está sendo utilizada pelo roteador naquele momento através de
um comando SNMP Get.

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

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

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

O termo correto para as variáveis armazenadas na MIB são objetos identificados por
números chamados de object ID ou OID. A MIB tem esses OIDs organizados em uma
árvore com base em padrões definidos por RFCs formando uma hierarquia de OIDs.

Essa árvore formada pela MIB contém algumas informações (OIDs) padronizadas por RFCs
e comuns a qualquer elemento de rede e também características próprias dos equipamentos
definidas pelo fabricante, por exemplo, informações específicas sobre a memória flash de
um roteador.

68
Por exemplo, se fosse necessário consultar o valor armazenado como “cisco flash group” o
gerenciador teria que procurar pelo OID “1.3.6.1.4.1.9.9.10”. No dia a dia esse tipo de
consulta pode se tornar inviável, porém os gerenciadores como o Cisco Prime tem essas
consultas pré-configuradas e você pode escolher o que monitorar sem saber especificamente
cada OID e seu caminho na árvore da MIB.

69
Tanto na versão 2 como na versão 1 do SNMP são utilizadas comunidades (community
strings) para definir o acesso às MIBs e qual o nível podemos ter a essas informações
através de dois tipos de comunidades.

Read-only (RO): permite acesso de leitura às variáveis da MIB e opção mais utilizada com
a Version 2c devido a falta de recursos de segurança adicionais dessa versão de SNMP.

Read-write (RW): permite acesso de leitura e escrita a quaisquer objetos da MIB sem
nenhuma verificação extra.

Portanto, com um nome ou string definimos o acesso e que tipo de acesso podemos fazer à
MIB dos dispositivos com SNMPv2c ativado.

70
Seguem os passos para configurar o SNMPv2. O passo 1 é obrigatório, os demais são
opcionais:

Configurar a community string e o nível de acesso com o comando “snmp-server

community comunidade RO|RW” em modo de configuração global.

Descrever (documentar) a localização do dispositivo com o comando “snmp-server

location”.

Documentar o contato responsável pelo dispositivo com o comando “snmp-server

contact”.

Restringir o acesso SNMP apenas ao servidor ou host que possui o sistema NMS utilizando
uma ACL no comando “snmp-server community nome-da-comunidade num-ou-nome-
da-acl”.

Para o envio de TRAPs (mensagens de problemas geradas pelos roteadores e switches)

primeiro precisamos definir o IP do servidor e depois habilitar o envio das mensagens.

71
No SNMP versão 3 temos realmente recursos de segurança implementados, são eles:

Integridade das mensagens: através de um algoritmo de hash pode ser verificado se o

conteúdo da mensagem não foi alterado em trânsito, seja por problemas na rede ou ataque.
Autenticação: ajuda a validar se a origem que está enviando informações realmente tem a
permissão para tal.
Criptografia: protege os dados eventualmente capturados em trânsito dificultando a leitura
das informações.

72
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, implementa autenticação e integridade com Message
Digest 5 (MD5) ou Secure Hash Algorithm (SHA) e criptografia através do DES ou DES-
56.

73
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.

O protocolo syslog é muito simples: o remetente envia uma pequena mensagem de texto
(com menos de 1024 bytes) para o destinatário (também chamado "syslogd", "serviço
syslog" ou "servidor syslog"). Tais mensagens podem ser enviadas tanto por UDP quanto
por TCP.

O protocolo syslog é tipicamente usado no gerenciamento de equipamentos em rede para

auditoria de segurança de sistemas ou análises de problemas. Por ser suportado por uma
grande variedade de dispositivos em diversas plataformas, o protocolo pode ser usado para
integrar diferentes sistemas em um só repositório de dados.

74
Os logs do roteador são as mensagens que ele fornece em caso de problemas, como quedas
de interface, ou quando um acesso é realizado ou um evento ocorre, normalmente são as
mensagens que recebemos via console e que atrapalham quando estamos configurando o
roteador.

Quando utilizamos um comando debug, por exemplo, essas mensagens serão também
enviadas para o syslog se configurado. Esse arquivo pode ser posteriormente analisado se
não está havendo acessos não autorizados ou problemas recorrentes.

75
Resumindo, dos níveis de 0 até 4 temos eventos que realmente podem impactar a operação
do equipamento em questão, já dos níveis 5 a 7 são eventos com menor relevância. Temos
que decidir no dia a dia até onde monitorar para não “entupir” o servidor de mensagens que
não poderão ser interpretadas ou simplesmente são inúteis.
Quanto maior a amplitude ou o nível de depuração do log, mais mensagens serão enviadas
ao servidor de syslog, portanto a análise de nível do log deve ser feita com
cuidado para não gerar sobrecarga no equipamento.

Para configurar a amplitude do log entre com o comando em modo de configuração global:

router(config)#logging trap nível

76
O logging buffer faz 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”.

77
Para verificar as mensagens geradas pelos dispositivos e armazenadas no buffer de registros
podemos utilizar o comando “show logging”.

78
As mensagens são mostradas por padrão conforme abaixo:

Um timestamp: marcação de data e hora que o registro ocorreu): Dec 18 17:10:15.079

03:04:25.389 BR
O recurso no roteador que gerou o registro (facility): %LINEPROTO
Nível de severidade (severity level): 5
Um mnemônico da mensagem: UPDOWN
Descrição breve da mensagem (description): Protocolo de linha na interface
FastEthernet0/0 alterou o estado para inoperante

79
Neste capítulo estaremos o protocolo NTP (Network Time Protocol), cuja função é permitir
que os dispositivos de rede estejam sincronizados com um relógio comum para que os
eventos possam ser organizados cronologicamente pelo sistema receptor.
Trata-se de um protocolo muito importnte, principalmente para Registro de Logs de
eventos, horários das Estações, Servidores e Telefones IPs, por exemplo.

80
Normalmente, os dispositivos de rede são capazes de gerar e enviar eventos relativos ao seu
funcionamento ou sobre alterações ocorridas no estado de algumas variáveis. Estes eventos
normalmente são recebidos e tratados por sistemas que podem construir um histórico do
comportamento e dos acontecimentos ocorridos em cada dispositivo e inclusive
correlacioná-los. Para que esta correlação faça sentido é preciso que os dispositivos estejam
sincronizados com um relógio comum para que os eventos possam ser organizados
cronologicamente pelo sistema receptor. Neste momento surge a necessidade de se utilizar
um mecanismo que faça a tarefa de sincronizar todos os dispositivos de forma automática.

O Network Time Protocol é o serviço de rede mais utilizado para este fim.

81
O servidor NTP é o dispositivo da rede eleito para fornecer a referência de data e hora para
todos os demais dispositivos. Através de consultas periódicas os dispositivos clientes
solicitam a atualização de data e hora e o servidor NTP responde com a informação. Cada
cliente NTP faz o desconto do tempo gasto no RTT (Round-Trip Time) da consulta e desta
forma o relógio de cada dispositivo fica exatamente igual em toda rede.

82
O NTP (Network Time Protocol) é um protocolo para sincronização dos relógios dos
dispositivos de rede baseado no UDP. O NTP permite manter o clock do seu dispositivo
com a data/hora sempre certa e com grande extatidão.

Os servidores NTP formam uma topologia hierárquica, dividida em camadas ou estratos

(em inglês: strata) numerados de 0 (zero) a 16 (dezesseis).

O estrato 0 (stratum 0) na verdade não faz parte da rede de servidores NTP, mas representa
a referência primária de tempo, que é geralmente um receptor do Sistema de
Posicionamento Global (GPS) ou um relógio atômico.

O estrato 16 indica que um determinado servidor está inoperante.

83
O estrato 0, ou relógio de referência, fornece o tempo correto para o estrato 1, que por sua
vez fornece o tempo para o estrato 2 e assim por diante. O NTP é então, simultaneamente,
servidor (fornece o tempo) e cliente (consulta o tempo), formando uma topologia em árvore.

Na Internet você pode encontrar diversos servidores publicos estratos 2 ou 3 (e até mesmos
alguns estrato 1) para utilizar. Uma lista dos servidores NTP disponíveis na
Internet pode se encontrada no endereço:
http://support.ntp.org/bin/view/Servers/WebHome.

84
O comando ntp server 10.11.11.2 define o Servidor NTP de referência da sua rede, o qual
deve apontar para um NTP de referência na Internet.

Para verificar o funcionamento do NTP utilize os comandos “show ntp associations” e

“show ntp status”.

Bem, após sincronizarmos com o servidor NTP devemos configurar o nosso timezone. Caso
isso não seja feito o roteador irá exibir a hora tendo como referência o timezone UTC 0.
Aqui no Brasil, estamos no timezone UTC -3, ou seja, com 3 horas a menos que o UTC 0.
Esse é o nosso fuso horário.

A sintaxe do comando é clock timezone nomedatimezone offset,

onde nomedatimezone pode ser qualquer nome
offset é offset do seu timezone em relação ao UTC 0.

No nosso exemplo, criamos o timezone com o nome BR e com 3horas de diferença ao UTC.

Para configurar a mudança do horário automaticamente no horário de verão

precisamos utilizar o comando “clock summer-time“.

Para descobrir o seu timezone você pode utilizar o link abaixo:

http://www.timeanddate.com/worldclock/

85
Neste capítulo estudaremos o recurso de segurança para ativos de rede conhecido como
AAA, que significa Authentication, Authorization and Accounting (Autenticação,
Autorização e Contabilidade).

86
Autenticação é o processo de verificação da identidade de um usuário para determinar se ele
deve ser autorizado a acessar o dispositivo. É a comprovação de que o usuário é quem alega
ser.

Autorização é o ato de limitar ou permitir o acesso a certos recursos do dispositivo depois

que um usuário foi autenticado.

Contabilidade é o registro de ações executadas pelo usuário depois que ele foi autenticado e
autorizado.

87
Podemos fazer uma analogia com um cartão um cartão de crédito, onde a autenticação seria
sua identificação escrita no cartão, sua autorização seria os recursos que seriam permitidos
para uso do cartão, ou seja, as operações possíveis de efetuar, e a contabilidade seria o
registro de tudo que você gastou.

88
Dentre os benefícios do AAA, podemos citar:

• Padronização das formas de autenticação: Todos os seus usuários poderão ser

autenticados através de um método único e centralizado, diminuindo a complexidade e
facilitando o gerenciamento da rede.

• Gerenciamento aprimorado: O AAA reduz os esforços para a configuração dos métodos

de autenticação e controle de acessos aos equipamentos de rede. Toda a configuração
poderá ser executada de forma centralizada.

• Backup. É possível disponibilizar mecanismos redundantes para garantir a continuidade

do serviço AAA.

89
Uma das vantagens de usar a AAA é a possibilidade de usar um servidor externo para
autenticação, autorização e contabilidade.

Quando um servidor externo é usado, todas as informações do usuário são armazenadas

externamente ao dispositivo de rede.

A administração da segurança do usuário é portanto centralizada. Isso permite que usuários

individuais acessem muitos dispositivos, admitindo também que o administrador limite o
acesso dos usuários.

RADIUS e TACACS+ são dois protocolos usados para aplicações de autenticação e

autorização.

90
Para evitar uma autenticação local nos equipamentos, o que seria inviável para
administração considerando uma grande rede, utilizamos servidores de TACACS ou
RADIUS para que esta autenticação seja feita em um servidor centralizado, a nos ativos de
rede apenas seja feita um apontamento para este servidor.

91
A tabela resume algumas diferenças entre TACACS e RADIUS, embora na prática ambos
façam funções similares e sejam bem utilizados para autenticação de usuários.

92
Neste capítulo estudaremos a feature Cisco IP SLA.
A Cisco IP SLA é uma feature presente em algumas versões do IOS que permite o
gerenciamento proativo das condições da rede monitorada. Basicamente, gera-se um tráfego
específico de um dispositivo com destino a outro, que responde à este tráfego e medições
são realizadas no decorrer do processo.

93
O IP SLA é um recurso presente em algumas versões do IOS da Cisco, que permite o
gerenciamento proativo das condições da rede monitorada.
O IP SLA é uma feature do Cisco IOS que permite você configurar um roteador para enviar
tráfego sintético para:
- Um computador
- - Roteador que foi configurado para responder.

94
Para habilitar o IP SLA, é necessário configurar ao menos 2 elementos: O “transmitter” e o
“responder”.

A configuração do responder é bastante simples (uma linha de comando, apenas). Ao iniciar

a operação, o transmitter envia mensagens de controle ao responder.

Estas mensagens de controle informam ao responder qual porta lógica (TCP ou UDP) deve
ser usada para as requisições do transmitter. A ativação do serviço “responder” pode nem ser
necessária, se o elemento que irá responder às solicitações do transmitter já estiver
aguardando dados nas portas a serem testadas (ex. o serviço HTTP já está ativado no router
que agirá como responder, e este é o serviço que queremos “medir”).

95
Há várias probles de SLA que podem ser usadas, porém iremos focar no ICMP Echo, o qual
é proveitoso para troubleshooting problemas de conectividade.

96
Exemplo de uso do IP SLA com ICMP Echo.

97
Exemplo de uso do IP SLA com ICMP Echo.

98
Exemplo de uso do IP SLA com ICMP Echo.

99
Este capítulo estuda os conceitos das Redes Definidas por Software, ou SDN.

100
As redes definidas por software podem ser conceituas como:

Uma forma padrão de programar o dispositivo de rede remotamente, permitindo que a

camada de controle possa ser movida para um servidor dedicado e com alta capacidade de
processamento.

101
SDN é um paradigma de rede emergente que separa o plano de controle do plano de dados.
Apesar deste paradigma ter iniciado na academia (MCKEOWN,2008), ele ganhou espaço
nas indústrias nos últimos anos. A utilização de SDN ganhou tamanha força que fez o
Google, Facebook, Yahoo, Microsoft, Verizon, e Deutshche Telekon fundar a Fundação
Open Networking (do inglês, Open Networking Foundation – ONF) com o objetivo de
promover a adoção de SDN.

102
Em uma rede SDN, a inteligência da rede é logicamente centralizada no chamado
controlador SDN que mantêm uma visão global das informações da rede como, por
exemplo, o número total de switches, as suas conexões e o estado dessas conexões. Desta
forma, a rede é apresentada para as aplicações e serviços como se toda a infraestrutura fosse
um único switch lógico. As aplicações, juntamente com o controlador, representam a
inteligência da rede e se responsabilizam por diversas funções importantes como, por
exemplo, fazer a escolha do melhor caminho que os pacotes devem seguir e a qualidade de
serviço das mesmas.

103
Em face à necessidade de implementação e experimentação de novas propostas na área de
arquiteturas de redes em ambientes reais foi desenvolvido o OpenFlow, que propõe um
mecanismo para permitir que redes reais sejam utilizadas como um ambiente de
experimentos.

104
Este capítulo apresenta um estudo sobre o Licenciamento do Sistema Operacional utilizado
pela Cisco (IOS) e entender como esse sistema operacional era distribuído no passado e
atualmente com o novo modelo de licenciamento.

105
No início desde 1980 até meados de 2012 as imagens do Cisco IOS eram distribuídas por
modelo, série e por versão/release de Software. Isso acontecia desde as versões 10.x, 11.x
até a 12.x, a qual finalizou com a versão 12.4 para a linha ISR-G1. Vamos entender o que
isso significa.

Por exemplo, existiam vários modelos de equipamentos para uma mesma série de
roteadores, tais como na linha 1700 tínhamos os modelos 1701, 1721, 1751, 1751-V e assim
por diante. Por isso era preciso uma versão diferente devido aos modelos nem sempre
suportarem a mesma quantidade e/ou tipo de interfaces ou utilizarem processadores
diferentes, portanto a Cisco precisava compilar diferentes versões de imagens de IOS para
os diferentes tipos de processadores.

Além disso, a Cisco precisava de imagens de IOS diferentes para cada nova versão ou
release de software. Uma revisão significativa (major revisions) no software Cisco IOS
utilizava o termo versão (version), enquanto mudanças menores recebiam a denominação de
release.

Por exemplo, ao invés da Cisco lançar um bug fix ou novo recurso como um patch, essas
correções eram lançadas em arquivos de IOS separados, ou seja, em uma nova release da
mesma versão de IOS ou até uma nova versão, portanto, para implantar aquela correção de
problemas ou recurso adicional de software era necessário trocar o software inteiro e inserir
um novo Cisco IOS no roteador.

106
Cada versão de IOS possuía listas de recursos chamadas feature set, por exemplo, os roteadores
saíam com uma feature set básica chamada IP Base, com suporte a determinados recursos de
software. Se a empresa precisava ativar recursos de segurança precisaria comprar outra versão de
IOS com a feature set de segurança, por exemplo, para suportar a implantação de um firewall CBAC.

Para cada item no fluxograma temos recursos específicos que vão se somando até chegar a uma
versão completa chamada “Advanced Enterprise Services”, o qual tem também um custo mais alto.
Portanto para a Cisco lançar uma versão nova de IOS era preciso lançar pelo menos oito imagens de
IOS nesse modelo, uma para cada lista de recursos desejada.

Cada pacote tem um nome específico com uma lista de recursos (features) disponíveis, segue uma
descrição resumida de cada pacote abaixo (nomes válidos a partir da versão 12.3):

IP Base: Imagem de IOS padrão dos roteadores com recursos básicos do protocolo IP.
IP Voice: IOS para recursos de Voz e Dados (VoIP, VoFR e Telefonia IP).
Advanced Security: IOS com recursos de segurança e VPN, incluindo Cisco IOS Firewall, IDS/IPS,
IPSec, 3DES e VPN.
SP Services: Adiciona recursos para Service Providers como SSH/SSL, ATM, VoATM, e MPLS.
Enterprise Base: Protocolos básicos para empresas, porém com mais recursos que o IP Base.
Advanced IP Services: IOS com todos os recursos (features) do Cisco IOS Software.
Enterprise Services: Possuem os recursos do Enterprise Base, suporte IBM completa e serviços para
provedores.
SP Services: Recursos para empresas de Telecom como MPLS, ATM e VoATM.

107
A grande diferença com a entrada da família ISR-G2 é que ao invés da Cisco desenvolver
várias imagens de IOS para diferentes feature sets, todas as feature sets estão integradas em
uma mesma imagem chamada de Universal, sendo que a liberação dos recursos se dá
através de um processo de licenciamento.

Portanto na versão 15 do Cisco IOS existe uma imagem única chamada de Universal
Image, a qual possui os recursos (features) similares ao IP Base, ou seja, apenas recursos
básicos do protocolo IP estão liberados para uso.

A diferença da versão 15 para as versões anteriores é que agora foi introduzido o conceito
de licenças para liberar features avançadas (recursos de software mais avançados).

Existem licenças para recursos de Segurança (Security), Comunicações Unificadas

(Unified Communications ou Voice – VoIP e telefonia IP) e Dados (Data)

No Cisco IOS esses recursos ou packings são chamados de:

ipbasek9 (IP Base ou licença básica): funcionalidades básicas do Cisco IOS.
datak9 (Data ou dados): suporta recursos como MPLS, ATM, multiprotocolos e suporte a
IBM.
uck9 (Unified Communications ou Voz): suporta recursos de VoIP e Telfonia IP.
securityk9 (Security ou segurança): suporta recursos de segurança tais como IOS firewall,
IPS, IPsec, 3DES e VPN.

108
No Cisco IOS esses recursos ou packings são chamados de:

ipbasek9 (IP Base ou licença básica): funcionalidades básicas do Cisco IOS.

datak9 (Data ou dados): suporta recursos como MPLS, ATM, multiprotocolos e suporte a
IBM.
uck9 (Unified Communications ou Voz): suporta recursos de VoIP e Telfonia IP.
securityk9 (Security ou segurança): suporta recursos de segurança tais como IOS firewall,
IPS, IPsec, 3DES e VPN.

Portanto, para ter recursos de voz não será necessário instalar uma nova versão de IOS
como a IP Voice da versão 12.4, por exemplo. Ao invés disso, será preciso apenas liberar
uma licença para ativar os recursos de voz (Unified Communications) no roteador em
questão.

Então quantas versões de imagens de IOS a Cisco precisaria lançar no modelo anterior para
um mesmo equipamento? Várias, uma para cada combinação de recursos (feature set)
necessária. Já para a nova versão de IOS Packing é lançada apenas uma versão que
contempla todos os recursos para cada modelo de equipamento e release de software,
precisando de licenciamento para liberação dos recursos mais avançados.

109
O roteador em questão é um Cisco 1941, o qual não tem suporte a recursos de Voz, por isso
são listadas as tecnologias ipbasek9, securityk9 e datak9, sendo que a primeira possui uma
licença permanente e as duas últimas são apenas de avaliação, precisando de uma chave
válida para ser registrada permanentemente.

110
A ideia por trás do licenciamento de IOS introduzido para a linha de roteadores ISR-G2
(1900/2900/3900) é simples, pois para utilizar “feature sets” ou recursos de software que já
estão presentes na imagem universal é preciso destravar (unlock) a feature set utilizando um
processo de ativação de software definido pela Cisco.

Esse processo de ativação de software tem dois objetivos principais:

Habilitar recursos (Enable): habilitar ou ativar as features no roteador, pois sem essa
ativação de software somente os recursos básicos irão funcionar, ou seja, features avançadas
e seus comandos não serão reconhecidos pela CLI.

Verificar direitos legais: com esse processo a Cisco valida se o cliente final realmente
pagou pelo direito de utilizar aquela feature set no roteador onde ela está sendo ativada.

Podemos ativar as licenças manualmente ou utilizando o Cisco License Manager (CLM).

Uma alternativa diferente para o licenciamento é quando compramos um roteador e as
licenças são instaladas na própria fábrica, não sendo necessário nenhum trabalho por parte
do administrador de redes para sua ativação.

111
Locais para localizar as informações de UDI no roteador
Comando CLI: exibir o UDI de licença
Comando CLI: exibir versão
Na etiqueta plástica amarrada diretamente ao roteador

Essa informação será necessária mais tarde, para comprar atualizações e transferir e
pesquisar licenças.

112
A versão visual agora possui informações adicionais relacionadas à licença. Várias maneiras
de exibir estes dados.

Permite a identificação de:

• Status atual do pacote de tecnologia.

• Tipo atual de licença do pacote de tecnologia.
• Status da licença do pacote de tecnologia na próxima inicialização.

113
Mostra todas as licenças relacionadas. Tecnologia e função inclusas.

Primeira opção: ipbasek9 tem licença permanente, sem data de expiração

A tela mostra que os dados temporários da licença de tecnologia foi usada durante 18min e
59seg.

114
Exibe atributos da licença.
Exibe a lista atual de todos os recursos no roteador e quais estão ligadas.

115
Antes de ativar uma licença (se quiser que ela seja permanente) você precisa fazer o upload
do arquivo de licença (.lic) em flash.

Para ativar: license boot module <Model> technology-package <Package>

Para desativar: no license boot module <Model> technology-package <Package> OU

license boot module <Model> technology-package <Package> desabilitar

116
O processo de ativação manual necessita que você utilize um navegador de internet, conecte-se com
o site “Cisco Product License Registration Portal” (parte do sítio de Internet Cisco.com) e também
utilize alguns comandos via CLI no roteador ater licenças ativadas.

No site do Cisco Product License Registration Portal (www.cisco.com/go/license) você deve entrar
com o UDI (unique device identifier) do roteador se necessário. A informação é obtida com o
comando show license udi.

Na mesma página digite o PAK para a licença comprada, serial que deve ter sido fornecido pela
Cisco ou pela revenda que forneceu o roteador.

O Product Authorization Key ou PAK é uma espécie de recibo que contém um número único
gerado pela Cisco com a finalidade de confirmar em um banco de dados que aquela licença de
feature set realmente foi comprada. Com o UDI e o PAK será gerado pelo site de licenciamento
citado no passo 1 uma chave única de ativação que você deverá utilizar para liberação da ou das
feature sets adquiridas.
Pode ser que o processo de ativação na prática não peça primeiro o UDI e sim o PAK.

Preencha os campos necessários solicitados após entrar com o valor do PAK e no final copie a chave
da licença (license key por download ou email) quando indicado pelo Portal de Product License
Registration.

Disponibilize o arquivo via USB ou através de um servidor de rede, por exemplo, um servidor TFTP.

Pela CLI do roteador digite o comando “license install caminho-da-licença” para instalar a licença
no roteador

117
Este comando é emitido para verificar se o pacote de tecnologia já não está habilitado.

118
Observe o output após emitir o comando do módulo de inicialização de licença:

• Emita o comando “escrever” ou “escreva"

• O pacote de tecnologia estará ativo após próxima inicialização do roteador
• Emita o comando exibir versão | inicie o comando UDI para verificação

A Cisco permite utilizar as features atualmente sem a compra de um PAK utilizando uma
licença de uso ou right-to-use license.

Para habilitar uma right-to-use license devemos utilizar o comando “license boot module”,
por exemplo, para ativar temporariamente os recursos de Security no roteador R1 como
right-to-use license ou licença de avaliação (evaluation) utilizamos o comando:
Router(config)#license boot module c1900 technology-package securityk9.

Após um reload a licença aparecerá como de avaliação e ativa, porém normalmente uma
right-to-use license aparece com a mensagem “60 days left (8 weeks, 4 days)”, ou seja, ela
tem 60 dias de período de avaliação. A saída continua ao longo do tempo a contar os dias de
maneira decrescente até chegar a 0 dias para expirar, sendo que com as regras atuais em
setembro de 2013 ele converte para um período de tempo ilimitado.

119
Verifique se após a próxima inicialização do roteador os "dados" do pacote de tecnologia
estarão ativos.

120
Observe que há duas maneiras de desativar um pacote de tecnologia:

no license boot module <Model> technology-package <Package>

OU
license boot module <Model> technology-package<Package>

121
122