Introdução a Rede Ipê - Com Junos

Prévia do material em texto

Introdução à 
Rede Ipê 
Gustavo Batista
 
A RNP – Rede Nacional de Ensino 
e Pesquisa – é qualificada como 
uma Organização Social (OS), 
sendo ligada ao Ministério da 
Ciência, Tecnologia e Inovação 
( M C T I ) e r e s p o n s á v e l p e l o 
Programa Interministerial RNP, 
que conta com a participação dos 
ministérios da Educação (MEC), da 
Saúde (MS) e da Cultura (MinC). 
Pioneira no acesso à Internet no 
Brasil, a RNP planeja e mantém a 
rede Ipê, a rede óptica nacional 
acadêmica de alto desempenho. 
Com Pontos de Presença nas 
27 unidades da federação, a rede 
tem mais de 800 instituições 
conectadas. São aproximadamente 
3,5 milhões de usuários usufruindo 
de uma infraestrutura de redes 
avançadas para comunicação, 
computação e experimentação, 
que contribui para a integração 
entre o sistema de Ciência e 
Tecnologia, Educação Superior, 
Saúde e Cultura.
Ciência, Tecnologia
e Inovação
Ministério da
Educação
Ministério da
Saúde
Ministério da
Cultura
Ministério da
Gustavo Batista
Introdução à 
Rede Ipê
Gustavo Batista
Rio de Janeiro
Escola Superior de Redes
2013
Introdução à 
Rede Ipê
Copyright © 2013 – Rede Nacional de Ensino e Pesquisa – RNP 
Rua Lauro Müller, 116 sala 1103 
22290-906 Rio de Janeiro, RJ
Diretor Geral 
Nelson Simões
Diretor de Serviços e Soluções 
José Luiz Ribeiro Filho
Escola Superior de Redes
Coordenação 
Luiz Coelho
Edição 
Pedro Sangirardi
Coordenação Acadêmica de Redes 
Luiz Carlos Lobato
Equipe ESR 
Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Evellyn 
Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Renato Duarte, Sergio Ricardo 
de Souza e Yve Abel Marcial
Capa, projeto visual e diagramação 
Tecnodesign
Versão 
1.1.0
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de 
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e 
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a 
pessoas ou bens, originados do uso deste material. 
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuição 
Escola Superior de Redes 
Rua Lauro Müller, 116 – sala 1103 
22290-906 Rio de Janeiro, RJ 
http://esr.rnp.br 
info@esr.rnp.br
Dados Internacionais de Catalogação na Publicação (CIP)
B333i Batista, Gustavo 
 Introdução à rede Ipê / Gustavo Batista, Sidney Lucena; Colaboração de Beatriz Zoss. – 
 Rio de Janeiro: RNP/ESR, 2013. 
 293 p. : il. ; 28 cm.
 Bibliografia: p. 275. 
 ISBN 978-85-63630-33-9
 1. Redes de computadores – protocolos – conexão. 2. Rede Ipê. I. Lucena, Sidney. II. 
 Zoss, Beatriz. III.Título.
 CDD 004.62
iii
Sumário
Escola Superior de Redes
A metodologia da ESR xi
Sobre o curso  xii
A quem se destina xii
Organização do livro xii
Convenções utilizadas neste livro xiii
Permissões de uso xiv
Reconhecimentos xiv
Sobre os autores xiv
Prefácio xvi
1. Operação da rede Ipê
Impacto da conexão na organização da instituição 1
Serviços IP fundamentais da RNP 2
Serviços de tráfego da RNP 2
Trânsito Nacional 3
Trânsito Internacional 3
Trânsito Acadêmico de Colaboração 3
Trânsito de Peering 3
Outros serviços da RNP 4
Serviços de comunicação e colaboração 6
Conferência Web  6
fone@RNP  6
iv
Videoconferência  8
Telepresença  8
Serviços de disponibilização de conteúdos digitais  9
Videoaula@RNP  9
Vídeo sob Demanda  10
Transmissão de sinal de TV  11
Transmissão de Vídeo ao Vivo  11
Serviços de Gestão de Identidade  12
Comunidade Acadêmica Federada (CAFe) 12
eduroam 12
Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu) 13
Serviço de Hospedagem Estratégica  13
Apoio a serviços 14
Considerações de uso 14
Condições de uso 16
Como fazer quando o link cai 16
Procedimento para checar conexão local 16
Verificar condições básicas de roteamento 18
Procedimento para entrar em contato com o PoP visando abertura de chamado 20
Acompanhamento dos chamados abertos 20
Acompanhamento de problemas relacionados ao backbone 21
Roteiro de Atividades 1 25
Atividade 1.1 – Panorama do tráfego 25
Atividade 1.2 – Falha de conectividade da organização usuária 25
2. Segurança na rede Ipê
Centro de Atendimento a Incidentes de Segurança (CAIS) 27
Como fazer quando ocorre um problema de segurança 28
O que é o atendimento a incidentes? 28
O trabalho do CAIS 29
Recomendações à Organização Usuária 30
A ajuda do CAIS 30
Passos para a segurança de sua instituição 30
3. Infraestrutura de rede
Conexão da organização usuária ao PoP da RNP 33
v
Uso e especificação de switches e roteadores 36
Especificação de racks 37
Fontes redundantes 38
Topologia da rede 39
Identificação de cabos 41
Infraestrutura para abrigar os equipamentos e mantê-los 42
Localização e dimensões da sala 42
Equipamentos de apoio 42
Refrigeração 43
Instalação elétrica 43
Aterramento 43
Espaço para cabeamento e conexões 43
4. Switches e roteadores
Switches L2 45
Switches L3 46
Comutação L2 49
Empilhamento 50
Subdivisão da rede em VLANs de distribuição 51
Roteadores 52
Roteador de borda 56
Troubleshooting básico 56
Estudo de caso 59
Roteiro de Atividades 2 61
Atividade 2.1 – Endereçamento IP 61
Atividade 2.2 – Identificação de soluções 61
Atividade 2.3 – Planejando VLANs 62
Atividade 2.4 – Distribuição das sub-redes 63
5. Serviços e gerenciamento da rede da instituição
Serviços de rede 67
DNS 67
MX 70
Web 70
SFTP 71
vi
E-mail 71
Repositório de arquivos 72
Firewall, DMZ e NAT 73
Procedimento de solicitação de bloco IP 75
Adequação do tamanho do bloco às necessidades da IFES 75
DNS reverso  75
Procedimento para cadastro de reverso 76
Gerenciamento da rede da instituição 77
Ferramentas de monitoramento 78
6. Instalação do roteador da RNP
Requisitos de instalação do roteador 81
Requisitos físicos 81
Requisitos de ventilação 82
Requisitos de ambiente 82
Requisitos elétricos e planejamento de força 82
Manuseio de placas 83
Descarga eletrostática 84
Aterramento 84
Componentes básicos do roteador J2350 85
Componentes básicos do roteador J2320 86
7. Fundamentos de Junos 
Software modular 89
Separação entre planos de Controle e de Encaminhamento 90
Routine Engine (RE) 91
Packet Forwarding Engine 92
Processamento de tráfego 92
Tráfego de trânsito 92
Tráfego de exceção 93
8. Opções de acesso ao Junos
A interface de usuário 95
A CLI do Junos 96
Modos de acesso 96
Ajuda 97
vii
Help Topic 97
Help Reference 98
Completando comandos 99
Teclas de edição EMACS 99
Usando o caractere “pipe” 100
Roteiro de Atividades 3 103
Atividade 3.1 – Acessar o Juniper via console serial 103
Atividade 3.2 – Opções da interface de usuário 106
Modo de operação 107
Modo de configuração 108
Configuração exclusiva 110
Configuração privada 110
Hierarquia do Modo de Configuração 111
Movendo entre níveis no Modo de Configuração 112
Alterando linhas da Configuração Candidata 115
Ativando e desativando configurações 117
Verificando a Configuração Candidata 118
Salvando a Configuração Candidata 119
Checando alterações antes de salvar 122
Restaurando configurações 122
Salvando a configuração em arquivo ASCII 123
Carregando arquivo de configuração 124
Comando run 124
Interface J-Web GUI 125
Processo de login na J-Web 126
Roteiro de Atividades 4 131
Atividade 4.1 – Opções de acesso ao Junos131
9. Configurações do roteador
Configuração default de fábrica 133
Configurações iniciais 135
Entrando no Modo de Configuração 136
Definindo parâmetros de acesso 138
Definindo parâmetros de gerência 138
Configuração de resgate 139
Configuração de interface  140
Nomeando interfaces 141
viii
Múltiplos endereços 142
Propriedades físicas de interfaces 143
Propriedades lógicas de interfaces 143
Verificando o estado das interfaces 145
Roteiro de Atividades 5 147
Atividade 5.1 – Configuração básica (parte 1) 147
Atividade 5.2 – Configuração básica (parte 2) 149
Configurações de Usuário e Autenticação 151
Ordem da autenticação 151
Componentes da autenticação 155
Logs do sistema 158
Interpretando mensagens de log 159
Investigando problemas com traceoptions 160
Visualizando arquivos de log e trace 162
Monitorando arquivos de log e trace 162
Network Time Protocol (NTP) 163
Monitorando o NTP 164
Simple Network Management Protocol (SNMP) 164
MIBs SNMP 165
Configurando SNMP 165
Monitorando a operação do SNMP 167
Roteiro de Atividades 6 169
Atividade 6.1 – Configurações posteriores 169
10. Operação, manutenção e monitoração
Monitorando a plataforma e operando as interfaces 179
Monitorando a operação geral do sistema 179
Monitorando o chassi 180
Verificando o estado das interfaces 181
Estado das interfaces: informação extensiva 182
Monitorando interfaces 183
Utilitários de rede 184
Ping e Traceroute 184
Monitor traffic 185
Clientes de Telnet, SSH e FTP 187
ix
Mantendo o Junos  188
Convenção de nomes de pacotes de Junos 188
Recuperação de senha 189
Instalação e upgrade do Junos 190
Boas práticas de upgrade 191
Roteiro de Atividades 7 193
Atividade 7.1 – Instalação do Junos (parte 1) 193
Atividade 7.2 – Instalação do Junos (parte 2) 194
Atividade 7.3 – Upgrade do Junos 197
11. Fundamentos de roteamento
Conceitos de roteamento 201
Componentes do roteamento 202
Rotas diretamente conectadas 203
Tabela de rotas 203
Múltiplas tabelas de rotas 204
Preferência de rotas: selecionando a rota ativa 204
Verificando a tabela de rotas 207
Forwarding Table (FT) 208
Determinando o Next Hop 209
Instâncias de roteamento 210
Trabalhando com Instâncias de Roteamento 213
Roteamento estático 214
Roteiro de Atividades 8 219
Atividade 8.1 – Configurando rota estática 219
12. Filtros de firewall
Visão geral 223
Diagrama de bloco de um filtro de firewall 224
Condições Match 225
Ações do filtro de firewall 226
Definindo um filtro de firewall 227
Filtrando tráfego local 229
x
Implementando policing com filtros de firewall 230
Estudo de caso: filtros de firewall 234
Monitorando os resultados de um filtro 237
Verificação de RPF Unicast 238
Problemas com a verificação RPF 239
Filtros de “fail” 240
Roteiro de Atividades 9 243
Atividade 9.1 – Configurando filtro de firewall 243
Atividade 9.2 – Configurando polices de firewall 244
13. Troubleshooting em interfaces
Desativando e desabilitando interfaces 247
Exemplos de configuração de interfaces 249
Troubleshooting genérico de interfaces 250
Verificando erros na interface 254
Monitorando interface 255
Teste de loop 256
Tipos de teste de loop 257
Configurando testes de loop 258
Protocolos L2 e testes de loop 259
Ping e testes de loop 260
Troubleshooting específico de interfaces serial e ethernet 262
Interfaces de LAN e convenção de nomes 262
Interfaces E3 263
Verificando o funcionamento físico da porta 263
Checando compatibilidade com equipamento remoto 263
Verificando alarmes ativos em interfaces E3/T3 264
Interfaces E1 265
Alarmes e mídia E1 266
Interfaces Sonet/SDH 268
Monitorando interfaces Sonet/SDH 268
Verificando o estado da interface Sonet/SDH 269
Entendendo a rede Sonet/SDH 270
Bibliografia  275
xi
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) respon-
sável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). 
A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC 
para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades 
federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo 
funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao 
uso eficaz e eficiente das TIC. 
A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto 
de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e 
Governança de TI.
A ESR também participa de diversos projetos de interesse público, como a elaboração e 
execução de planos de capacitação para formação de multiplicadores para projetos edu-
cacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil 
(UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de 
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na 
aprendizagem como construção do conhecimento por meio da resolução de problemas 
típicos da realidade do profissional em formação. 
Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o 
instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e 
informações, mas principalmente como orientador do aluno na execução de atividades con-
textualizadas nas situações do cotidiano profissional. 
A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema 
semelhantes às encontradas na prática profissional, que são superadas por meio de análise, 
síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do pro-
blema, em abordagem orientada ao desenvolvimento de competências. 
Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as 
atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de apren-
dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor 
busca incentivar a participação dos alunos continuamente. 
Escola Superior de Redes
xii
As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das 
atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de 
estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atua-
ção do futuro especialista que se pretende formar. 
As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo 
para as atividades práticas, conforme descrição a seguir:
Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). 
O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema 
da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor 
levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando 
a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o 
aluno se coloque em posição de passividade, o que reduziria a aprendizagem. 
Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). 
Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e 
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto 
no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e 
oferecer explicações complementares. 
Terceira etapa: discussão das atividades realizadas(30 minutos). 
O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, 
devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a 
comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, 
estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem 
soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.
Sobre o curso 
A ESR elaborou este material com o objetivo de auxiliar na capacitação dos técnicos das novas 
instituições usuárias em sua conexão ao backbone da RNP, uma vez que a configuração dos 
equipamentos e da infraestrutura necessária é de responsabilidade da instituição usuária.
O curso descreve a RNP, a estrutura do seu backbone, seus Pontos de Presença (PoPs), 
os procedimentos de manutenção e o impacto da conexão à RNP nas novas instituições 
usuárias. São abordados aspectos técnicos da infraestrutura física, de conexão e de TI, 
o uso de switches e roteadores, a infraestrutura de TI da organização e a solicitação de 
blocos IP. Ainda serão descritos em detalhes a configuração, manuseio, manutenção e pro-
blemas de interface do roteador Juniper da RNP, além de conceitos básicos de roteamento 
e utilização de filtros de firewall.
A quem se destina
O curso é destinado aos técnicos de suporte e gerentes de infraestrutura de TI das organiza-
ções usuárias da rede RNP.
Organização do livro
O livro está organizado em partes bem definidas para facilitar o acesso ao conteúdo que o 
leitor desejar.
O Capítulo 1 apresenta a operação da RNP, os procedimentos de manutenção e o impacto 
da conexão à rede da RNP nas novas instituições usuárias. São propostas também ativida-
des práticas para fixação do conteúdo.
xiii
O Capítulo 2 descreve os procedimentos de segurança, as funções e as atividades exe-
cutadas pelo Centro de Atendimento a Incidentes de Segurança (CAIS) e como tratar um 
problema de segurança.
Os Capítulos 3, 4 e 5 descrevem a infraestrutura de rede recomendada para as instituições 
usuárias, a estrutura necessária para instalar os equipamentos da RNP, os conhecimen-
tos técnicos desejáveis para a equipe de TI relativos a equipamentos, tais como switches 
e roteadores e suas funcionalidades. Descrevem também os serviços de rede local dese-
jáveis, e recomendam procedimentos de gerenciamento da rede da instituição usuária. 
São propostas atividades práticas e estudos de caso para fixação dos conhecimentos 
técnicos apresentados.
Os Capítulos de 6 a 13 tratam especificamente do roteador da RNP, sua instalação, carac-
terísticas do sistema operacional Junos, configurações básicas e avançadas do roteador, 
procedimentos de operação e manutenção, configuração de rotas estáticas e utilização 
de filtros de firewall. Finalmente, são apresentados procedimentos básicos de resolução 
de problemas em interfaces do roteador. 
Esta última parte do livro vem acompanhada de atividades práticas realizadas em laboratório 
com roteadores idênticos aos que as instituições usuárias receberão da RNP, permitindo que 
os seus técnicos possam tirar o maior proveito da interligação com a rede da RNP. 
Todas as atividades são acompanhadas das respectivas soluções, para que os técnicos 
possam, a qualquer momento, reproduzir essas atividades em seus locais de trabalho.
Convenções utilizadas neste livro
As seguintes convenções tipográficas são usadas neste livro:
Itálico 
Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto. 
Largura constante
 
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída 
de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem 
o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).
Conteúdo de slide 
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula. 
Símbolo 
Indica referência complementar disponível em site ou página na internet.
Símbolo 
Indica um documento como referência complementar.
Símbolo 
Indica um vídeo como referência complementar. 
Símbolo 
Indica um arquivo de aúdio como referência complementar.
xiv
Símbolo 
Indica um aviso ou precaução a ser considerada.
Símbolo 
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao 
entendimento do tema em questão.
Símbolo 
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou 
mesmo uma observação.
Permissões de uso
Todos os direitos reservados à RNP. 
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. 
Exemplo de citação: Batista, Gustavo. Introdução à rede Ipê. Rio de Janeiro: Escola Superior 
de Redes, RNP, 2013.
Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação: 
Escola Superior de Redes RNP 
Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo 
Rio de Janeiro – RJ – 22290-906 
E-mail: info@esr.rnp.br
Reconhecimentos
Esta publicação não teria sido possível sem a colaboração da área de Engenharia de Redes 
e Operações da RNP. Agradecemos ao Centro de Atendimento a Incidentes de Segurança 
(CAIS) e a Gestão de Serviços da RNP pela sua contribuição; a Juniper Networks por ter 
gentilmente cedido os manuais técnicos que foram fundamentais para a elaboração deste 
conteúdo; a Sidney Lucena, ex-Coordenador Acadêmico de Redes da ESR, que organizou 
a primeira versão desse curso; e, finalmente, nosso muito obrigado a Beatriz Zoss, a Bia, 
gerente de relacionamento da RNP que identificou a necessidade e propôs a elaboração 
deste curso. 
Sobre os autores
Gustavo Batista graduou-se em Engenharia de Telecomunicações pela Universidade Fede-
ral Fluminense em 2003. Trabalhou durante 3 anos em operadora de telefonia celular com 
sistemas de gerência de rede telefônica, administrando sistemas Unix, Linux e Windows 
e executando projetos de integração de sistemas de gerência de diferentes fabricantes 
em uma plataforma única. Trabalhou no Centro de Engenharia e Operações da RNP (CEO) 
como analista de redes. Hoje atua na área de operações da rede multisserviços de uma 
empresa nacional de porte, onde também participa de projetos nas áreas de QoS em redes 
IP e desempenho de rede.
xv
Luiz Carlos Lobato é formado em Engenharia Eletrônica pelo ITA, com pós-graduação 
em Negócios e Serviços de Telecomunicações pelo CEFET-RJ. Possui certificação de redes 
CiscoCCNA. Gerente da Divisão de Suporte Técnico da Telebrás até a privatização das tele-
comunicações, sendo responsável pela operação e gerência da rede de dados do Sistema 
Telebrás. Após a privatização atuou como Coordenador de Cursos de Tecnologia de Redes 
(Graduação Superior) em diversas faculdades. É colaborador da Escola Superior de Redes 
desde 2008, tendo elaborado material de treinamento e lecionado diversos cursos na área 
de Redes. Atualmente é Coordenador Acadêmico de Redes da ESR.
xvi
Prefácio
Lembro com nitidez do dia em que, juntamente com Bia Zoss e Luiz Coelho, decidimos pela 
elaboração de um curso para o qual este livro se destina. Foi no ano de 2008, quando dois 
grandes desafios nos foram colocados: a conexão de centenas de novos campi de universi-
dades e de institutos federais – fruto da política de expansão do ensino do Governo Federal 
– e a mudança do fornecedor dos equipamentos roteadores usados para a conexão com a 
Internet das nossas instituições clientes. Assim, além de capacitá-los a recepcionar o enlace 
de dados da sua instituição, detectamos que seria importante também fazer uma apre-
sentação da própria RNP. Nessa ocasião, a despeito de todas as dificuldades e dos riscos 
envolvidos, optamos pela estratégia de “ensinara pescar”.
O desafio de criar um material para dar conta dessas duas questões e ser apresentado em 
um curso de 20 horas foi dado a Gustavo Batista, um ex-colaborador da RNP que, com sua 
saída, além de causar um sério desfalque na equipe, deixou o seu gestor com um zumbido 
nos ouvidos que ele conserva até os dias atuais. E, conforme vocês verão, Gustavo não 
decepcionou: preparou um excelente material que deve ser usado não apenas na sala de 
aula, mas no dia a dia do seu trabalho. Uma isca de primeira qualidade para a sua pescaria.
Ari Frazão Jr.
Gestor de engenharia e operações da RNP
1
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
ob
je
tiv
os
conceitos
1
Operação da rede Ipê
Orientar a instituição sobre os procedimentos adequados para se conectar ao 
backbone da RNP e tratamento dos problemas de conexão.
 
Impacto da conexão na organização, serviços fundamentais da RNP, considerações de 
uso, procedimentos de abertura de chamado, acompanhamento de problemas.
 
 
Impacto da conexão na organização da instituição
q 1 A organização usuária dos serviços da RNP passa a fazer parte do sistema autônomo 
da RNP. 
 1 A partir de então, todos os pontos da internet mundial passarão a enxergar a insti-
tuição como um cliente da RNP.
 1 Os endereços IP usados na rede da instituição serão cedidos pela RNP.
 1 Todos os equipamentos da rede local que precisarem do serviço da rede Ipê deverão, 
necessariamente, usar endereço IP da RNP. 
 2 É proibido o uso dos serviços da RNP sem o atendimento a esse requisito.
 1 Caso a instituição deseje manter os serviços de outro provedor além da RNP, os equi-
pamentos servidos pelo outro provedor não poderão usar endereços IP da RNP. 
 1 Da mesma forma, os equipamentos endereçados com IPs cedidos pela RNP não 
poderão usar o serviço de outro provedor sob nenhuma hipótese. 
 1 Assim, essas duas redes deverão ser segmentadas; do contrário, podem ocorrer 
sérios problemas de roteamento.
Embora o cenário descrito seja permitido, não é aconselhável. A figura a seguir ilustra um 
cenário proibido:
Sistema autônomo 
Provedor de rede 
formalizado como parte 
integrante da internet 
mundial. A formalização 
se dá através de um 
identificador chamado 
Autonomous System 
Number (ASN), único em 
todo o planeta.
2
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
RNP
Provedor 
comercial
LAN
organização
usuária
Hosts com IP da RNP
A figura a seguir ilustra um cenário permitido caso se deseje manter a conexão de outro provedor 
depois de se tornar cliente da RNP. O cenário ilustrado, embora permitido, não é recomendado.
RNPProvedor 
comercial
Organização
usuária
Hosts com IP da RNPHosts com IP de terceiro
Serviços IP fundamentais da RNP
Serviços de tráfego da RNP
q 1 As instituições primárias e secundárias poderão cursar todo o seu tráfego pela RNP. 
 1 Elas estão aptas a utilizar em sua totalidade os serviços IP fundamentais da RNP, a saber:
 2 Trânsito Nacional.
 2 Trânsito Internacional.
 2 Trânsito Acadêmico de Colaboração.
 2 Trânsito de Peering.
A definição de cada um desses serviços é ilustrada a seguir.
Figura 1.1 
Hosts com IP RNP 
não podem usar 
serviço de outro 
provedor, e vice-
versa.
Figura 1.2 
Cenário permitido 
em instituição com 
dois provedores.
3
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
Trânsito Nacional
qÉ definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas, 
recursos e sistemas localizados em algum ponto do país conectado à rede Ipê, direta ou 
indiretamente através de uma rede regional.
Internet 
Commodity
Nacional
Cliente
BACKBONE
PoP
Trânsito Internacional
qÉ definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas, 
recursos e sistemas localizados em algum ponto fora do país através da internet global.
Internet 
Commodity
Internacional
Cliente
BACKBONE
PoP
Trânsito Acadêmico de Colaboração
qÉ definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas, 
recursos e sistemas localizados em algum ponto nas redes acadêmicas no Brasil e em 
outros países.
Internet 
Acadêmica 
Internacional
Cliente
BACKBONE
PoP
Trânsito de Peering
qÉ definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas, 
recursos e sistemas localizados em redes comerciais nacionais ou internacionais, redes 
corporativas e redes federais autônomas através de acordos de troca de tráfego estabe-
lecidos entre a rede Ipê e essas redes.
Figura 1.3 
Exemplo de 
Trânsito Nacional.
Figura 1.4 
Exemplo 
de Trânsito 
Internacional.
Figura 1.5 
Exemplo de 
Trânsito Acadêmico 
de Colaboração.
4
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
PoP
PTT
Empresa 
Privada
Cliente
BACKBONE
A figura seguinte resume os serviços fundamentais aos quais o cliente da RNP tem acesso:
BACKBONE
RedeComep
Rede 
Acadêmica
Estadual
Internet Acadêmica
Internacional
Cliente A
Cliente B
PoP PTT
Empresa 
Privada
Provedor 
Internet Commodity 
Nacional
Provedor 
Internet Commodity 
Internacional
3
3
2
1
4
Os números das setas estão associados aos serviços da seguinte maneira:
 1 Trânsito Nacional: seta 1;
 1 Trânsito Internacional: seta 2;
 1 Trânsito Acadêmico: setas 3;
 1 Trânsito de Peering: seta 4.
Outros serviços da RNP
q 1 Serviços de comunicação e colaboração:
 2 Conferência web.
 2 fone@RNP.
 2 Videoconferência.
 2 Telepresença.
Figura 1.6 
Exemplo de 
Trânsito de Peering.
Figura 1.7 
Serviços 
fundamentais RNP.
5
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
q 1 Serviços de Disponibilização de Conteúdos Digitais: 
 2 Videoaula@RNP.
 2 Vídeo sob Demanda.
 2 Transmissão de Sinal de TV.
 2 Transmissão de Vídeo ao Vivo.
 1 Serviços de Gestão de Identidade:
 2 Comunidade Acadêmica Federada (CAFe).
 2 eduroam.
 2 Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu).
 1 Serviços de Hospedagem Estratégica:
 2 Internet Data Center (IDC).
 1 Apoio aos serviços:
 2 Service Desk.
Os serviços disponibilizados pela RNP às suas organizações usuárias são resultados de pro-
cessos de inovação e prospecção, de acordo com as necessidades dos clientes, em atividades 
de análise de cenários e tendências com parceiros como a academia, o setor empresarial e as 
principais redes acadêmicas mundiais. Os principais benefícios dos serviços da RNP são faci-
litar e promover a comunicação, a colaboração à distância e a disseminação de conhecimento.
As informações sobre os serviços disponibilizados pela RNP para suas organizações usuárias 
e comunidades de clientes especiais e estratégicos encontram-se consolidadas no Catálogo 
de Serviços, estando os serviços classificados da seguinte forma: 
 1 Serviços de Comunicação e Colaboração: 
 2 Conferência web.
 2 fone@RNP.
 2 Videoconferência.
 2 Telepresença.
 1 Serviços de Disponibilização de Conteúdos Digitais: 
 2 Videoaula@RNP.
 2 Vídeo sob Demanda.
 2 Transmissão de Sinal de TV.
 2 Transmissão de Vídeo ao Vivo.
 1 Serviços de Gestão de Identidade: 
 2 Comunidade Acadêmica Federada (CAFe).
 2 eduroam.
 2 Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu).
 1 Serviços de Hospedagem Estratégica:
 2 Internet Data Center (IDC).
6
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Serviços de comunicação e colaboração
qA RNP oferece aos seus clientes os seguintes serviços de comunicação e colaboração:
 1 Conferência web.
 1 fone@RNP.
 1 Videoconferência.
 1 Telepresença.Conferência Web 
O objetivo principal do serviço é realizar reuniões virtuais entre participantes remotos com a 
utilização de recursos de áudio, vídeo, texto, quadro de notas, chat e imagens, além do compar-
tilhamento da tela do computador ou de aplicativos específicos. Ele se destaca pela facilidade 
de uso e mobilidade, aliada a um investimento de baixo custo para as instituições clientes.
Voltado para clientes que demandam uma solução de menor custo para reuniões virtuais, 
treinamentos e palestras à distância, o serviço também se destaca pela facilidade de uso. 
Para utilizar toda a integração e a interatividade disponibilizadas pela conferência web, 
basta um computador, celular ou tablet conectado à internet, um navegador (browser) e 
um conjunto de microfone e fone de ouvido, sem necessidade adicional de hardware ou 
software. Além desses recursos, o serviço possui a funcionalidade de gravar reuniões, que 
podem ser disponibilizadas para visualização ou baixadas para armazenamento.
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/conferencia-web 
fone@RNP 
Serviço que permite a interconexão VoIP (Voz sobre IP) entre diferentes organizações. Com 
isso, os clientes deste serviço conseguem oferecer a seus usuários a possibilidade de rea-
lizar chamadas telefônicas gratuitas para outras instituições distantes geograficamente no 
Brasil ou no exterior, dentro ou fora da rede VoIP da RNP. 
Figura 1.8 
Conferência Web.
7
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
O benefício das ligações gratuitas para o usuário final se estende através da capilaridade do 
fone@RNP, com presença em todos os estados brasileiros, e das conexões VoIP com a rede 
pública de telefonia de algumas instituições clientes, o que propicia ao usuário final ligar 
para um número telefônico comum a partir de um ramal VoIP. Destaque também para a 
interconexão da rede VoIP da RNP com outras redes VoIP dentro e fora do país.
Atualmente, o fone@RNP reúne mais de cem instituições clientes distribuídas pelo território 
nacional, com mais de 40 organizações que completam ligações para a rede pública de 
telefonia. Conta também com acordos de troca de tráfego com outras redes VoIP do governo 
brasileiro e de instituições de ensino e pesquisa da Argentina, Austrália, Bélgica, Croácia, 
Eslovênia, Espanha, Grécia, Holanda, Hungria, Itália, Letônia, Lituânia, México, Portugal, 
Sérvia e Suíça. Os acordos com esses países foram possibilitados pela integração do serviço 
à iniciativa internacional do NreNum.net, da Terena (Associação de Redes de Educação e 
Pesquisa Transeuropeia).
Além das ligações telefônicas gratuitas, as instituições clientes podem acessar um sistema 
centralizado de estatísticas, que propicia ao gestor da infraestrutura local dispor de dados 
sobre como o serviço tem sido utilizado na sua instituição ou em outras que integram o 
fone@RNP.
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/fone-rnp 
Sistema de estatísticas do fone@RNP
q 1 O sistema de estatísticas do fone@RNP (http://estatisticasfone.rnp.br/) visa pro-
porcionar uma visão detalhada do uso e da economia que o serviço traz para suas 
instituições clientes.
 1 Dado o acesso aberto ao sistema, as organizações podem obter informações que 
subsidiem decisões locais relacionadas à disseminação do uso institucional, com base 
na demonstração da economia obtida. 
 1 A adesão ao sistema é feita como parte da homologação da instituição no serviço.
 
Figura 1.9 
Estatísticas do 
fone@RNP.
8
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Videoconferência 
Fornecer salas virtuais para viabilizar a realização de videoconferências multiponto para as 
instituições clientes sem que estas precisem arcar com o ônus de adquirir uma solução local 
para isso. 
O serviço também oferece recursos de gravação, streaming e integração com sistemas de 
videoconferência que utilizem ISDN, além de alta definição (Hd) e novas funcionalidades 
que podem surgir em decorrência de melhorias e investimentos contínuos na ampliação da 
infraestrutura da videoconferência.
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/videoconferencia
Telepresença 
Participantes em diferentes locais interagindo como se estivessem frente a frente na mesma 
mesa de reunião; essa experiência imersiva é a proposta do serviço de telepresença. Verda-
deiro estado da arte na tecnologia de videoconferência, o serviço oferece recursos tecno-
lógicos de ponta em salas físicas planejadas e ambientadas especificamente para ampliar a 
sensação de realismo na colaboração entre participantes remotos. 
Com áudio e vídeo de alta qualidade, atualmente são oferecidas aos clientes do serviço seis 
salas, distribuídas por cinco estados do país. Cada uma delas está equipada com câmeras 
de alta definição posicionadas para a melhor cobertura do espaço assim que o sistema for 
iniciado, sem que os participantes precisem se preocupar com os ajustes dos equipamentos 
durante as reuniões. 
A telepresença pode ser usada de forma integrada com outros serviços da RNP, como a vide-
oconferência e o fone@RNP, e também pode ser realizada por meio da conexão entre duas 
salas (ponto a ponto) ou mais ambientes (multiponto).
Figura 1.10 
Videoconferência.
9
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/telepresenca1 
Serviços de disponibilização de conteúdos digitais 
q 1 Videoaula@RNP.
 1 Vídeo sob Demanda.
 1 Transmissão de Sinal de TV.
 1 Transmissão de Vídeo ao Vivo.
A RNP oferece aos seus clientes os serviços descritos a seguir, voltados para a disponibilização 
de conteúdos digitais.
Videoaula@RNP 
Serviço integrado para elaboração, armazenamento e disponibilização pela web de videoaulas 
produzidas pelas instituições clientes. Tais organizações passam a ter, por meio desse 
serviço, um meio para acesso e armazenamento de um amplo e interessante material didático 
formado por múltiplas mídias (vídeo, áudio, animações, roteiro e arquivos de apoio), que 
pode ser utilizado como apoio ao ensino à distância ou presencial. 
O upload das videoaulas digitais é feito em um sistema com redundância e alta disponibilidade, 
resultando em um acesso rápido e fácil a partir de um simples navegador (browser).
Figura 1.11 
Telepresença.
10
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/videoaula-rnp 
Vídeo sob Demanda 
Vídeo Sob Demanda é o ambiente para disponibilização e armazenamento de conteúdo 
audiovisual, a partir de um portal web (video.rnp.br) que contém vídeos públicos ou res-
tritos, que podem ser postados por integrantes das organizações clientes da RNP e assis-
tidos potencialmente por qualquer usuário da internet. 
Mais do que um portal para upload e visualização de vídeos com interface amigável, e infra-
estrutura de servidores distribuídos que otimiza o acesso e a distribuição do seu conteúdo 
pelo território nacional, este serviço se diferencia dos outros portais de vídeo da internet 
pela procedência do material disponível. Afinal, o conteúdo é oferecido pela comunidade 
brasileira de ensino e pesquisa e pelas demais organizações vinculadas aos ministérios e ins-
tituições com os quais a RNP desenvolve parcerias. 
Beneficia-se também da rede de vídeo digital (RVD), uma rede de disponibilização de conte-
údos (CDN) estruturada a partir de equipamentos, denominados refletores, distribuídos por 
27 Pontos de Presença (PoPs) interligados pela rede Ipê. Os refletores permitemque os vídeos 
solicitados fiquem temporariamente armazenados, agilizando o acesso regional ao conteúdo.
Figura 1.12 
Videoaula@RNP.
11
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/video-sob-demanda 
Transmissão de sinal de TV 
Transmissão, pela internet, do sinal de emissoras de TV a partir de uma infraestrutura de 
servidores distribuídos em todos os estados brasileiros. As principais vantagens são a eco-
nomia de banda e a redução do tempo de acesso, já que o cliente não precisa de equipa-
mentos de grande porte para suportar um elevado número de pedidos. 
Este serviço disponibiliza, para a internet, o sinal de TV de emissoras que têm participação 
ou parceria com a RNP e uma programação relevante à comunidade acadêmica, como TV 
escola, TV Brasil e Canal Saúde, dentre outras. 
Mais informações sobre este serviço estão disponíveis em: 
http://portal.rnp.br/web/servicos/transmissao-de-sinal-de-tv 
Transmissão de Vídeo ao Vivo 
O objetivo do serviço de transmissão de vídeo ao vivo é prover uma infraestrutura de ser-
vidores distribuídos ao longo de todo o território nacional, para propiciar uma distribuição 
on-line e otimizada de vídeos para as instituições clientes. Com isso, os clientes que desejam 
transmitir ao vivo um evento realizado em sua organização não precisam ter um servidor 
robusto ou uma grande capacidade de banda para dar conta dos inúmeros acessos simul-
tâneos de usuários e espectadores. A otimização é realizada através de uma conexão desse 
servidor local com a rede de vídeo digital (RVD), infraestrutura que distribui o vídeo para 
todo o território nacional conforme a demanda de acesso dos usuários.
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/transmissoes-de-video-ao-vivo
Figura 1.13 
Vídeo sob 
demanda.
12
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Serviços de Gestão de Identidade 
qA RNP oferece aos seus clientes os seguintes serviços para a gestão de identidade:
 1 Comunidade Acadêmica Federada (CAFe).
 1 eduroam.
 1 Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu).
Comunidade Acadêmica Federada (CAFe)
A comunidade acadêmica federada (CAFe) reúne instituições de ensino e pesquisa brasi-
leiras que podem atuar como provedores de identidade (responsáveis pela autenticação das 
informações dos usuários) e de serviço (oferta de recursos e ferramentas). 
Com isso, a CAFe propicia que os usuários acessem diferentes serviços da rede utilizando o 
login e a senha que possuem na instituição de origem. Além disso, devido às exigências do 
processo de adesão ao serviço, as instituições clientes da CAFe passam a desfrutar também 
da vantagem de propiciar acesso facilitado aos serviços locais através de um login único 
(single sign on) para seus usuários.
Além de atender a um número crescente de instituições de ensino e pesquisa brasileiras, a CAFe 
faz parte de iniciativas internacionais, como a REFEDS (Research and Education Federations), 
gerenciada pela Terena, que articula as necessidades de federações de identidade para edu-
cação e pesquisa em todo o mundo; e o serviço edugain, da Géant, que reúne em uma rede 
de confiança outras federações análogas à CAFe espalhadas por todo o mundo, além de um 
número significativo de serviços oferecidos a essas federações, que podem ser potencial-
mente compartilhados na CAFe.
Mais informações sobre o serviço em: 
http://portal.rnp.br/web/servicos/cafe
eduroam
O eduroam (education roaming) é um serviço de acesso sem fio seguro, desenvolvido para 
a comunidade internacional de educação e pesquisa. A iniciativa permite que estudantes, 
pesquisadores e equipes das instituições participantes obtenham conectividade à internet, 
através de conexão sem fio (Wi-Fi) dentro de seus campi e em qualquer localidade que 
ofereça esta facilidade como provedora de serviço.
Figura 1.14 
CAFe.
13
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
Lançada no Brasil em 2012, a iniciativa internacional já reúne instituições de aproximada-
mente 60 países, unindo diversos usuários na troca de experiências e conhecimento de 
forma simples, rápida e segura a partir da internet.
O eduroam oferece acesso seguro e sem fio à internet para estudantes e pesquisadores 
nas universidades cadastradas, sem necessidade de múltiplos logins e senhas. Após efetuar 
o registro na base do serviço, seguido da configuração do computador do usuário para 
conexão com a rede, é possível acessar a web em qualquer provedor de serviço do mundo. 
Mais detalhes sobre a adesão ao serviço e sua utilização em: 
http://portal.rnp.br/web/servicos/eduroam 
Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu)
A Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPedu) consiste na implan-
tação de uma estrutura para criação de certificados digitais e chaves de segurança aplicados 
em autenticação, assinatura digital e sigilo dentro do ambiente das instituições federais de 
ensino superior (IFES), Unidades de Pesquisa (UPs) e demais instituições de ensino.
Assim, as instituições clientes podem emitir gratuitamente os próprios certificados digitais, 
que funcionam como assinaturas eletrônicas para pessoas e serviços. Consequentemente, 
passam a ter mais credibilidade em seus processos administrativos, além de ganhar em efi-
ciência, economizando tempo e recursos financeiros e garantindo a identidade do portador 
de documentos eletrônicos específicos utilizados nesses processos.
Mais detalhes sobre o serviço em: 
http://portal.rnp.br/web/servicos/icpedu
 
Serviço de Hospedagem Estratégica 
Serviço da RNP planejado para fornecer um alto nível de infraestrutura e gerenciamento 
de ambiente de tecnologia da informação e comunicação, atendendo a demanda do cliente 
com garantia de alta disponibilidade, segurança e operação ininterrupta.
O IDC garante monitoramento de banda por usuário, relatórios via web em tempo real e 
contato permanente com a equipe especializada do centro de operações. Além disso, quin-
zenalmente, o Centro de Atendimento a Incidentes de Segurança (CAIS) envia uma análise 
detalhada que indica eventuais correções de segurança necessárias.
A RNP oferece toda a infraestrutura física, elétrica e lógica para abrigar as máquinas, 
abrindo uma porta de acesso à rede ipê. O IDC ocupa um espaço com controle de acesso, 
vigilância com câmeras, climatização ininterrupta, redundância e sistemas de segurança, 
detecção e combate a incêndios. Encontra-se estrategicamente localizado em Brasília (DF), 
abrigando em suas instalações o Ponto de Presença da RNP no Distrito Federal (PoP-DF), 
diretamente conectado ao backbone de educação e pesquisa multigigabit da rede Ipê. 
Figura 1.15 
ICPEdu.
14
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Mais detalhes sobre o Internet Data Center da RNP podem obtidos em: 
http://portal.rnp.br/web/servicos/internet-data-center
Apoio a serviços
O Service Desk tem como objetivo principal o atendimento de primeiro nível aos serviços 
da RNP, ou seja, o atendimento aos clientes que desejam aderir, agendar, reclamar ou 
demandar o uso dos serviços oferecidos pela RNP às suas instituições usuárias.
O Service Desk não tem a finalidade de substituir o suporte local das instituições clientes, 
que continua sendo fornecido pelas equipes de suporte local ou pelo responsável técnico 
do serviço. A atuação do Service Desk começa, portanto, quando estes grupos locais ou 
pessoas autorizadas precisam demandar ou reclamar dos serviços ofertados pela RNP.
Assim, o escopo de ação do ServiceDesk está circunscrito ao suporte remoto dos clientes 
da RNP, ou seja, àquelas instituições usuárias qualificadas para fazer uso dos seus serviços e 
que possuem uma estrutura de suporte local para seus usuários finais. Além disso, o Service 
Desk realiza atividades proativas relacionadas ao monitoramento do uso dos serviços, 
gerando estatísticas para fins gerenciais e de prestação de contas aos clientes.
Mais detalhes sobre a atuação do Service Desk em: 
http://portal.rnp.br/web/servicos/service-desk
Considerações de uso
A rede Ipê é um dos sistemas autônomos (ASs) que compõem a internet, operando sob o 
número de sistema autônomo 1916. Trata-se de uma infraestrutura de rede formada por um 
conjunto de equipamentos e enlaces de dados sob a administração de uma mesma enti-
dade. Essa infraestrutura possui um Autonomous System Number (ASN) que a identifica e a 
formaliza como uma unidade que compõe a Internet Global.
q 1 A infraestrutura da rede Ipê permitirá atender às aplicações de ensino superior e 
pesquisa de forma eficiente. 
 1 Quando necessário, serão usados mecanismos de segregação de tráfego ou reserva 
de banda para priorizar as aplicações de ensino superior e pesquisa diante das 
demais aplicações em curso na rede.
 1 As organizações usuárias já devidamente qualificadas pelo CG-RNP podem se 
conectar à RNP apenas através de um PoP, direta ou indiretamente (via rede acadê-
mica regional ou Redecomep).
Instituições usuárias classificadas como temporárias somente poderão cursar na rede o tráfego 
referente ao projeto executado em parceria com uma instituição primária ou secundária.
qCaso a instituição possua campi ou filiais remotos, a conexão à rede Ipê desses atores 
poderá ocorrer de duas maneiras:
 1 Conexão física e lógica das filiais à rede Ipê se dá diretamente via PoP RNP.
 1 Conexão física das filiais é via PoP, mas a conexão lógica é com a sede.
15
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
As duas categorias de conexão são exibidas nas figuras seguintes:
A figura anterior exibe a primeira forma de se conectar uma filial à RNP. Nesse modelo a filial 
é tratada como se fosse outro cliente. As setas exibem o tráfego trocado entre a filial e a 
rede Ipê.
A figura anterior exibe a segunda forma de se conectar uma filial à RNP. As setas cinzas 
exibem o tráfego saindo da filial para a rede Ipê. As setas pretas mostram o tráfego gerado 
na rede Ipê com destino à filial. 
q 1 Nesse modelo, a filial é conectada fisicamente ao PoP, mas uma conexão lógica é 
construída de modo que todo o tráfego da filial seja forçado a passar pela sede.
 1 Essa categoria de conexão é adequada quando se deseja que a filial esteja submetida 
às mesmas políticas de roteamento e de segurança da sede, mas a filial não tem os 
equipamentos necessários para a aplicação dessas políticas (firewalls, web sense etc.).
Existem várias tecnologias que poderão ser usadas para implementar esse tipo de conexão 
lógica (Túnel GRE, túnel IPSec, roteamento estático etc.).
É importante frisar que essa categoria de conexão aumenta a carga do enlace de dados da 
instituição-sede com a RNP.
Figura 1.16 
Conexão da filial 
diretamente com 
o PoP.
Figura 1.17 
Conexão lógica da 
filial com a sede.
16
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Condições de uso
Na execução de suas atividades de ensino e pesquisa, as organizações usuárias podem usar 
os serviços fundamentais de trânsito nacional, internacional, acadêmico e de peering, bem 
como os serviços avançados, que serão descritos no decorrer do curso. 
qO uso desses serviços não será permitido nas seguintes condições:
 1 Transmissão de materiais considerados ilegais por caracterizarem: 
 2 Transgressão de direitos autorais. 
 2 Agressão à criança e ao meio ambiente. 
 2 Atentado à privacidade ou discriminação racial ou religiosa.
 2 Disseminação de propaganda comercial, política ou religiosa.
 2 Transmissão de material de propaganda não solicitado pelo destinatário (spam).
 2 Atividades estritamente comerciais.
 2 Atividades que contribuam para o esgotamento excessivo dos recursos da rede, 
sejam computacionais, comunicacionais ou humanas.
 2 Promoção de corrupção ou destruição de dados de usuários.
 2 Atividades prejudiciais à utilização dos serviços de rede por outros usuários.
 2 Interligação ou abrigo em seu espaço de endereçamento de uma terceira insti-
tuição, não qualificada para usar serviços da RNP.
Como fazer quando o link cai
Procedimento para checar conexão local
Ao perceber perda de serviço e/ou reclamações de usuários, o primeiro passo é verificar a 
conexão com a RNP. Este tópico exibe algumas ações sugeridas para checar a conexão local 
antes de acionamento do PoP da RNP. A execução das ações que serão sugeridas facilitará as 
ações do PoP, caso este seja acionado.
Além das sugestões descritas é importante que o contato técnico da instituição verifique 
junto ao seu PoP as ações que aquele ator recomenda. Cada PoP dispõe de diferentes 
recursos para prover essa verificação.
Figura 1.18 
Interligação 
proibida de 
instituição não 
qualificada.
17
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
A figura anterior mostra uma conexão típica entre a organização usuária e o PoP.
Podemos chamar as interfaces de onde saem as setas de:
 1 Uplink da organização usuária (seta na parte inferior da figura);
 1 Downlink da organização usuária (seta na parte superior da figura).
qEm geral essas duas interfaces fazem parte de uma sub-rede IP com dois endereços 
(rede /30). 
Um dos endereços é associado ao downlink e o outro é associado ao uplink.
q 1 O primeiro procedimento a ser executado para verificação da saúde da conexão local 
é a verificação do estado do roteador Juniper da instituição e da interface de uplink. 
 1 Para tal deve-se proceder com as seguintes verificações:
 2 Verificar se o roteador está ligado e operacional.
 2 Se o roteador estiver desligado e não for possível reativá-lo através do botão 
“Power”, deve-se abrir um chamado no PoP.
 2 Verificar as condições gerais de hardware, software e interfaces de produção 
(uplink e de LAN).
Estando o equipamento ligado, pode estar ocorrendo uma falha no sistema operacional, em 
componente de software ou hardware, a qual promove a perda do serviço de roteamento. 
q 1 Nesse caso, pode-se conectar ao roteador (através de telnet para o IP da interface 
LAN ou de porta console) e verificar as mensagens de erro com o comando 
“show log messages”.
 1 Há algum erro explícito de hardware e/ou software? Deve-se abrir um chamado no 
PoP detalhando o ocorrido.
 1 Deve-se verificar as condições operacionais das interfaces de uplink e de LAN do roteador.
 2 Isso pode ser feito no equipamento Juniper com o comando “show interfaces terse”. 
Figura 1.19 
Interligação típica 
entre organização 
usuária e Pop.
Telnet
Protocolo da camada de 
aplicação que permite a 
um usuário iniciar uma 
sessão remota em um 
equipamento de rede ou 
qualquer máquina que 
possua um servidor do 
serviço Telnet. Através 
da sessão é possível 
enviar comandos ao 
equipamento.
Porta console
Interface de equipa-
mento de rede através 
da qual é possível 
conectar um PC ou 
notebook e, utilizando 
aplicação adequada, 
iniciar uma sessão local 
no equipamento. Através 
da sessão é possível 
enviar comandos ao 
equipamento.
18
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
user@Merlot> show interfaces terse
 Interface Admin Link Proto Local
 fe-0/0/0 up up
 fe-0/0/0.100 up up ccc
 fe-0/0/0.200 up up ccc
 fe-0/0/1 up up
 fe-0/0/1.0 upup inet 10.0.31.1/24
 fe-0/0/2 up down
 fe-0/0/3 up down
q 1 As interfaces de produção devem estar no estado “up up”. 
 1 Se a interface de uplink não estiver no estado “up up”, deve-se abrir um chamado no 
PoP, detalhando o fato. 
 1 Nesse caso, pode-se passar também alguma mensagem de erro explícita que tenha 
sido percebida ao se executar o “show log messages”.
 1 Se a interface de uplink está no estado “up up” mas a interface de LAN não está, 
deve-se verificar o estado do equipamento de distribuição de rede que se conecta a 
essa interface. 
 1 Nesse caso não há ação do PoP. A atividade corretiva é de responsabilidade da insti-
tuição usuária.
Verificar condições básicas de roteamento
Se a análise mostrar todas as interfaces de produção no estado correto e nenhuma falha em 
componentes de hardware e software do roteador, deve-se analisar as condições básicas de 
roteamento. Normalmente, a interface de uplink da instituição se conecta ao PoP através de 
uma rede IP de dois endereços (rede /30), onde um endereço é do PoP e o outro da interface 
de uplink.
q 1 Um teste básico de roteamento consiste em executar o comando ping alterando o 
IP de origem para o endereço de LAN do roteador. 
 1 Com esse procedimento é possível testar se o roteador do PoP ainda “sabe” rotear 
pacotes para a rede da organização usuária. 
As figuras a seguir exibem a diferença de um ping simples para o ping com IP de origem 
alterado.
qComando ping simples: 
 1 No Juniper, faz-se simplesmente “ping <IP Destino>”.
19
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
 
qComando ping endereçado pela LAN:
 1 No Juniper, faz-se “ping <IP Destino> from <IP LAN>”.
Figura 1.20 
Ping simples no 
Juniper: comando 
“ping 10.1.1.1”.
Figura 1.21 
Ping com origem 
na LAN no Juniper: 
comando “ping 
10.1.1.1 from 
192.168.1.1”.
20
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Se o equipamento do PoP responder corretamente, fica caracterizado o bom funcionamento 
do roteamento entre PoP e organização usuária. Nesse caso, pode existir um problema no 
backbone da RNP. Deve-se, então, abrir um chamado no PoP, repassando o resultado do 
teste de ping executado.
Procedimento para entrar em contato com o PoP visando abertura de chamado
Todos os testes do tópico anterior foram citados para agilizar o trabalho de suporte da 
equipe técnica do PoP. No entanto, não foi explicitado como fazer o acionamento ao PoP.
q 1 Um chamado no PoP pode ser aberto de três maneiras: 
 2 Via e-mail. 
 2 Via trouble-ticket (boa parte dos PoPs já suportam essa modalidade de aciona-
mento). 
 2 Via telefone.
 1 Em casos graves (indisponibilidade total de serviço ou grande problema repentino de 
performance) é recomendado que o acionamento se dê por telefone, para o número 
de suporte disponibilizado pelo PoP. 
 2 Nesses casos, deve-se informar ao profissional do PoP todos os testes já execu-
tados. 
 2 É esperado que o profissional do PoP registre o problema e inicie a sua investi-
gação.
 1 Em casos menos graves pode-se abrir o chamado por e-mail. 
 2 Alguns PoPs disponibilizam o sistema de trouble-ticket, através do qual se envia 
um e-mail para um endereço eletrônico definido pelo PoP e, em seguida, se recebe 
o número do chamado aberto por e-mail automaticamente.
Outros PoPs ainda não disponibilizam esse sistema. Nesse caso, envia-se o e-mail repor-
tando a falha e os testes executados para o endereço eletrônico disponibilizado pelo PoP. 
O registro do chamado é executado manualmente pelo PoP a posteriori.
É importante que esse acionamento seja executado pelo contato técnico da instituição, ou 
pelo profissional a quem essa tarefa específica foi delegada. Caso a tarefa tenha sido dele-
gada, é importante que a pessoa que fará o acionamento também conheça a infraestrutura 
de rede da instituição. Caso seja necessário acionar uma operadora de telecomunicações, 
essa ação será feita pelo PoP da RNP.
Acompanhamento dos chamados abertos
q 1 O acompanhamento dos chamados se dá através do contato com a equipe técnica do 
PoP, via número de telefone disponibilizado pelo PoP (em casos graves) ou via e-mail.
 1 Em casos de acionamento de operadoras, o PoP contatará os representantes daquele 
órgão periodicamente e manterá a instituição informada de toda e qualquer novidade.
 1 É recomendável que a própria instituição entre em contato com o PoP para cobrar 
uma posição da operadora sempre que for necessário obter informações mais deta-
lhadas sobre o caso.
21
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
Acompanhamento de problemas relacionados ao backbone
q 1 Se a conexão local está funcionando, mas ocorre falha no uso do serviço, é provável 
que a falha esteja fora da alçada do PoP da RNP. 
 1 Nesses casos, o PoP entra em contato com a equipe de operações da GO/RNP e 
mantém contato permanente até a solução do caso. 
 1 A GO/RNP é a entidade responsável pela manutenção da rede Ipê.
A instituição usuária pode, sempre que precisar, solicitar ao PoP as últimas informações 
sobre o diagnóstico e a solução do problema.
q 1 A GO disponibiliza na web page da RNP o Panorama do Tráfego. 
 1 Esta ferramenta informa, entre outras coisas, a saúde dos enlaces do backbone da RNP. 
 1 Este recurso está disponível, on-line, a qualquer hora.
 1 O Panorama do Tráfego: 
 2 Mostra o nível de utilização de todos os enlaces de dados que compõem o backbone.
 2 É atualizado a cada cinco minutos. 
 1 Os enlaces possuem as seguintes situações:
 2 ADEQUADO (nível de utilização adequado).
 2 ACIMA (nível de utilização acima do adequado, mas ainda não saturado).
 2 SATURADO (enlace de dados com excesso de uso. Já atingiu a saturação).
 2 INDISPONÍVEL (enlace de dados indisponível no momento).
A figura seguinte mostra uma foto da ferramenta:
 
No momento em que a ferramenta foi acessada, quando se extraiu a imagem acima, o 
enlace de dados que liga os PoPs do Ceará (CE) e Maranhão (MA) estava indisponível.
Figura 1.22 
Panorama do 
Tráfego da rede Ipê.
22
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Pelo desenho da rede é possível verificar que essa falha não acarreta perda de serviço, pois 
o enlace defeituoso é parte de um anel que ainda conta com outros enlaces. Os clientes da 
RNP do Maranhão ainda conseguem acessar o PoP do Ceará fazendo o caminho: 
MA->PA->PI->PE->PB(CGE)->PB(JPA)->RN->CE
No entanto, essa falha pode justificar um aumento na latência de determinadas aplicações. 
Por exemplo, uma instituição cliente do PoP do Pará (PA) que possui uma aplicação que 
consulta uma base de dados em uma instituição parceira que está conectada ao PoP-CE 
normalmente percorre o caminho:
PA->MA->CE
Com a falha do link da figura, o caminho será:
PA->PI->PE->PB(CGE)->PB(JPA)->RN->CE
Apesar de a largura de banda em todos esses enlaces ser alta, as aplicações vão perceber um 
inevitável aumento de latência. Se esse for um parâmetro crítico para o funcionamento de uma 
aplicação, impactos podem ser percebidos. Outra informação útil do Panorama do Tráfego que 
pode ajudar no entendimento de problemas é o nível de uso dos enlaces de dados.
Por exemplo: na Figura 1.23 percebe-se que o enlace de dados que atende ao PoP-AP está 
amarelo. Ao posicionar o cursor no link daquele PoP verifica-se o volume do tráfego no 
enlace, vide a figura seguinte:
A Figura 1.23 mostra que, em alguns horários, o tráfego entrante no Amapá chega a 51,14 
Mbps, que corresponde a 75,20% da capacidade total desse enlace. Embora esse fato justi-
fique bem alguma percepção de lentidão por parte de uma instituição atendida pelo PoP-AP, 
ele pode indicar atenção, poisum maior uso do canal poderá rapidamente deteriorar a 
qualidade da comunicação de todos os clientes desse PoP.
Latência
Tempo passado desde 
a saída de um pacote 
de dados de sua origem 
até a chegada em seu 
destino.
Figura 1.23 
Panorama do 
tráfego: tráfego de 
enlace de dados.
23
 
C
ap
ítu
lo
 1
 - 
O
pe
ra
çã
o 
da
 r
ed
e 
Ip
ê
O Panorama do Tráfego constitui, portanto, uma ferramenta útil de acompanhamento não 
só de problemas do backbone, como da evolução natural do tráfego de um PoP de interesse. 
A consulta a essa ferramenta complementa as informações sobre falhas de backbone que 
podem ser obtidas diretamente com o PoP.
24
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
25
 
C
ap
ítu
lo
 1
 - 
Ro
te
ir
o 
de
 a
ti
vi
da
de
 1
Roteiro de Atividades 1
Atividade 1.1 – Panorama do tráfego
Uma organização usuária começou a perceber certa lentidão no acesso a um determinado 
site da internet. Proativamente, o administrador da rede resolveu acessar a ferramenta 
Panorama do Tráfego, disponível em http://www.rnp.br/ceo/trafego/panorama.php. 
Ao fazê-lo, o administrador concluiu que o problema, no momento, provavelmente afeta 
também outros clientes. Resolveu então ligar para o PoP da RNP para verificar se algo pode 
ser feito.
A figura seguinte retrata o panorama que foi visto pelo administrador de rede no momento 
de seu acesso. Considerada a figura, onde deve estar localizado o site com o qual o cliente 
quer se comunicar? 
Atividade 1.2 – Falha de conectividade da organização usuária
O administrador de rede da organização usuária recebeu várias reclamações dando conta 
que a conexão com a internet estaria indisponível. A partir desse evento, a RNP recomenda 
uma metodologia de troubleshooting preliminar, a fim de facilitar a atuação do PoP/RNP, 
quando solicitado.
Cite a ordem recomendada para as ações abaixo e, quando houver necessidade de executar 
algum comando, cite os comandos que devem ser usados.
Figura 1.24 
Panorama da 
Atividade 1.1.
26
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Ações:
( ) Executar um ping para o roteador do PoP utilizando IP origem da LAN, para testar se há 
falha de roteamento na comunicação PoP-Organização.
Ordem: 
Comandos: 
( ) Verificar se o roteador da organização está ligado e operacional.
Ordem: 
Comandos: 
( ) Verificar as condições gerais de hardware, software e interfaces de produção no roteador 
da organização com os comandos “show log messages” e “show interfaces terse”.
Ordem: 
Comandos: 
27
 
C
ap
ítu
lo
 2
 - 
Se
gu
ra
nç
a 
na
 r
ed
e 
Ip
ê
ob
je
tiv
os
conceitos
2
Segurança na rede Ipê
Orientar a instituição sobre os procedimentos adequados para tratar os incidentes 
de segurança e como se relacionar com o CAIS.
 
CAIS, serviços do CAIS, segurança.
 
 
Centro de Atendimento a Incidentes de Segurança (CAIS)
q 1 Compreende uma equipe técnica fortemente qualificada na área de segurança de redes.
 1 Nacional e internacionalmente reconhecido por sua atuação na detecção, resolução e 
prevenção de incidentes de segurança.
 1 Elabora, promove e dissemina práticas de segurança em redes.
 1 Participa largamente de organismos internacionais na área de segurança.
 1 Interage com equipes de resposta a incidentes de segurança de diversos países.
 2 Essas equipes são conhecidas pela sigla CSIRT (Computer Security Incident 
Response Team).
 2 No Brasil, várias instituições acadêmicas já contam com seu próprio CSIRT.
 1 Na área internacional, o CAIS ainda coordena o grupo de trabalho de segurança da 
rede acadêmica CLARA.
 1 No Brasil, presta diversos serviços à comunidade acadêmica.
 1 Organiza o Dia Internacional de Segurança em Informática (DISI).
O Centro de Atendimento a Incidentes de Segurança da RNP foi criado em 1997. Hoje o CAIS 
compreende uma equipe técnica com notável reputação na área de segurança de redes, 
equipe que se reporta à Diretoria de Serviços e Soluções (DSS) da RNP.
O CAIS é internacionalmente reconhecido por sua atuação na detecção, resolução e pre-
venção de incidentes de segurança na rede acadêmica brasileira e por sua forte presença na 
América Latina, promovendo a cultura de segurança. O CAIS elabora, promove e dissemina 
práticas de segurança em redes.
Entre os órgãos internacionais que contam com a participação do CAIS estão o Forum of 
Incident Response and Security Teams (FIRST – www.first.org) e o Anti-Phishing Working 
Group (APGW – www.antiphishing.org).
28
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
O contato com diversas instituições internacionais permite ao CAIS interagir com equipes 
de resposta a incidentes de segurança de diversos países e setores. Essas equipes são 
conhecidas como Computer Security Incident Response Team (CSIRT). No Brasil, o CAIS 
presta serviços à comunidade acadêmica e organiza anualmente o Dia Internacional de 
Segurança em Informática (DISI), evento voltado para a conscientização do usuário final no 
uso da internet e outros ambientes.
Os serviços típicos prestados pelo CAIS se materializam em:
q 1 Tratamento de incidentes.
 1 Disseminação da cultura de segurança.
 1 Infraestrutura de segurança.
 1 Gestão de segurança da informação.
 1 O CAIS trata incidentes de segurança que envolvam o backbone da RNP, trocando 
informações com os PoPs, CSIRTs no Brasil e provedores de serviço. 
 1 Incidentes podem ser comunicados ao CAIS através do e-mail: cais@cais.rnp.br.
Como fazer quando ocorre um problema de segurança
A RNP atua na resolução, detecção e prevenção de incidentes de segurança. Normalmente 
um incidente de segurança objetiva:
q 1 Destruição, corrupção ou roubo de dados.
 1 Redução de performance ou indisponibilidade da rede de uma instituição.
 1 Ao se deparar com um ataque que produza impactos imediatos, como indisponibi-
lidade ou lentidão de serviço, a instituição deverá contatar imediatamente o PoP, 
descrevendo os sintomas experimentados. 
 1 Os PoPs e a gerência de operações da RNP possuem ferramental adequado para 
caracterizar o tipo de ataque ocorrido. 
 1 A partir do ataque reportado, a gerência de operações da RNP e o PoP atuarão juntos 
na sua investigação. 
 1 O PoP manterá contato com a instituição. Uma vez sanado ou atenuado o ataque, o 
evento será reportado ao CAIS, que investigará suas características e poderá gerar 
ações recomendadas para evitar um novo ataque.
 1 Caso o ataque identificado não gere impacto imediato (ou já tenha sido sanado), a 
instituição deverá reportá-lo diretamente ao CAIS, através do serviço de atendimento 
a incidentes de segurança.
Para contatos de emergência com a equipe do CAIS/RNP: 
 1 Telefone:(61) 3243-4400 – a ligação pode ser feita inclusive fora do horário comercial.
Contatos não emergenciais podem ser feitos via e-mail: cais@cais.rnp.br, ou através de um for-
mulário específico disponível no portal do CAIS em: http://www.rnp.br/cais/atendimento.html
O que é o atendimento a incidentes?
q 1 É um serviço oferecido pelo CAIS às instituições usuárias, que auxilia na identificação, 
notificação e solução de problemas em sistemas computacionais que atinjam as 
instituições, ou mesmo a RNP.
29
 
C
ap
ítu
lo
 2
 - 
Se
gu
ra
nç
a 
na
 r
ed
e 
Ip
ê
q 1 Qualquer incidente de segurança pode ser reportado ao CAIS. 
 1 Por incidente de segurança entenda-se qualquer evento que promova a quebra da 
política de uso da RNP.
 1 A política estabelece que as organizações usuárias da RNP, para a promoção de suas 
atividades de ensino e pesquisa, podem: 
 2 Utilizar os serviços de rede disponíveis, suas facilidades de trânsito nacional 
e internacional. 
 2 Usufruir de acordos de interconexão existentes entre a RNP e outras redes. Exceto 
quando esse uso se reflete em: 
1. Produção ou transmissão de dados ou materiais considerados ilegais, entre 
outros, por caracterizarem: transgressão dos direitos do autor, de proteção 
à criança e ao meio ambiente, atentado à privacidade ou promoção à discrimi-
nação racial ou religiosa.
2. Veiculação de propaganda comercial, política ou religiosa.
3. Transmissão de mensagens ou material de propaganda não solicitado pelo 
destinatário.
4. Uso em atividades estritamente comerciais.
5. Atividades que contribuam para a ineficiência ou esgotamento dos recursos na 
rede, sejam eles computacionais, comunicacionais ou humanos.
6. Atividades que promovam a corrupção ou destruição de dados de usuários.
7. Atividades que interrompam ou prejudiquem a utilização dos serviços de rede 
por outros usuários.
8. Interligação ou abrigo em seu espaço de endereçamento de uma terceira insti-
tuição sem qualificação obtida através desta Política de Uso.
Um evento que fere os itens 3 ou 7 não configura um incidente de segurança. Um evento 
que fere quaisquer dos outros itens da política é dado como um incidente de segurança.
q 1 Caso ocorram incidentes de segurança dentro da instituição, ela deve se preocupar em 
corrigir o problema, sob pena de deixar de usufruir dos serviços de rede disponíveis.
 1 Algumas consequências indiretas também podem ocorrer, como:
 2 Bloqueio, por parte de terceiros, da entrega de e-mails enviados a partir 
da instituição.
 2 Enquadramento em leis internacionais de proteção à propriedade intelectual.
 2 Comprometimento da imagem da instituição ou mesmo da RNP.
O trabalho do CAIS
q 1 Os incidentes de segurança mais comuns tratados pelo CAIS são:
 2 Envio de mensagens de e-mail não solicitadas (spam).
 2 Ataques a sistemas (procura por vulnerabilidades e invasão).
 2 Golpes de fraudes bancárias, cartões de crédito (phishing).
 2 Troca de páginas web.
 2 Download de material protegido por copyright (P2P e outros).
 2 Disseminação de malware.
30
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Os incidentes de segurança mais sérios (e menos frequentes) tratados pelo CAIS são:
 2 Pedofilia.
 2 Difamação.
 2 Solicitações judiciais.
Recomendações à Organização Usuária
q 1 A organização usuária também tem seu papel no tratamento dos incidentes de segurança. 
 1 É recomendado que a instituição mantenha uma equipe ou profissional responsável 
pela segurança de suas redes e sistemas.
 1 Caberá a essa entidade investigar as ocorrências registradas em sua instituição e 
corrigir os problemas de segurança em sua alçada. 
 1 É recomendado que essa entidade notifique o CAIS em relação aos ataques rece-
bidos, bem como os responsáveis pelas redes atacantes, solicitando providências 
(nesse caso, sempre copiando o CAIS nas mensagens).
 1 A equipe/profissional responsável pela segurança das redes da instituição deverá 
também adotar práticas de prevenção:
 2 Executar a gerência de redes e sistemas.
 2 Manter os sistemas atualizados, originais e protegidos por antivírus.
 2 Permitir somente o envio de e-mails através de servidores específicos.
 2 Identificar e bloquear abusos na rede (P2P).
 2 Definir uma topologia de rede que facilite a gerência e controle, utilizando DMZ e 
firewall.
 2 Ter cuidados especiais com senhas de servidores.
 2 Acompanhar listas de segurança e vulnerabilidades em produtos instalados (rotea-
dores, servidores web, apache, php, mysql).
A ajuda do CAIS
Na prática, o CAIS oferece os seguintes serviços:
q 1 Notificação às instituições clientes sobre quaisquer incidentes de segurança que 
cheguem ao conhecimento da comunidade acadêmica nacional de segurança.
 1 Auxílio na resolução dos incidentes, seja esclarecendo dúvidas, orientando sobre 
boas práticas ou fazendo interface com outros grupos de segurança.
 1 Manutenção e disponibilização de dados estatísticos sobre o atendimento a inci-
dentes na RNP.
 1 Acesso direto à equipe do CAIS através de ferramenta de diálogo IRC, facilitando a 
comunicação para resolução de incidentes.
Passos para a segurança de sua instituição
q 1 Estabeleça um ponto de contato único como contato de segurança: abuse@, 
seguranca@ ou security@. 
 1 Informe esse contato à RNP e ao CAIS. 
 1 Repasse as mensagens recebidas nestes e-mails aos responsáveis pelas questões 
de segurança.
31
 
C
ap
ítu
lo
 2
 - 
Se
gu
ra
nç
a 
na
 r
ed
e 
Ip
ê
q 1 Mantenha a data e hora de seus sistemas ajustados por NTP, para garantir a precisão 
do horário nos logs de eventuais ataques.
 1 Caso a instituição tenha sofrido algum incidente de segurança:
 2 Colete todos os dados relacionados ao incidente.
 2 Certifique-se de incluir data, hora e fuso horário.
 2 Notifique o atacante, com cópia ao CAIS.
 2 Caso a instituição tenha sido origem de um incidente de segurança:
 3 Trate o caso com responsabilidade.
 3 Busque identificar o problema, resolvê-lo, e responder ao solicitante, copiando 
o CAIS na resposta.
32
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
33
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
ob
je
tiv
os
conceitos
3
Infraestrutura de rede
Orientar a instituição sobre os tipos de conexão à rede da RNP, a infraestrutura de rede, 
equipamentos, cabeamento e infraestrutura física. 
 
Conexão da organização usuária ao PoP da RNP, uso e especificação de switches e 
roteadores, topologia da rede, infraestrutura de cabeamento e infraestrutura física.
 
 
Conexão da organização usuária ao PoP da RNP
q 1 Tipicamente a organização usuária se ligará ao PoP RNP através de um enlace de 
dados provido por uma operadora de telecomunicações. 
 1 Esse ator alugará um meio físico para prover o contato da instituição com a rede Ipê. 
 1 Esse meio será implementado por uma dentre diversas tecnologias. 
 2 O que ocorre usualmente é que o meio físico é uma fibra óptica, um cabo de cobre 
ou um radioenlace (sem fio). 
 1 Em alguns casos, dependendo da geografia da instituição a ser conectada, esse 
enlace de dados poderá ser implantado via um link de satélite.
As figuras abaixo exibem cada um dos casos:
Organização 
usuária
PoP RNP
RNP
A Figura 3.1 mostra uma conexão de fibra óptica entre uma organização usuária e o PoP 
da RNP. O enlace exibido reporta a conexão lógica. Fisicamente não existe um cabo óptico 
conectando os dois pontos. A operadora “constrói” esse circuito dentro da sua infraestru-
tura. Ou seja, em termos práticos, o link é implementado passando por uma ou mais esta-
ções da operadora em questão.
Figura 3.1 
Ligação de 
instituiçãovia fibra 
óptica.
34
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Organização 
usuária
PoP RNP
RNP
A Figura 3.2 exibe uma instituição que foi conectada à rede Ipê via rádio. Essa é uma opção 
utilizada principalmente em locais onde não existe infraestrutura de cabeamento pronta 
para uso. Dependendo da situação, a conexão rádio pode ser implementada exatamente 
como na Figura 3.2, com uma antena no PoP da RNP e outra no cliente. Porém, o que ocorre 
cotidianamente é que o link rádio liga a organização usuária a um ponto de presença da 
operadora, e esse ponto é conectado ao PoP RNP via rede cabeada. Ou seja, de fato tem-se 
um enlace que é parte sem fio e parte cabeado.
Organização 
usuária
PoP
Operadora
PoP RNP
RNP
A Figura 3.3 exibe uma instituição conectada à rede Ipê via satélite. Essa opção é usada em 
casos onde a organização usuária encontra-se em um lugar remoto onde não se pode usar 
cabos ou um rádio diretivo por falta de visibilidade entre a instituição e o ponto de presença 
da operadora mais próximo. Um exemplo típico são as instituições localizadas em áreas de 
selva nos estados amazônicos.
Figura 3.2 
Ligação de 
instituição via rádio.
Figura 3.3 
Ligação de 
instituição via 
satélite.
35
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
q 1 Nos casos exibidos o enlace de dados é contratado pela RNP junto a uma operadora 
de telecomunicações. 
 1 O contrato firmado entre essas duas partes estabelece parâmetros de qualidade que 
deverão ser atendidos, como: 
 2 Largura de banda disponível, tempo de resposta, taxa de erro de bit (BER) etc.
 1 Cabe à RNP executar a gestão desse contrato, garantindo o seu cumprimento e apli-
cando as punições necessárias quando os itens acordados não forem atendidos.
 1 Em qualquer dos casos, invariavelmente, a organização usuária receberá, em suas 
dependências, alguma infraestrutura de equipamentos da operadora. 
 1 A organização terá que zelar pelo bom funcionamento desses equipamentos, 
mantendo-os em condições recomendadas. 
 1 No caso mais simples, de organização usuária atendida por rede cabeada, a opera-
dora instala um modem nas dependências da organização. 
A conexão se apresenta como no esquema da Figura 3.4.
Rede Operadora
Modem
Cabo serial
Roteador RNP
Todos os equipamentos detalhados na figura ficarão nas dependências da organização 
usuária. Na Figura 3.4 o roteador é fornecido pela RNP e seu objetivo é receber a conexão 
da operadora e rotear pacotes de dados da rede da instituição para fora. O modem da figura 
pertence à operadora de telecomunicações. 
A infraestrutura adequada para abrigar esses dispositivos será apresentada adiante.
q 1 A conexão entre o roteador e o modem quase sempre se dá via interface serial 
do roteador.
 1 Existe uma grande variedade de conectores que podem compor o cabo que faz essa 
conexão.
 1 O conector V.35 é um dos mais populares. 
Figura 3.4 
Conexão 
instituição: 
operadora.
36
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
A Figura 3.5 mostra, além do V.35, outros conectores que são usados cotidianamente.
EIA/TIA-232 EIA/TIA-449 V-35 X21 EIA-530
Na figura, a parte superior dos cabos corresponde ao conector que se liga à porta serial do 
roteador da RNP. A parte inferior do cabo se liga ao modem da operadora. Esse cabo, via de 
regra, é fornecido pela operadora de telecomunicações provedora do circuito de dados.
Para os casos em que a instituição é conectada via rede sem fio, a infraestrutura instalada 
pela operadora é um pouco mais complexa. O equipamento da RNP é sempre o mesmo: um 
roteador. Além da antena, que deve ficar no telhado ou em uma torre para prover visibili-
dade com a antena que fica no ponto de presença da operadora, é necessária a instalação 
de uma infraestrutura específica. Para trazer o sinal da antena para dentro da instituição 
é instalado um cabeamento de RF. Esse cabeamento termina em um transceiver, o qual se 
conectará ao roteador. A operadora instala isoladores no cabeamento, perto da antena, 
para proteger os equipamentos de rede da instituição de descargas elétricas que porven-
tura tentem se propagar via cabeamento da antena para dentro da instituição.
Para o caso da conexão via satélite a infraestrutura é similar ao cenário da rede sem fio, 
porém nesse caso temos o roteador ligado a um modem satélite, que adapta o sinal do rote-
ador ao meio físico do enlace satelital.
Em todos os cenários apresentados o enlace da operadora sempre acaba no roteador da 
RNP. Esse equipamento define o ponto de delimitação entre a responsabilidade da opera-
dora e da organização usuária. O roteador tem como objetivo principal prover o trânsito de 
pacotes de dados da rede da instituição para o PoP e vice-versa. 
O equipamento suporta ainda outras funcionalidades que poderão ou não ser usadas, 
como protocolos de roteamento, VPN, firewall, segmentação de rede em VLANs e NAT, entre 
outras. Mais detalhes sobre o equipamento que será usado pela instituição serão apresen-
tados mais à frente neste curso.
Uso e especificação de switches e roteadores
Os equipamentos de rede mais usados em redes profissionais são os roteadores e os switches. 
Em redes mais antigas ou em ambientes não corporativos hubs também podem ser usados. 
Esse curso não tratará de hubs, pois o uso deles já não é recomendado por diversos motivos.
Figura 3.5 
Cabos seriais. 
37
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
Os fabricantes de rede dividem a linha de equipamentos em:
q 1 Produtos para escritório (Office).
 1 Produtos para empresa (Enterprise).
 1 Produtos para provedor de serviço (Provider).
O nome comercial varia entre fabricantes. Em alguns casos a linha pode ser subdividida em 
mais segmentos. As três linhas citadas são a referência de mercado. Alguns fabricantes definem 
ainda uma linha adicional de produtos para centro de processamento de dados (Data Center).
Essa linha adicional se destina especificamente às empresas que administram grandes 
infraestruturas de processamento de dados. A complexidade, os protocolos particulares e o 
gigantesco volume de dados que ali existem implicam otimizações específicas na arquitetura 
dos equipamentos dessa linha.
Especificação de racks
Os equipamentos de infraestrutura de redes e de serviços podem ser classificados quanto a 
sua disposição física em duas grandes famílias:
 1 Equipamentos de mesa;
 1 Equipamentos de rack.
Dentre os equipamentos de mesa estão os servidores de torre e os PCs (que constante-
mente abrigam serviços).
Em algumas empresas, os equipamentos de mesa são rejeitados, porque não é possível 
organizá-los em racks. Constantemente os equipamentos de mesa ocupam espaços impor-
tantes de CPDs de maneira difícil de organizar.
q 1 Os racks são armários próprios para receber equipamentos de telecomunicações. 
 1 Proveem infraestrutura específica para passagem de cabos, acomodação de fontes 
extras, ventiladores, barra de aterramento e réguas de energia.
 1 Os racks de 19´´ são os preferidos da indústria de telecomunicações e grande parte dos 
equipamentos do mercado é fabricada de modo a encaixar perfeitamente nesses racks.
 1 Normalmente um equipamento ocupa toda a largura do rack e parte de sua altura. 
 1 O espaço de altura dos racks é dividido em RUs (rack units). 
 1 Ao comprar um equipamento deve-se atentar para a informação de espaço físico 
necessário em rack. 
Figura 3.6 
Equipamentos de 
mesa (Fonte: 
www.sevenl.net).
38
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Alguns tamanhos típicos de rack são 8, 12 e 16 RUs. O equipamento Juniper J2350,por 
exemplo, possui 1,5 RU.
1,5 RU
40 RUs
Fontes redundantes
Quase todo equipamento moderno de redes ou de telecomunicações possui uma versão 
com fontes redundantes. A fonte de um equipamento, assim como ocorre com um compu-
tador pessoal, é responsável pelo fornecimento de energia para todos os componentes do 
hardware. Uma falha de fonte provoca a parada imediata do equipamento. A fonte redun-
dante é capaz de resolver o problema. 
Na grande maioria dos casos o equipamento possui tecnologia para promover a comutação 
automática para a fonte backup em caso de falha na fonte principal. 
q 1 Os equipamentos também possuem a tecnologia de “hot swap”, que permite trocar 
uma fonte queimada sem parada do equipamento.
 1 Um dos perigos da fonte redundante é a sua gerência. É muito comum no mundo 
corporativo ocorrerem falhas de fonte sem que o administrador do equipamento 
tome conhecimento. 
 1 Nesses casos a fonte backup assume, mas não haverá backup para ela. 
 1 Se esse componente falhar, haverá parada de serviço. 
 1 Conclusão: não adianta ter fontes redundantes enquanto não se intervém na fonte 
defeituosa. 
Figura 3.7 
Rack de 19´´ para 
telecomunicações.
Figura 3.8 
Divisão de rack 
em RUs.
39
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
É fundamental um eficiente ferramental de gerência de hardware. Tipicamente o protocolo 
SNMP é o responsável pelo reporte de uma falha dessa magnitude, sendo suportado por 
praticamente todo tipo de equipamento de redes e de telecomunicações.
Topologia da rede
O objetivo maior da gerência de redes é garantir o maior tempo de disponibilidade possível 
para os recursos e serviços da instituição. Para ajudar a alcançar esse objetivo existem 
várias outras boas práticas além da atividade de gerência. Uma dessas atividades é o 
desenho racional da topologia da rede. 
q 1 Existem três desenhos básicos: barramento, anel e estrela. 
 1 A maioria das topologias de rede possui uma dessas três configurações ou uma com-
binação delas. 
 
Figura 3.9 
Topologia 
barramento.
Figura 3.10 
 Topologia anel.
40
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Ao definir a topologia da rede dois conceitos ajudam a melhorar a robustez dela: 
redundância e hierarquia.
 1 O conceito de redundância fica claro na topologia em anel. Uma topologia preocu-
pada com a redundância evita que as VLANs (ou redes) dependam de um único link 
para se manterem disponíveis.
 1 A ideia de hierarquia define equipamentos com funções bem definidas na rede, 
evitando mistura de papéis entre eles. 
Cada tipo de equipamento tem uma tarefa bem definida, e por isso sua especificação técnica 
é particular e direcionada à tarefa para a qual será designado. A figura seguinte exibe um 
modelo de referência que assume os conceitos de redundância e hierarquia.
Núcleo
Distribuição
Acesso
Nesse modelo de referência os equipamentos foram divididos em camadas. 
q 1 Cada camada provê serviço para todas as camadas mais abaixo. 
 1 A camada de acesso conecta os usuários à rede e provê comutação de frames entre 
usuários da mesma VLAN. 
Figura 3.11 
Topologia estrela.
Figura 3.12 
Modelo de 
referência: rede 
redundante e 
hierarquizada.
41
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
q 1 A camada de distribuição concentra os equipamentos de acesso e segmenta dife-
rentes grupos de trabalho. 
 2 Um bom arranjo dessa camada ajuda a isolar problemas de rede. 
 2 Essa camada também pode implementar políticas de segurança.
 1 A camada de núcleo constitui a espinha dorsal da rede, constituída de links de alta 
velocidade, normalmente na faixa dos gigabits por segundo. 
 2 Essa camada concentra os equipamentos de distribuição. 
 2 Sua função é rotear pacotes entre os equipamentos de distribuição e as redes 
externas o mais rápido possível.
 1 No modelo, cada equipamento possui duas conexões com a camada imediatamente 
acima, por questões de redundância.
O esquema representado na figura acima é apenas uma referência. No mundo real nem 
sempre é possível obter-se um modelo de rede perfeitamente hierarquizado e redundante, 
principalmente por questões financeiras. De toda forma, quanto mais perto do modelo de 
referência for a rede, melhor o seu desempenho geral.
Identificação de cabos
q 1 Uma prática muito simples que ajuda enormemente a tarefa de manter a rede organi-
zada e documentada é a identificação de cabos. 
 1 Uma rede que se estende por um espaço físico muito extenso e que possua muitos 
cabos rapidamente se transforma em um caos completo.
 
A identificação de cabos permite saber de imediato que equipamentos estão conectados 
entre si e qual cabo provê essa conexão, agilizando todo tipo de aprovisionamento, desapro-
visionamento ou troubleshooting da infraestrutura física de cabeamento.
Figura 3.13 
Exemplo de 
ambiente caótico 
(Fonte: www.
bernabauer.com)
42
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Obviamente, para garantir a organização do ambiente não basta identificar os cabos, é 
preciso manter as etiquetas atualizadas toda vez que uma mudança for feita, ou seja, é reco-
mendado estabelecer um processo de mudança das conexões da rede.
Infraestrutura para abrigar os equipamentos e mantê-los
q 1 Não existem padrões para a infraestrutura que abrigará os equipamentos da RNP. 
 1 A orientação é que a instituição se preocupe com a documentação técnica dos equi-
pamentos que receberá em suas dependências. 
 1 Esses documentos especificarão as condições ideais que permitirão aos equipa-
mentos uma vida útil ótima.
A seguir veremos os pontos que devem ser verificados.
Localização e dimensões da sala
q 1 A localização da sala deve ser tal que evite a propagação de ruído dos equipamentos 
ao restante do ambiente, evitando prejuízo para a população da instituição. 
 1 A dimensão da sala deve ser tal que permita ao equipamento de ar-condicionado que 
a atende refrigerá-la com eficiência. 
 2 Salas grandes são mais difíceis de refrigerar. 
 2 Temperatura é um dos itens mais importantes para o bom funcionamento de equi-
pamentos de redes e telecomunicações.
É recomendável que o acesso à sala seja restrito aos profissionais capacitados a operar os 
equipamentos ali presentes. A segurança física dos equipamentos deve ser verificada antes 
que qualquer política de segurança lógica seja elaborada.
Equipamentos de apoio
q 1 Alguns equipamentos de apoio ajudam a aumentar a disponibilidade dos equipamentos.
 2 Exemplos: nobreaks e geradores.
 1 Os nobreaks protegem os equipamentos contra picos de luz, cobrindo o fornecimento 
de energia durante falhas curtas de fornecimento elétrico. 
Figura 3.14 
Cabo identificado 
(Fonte: www.
midiasolucao.com.br).
43
 
C
ap
ítu
lo
 3
 - 
In
fr
ae
st
ru
tu
ra
 d
e 
re
de
 
q 1 Dependendo da criticidade das aplicações da rede a instituição pode lançar mão de 
um gerador, que permite a manutenção de energia elétrica mesmo durante longas 
falhas da concessionária de energia. 
 1 Existem vários tipos de geradores, dos mais robustos e caros aos mais simples 
e baratos.
Um erro comum é ignorar a necessidade de manutenção dos equipamentos de apoio. 
É muito comum ocorrerem casos de falhas de energia onde o gerador não assume porque, 
por exemplo, está sem carga.
Refrigeração
q 1 Todo equipamento instalado na sala de equipamentos traz em sua documentação 
técnica a quantidade de BTUs que será consumida. 
 1 É importante fazer a gerência da capacidade de refrigeração da sala, de modo a 
garantir que o consumo de refrigeração dos equipamentos da sala não ultrapassará acapacidade de refrigeração do equipamento de ar-condicionado.
Instalação elétrica
Todo equipamento instalado na sala de equipamentos (ou CPD) traz em sua documentação 
técnica a potência média dissipada, bem como a capacidade máxima de sua(s) fonte(s). 
É importante fazer a gerência da infraestrutura elétrica da sala de equipamentos para evitar 
que a capacidade dos componentes (quadros de energia, disjuntores etc.) seja ferida.
Aterramento
q 1 Todo equipamento de redes e de telecomunicações deve ser aterrado em 
infraestrutura adequada. 
 1 É fortemente indicado que a instituição que abrigará equipamentos em suas depen-
dências providencie uma malha de terra adequada. 
 1 É comum instituições e residências ignorarem essa questão, que pode evitar a 
queima dos equipamentos em situações de descargas elétricas.
Espaço para cabeamento e conexões
q 1 A saúde e vida útil do cabeamento utilizado nas redes dependem significativamente 
da disposição física utilizada. 
 1 Os cabos devem ser instalados de modo a evitar tensão no corpo dos cabos e nos 
conectores.
 1 Deve-se evitar dobrar o cabo em ângulos muito pequenos. 
 1 Para atender a esses objetivos é importante alocar espaço adequado dentro dos 
racks para acomodação de sobras de cabeamento.
Veja no destaque da figura seguinte as dobras com ângulos diferentes.
44
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 
Figura 3.15 
Boas práticas de 
cabeamento (Fonte: 
taquara.olx.com.br).
45
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
ob
je
tiv
os
conceitos
4
Switches e roteadores
Descrever o uso de switches de camada 2 e de camada 3, o uso de roteadores na rede 
da instituição, a conexão com a rede da RNP e as vantagens de utilizar VLANs. 
 
Switches L2 e L3, comutação L2, empilhamento, subdivisão da rede em VLANs, 
roteadores.
 
 
Switches L2
q 1 Os switches L2 têm a função de distribuir e segmentar os pontos de rede e as LANs 
do ambiente. 
 1 A função fundamental desses elementos é receber um frame, avaliar o campo “ende-
reço MAC destino” e tomar a decisão de encaminhamento. 
 1 O switch L2 não faz o serviço de roteamento de pacotes; se um frame chega para ele, 
ocorre que tipicamente algum roteador já tomou a decisão de roteamento, ou seja, 
a rede onde o destinatário do pacote reside já foi descoberta.
 1 Cabe ao switch apenas avaliar em qual ponto de rede está o destinatário do frame.
46
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Em qual porta física está o destino?
Destino
Roteamento L3
Pacote
Default
Gateway
Rede L2 (comutação)
Em qual porta física
está o destino?
O dimensionamento de um switch depende principalmente:
 1 Da quantidade de interfaces requeridas;
 1 Da velocidade dessas interfaces;
 1 Da quantidade de LANs (VLANs) que trafegarão dados pelo equipamento;
 1 Da necessidade de redundância de hardware (fontes, CPUs, backplanes etc);
 1 Da necessidade de ter serviços L2 e L3 no mesmo equipamento.
A exemplo do que ocorre com os roteadores, o porte de um switch pode variar tremen-
damente dependendo de sua aplicação. Para referência, o peso dos switches usados pelo 
mercado pode variar de 1,5 a 300 kg. Seu preço pode sair da ordem de centenas de reais até 
centenas de milhares de dólares.
Um switch de rede local popular possui 24 portas fast ethernet (100 Mbps). Um switch de 
um centro de processamento de dados de um grande provedor de conteúdo de internet 
possui mais de 200 portas com capacidade de 10Gbps cada uma. A diferença de capacidade 
de processamento entre os equipamentos desse exemplo justifica a grande diferença de 
preço entre eles.
Switches L3
q 1 Os switches L3 podem fazer as funções de L3 e/ou de L2. 
 1 Cabe ao administrador de rede fazer essa definição. 
 1 Em algumas situações, o switch L3 pode substituir o uso do roteador e do switch L2, 
de modo que as funções L2 e L3 estejam no mesmo equipamento. 
 1 Em outras aplicações, o switch L3 pode fazer a função L2 para algumas VLANs e a 
função de L3 para outras, dependendo da conveniência do administrador.
Figura 4.1 
Roteamento 
L3 versus 
encaminhamento 
L2.
47
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
Algumas aplicações do switch L3 são mostradas a seguir. A figura seguinte exibe uma rede 
local típica, um roteador fazendo o papel de default gateway da LAN e um switch fazendo o 
papel de distribuição dos pontos de rede. Embora haja apenas um único switch no esquema 
da figura, poderiam existir vários outros, operando em diferentes hierarquias.
Default gateway das VLANs A, B e C
Função L3
Função L2
VLAN A VLAN CVLAN B
A figura seguinte mostra a mesma LAN, mas o roteador e o switch foram substituídos por 
um único equipamento, um switch L3.
Default gateway das VLANs A, B e C
Funções L3 e L2
VLAN A VLAN CVLAN B
Uma aplicação típica do switch L3 no mundo real pode ser vista nas próximas figuras. 
q 1 Os servidores das VLANs 10 e 20 não acessam a internet nem a rede Ipê, no entanto 
essas duas VLANs trocam grande volume de tráfego entre si.
 1 A VLAN 30 usa a rede Ipê intensamente, acessando servidores das VLANs 10 e 
20 eventualmente. 
O administrador de rede recebeu várias reclamações de lentidão de usuários da VLAN 30. 
Na figura abaixo as setas pretas exibem o tráfego entre as VLANs 10 e 20. As setas cinzas 
mostram o tráfego da VLAN 30.
Figura 4.2 
Interação L2-L3 
tradicional com 
switch e roteador.
Figura 4.3 
Switch L3 faz o 
papel de default 
gateway de várias 
redes/sub-redes/
VLANs.
48
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Rede Ipê
VLAN 10VLAN 30 VLAN 20
Default Gateway das VLANs 10, 20 e 30
Link saturado
Após uma investigação, foi percebido que o link entre o switch L2 e o roteador apresentava 
descarte de pacotes, sinal de saturação. 
q 1 O administrador de rede dispunha de um switch L3 que sobrou de um projeto não 
terminado e resolveu trocar o switch L2 pelo L3. 
 1 O switch L3 se tornou o default gateway das VLANs 10 e 20. 
 1 O tráfego entre as VLANs 10 e 20 não compete mais com o tráfego entre VLAN 30 e 
rede Ipê.
Figura 4.4 
Usuários da 
VLAN 30 reclamam 
de lentidão.
49
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
Rede Ipê
VLAN 10VLAN 30 VLAN 20
Default Gateway da VLAN 30
Default Gateway das VLANs 10 e 20
Link OK
No mundo real poderíamos pensar em fundir as VLANs 10 e 20 em uma mesma VLAN. Dessa 
forma o tráfego entre os hosts das duas redes não mais competiria com o tráfego da VLAN 
30. No entanto, existem situações em que essa fusão não é possível, por motivos técnicos 
ou políticos.
Seria possível ainda pensar em substituir também o roteador. Na figura optou-se por manter 
o roteador ativo. Essa decisão pode ser correta em casos onde o roteador presta outros ser-
viços além do roteamento tradicional, como NAT, firewall e VPN, entre outros. Dessa forma, 
evita-se que o switch L3 fique com seus recursos de hardware saturados, mantendo nesse 
equipamento apenas os serviços tradicionais de roteamento e switching. Da mesma forma, 
há economia de recursos do roteador com a redução do tráfego que ele precisa tratar.
O dimensionamento dos switches L3 é definido quase pelos mesmos parâmetros dos 
switches L2.
Comutação L2
q 1 Os switches L2 também executam protocolos para otimizar o serviço de encaminhamento. 
 2 Exemplo: protocolo spanning-tree. 
 1 Os switches se utilizam desse protocolo para evitar que ocorram loops de encaminha-
mento na rede. 
 1 Um loop de encaminhamento tem o poder de parar completamente uma rede, e isso 
efetivamente ocorre no mundoreal.
Figura 4.5 
Switch L3 elimina 
o problema.
50
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Em ambientes onde existe mais de um caminho possível para se chegar a um host é 
fundamental a presença do spanning-tree, tanto que todos os fabricantes de equipa-
mentos de rede já deixam esse protocolo habilitado de fábrica. 
 1 Um switch normalmente executa uma instância de spanning-tree para cada 
VLAN existente. 
Tem-se aí um ponto de limitação para o dimensionamento do número de VLANs que um 
switch pode suportar.
Links operando
Links bloqueados
Root Bridge
A operação do spanning-tree não será detalhada neste curso. 
qEm resumo, seu objetivo é fazer com que só exista um caminho válido entre dois pontos 
quaisquer de uma rede L2.
Empilhamento
q 1 Quando o número de usuários de uma rede local aumenta muito, é necessário lançar 
mão de outros recursos para fazer a rede escalar. 
 1 Os esquemas de expansão de portas não podem ajudar neste caso específico. Nesse 
cenário a solução é mesmo aumentar o número de portas físicas.
 1 Quando um switch não tem mais portas físicas disponíveis é possível empilhar mais 
de um switch para aumentar a densidade de portas. 
 1 O empilhamento consiste em criar um único equipamento lógico a partir de dois ou 
mais switches físicos.
 1 A comunicação entre os switches pode se dar via porta Ethernet ou via cabeamento 
específico para o fim de empilhamento.
A ideia é simples. O administrador de redes empilha dois switches de 24 portas cada e 
obtém um único “switch lógico”, que possui 48 portas. Os demais equipamentos de rede 
nunca saberão que ali existem dois switches, pois ambos respondem pelos mesmos ende-
reços IPs e pelo mesmo hostname.
Figura 4.6 
Spanning-tree: evita 
loops de rede.
51
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
Subdivisão da rede em VLANs de distribuição
qA divisão da rede em VLANs é uma das boas práticas em rede local. Há vários motivos 
para realizá-la. Aqui citaremos cinco:
 1 Aumento da confidencialidade dos dados das diferentes redes.
 1 Economia de recursos dos elementos de rede e de links.
 1 Economia de recursos dos hosts através da redução dos domínios de broadcast.
 1 Flexibilidade para configuração de políticas de roteamento e segurança.
 1 Flexibilidade para distribuição física dos pontos de redes. 
Neste texto os termos VLAN e sub-rede são usados de maneira intercambiável, pois em uma 
rede dividida em VLANs os termos têm exatamente o mesmo significado. A figura seguinte 
ilustra um esquema onde os diferentes departamentos de uma instituição estão separados 
em VLANs. 
R1 R2
SW2SW1
200.1.1.64/26 200.1.1.0/26 200.1.1.128/25
Depto. financeiro
(VLAN 10)
Depto. de docentes
(VLAN 20)
Laboratório de alunos
(VLAN 30)
Figura 4.7 
Switches 
empilhados 
(Fonte: www.
kathmann.com).
Figura 4.8 
Divisão da rede 
em VLANs.
52
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 A boa prática diz que os hosts com maior interesse de tráfego devem ficar na mesma 
VLAN (rede). 
 1 Dessa forma o tráfego entre esses hosts não competirá pelos recursos de rede com 
outros hosts. 
 1 O tráfego de uma VLAN fica isolado do tráfego das demais. 
 1 O isolamento de tráfego das VLANs, além de salvar recursos da rede, promove um 
maior grau de segurança. 
Um capturador de tráfego que deseje capturar dados de um determinado departamento 
terá que usar um ponto de rede na VLAN do departamento a ser vitimado. Outros pontos de 
rede não enxergarão esse tráfego.
O processamento dos hosts da rede também tende a cair com a redução do domínio de bro-
adcast consequente da subdivisão em VLANs. Quando os hosts estão todos na mesma rede 
(ou VLAN) um broadcast gerado por qualquer host é recebido por todos os outros. A maioria 
dos hosts não usará a mensagem de broadcast. Com a rede dividida em sub-redes somente 
os pontos da VLAN onde foi gerado o broadcast recebem a mensagem, e recursos de rede e 
de hosts são economizados.
A rede dividida também facilita a configuração de políticas de roteamento e segurança. 
Na Figura 4.8 o roteador R1 é o default gateway das VLANs 10 e 20, e o roteador R2 é o 
default gateway da VLAN 30. Imagine que os dados do departamento financeiro são estri-
tamente confidenciais e não devem trafegar por nenhuma outra VLAN. Para implementar 
essa condição em uma rede dividida em VLANs, basta criar uma regra, ou lista de acesso, 
impedindo que pacotes com IP origem que não estejam na rede 200.1.1.64/26 possam ser 
destinados a pacotes desse alcance. Essa regra poderia ser configurada na saída da inter-
face de R1, que conecta ao switch SW1.
Se todos os hosts estivessem misturados em uma grande rede, a configuração dessa política 
seria complicada. Analogamente, a configuração de políticas de roteamento também é 
simplificada. Ainda na Figura 4.8, tem-se que o laboratório dos alunos não pode ser capaz 
de acessar os websites hospedados no departamento de docentes. Pode-se configurar uma 
política de roteamento no roteador R1 de modo que a rede 200.1.1.0/26 não seja anunciada 
ao roteador R2. Dessa forma, caso R2 não tenha uma rota default para o R1, os alunos não 
conseguirão acesso aos sistemas da VLAN dos docentes.
Observe que a solução do problema do parágrafo acima também poderia ser a criação de 
uma regra de segurança, mas uma vez que a rede da figura não possui firewalls, o admi-
nistrador da rede pode usar o roteador apenas para a tarefa de roteamento. O problema 
foi então resolvido com a manipulação de uma política de roteamento. Se os websites do 
departamento de docentes estivessem misturados na mesma VLAN do laboratório dos 
alunos, a configuração dessa política seria complicada.
Roteadores
q 1 Os roteadores são os protagonistas das redes baseadas em arquitetura TCP/IP 
ou IP/MPLS. 
 1 A função fundamental desses elementos é receber os pacotes IP, interpretar o campo 
“IP destino” e decidir como encaminhar o pacote. 
53
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
q 1 Essa decisão é a chave para o bom desempenho da rede e das aplicações que dela 
se utilizam.
 1 O uso de roteadores é mandatório em ambientes que tenham mais de uma rede, 
sub-rede ou VLAN. 
Um ambiente de rede que possui apenas uma única rede/sub-rede/VLAN não necessita de 
um roteador. Toda rede/sub-rede/VLAN, para ter seus pacotes chegando em outras redes, 
precisa de pelo menos um roteador. O roteador que roteia os pacotes da rede é chamado 
“default gateway” da rede/sub-rede/VLAN.
A figura seguinte exemplifica um ambiente de rede onde todos os hosts estão na mesma 
rede, ou seja, estão sobre o mesmo espaço de endereçamento IP. Nesse esquema um switch 
de rede (que não faz a tarefa de roteamento) fica diretamente conectado a um modem for-
necido pelo provedor de serviço, cenário que dispensa a necessidade de um roteador.
Provedor de serviço
Cliente com rede única
10.1.1.14 10.1.1.1210.1.1.19
Internet
10.1.1.0/24
q 1 Quando os roteadores da rede fazem uso de um protocolo de roteamento, diz-se que 
o roteamento ali é dinâmico. 
 1 O roteamento dinâmico se caracteriza por recalcular automaticamente as rotas quando 
ocorrem alterações na topologia da rede (quando ocorre uma falha, por exemplo). 
 1 Em redes complexas, onde existem várias possibilidades de encaminhamento, o uso 
do roteamento dinâmico é salutar.
Figura 4.9 
Ambiente de rede 
com uma única 
rede/sub-rede/
VLAN.
54
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Vários caminhos levam
do ponto A ou B
q 1 O roteamento estático também é utilizado na rede Ipê, para executar o serviço de 
encaminhamento de pacotesem partes da rede onde não há decisão de encaminha-
mento a ser feita. 
 1 O roteamento estático, diferente do dinâmico, não caracteriza troca de informações 
entre roteadores. 
 1 A informação de roteamento é inserida manualmente no roteador por um adminis-
trador de rede.
Há um único caminho
possível do ponto A ou B
A comunicação entre o roteador da instituição e a rede IP se dá tipicamente através de 
roteamento estático, pois há apenas um caminho possível entre as duas entidades. A van-
tagem de se usar essa modalidade de roteamento é a economia de recursos. O roteamento 
estático usa muito pouco de memória e CPU do roteador, enquanto que os protocolos de 
roteamento dinâmico, dependendo do tamanho da rede, podem requerer roteadores de 
grande porte, que são equipamentos caros.
Fazendo referência à arquitetura de referência OSI, diz-se que os roteadores atuam na 
camada 3 (layer 3) da arquitetura, chamada “camada de inter-rede”; na arquitetura TCP/IP 
essa camada se chama simplesmente “camada de rede”. Daí a expressão “equipamento L3”.
Figura 4.10 
Vários caminhos 
disponíveis: 
roteamento 
dinâmico.
Figura 4.11 
Apenas um 
caminho disponível: 
roteamento 
estático.
55
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
O dimensionamento de um roteador depende: 
 1 Do volume de tráfego que será cursado em suas interfaces;
 1 Da quantidade de interfaces que o roteador pode suportar;
 1 Da necessidade de redundância de hardware (fontes, CPUs, backplanes);
 1 Da capacidade do seu backplane (hardware de encaminhamento interno por onde 
passará o tráfego de todas as interfaces);
 1 Dos protocolos que serão usados e do tamanho da rede envolvida.
O backplane do hardware está intrinsecamente ligado à soma das capacidades das inter-
faces que funcionarão no equipamento. Um roteador com backplane de baixa capacidade 
não pode ter, por exemplo, dezenas de interfaces de 10Gbps, pois todo esse tráfego passará 
pelo backplane.
Em algumas situações, as placas de rede possuem alguma capacidade de processamento, 
fazendo com que parte da decisão de encaminhamento seja definida na própria interface 
de rede, que acaba por otimizar recursos do backplane e da CPU principal da máquina, evi-
tando que a sua capacidade precise ser maior que a soma das capacidades das interfaces. 
Em arquiteturas mais novas, o backplane é subdividido em estruturas menores, de modo 
que cada estrutura fica responsável por um conjunto de interfaces.
O porte de um roteador pode variar muito dependendo do seu uso. Por exemplo, o peso de 
um roteador pode variar de 6 (default gateway de algumas redes locais) a 180 kg (roteador 
de um provedor de porte nacional). Seu preço pode variar de pouco milhares de reais até 
centenas de milhares de dólares.
Para tomar a decisão de encaminhamento da forma mais eficiente os roteadores podem 
fazer uso de um protocolo de roteamento dinâmico. Através dele os diferentes roteadores 
que compõem a rede trocam informações uns com os outros e, baseando-se nas informa-
ções recebidas dos vizinhos, concluem qual o melhor caminho para se direcionar cada um 
dos pacotes IP recebidos.
q 1 Os principais protocolos de roteamento dinâmico executados na rede Ipê e em vários 
outros provedores comerciais são OSPF e BGP. 
 1 Em redes de organizações menores pode-se utilizar outros protocolos mais simples 
que consomem menos recursos de hardware (e consequentemente requerem equi-
pamentos mais baratos). 
 1 Um exemplo de protocolo de roteamento simples é o RIP.
 1 Exemplos de outros protocolos menos populares, mas não menos eficientes que 
os citados:
 2 IS-IS. 
 2 EIGRP.
Figura 4.12 
Roteador Juniper 
Série J: pequeno 
porte (Fonte: 
www.juniper.net).
56
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
O funcionamento detalhado de cada um desses protocolos de roteamento não é tema deste curso.
Roteador de borda
q 1 O roteador de borda provê a comunicação de todas as VLANs da rede local com 
a internet.
 1 Esse elemento é candidato natural a receber a configuração das políticas de rotea-
mento da instituição, tais como restrições de acesso a sites não autorizados.
 1 Problemas de lentidão ou indisponibilidade de serviços de internet podem ter ligação 
direta com a boa saúde desse roteador e do seu link com a internet, normalmente 
chamado de “uplink da instituição”.
 1 Quando a conexão da instituição não tiver um enlace de backup, esse roteador execu-
tará roteamento estático, o mais recomendado para esse cenário. 
 1 Se houver mais de um enlace através do qual se possa chegar à internet, esse ele-
mento deverá executar um protocolo de roteamento dinâmico.
Internet
Rede local
Roteador de borda
VLAN 21 VLAN 22 VLAN 23
Troubleshooting básico
Gerência e documentação de rede, planejamento de topologia, controle da alocação de IPs e da 
distribuição das sub-redes e identificação de cabos. Todas essas práticas apresentadas confi-
guram diferentes recursos para atingir um mesmo fim: manter a maior disponibilidade possível 
dos serviços de rede. Às vezes, mesmo com todos esses cuidados, os problemas ocorrem.
O troubleshoot de falhas pode ser simples ou complexo, dependendo dos recursos disponíveis. 
Todas as práticas apresentadas no parágrafo anterior ajudam significativamente a acelerar o 
processo de solução. O último recurso é uma metodologia básica de ataque a problemas.
Uma metodologia que funciona com frequência é a seguinte:
1. Predizer o comportamento normal da rede e comparar o cenário correto com 
o sintoma percebido.
Figura 4.13 
Roteador de borda.
57
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
2. Isolar o problema: investigar a conectividade de camada 3 de cada hop. 
3. Ao encontrar o hop cuja conectividade de camada 3 não funciona, verificar nesse hop a 
saúde das camadas 2 e 1. 
Para executar esse processo aparentemente simples, faz-se uso de uma série de conheci-
mentos e recursos. 
O exemplo seguinte ilustra a aplicação do método de forma didática e demorada. 
Na prática, várias das etapas da investigação que será apresentada podem ser executadas 
de maneira simplificada com o comando “traceroute” ou com uma breve entrevista junto 
ao usuário reclamante.
PC 1
10.0.1.1/24
PC 2
10.0.1.2/24
PC 3
R1 R2
Servidor Web
10.0.0.1/24
Sw1
Sw2
Sw3
Sw4
f0/0
f0/1f0/1 f0/2
5
2
1
6
4
3
O usuário do PC1 reclamou que não consegue mais acessar http://webserver.com/relatorio, 
uma página web que está hospedada no servidor web da figura. Um usuário do PC3 acessa 
normalmente o site, sugerindo que não há problema com o servidor.
A Figura 4.14 ilustra todos os passos da conectividade de camada 3 entre PC1 e o servidor 
em uma situação normal. Os números ao lado das setas identificam a ordem dos aconteci-
mentos. As setas pretas ilustram a viagem dos dados de PC1 até o servidor. As setas cinzas 
mostram o caminho da resposta do servidor até PC1.
Como o servidor está funcionando, o administrador da rede orientou o usuário a fazer um 
“ping” para o IP do servidor. O “ping” não teve sucesso. Dessa forma, a próxima etapa é veri-
ficar qual dos 6 passos não está ocorrendo. Para cada passo investigado, caso a conectivi-
dade de camada 3 funcione, não se fará necessário verificar as camadas 2 e 1 do hop.
Investigando o passo 1, foi verificado se o pacote está realmente saindo de PC1 e chegando 
ao R1. O primeiro passo foi investigar se o browser utilizado no PC1 está conseguindo tra-
duzir o nome do servidor para o IP correto, 10.0.0.1. Isso pôde ser verificado executando-se 
no PC1 o comando “nslookup webserver.com”.
Figura 4.14 
Cenário de 
problema.58
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
O próximo passo foi verificar se a configuração de default gateway do PC1 está correta. 
O comando “ipconfig /all” mostrou o IP da interface f0/0 do R1 como o default gateway. 
A configuração do PC1 estava correta. Foi executado um “ping” do PC1 para o IP do seu 
default gateway, no caso, o IP da interface f0/0 de R1. O “ping” funcionou. O passo 1 da 
figura está funcionando. 
Em seguida o passo 2 foi investigado. Analisando a tabela de rotas de R1 foi verificado se ele 
conhece a rede 10.0.0.0/24, onde está o servidor. Verificou-se que a rota é conhecida e que 
aponta para R2, o que é correto. Por fim, a partir de R1 foi feito um “ping” para a interface 
f0/1 de R2, que funciona. O passo 2 corretamente verificado.
Em seguida o passo 3 foi investigado. Analisando a tabela de rotas de R2 foi verificado se ele 
conhece a rede 10.0.0.0/24, onde está o servidor. Verificou-se que a rota é conhecida. Em 
seguida o administrador tentou um “ping” do R2 para o IP do servidor web, que funcionou. 
Passo 3 corretamente verificado.
Os parágrafos acima mostram que um pacote saindo do PC1 chega ao servidor. Agora, o 
administrador avalia o tráfego de retorno. Como o “ping” do passo 3 funcionou, o admi-
nistrador concluiu de imediato que o servidor consegue fazer um “ping” para o seu default 
gateway, logo, o passo 4 funciona. Isso já poderia ser concluído apenas pelo fato de o PC3 
conseguir acessar o serviço.
Em seguida o passo 5 foi investigado. Analisando a tabela de rotas de R2 foi verificado se ele 
conhece a rede 10.0.1.0/24, onde está o PC1. A rota é desconhecida. A partir de R2 foi feito 
um “ping” para o IP de PC1. O “ping” não funcionou! O passo 5 não está funcionando. A partir 
daqui a investigação se concentra nesse hop. Nesse caso, existe uma clara falha na camada 3. 
Assim, por ora, não será necessário “descer” às camadas 2 e 1. 
Foi verificado que a vizinhança OSPF entre R1 e R2 estava estabelecida. No entanto, por 
algum motivo, R1 deixou de anunciar a rota 10.0.1.0/24 para R2. Foi verificado que alguém 
editou um filtro de rotas de maneira incorreta em R1, o que provocou a falha. O adminis-
trador corrigiu o filtro e o passo 5 passou a funcionar.
Fazendo uma nova tentativa o usuário conseguiu acesso ao servidor. Se após a alteração no 
protocolo de roteamento o passo 5 continuasse a falhar, o próximo passo seria investigar a 
camada 2 nesse passo, ou seja, as configurações do switch SW2.
59
 
C
ap
ítu
lo
 4
 - 
Sw
itc
he
s 
e 
ro
te
ad
or
es
 
Estudo de caso
Solicitação, atribuição e administração de blocos IP
RNP / Internet 
VLANs 
10 e 20 VLAN 30 VLAN 40
 
VLAN 50
fe-0/0/0 
fe-0/0/1 
R1
 
R2 
SW1 SW2 SW3 SW4
fe-0/0/1
fe-0/0/0
fe-0/0/2
fe-0/0/2
Dados da rede
VLANs Intervalo Total 
de IPs
IPs em 
uso
Crescimento 
estimado
PCs administração 200.33.1.128/25 126 112 126
Laboratórios 200.33.1.32/28 14 4 6
Infraestrutura 200.33.1.16/29 6 3 3
Serviços 200.33.1.64/27 30 11 12
PCs professores 200.33.1.96/27 30 5 20
Descrição das VLANs
 1 10 – Desktops administrativos: máquinas de diretores, secretárias e da área financeira.
 1 20 – Laboratórios: PCs e outros equipamentos IP usados nas aulas práticas.
 1 30 – Dois servidores de backup (B1 e B2) e um servidor de repositórios de arquivos (A1), 
onde professores gravam e recuperam material de aulas. O servidor B1 faz backup 
somente dos serviços da VLAN 40. O servidor B2 faz backup de todos os PCs (professores 
e administração) e ainda do servidor de repositório A1.
 1 40 – Serviços: base de dados de matrículas e dados dos alunos, servidor de FTP, servidor 
de e-mail, DNS e outros.
 1 50 – Desktops das salas dos respectivos professores. 
Figura 4.15 
Cenário do estudo 
de caso.
60
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Descrição do cenário
Uma instituição de ensino mantém a rede cujo esboço do diagrama de rede encontra-se 
na figura. Na época da qualificação junto à RNP foi concedido à organização o intervalo de 
endereços 200.33.1.0/24.
À época, a demanda da rede era de 100 endereços. O administrador de rede dividiu então o 
intervalo /24 em dois intervalos /25.
 1 Intervalo 1: 200.33.1.0/25;
 1 Intervalo 2: 200.33.1.128/25.
O administrador usou o segundo intervalo para compor uma VLAN de PCs da administração, a 
VLAN 10 (a única rede existente à época) e guardou o primeiro intervalo para demandas futuras. 
Um ano depois, toda a equipe de administradores de rede mudou e não havia muita docu-
mentação. Várias demandas de novas VLANs surgiram. Os novos administradores foram 
alocando novos intervalos de IP sem muito planejamento. 
Nesse período foram criadas mais 4 VLANs: 20, 30, 40 e 50. Além disso, o número de usuá-
rios da VLAN 10 cresceu mais. Os dados atuais das 5 VLANs da instituição são encontrados 
logo abaixo da figura.
Você foi contratado para ajudar os administradores de rede da instituição a resolver vários 
problemas da rede. O primeiro problema é o atendimento a uma demanda por uma nova 
VLAN, número 60, que será usada por notebooks de alunos durante as aulas. Estima-se que 
essa nova VLAN precisa de pelo menos 40 IPs.
61
 
C
ap
ítu
lo
 4
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
2
Roteiro de Atividades 2
Atividade 2.1 – Endereçamento IP
Qual o tamanho de máscara máximo necessário para uma sub-rede comportar essa nova VLAN?
Dada a utilização atual da rede 200.33.1.0/24 na instituição, exemplifique uma sub-rede 
daquele intervalo de IPs que poderia ser usada para abrigar a nova VLAN?
Após a análise do item anterior, um dos integrantes da equipe de administradores sugeriu 
solicitar um novo bloco IP à RNP. Ao analisar a situação, qual posição você acha que a equipe 
da RNP responsável tomará? Por quê?
Atividade 2.2 – Identificação de soluções
A ideia de solicitar um novo bloco não foi adiante. Dessa forma, sua ajuda foi requisitada 
para resolver o problema de rearranjo de endereços para implementar uma nova VLAN, 
com previsão de 40 endereços. Porém, outros problemas foram expostos, e você terá que 
propor soluções para todos eles. Para tal, utilize as informações contidas na área “Descrição 
das VLANs”. Os problemas são os seguintes:
1. Organizar a distribuição de endereços da rede de modo que uma nova sub-rede possa 
ser definida para abrigar a nova VLAN 60, e ainda atender à expectativa de crescimento 
das demais VLANs (a demanda de crescimento encontra-se na área “Dados da rede”).
2. Professores do turno da noite reclamam de lentidão ao acessar o servidor de repositório. 
É sabido que os backups ocorrem durante a noite. Os servidores de backup estão na 
VLAN 30, e realizam o backup dos hosts das VLANs “Serviços” e “PCs administração”, além 
do próprio servidor de repositório de arquivos.
3. Os hosts da VLAN “Serviços” possuem licenças de software associadas a seus endereços 
IP, e não podem ter seus endereços trocados sob nenhuma hipótese.
4. Para manter a simplicidade, foi definido pela equipe de administradores que a topologia 
básica da rede não mudará. Ou seja, as conexões entre switches e roteadores não pode 
ser modificada.
Dados os problemas “1” e “2” e as premissas “3” e “4”, indique a seguir propostas de melhoria. 
Pode ser usada toda e qualquer ação que respeite as duas premissas estabelecidas.
62
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Atividade 2.3 – Planejando VLANs
Agora que seu grupo já possui um conjunto de soluções formuladas, faça um esboço 
de como ficaria a distribuição das VLANs e dos elementos chave dentro da rede. Nesse 
desenho, destaque as VLANs utilizando figuras de nuvens,e, se desejar, destaque os servi-
dores (de backup e/ou de repositório de arquivos) com as letras B1, B2 e A1, de acordo com o 
nome do servidor. No desenho, considere já a implantação da nova VLAN 60 para os PCs de 
alunos, já a posicionando no switch que lhe parecer mais conveniente.
63
 
C
ap
ítu
lo
 4
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
2
Atividade 2.4 – Distribuição das sub-redes
Considerado o desenho esboçado, é hora de definir a distribuição das sub-redes dentro do 
endereçamento 200.33.1.0/24. Cabe lembrar nesse momento a necessidade de atendimento 
à premissa “3”, estabelecida no início da atividade, e a demanda de crescimento de cada 
VLAN, citada na área “Dados da rede”. Tome o cuidado de utilizar uma solução que valorize 
os seguintes parâmetros (nessa ordem):
 1 Solução mais adequada às demandas de crescimento de cada VLAN;
 1 Solução que se traduza na menor quantidade de mudanças, tornando a ação o mais 
simples possível.
Depois de avaliar a tabela de endereçamento, é possível que você tenha que readequar sua 
solução de desenho da rede (Atividade 2.3) ou mesmo pensar em novas soluções (além das 
citadas na Atividade 2.2) para liberar mais endereços.
A tabela seguinte mostra uma possível distribuição:
Número da 
VLAN
Nome Prefixo/ 
máscara
Total 
de IPs
IPs em 
uso
Demanda
10 PCs administração 200.33.1.128/25 126 112 126
20 Laboratórios 200.33.1.80/29 6 4 6
30 Infraestrutura 200.33.1.88/29 6 3 3
40 Serviços 200.33.1.64/28 14 11 12
50 PCs professores 200.33.1.96/27 30 5 20
60 PCs alunos 200.33.1.0/26 62 40 40
A metodologia para se chegar a essa solução é a seguinte:
 1 A sub-rede da VLAN 40 tem que ser 200.33.1.64 (condição do enunciado). Como o enun-
ciado também pede que se use a “solução mais adequada às demandas de crescimento 
de cada VLAN”, a máscara dessa rede deverá ser /28.
 1 Para as demais VLANs: aloca-se o endereço da maior VLAN para a menor, sempre verifi-
cando se é possível manter o mesmo range de IPs da rede original.
Dessa forma, a primeira premissa estabelecida para a solução é: “Solução mais adequada às 
demandas de crescimento de cada VLAN”.
Assim, o menor tamanho possível para cada VLAN é:
Nome da 
VLAN
Máscara Quantidade 
de IPs
Observações
VLAN 10 /25 126 IPs -
VLAN 20 /29 6 IPs -
VLAN 30 /29 6 IPs Dependendo da solução usada pelo aluno, essa 
VLAN pode nem existir mais.
64
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Nome da 
VLAN
Máscara Quantidade 
de IPs
Observações
VLAN 40 /28 14 IPs O endereço IP dos servidores dessa VLAN não 
pode mudar, mas a máscara pode.
VLAN 50 /27 30 IPs -
VLAN 60 /26 62 IPs -
O primeiro ponto a se observar é que os hosts da VLAN 40 não podem ter seus IPs alte-
rados, logo, o prefixo dessa VLAN não pode mudar, apenas a máscara.
O segundo ponto é que a maior VLAN (número 10) consome um /25 inteiro. Um dos obje-
tivos traçados pelo enunciado é obter uma “solução que se traduza na menor quantidade 
de mudanças, tornando a ação o mais simples possível”. Para se chegar a esse objetivo é 
razoável pensar em manter intocáveis os IPs da VLAN 10. Dessa forma, nada menos que 112 
hosts ficarão inalterados. Dessa forma, o primeiro ponto é fechar a sub-rede das VLANs 10 e 
40, que ficam assim:
VLAN Nome Prefixo Total de IPs IPs em uso Demanda
10 PCs administração 200.33.1.128/25 126 112 126
40 Serviços 200.33.1.64/28 14 11 12
A segunda maior sub-rede será a nova VLAN 60, a qual precisará ser pelo menos um /26. 
A definição das VLANs 10 e 40 deixa apenas uma rede /26 livre: 200.33.1.0/26. Com isso, a 
definição evolui para:
VLAN Nome Prefixo Total de IPs IPs em uso Demanda
10 PCs administração 200.33.1.128/25 126 112 126
40 Serviços 200.33.1.64/28 14 11 12
60 PCs alunos 200.33.1.0/26 62 xxx 40
Nesse ponto, se dividirmos a rede da instituição em sub-redes /26, temos as 4 redes:
a – 200.33.1.0/26
b – 200.33.1.64/26
c – 200.33.1.128/26
d – 200.33.1.192/26.
Juntas, as VLANs 10 e 60, que já definimos, consomem por inteiro as sub-redes “a”, “c” e “d”.
A sub-rede “b”, que resta, pode ser dividida em duas sub-redes /27, que chamaremos redes 
“d” e “e”.
 /26 /27
_________________________________________________________________________
65
 
C
ap
ítu
lo
 4
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
2
b - 200.33.1.64/26 == 200.33.1.01 000000 == d - 200.33.1.010 00000
 == e - 200.33.1.011 00000
-----------------------------------------------------------------------------------------------------------------------
Metade da rede “d” (um /28) já foi consumida pela VLAN 40. A rede “e” permanece disponível. 
Nesse ponto, temos então à disposição uma rede /27 inteira (a rede “e”) e uma rede /28 inteira.
Resta definir os endereços das VLANs 20, 30 e 50. A maior delas é a VLAN 50. Como o obje-
tivo é buscar a ação o mais simples possível, vamos verificar se é possível manter os hosts 
dessa VLAN com seus IPs inalterados. O range atual é um /27:
200.33.1.96/27
Esse range corresponde à rede “e”, que está disponível. Então, alocamos a rede para a VLAN 50.
VLAN Nome Prefixo Total de IPs IPs em uso Demanda
10 PCs administração 200.33.1.128/25 126 112 126
40 Serviços 200.33.1.64/28 14 11 12
50 PCs professores 200.33.1.96/27 30 5 20
60 PCs alunos 200.33.1.0/26 62 xxx 40
Resta alocar endereços para as VLANs 20 e 30. Ambas as redes são /29. Nesse momento, 
ainda nos resta uma rede /28, que pode ser dividida em duas redes /29.
A VLAN 20 originalmente usava o range 200.33.1.32/28, o qual já está em uso nesse 
momento. Então, usamos uma rede /29 que ainda está disponível. Usamos a rede 
200.33.1.80/29, por exemplo. Para a VLAN 30, resta a rede 200.33.1.88/29. Dependendo das 
decisões que o grupo tomou, esta VLAN 30 pode nem ser necessária.
66
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
67
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
ob
je
tiv
os
conceitos
5
Serviços e gerenciamento da rede 
da instituição
Descrever os principais serviços de rede da instituição, os procedimentos para obtenção 
de blocos de endereços IP e as principais ferramentas de gerenciamento de rede.
 
Serviços DNS, registro MX, web, SFTP, e-mail, repositório de arquivos, firewall, DMZ, NAT. 
 
 
Serviços de rede
O objetivo maior de uma rede local é prover serviços a seus usuários. Pode-se dizer que 
esses serviços são o que os clientes realmente enxergam. Do ponto de vista do adminis-
trador de redes é comum receber uma descrição de reclamação do tipo “rede lenta”, quando 
na verdade há um único serviço que apresenta lentidão. Muitas vezes todos os outros ser-
viços estão funcionando a contento.
q 1 Os serviços podem ser hospedados na própria rede local ou em redes remotas, que 
pertencem a terceiros. 
 1 A vantagem de se manter serviços na rede de terceiros é a simplificação da tarefa de 
sua administração. 
 1 Nesse caso, a responsabilidade pela manutenção da boa saúde dos servidores fica 
com os administradores da rede remota. 
 1 A grande desvantagem é que a qualidade do serviço prestado na rede local fica à 
mercê da capacidade daquela equipe remota.
 1 A desvantagem descrita faz com que os administradores da rede local sejam levados 
a manter alguns serviços fundamentais na própria rede local. 
 1 Serão feitas sugestões de serviços que devem ser mantidos em rede local.
DNS
O serviço de DNS pode ser tema de um curso inteiro. Os detalhes do funcionamento do 
serviçonão serão explorados aqui, de modo que faremos apenas uma análise suficiente 
para os objetivos deste curso.
q 1 O DNS pode ser descrito como uma grande e importante base de dados distribuída 
pela internet. 
68
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Essa base é responsável por um dos serviços mais importantes da internet contem-
porânea: a tradução de nomes para endereços IP. 
Os usuários da internet não conhecem o endereço IP de nenhum serviço, mas conhecem o 
seu nome. O PC desses usuários, por sua vez, precisa do endereço IP para acessar o serviço. 
Dessa forma, uma tradução nome-IP deverá ocorrer.
Quando o usuário digita no seu browser o URL www.rnp.br, o serviço de DNS deverá ser 
acionado para que o browser efetivamente consiga buscar o IP do sítio da RNP.
Existem diferentes tipos de servidores DNS, bem como diferentes métodos de consulta.
q 1 Além de usado para consultas a nomes de serviços remotos, o DNS também é usado 
para descobrir o IP de serviços de rede local. 
 1 Quando se tenta, por exemplo, mapear uma pasta de rede chamada 
\\servidor_arquivos1.esr.rnp.br\curso, o PC precisa saber o IP da máquina 
“servidor_arquivos1”, que fica no domínio esr.rnp.br. O DNS dará essa resposta.
 1 O servidor de DNS tem importância particular para instituições que possuem nome 
de domínio registrado junto ao Nic.br.
 2 Nic.br é o órgão responsável pelo registro de domínios no Brasil, administrado 
pelo Comitê Gestor da Internet no Brasil (CGI.br).
 1 Todo domínio com final “.br” deve ser conhecido pelos servidores DNS do Nic.br, ou 
seja, deve estar registrado junto ao órgão.
q 1 Todo domínio precisa de pelo menos um servidor DNS autoritativo. 
 1 Aos clientes da RNP é sugerido um mínimo de dois servidores para esse fim (por 
segurança). 
 1 Quando uma instituição registra um domínio, ela informa ao Nic.br quem é(são) o(s) 
servidor(es) DNS autoritativo(s) daquele domínio. 
 2 O servidor autoritativo é aquele que responde pelo domínio. 
Na Figura 5.2, o domínio “rnp.br” está registrado no Nic.br. O servidor DNS autoritativo do 
domínio está hospedado na rede local da RNP. O Nic.br sabe quem é esse servidor. Dessa 
forma, quando um usuário da internet acessa o serviço www.rnp.br, uma consulta DNS é 
gerada ao servidor de DNS que atende a esse usuário. Normalmente esse servidor está 
hospedado no provedor de internet do usuário.
Figura 5.1 
Organograma 
Nic.br.
69
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
Esse servidor vai consultar recursivamente quantos servidores são necessários para chegar 
ao servidor autoritativo da RNP, que conseguirá indicar o IP da máquina www do domínio 
esr.rnp.br.
Instituição
rnp.br
Pergunte ao DNS rnp.br
Qual o IP de www.rnp.br ?
Servidor DNS
domínio “.br”
Servidor DNS instituição
Servidor DNS
domínio “rnp.br”
Qual o IP de
www.rnp.br ?
Qu
al 
o I
P d
e w
ww
.rn
p.b
r ?
O 
IP 
é Y
.Y.
Y.Y
 !
O IP é Y.Y.Y.Y !
1
4
5
6
2
3
.br
q 1 Vantagens de uma instituição em manter o servidor DNS autoritativo do seu domínio 
sob sua própria administração:
 2 Flexibilidade na administração do serviço.
 2 Responsabilidade pela manutenção do serviço. 
 1 Quando o servidor autoritativo está sob administração de uma entidade externa, não 
se pode garantir que o serviço de nomes do domínio estará no ar o tempo todo.
 1 Outro problema pode ser gerado toda vez que um serviço do domínio precisar mudar 
de endereço IP. 
 1 Quando uma instituição passa a fazer parte do sistema autônomo da RNP, é comum 
que seus endereços IP sejam migrados para o espaço de endereçamento da RNP. 
Se a instituição tem a administração do servidor DNS, ela mesma terá a oportunidade de 
realizar a migração do endereço, alterando também a configuração do servidor DNS respon-
sável pelos seus domínios. Se a administração desse servidor fica a cargo de uma entidade 
remota, a tarefa de migração fica muito mais complicada.
A migração de endereço IP de serviços juntamente com a reconfiguração do DNS autoritativo 
é uma tarefa grande, que não será aqui detalhada. 
Figura 5.2 
Consulta recursiva 
para localizar 
www.esr.rnp.br.
70
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
MX
O serviço de DNS descrito provê acesso aos registros do tipo A (address).
q 1 Além do acesso aos registros “A”, o servidor autoritativo de um domínio também 
pode prover consultas ao registro MX, usado na execução do serviço de e-mail.
 1 Exemplo: 
 2 Um usuário da internet, proprietário da conta de e-mail “huguinho@cartoons.
com”, deseja enviar uma mensagem de e-mail para “zezinho@rnp.br”. 
 2 O servidor de e-mail do domínio “cartoons.com” receberá a mensagem e tentará 
descobrir o IP de um servidor de e-mail do domínio rnp.br, que poderá receber a 
mensagem e passá-la para o usuário Zezinho. 
 2 Assim, será gerada uma consulta DNS do tipo MX.
O endereço IP será provido pelo serviço de DNS, através do registro MX. Assim, o servidor 
autoritativo responsável pelo domínio rnp.br será consultado. O servidor verificará o valor 
configurado na entrada MX e responderá. Descoberto o endereço do servidor de e-mail do 
domínio do destinatário da mensagem, o servidor de e-mail de “cartoons.com” se comuni-
cará via protocolo SMTP com o servidor de e-mail de rnp.br, e a mensagem será transferida.
DNS
Qual é IP do serviço 
de correio de rnp.br ?
O IP é X.X.X.X
O IP é X.X.X.X
e-mail para
zezinho@rnp.br
e-mail para
zezinho@rnp.br
3
4
1
7
5
2
6
e-mail para
zezinho@rnp.br
DNS
SMTP
POP3
Legenda:
Qual é IP do serviço 
de correio de rnp.br ?
Serviço DNS Internet
Servidor DNS Local
Rede Local
Servidor de
Correio local
Servidor de
Correio rnp.br
Web
q 1 Esse serviço é o mais popular da internet. 
 1 Praticamente todas as instituições com um domínio registrado possuem um servidor 
web que hospeda seu sítio e serviços on-line. 
 1 Deixar esse serviço sob a hospedagem de terceiros significa entregar a entidades externas 
a responsabilidade pela disponibilidade e manutenção dos serviços web da instituição.
Figura 5.3 
Consulta ao 
registro MX para 
envio de e-mail.
71
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
Existe uma grande tendência de migração de serviços para o ambiente web, o que torna a 
importância desse serviço ainda maior. Alguns especialistas preveem que na internet do 
futuro (não muito distante) o usuário de PC terá apenas um único programa instalado em 
sua máquina: um web browser, que proverá acesso a qualquer tipo de serviço: web, e-mail, 
edição de textos e planilhas, acesso remoto, home-banking, home-office, videoconferência, 
videochamada, videomedicina, monitoração remota de ambientes etc.
SFTP
q 1 Provê as mesmas funcionalidades do servidor de FTP, porém aplicando criptografia, 
para garantir a confidencialidade e integridade dos dados transferidos. 
 1 Esse serviço possibilita transferir e armazenar arquivos na rede local. 
 1 A aplicabilidade desse serviço na rede local é vasta. 
 1 Dentre as várias aplicações, o uso desse serviço evita que usuários da rede transfiram 
grandes quantidades de dados via e-mail, o que nem sempre é possível por limitações 
do serviço.
 1 O serviço de SFTP é o mais adequado para prover transferência de arquivos com 
tamanho da ordem de megabytes ou gigabytes.
E-mail
q 1 O servidor de e-mail é o responsável por receber todas as mensagens destinadas aos 
usuários da rede local, bem como transmitir para os servidores de e-mail remotos 
todas asmensagens de e-mail desses mesmos usuários. 
 1 Esse serviço utiliza dois tipos de protocolo: 
 2 Um para a comunicação entre servidores de e-mail. 
 2 Outro para comunicação entre servidor de e-mail e cliente.
 1 Os diferentes servidores se comunicam via protocolo SMTP. 
 1 A comunicação entre os softwares clientes e seus servidores pode se dar via proto-
colos IMAP ou POP3 para a recepção de mensagens.
 1 Para o envio de mensagens é usado também o SMTP. 
Existem outros protocolos menos conhecidos para prover essa interação. Uma das princi-
pais diferenças entre esses protocolos é que o Post Office Protocol version 3 (POP3) é usado 
em situações onde se espera que um único cliente precise se conectar a uma caixa postal. 
O Internet Message Access Protocol (IMAP) permite que vários clientes possam se conectar 
à mesma caixa postal. O IMAP é adequado para situações onde uma caixa postal é utilizada 
por mais de um usuário.
72
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Remetente
Servidor de Correio remetente
SMTP
POP3 
ou IMAP
Destinatário
Servidor de Correio destinatário
SMTP
q 1 Muitas instituições não possuem mão de obra adequada para administrar um 
servidor de e-mail. 
 1 Nesses casos pode-se fazer uso de um serviço de e-mail comercial, administrado por 
uma entidade externa. 
 1 Nesse caso cabe à instituição cuidar apenas da comunicação entre os softwares 
clientes de e-mail e esses servidores externos (usando SMTP e POP3 ou IMAP).
 1 Quando o serviço de e-mail fica hospedado em um ambiente externo, a sua disponibi-
lidade e qualidade ficam a cargo de terceiros.
Servidor de correio externo
POP3 ou IMAP
SMTP
Rede local
Internet Servidor de correio destinatário
SMTP
Remetente Destinatário
Repositório de arquivos
q 1 Esse serviço é provido através dos ditos “HDs virtuais”, serviço largamente oferecido 
na internet de graça. 
 1 Sua utilidade é grande, pois permite a usuários da instituição compartilhar arquivos e 
documentos com qualquer usuário da internet ou com usuários da própria instituição 
que estejam trabalhando remotamente. 
Figura 5.4 
Serviço de e-mail: 
servidores e 
clientes de e-mail.
Figura 5.5 
Serviço de e-mail 
hospedado 
remotamente.
73
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
q 1 O compartilhamento é feito sem que o usuário remoto necessite de qualquer recurso 
especial, basta uma conexão à internet.
 1 É importante que esse serviço seja usado apenas como repositório e nunca como 
ponto oficial de armazenamento de dados relevantes. 
O motivo é trivial: a disponibilidade de arquivos e documentos importantes da instituição 
não pode ficar sob a dependência de entidades externas.
Firewall, DMZ e NAT
q 1 Esses três recursos são largamente utilizados na borda da rede local. 
 1 Normalmente o firewall é o elemento que protagoniza a implementação da rede 
DMZ e também do NAT, embora o NAT possa ser feito normalmente por um rote-
ador ou switch L3.
Internet
Rede corporativa
Rede DMZ
A figura anterior explicita o uso clássico do firewall. 
q 1 Os serviços hospedados na rede DMZ (zona desmilitarizada) devem estar acessíveis 
a partir da internet. 
 1 Os serviços e hosts da rede corporativa não podem ser acessados por entidades na 
internet. 
 1 Esses objetivos são alcançados através de regras construídas no firewall. 
 1 A operação básica dos firewalls é comparar todos os pacotes que passam pelas suas 
interfaces com regras configuradas manualmente pelo administrador de redes. 
 1 Se o pacote estiver contemplado nas regras de permissão ele receberá serviço. Do 
contrário, será descartado.
 1 Em muitas redes os firewalls também fazem a tarefa de NAT e PAT. 
As figuras seguintes definem a operação de NAT e PAT.
Figura 5.6 
Rede corporativa 
e DMZ: firewall.
74
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
10.0.1.1
10.0.1.2
10.0.1.3
10.0.1.1 200.1.1.1
10.0.1.2 200.1.1.2
10.0.1.3 200.1.1.3
Internet
10.0.1.1
10.0.1.2
10.0.1.3
10.0.1.1:8811 200.1.1.1:8811
10.0.1.2:9112 200.1.1.1:9112
10.0.1.3:8811 200.1.1.1:13532
Internet
q 1 Nos dias atuais, o PAT é muito mais usado que o NAT, porque efetivamente economiza 
o uso de endereços IP, dado que todos os elementos de uma rede são enxergados na 
internet sob um único endereço. 
 2 O efeito prático é que apenas um endereço IP válido é consumido. 
 2 Todos os demais endereços IP são privados e não serão enxergados na internet.
 1 NAT e PAT também podem ser implementados em roteadores, embora alguns 
autores defendam que essa tarefa deve ser realizada no firewall. 
 1 O argumento principal é que os recursos de hardware do roteador devem ser usados 
para a tarefa de rotear, ao passo que a arquitetura do hardware do firewall é conce-
bida de modo a torná-lo adequado a essa tarefa.
 1 O modelo Juniper J2350 fornecido às organizações usuárias suporta NAT e PAT.
Figura 5.7 
Operação do NAT: 
conversão de 
endereços.
Figura 5.8 
Operação do PAT: 
conversão de 
endereço e porta.
75
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
Procedimento de solicitação de bloco IP
q 1 Uma vez qualificada pelo CG-RNP para ser cliente da rede Ipê, a organização usuária 
terá direito a um bloco IP fornecido pela RNP. 
 1 A solicitação desse bloco é feita pelo contato técnico da organização e constitui uma 
das etapas do processo de qualificação da organização usuária. 
 1 O contato técnico ganhará um acesso à extranet da RNP e terá que preencher um ques-
tionário fornecendo várias informações, incluindo o número de hosts endereçáveis de 
sua rede e a perspectiva de crescimento desse número para os próximos anos. 
 2 Nesse mesmo questionário é solicitado um bloco IP.
 1 A solicitação de bloco também pode ocorrer posteriormente ao processo de qualificação.
 1 Depois de algum tempo, caso haja perspectiva de crescimento da rede, a instituição 
poderá solicitar um bloco adicional através de seu contato técnico. 
 2 Nesse caso, o pedido será feito por e-mail. 
 2 Uma mensagem com o número de IPs adicionais necessários e a justificativa do 
pedido deverá ser enviada para registro@rnp.br. 
 2 O solicitante receberá uma resposta automática do sistema de trouble-ticket da 
GO e deverá aguardar um retorno. 
 2 A GO avaliará a justificativa do pedido, que poderá ser atendido integral ou parcial-
mente, ou ser negado. 
Em caso de dúvidas em relação ao procedimento, a instituição poderá ainda entrar em 
contato com o seu PoP, que poderá buscar informações junto à GO, se necessário. A solici-
tação de endereços IPv6 é feita através do mesmo procedimento.
Adequação do tamanho do bloco às necessidades da IFES
q 1 Endereços IPv4 são recursos escassos e devem acabar nos próximos anos. Por isso, 
não só a RNP, mas todos os sistemas autônomos que compõem a internet mundial 
usam certo critério ao alocar os blocos IP.
 1 A instituição não poderá escolher o bloco IP que usará, mas o tamanho do seu bloco. 
 1 Os números IP propriamente ditos serão definidos pela RNP de acordo com a sua 
conveniência.
 1 A solicitação do tamanho do bloco deriva da quantidade de hosts que precisam de 
endereços e da perspectiva de escalabilidade da rede. 
 1 Caso julgue que o tamanho do bloco solicitado pela instituição não é proporcional 
à realidade da infraestrutura dela, a RNP poderá questionar a real necessidade do 
bloco e sugerir um novo bloco. 
DNS reverso 
q 1 O serviço de DNS reverso, como o nome sugere, executa uma tarefa oposta ao DNS 
tradicional, mas de modo similar.1 Em determinadas situações é importante para uma aplicação descobrir um nome a 
partir do endereço IP, e não o contrário. 
 2 Isso é particularmente interessante quando se quer garantir que o hostname 
da máquina que enviou uma mensagem realmente possui o endereço IP que se 
encontra no pacote da mensagem.
76
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 O serviço de DNS tradicional utiliza os registros do tipo A (address). O DNS reverso 
funciona através de consultas aos registros PTR dos servidores de DNS.
 1 Uma das aplicações mais latentes do DNS reverso atualmente está ligada ao serviço 
de e-mail. 
 2 Ao enviar um e-mail, o software cliente tem total liberdade para editar os campos 
do remetente, data, hora e destinatário da mensagem. 
 2 Esses dados não são questionados pelo protocolo que fará a transmissão do 
e-mail, o SMTP. 
 2 Dessa forma, nada impede que um software malicioso envie um e-mail preen-
chendo o campo do remetente com um valor falso.
 1 É comum para qualquer usuário da internet receber e-mails aparentemente remetidos por 
seus amigos com mensagens de anúncios comerciais, um tipo de spam mais elaborado.
 1 O problema do spam se tornou tão maciço que praticamente todos os servidores de 
e-mail importantes, ao receberem um e-mail, fazem a consulta de reverso para averi-
guar se o endereço IP do remetente coincide com a informação contida no serviço de 
DNS reverso.
 1 O exemplo a seguir ilustra a utilidade do DNS reverso para o serviço de e-mail:
 2 O servidor de e-mail do domínio “rnp.br” recebeu um e-mail de luizinho@cartoons.
com para huguinho@rnp.br. 
 2 Antes de repassar o e-mail para o usuário Huguinho, o servidor de e-mail pergunta 
ao DNS o hostname do servidor de e-mail cujo IP é 200.1.1.1 (IP origem que chegou 
na mensagem de e-mail).
 1 O DNS começa uma busca recursiva até chegar ao servidor DNS, que responde por 
consultas de reverso para o range 200.1.1.0/24. 
 1 Esse servidor responderá que o hostname procurado é “mail.cartoons.com”. Com 
isso, a autenticidade da mensagem é reconhecida.
 1 Se o administrador do domínio “cartoons.com” não tivesse configurado o DNS 
reverso corretamente a procura falharia e o servidor em “rnp.br” teria dúvidas sobre 
a real identidade do remetente. 
 1 Dependendo da configuração do servidor destino, a mensagem poderá ser entregue, 
descartada ou movida para uma pasta de spam.
 1 O resultado prático é que se o DNS reverso de uma instituição não está registrado corre-
tamente, vários e-mails enviados por usuários daquela instituição não serão entregues.
 2 A entrega dependerá da configuração do servidor do domínio destino.
A configuração de DNS reverso é similar ao DNS tradicional. A instituição deve informar ao 
seu provedor (RNP) quais são os servidores autoritativos que respondem pelo serviço de 
DNS reverso para seus IPs. A RNP difundirá a informação para os root servers da internet. 
Dessa forma, toda vez que um servidor DNS qualquer da internet receber uma consulta 
de DNS reverso para um IP da instituição, a consulta será direcionada para o servidor DNS 
registrado, que poderá responder à consulta.
Procedimento para cadastro de reverso
q 1 O cliente da RNP precisará configurar entre 2 e 5 servidores autoritativos para 
responder pelo seu domínio. 
77
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
q 1 Em seguida, deverá enviar um e-mail para registro@rnp.br informando os hostnames 
dos servidores e a faixa de IP pelas quais eles respondem.
 1 Dúvidas sobre a configuração do servidor DNS propriamente dito poderão ser escla-
recidas junto ao PoP da RNP. 
 1 A configuração do DNS reverso no servidor da instituição não é atribuição do PoP, 
mas da instituição.
Gerenciamento da rede da instituição
q 1 A gerência da rede é uma das tarefas mais importantes do dia a dia da administração 
de redes. 
 1 Essa atividade permite ao administrador conhecer o nível de utilização dos recursos 
e serviços da rede, de modo que quando ocorrem variações dos níveis considerados 
cotidianos a equipe técnica terá condições de perceber a mudança mais rapidamente. 
 1 Ocorre assim menor tempo de reação a problemas ou a potenciais problemas.
 1 Alguns recursos tipicamente monitorados são: 
 2 Utilização de CPU e memória de servidores, roteadores e switches.
 2 Conectividade IP de servidores, roteadores e switches.
 2 Processos específicos de servidores.
 2 Utilização do enlace de dados do roteador de borda.
 2 Status de componentes de hardware de servidores, roteadores e switches, como 
fontes, ventiladores e processador.
 1 O PoP da RNP executa a monitoração do enlace de dados que conecta a organização 
usuária à rede Ipê. 
 1 Grande parte dos PoPs já disponibiliza essa informação on-line em seu website.
 1 A gerência dos recursos e serviços nas redes locais da instituição não é atribuição da 
RNP nem de seus PoPs.
Serviços que devem ser gerenciados
q 1 Todo serviço que agregue valor à atividade da instituição ou que suporte suas ativi-
dades é candidato potencial a ser gerenciado. 
 1 Isso inclui os serviços de e-mail, DNS, portais web, SAP e outras plataformas de serviço. 
 1 A atividade de gerência de rede pode abranger a monitoração de componentes 
de hardware e/ou software que sejam fundamentais à disponibilidade dos 
serviços gerenciados.
Documentação
q 1 A documentação da rede é um dos maiores desafios que acompanham a atividade de 
administração de rede. 
 1 Embora seja uma tarefa simples, raramente existe uma equipe exclusivamente designada 
para esse fim, o que quase sempre provoca a existência de documentação desatualizada.
Estudos mostram que o ambiente de rede bem documentado tem menor tempo de dispo-
nibilidade que ambientes desorganizados. Esse dado é facilmente justificado. Um bom pro-
cesso de documentação é recomendável e contribui para o bom desempenho dos serviços e 
para redução do “downtime”, simplificando troubleshooting e aprovisionamentos.
78
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
De posse da descrição de um problema e da documentação da topologia, do cabeamento e 
das VLANs da rede, pode-se avaliar com facilidade os pontos da rede com maiores chances de 
provocar a falha. Em alguns casos pode-se diagnosticar o problema sem sequer conectar-se a 
um equipamento de rede.
A definição de um bom processo de documentação juntamente com uma ferramenta 
adequada é recomendável para o bom desempenho dos serviços que dependem do bom 
funcionamento da rede de dados de uma instituição.
Ferramentas de monitoramento
q 1 Existem diversas ferramentas projetadas para realizar o gerenciamento de redes. 
 1 Há boas opções de soluções proprietárias bem como competentes ferramentas de 
software livre. 
 1 As ferramentas proprietárias têm a desvantagem de serem caras. 
 1 O software livre é grátis e em muitos casos pode oferecer serviços tão adequados às 
necessidades da instituição quanto as soluções de mercado. 
No entanto, o bom desempenho das ferramentas livres depende fortemente da dedicação 
de mão de obra técnica para customizá-las para as necessidades da instituição, o que requer 
tempo e dedicação. Feito isso seu desempenho será satisfatório.
A seguir serão apresentadas algumas ferramentas de gerência implementadas em software livre.
qCacti
 1 Ferramenta totalmente gráfica baseada em consultas SNMP. 
 1 Praticamente qualquer recurso de rede compatível com o protocolo SNMP (popular 
no mercado de tecnologia) pode ter um gráfico plotado. 
 1 Inclui interfaces de rede, utilização de CPU, memória, área de swap de servidores etc. 
 1 Os gráficos são armazenados em base de dados do tipo RRD.
 
Figura 5.9 
Cacti.79
 
C
ap
ítu
lo
 5
 - 
Se
rv
iç
os
 e
 g
er
en
ci
am
en
to
 d
a 
re
de
 d
a 
in
st
itu
iç
ão
qMRTG
 1 Ferramenta totalmente gráfica com a mesma proposta do Cacti, mas possui menos 
recursos. 
 1 Também utiliza o protocolo SNMP como principal recurso.
qNFSen
 1 Ferramenta gráfica que recebe e processa mensagens de “flow” dos equipamentos 
de rede. 
 1 Permite traçar o gráfico de utilização de interfaces de rede com um diferencial: 
discernir as aplicações que estão usando os recursos. 
 1 As ferramentas baseadas em SNMP permitem definir, por exemplo, que uma inter-
face de determinado roteador tem uso de 8Mbps em um determinado horário. 
 1 Já as ferramentas baseadas em flow, como o NFSen, permitem saber adicionalmente 
que desse total: 
 2 1Mbps vem do servidor de e-mail, 2Mbps são de aplicações de backup e 5Mbps 
de tráfego de internet.
Figura 5.10 
MRTG.
Figura 5.11 
NFSen.
80
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Muitas outras ferramentas estão disponíveis. As equipes da GO e dos PoPs utilizam diversas 
ferramentas de gerência para administrar a rede Ipê. A experiência dessas equipes com as 
ferramentas de gerência utilizadas é compartilhada em eventos periódicos, como o WRNP. 
Os clientes da RNP são motivados a participar dos minicursos disponíveis nesse evento. 
O WRNP tem ainda outras propostas. 
Para mais informações 
sobre o evento: http://
www.rnp.br/wrnp/
l
81
 
C
ap
ítu
lo
 6
 - 
In
st
al
aç
ão
 d
o 
ro
te
ad
or
 d
a 
RN
P 
ob
je
tiv
os
conceitos
6
Instalação do roteador da RNP
Descrever os requisitos de instalação física do roteador Juniper.
 
Componentes básicos dos roteadores J2350 e J2320. 
 
Requisitos de instalação do roteador
q 1 A organização usuária cliente da RNP receberá em suas dependências um roteador 
da RNP. 
 2 Esse equipamento será um modelo Juniper 2350. 
 2 Ele fará a interface entre a rede da instituição e a rede de acesso do PoP RNP.
 1 Cada plataforma Juniper possui um guia de hardware que provê as instruções deta-
lhadas de instalação. 
Esse capítulo comentará detalhes do planejamento de instalação da plataforma da série J. 
O detalhamento de cada tarefa que compõe o procedimento de instalação pode ser verifi-
cado no documento “J Series Services Routers Hardware Guide”.
Requisitos físicos
q 1 O roteador da série J é preparado para ser instalado em um rack. 
 1 Para abrigar o equipamento, um rack deve atender aos requisitos:
 2 Rack de 19 polegadas, como definido pelo documento EIA-310-D, publicado pela 
European Telecommunications Standards (ETSI). 
 1 Racks populares do mercado contemplam esse padrão.
O espaço horizontal entre os suportes de um rack que satisfaz um dos padrões citados é 
normalmente um pouco maior que o espaço entre as presilhas de montagem do roteador, 
que mede 19 polegadas (48,2 cm).
Caso o espaço entre os suportes do rack seja configurável, deverá ser arranjado de modo a 
acomodar as dimensões externas do chassi. Além disso, deve-se verificar se a especificação 
do rack permite que o peso do roteador seja adicionado à carga total existente.
qO modelo J2320 possui as seguintes dimensões: 
 1 4,45 cm de altura, 38,35 cm de comprimento e 44,48 cm de largura. 
82
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 O equipamento consome 1 RU do rack.
 1 Seu peso varia de 6,8 a 7,6 Kg, dependendo da quantidade de placas instaladas.
O modelo J2350 possui as seguintes dimensões: 
 1 6,63 cm de altura, 38,35 cm de comprimento e 44,48 cm de largura. 
 1 O equipamento consome 1,5 RU do rack.
 1 Seu peso varia de 7,4 a 8,3 Kg, dependendo da quantidade de placas instaladas.
Em racks com múltiplos equipamentos deve-se certificar que os mais pesados estão na 
parte de baixo. Caso o rack tenha apenas um único equipamento (o roteador RNP) é reco-
mendado colocá-lo na parte inferior.
Requisitos de ventilação
qO sistema de cooling dos roteadores J2350/J2320 funciona gerando o fluxo de ar de uma 
lateral do equipamento (no lado esquerdo) até a outra (no lado direito). 
Assim, para que o sistema de cooling funcione adequadamente, é necessário que os lados 
do equipamento tenham um espaço livre. Dessa forma, é recomendado que as paredes 
laterais do rack sejam vazadas. Além disso, recomenda-se que essas laterais tenham um 
espaço livre de pelo menos 15 cm. O roteador tem cinco ventiladores que enviam ar do 
lado esquerdo do roteador para o direito. Esse fluxo de ar mantém o equipamento em 
temperatura adequada. 
q 1 A velocidade dos ventiladores é ajustada automaticamente dependendo da 
temperatura corrente. 
 1 As entradas de ar que abastecem os ventiladores devem ser limpas periodicamente. 
 1 A poeira reduz a capacidade de ventilação do sistema de cooling.
Requisitos de ambiente
A tabela seguinte exibe as condições de ambiente consideradas ótimas para a operação 
normal do roteador Juniper.
Descrição Valor
Umidade relativa 5% a 90% sem condensação
Temperatura 0% a 40%
Consumo de calor J2350 – 1195 BTU/h (350 W)
Consumo de calor J2320 – 1091 BTU/h (320 W)
Requisitos elétricos e planejamento de força
O modelo J2320 é compatível com potência AC. Da série J, apenas os modelos J2350, 
J4350 e J6350 estão disponíveis em DC. A tabela a seguir ilustra as especificações elétricas 
do equipamento.
Figura 6.1 
Roteador J2350: 
ventilação lateral 
(Fonte: http:www.
juniper.net)
Tabela 6.1 
Requisitos de 
ambiente.
83
 
C
ap
ítu
lo
 6
 - 
In
st
al
aç
ão
 d
o 
ro
te
ad
or
 d
a 
RN
P 
Descrição Valor
Voltagem AC 100 –240 V
Frequência AC 50 a 60 Hz
Corrente AC J2350 – 3,5 A a 1,5 A
Corrente AC J2320 – 3,2 A a 1,3 A
Os cabos de força apropriados são disponibilizados junto com o equipamento. O conector 
fêmea do cabo deve ser conectado à tomada macho do roteador, que levará a energia até a 
fonte AC. O plug macho disponível no cabo, o qual se ligará à fonte de energia do prédio, 
será compatível com a localização geográfica do usuário.
É importante que o ambiente seja pensado de tal forma que o cabo de força não atravesse o 
mesmo caminho que será usado pelas pessoas.
q 1 Antes de adicionar novas PIMs (Physical Interface Module) ao chassi, é preciso veri-
ficar se a combinação de PIMs e módulos não excederá a capacidade de força e calor 
do equipamento.
 1 Se a funcionalidade de “J Series Power Management” estiver habilitada, PIMs e 
módulos que excederem a capacidade de força e de calor permanecerão desligadas 
quando o chassi for ligado.
Manuseio de placas
Placas da Juniper (PIMs ou outras) são dispositivos caros e sensíveis. A seguir exemplos de 
como NÃO se deve fazer o translado de uma placa.
As placas deverão ser transportadas com as duas mãos apoiando a parte inferior do hardware.
Tabela 6.2 
Especificações 
elétricas.
Figura 6.2 
Como NÃO 
transportar 
uma placa.
84
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Descarga eletrostática
q 1 Placas que são retiradas do equipamento contêm partes sensíveis à descarga 
eletrostática. 
 1 Placas PIMs (ou outras) podem sofrer danos sob voltagens da ordem de 30 V. 
 1 Uma pessoa pode facilmente gerar uma energia estática dessa magnitude quando 
manuseia um material plástico ou uma embalagem de espuma, por exemplo. 
 1 Para evitar prejuízos desnecessários, deve-se observar as precauções contra 
descarga eletrostática:
 2 Sempre use uma pulseira (ou tira) eletrostática ao manusear placas do roteador.
 2 Certifique-se de que a pele está em contato com a pulseira. 
 1 Se possível, verifique periodicamente a resistência do material usado. Essevalor deve 
sempre estar entre 1 e 10 mega ohms.
 1 Ao manusear um componente do hardware, certifique-se de que o fio da pulseira eletros-
tática está em contato com um dos pontos de descarga eletrostática do chassi.
 1 Evite o contato do hardware com a sua roupa. Ela também pode emitir voltagem sufi-
ciente para danificar o equipamento.
 1 Ao remover um componente do hardware do roteador, sempre o coloque em um local de 
modo que os componentes eletrônicos fiquem em contato com uma superfície eletrostática.
Aterramento
É recomendável que a infraestrutura física que abrigará o roteador da RNP possua recursos 
para dissipação de energia, tal qual uma malha de terra.
Para proteger o equipamento de descargas, deve-se aterrá-lo antes de ligar. O equipamento 
traz na sua parte traseira um pino próprio para a conexão do aterramento. Além do pino terra, 
uma rosca, um parafuso e uma arruela são fornecidos para acoplar o fio de terra ao roteador. 
Figura 6.3 
Como transportar 
uma placa.
85
 
C
ap
ítu
lo
 6
 - 
In
st
al
aç
ão
 d
o 
ro
te
ad
or
 d
a 
RN
P 
Terminal de aterramento 
Ponto de aterramento 
de proteção em chassis
Parafuso com
arruela prisioneira
Componentes básicos do roteador J2350
POWER LED
STATUS LED
ALARM LED
HA LED Power 
button
RESET
CONFIG
button
Console
port
Auxiliary 
port
LAN
ports
USB ports
Phisical Interface
Module (PIM) PIN blanks
ESD 
point
CONFIG
LED
O roteador J2350 é um equipamento da série J. O hardware tem as seguintes características 
principais:
q 1 Ocupa 1,5 RU de rack.
 1 512 MB de DRAM (expansível até 1GB).
 1 512 MB de compact flash disc (expansível até 1GB).
 1 400 Mbps de vazão.
O roteador possui: 
 1 Duas portas USB, que permitem que um drive USB seja usado como unidade de armaze-
namento secundária;
 1 4 portas Ethernet 10/100/1000 Mbps fixas;
 1 5 Slots para PIMs (há grande variedade de PIMs disponíveis).
Figura 6.4 
Aterramento.
Figura 6.5 
Juniper J2350.
86
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Componentes básicos do roteador J2320
POWER LED
STATUS LED
ALARM LED
HA LED Power 
button
RESET
CONFIG
button
Console
port
Auxiliary 
port
LAN
ports
USB ports
Phisical Interface
Module (PIM) PIN blanks
ESD 
point
CONFIG
LED
O roteador J2320 é o equipamento de entrada da série J. O hardware tem as seguintes 
características principais:
q 1 Ocupa 1 RU de rack.
 1 256 MB de DRAM (expansível até 1GB).
 1 256 MB de compact flash disc (expansível até 1GB).
 1 Possui uma porta USB, que permite que um drive USB seja usado como unidade de 
armazenamento secundária.
 1 400 Mbps de vazão.
 1 4 portas Ethernet 10/100/1000 Mbps fixas.
 1 3 slots para PIMs (há grande variedade de PIMs disponíveis).
Os demais componentes da série J2300 são descritos a seguir:
 1 Ponto ESD (eletrostatic discharge): usado para conectar uma pulseira eletrostática;
 1 LED Alarm: se aceso, indica que há um alarme ativo. Pode ser um alarme crítico, majori-
tário ou minoritário. Para mais detalhes será necessário se conectar ao sistema;
 1 LED Power: se aceso, indica que o equipamento está ligado;
 1 Botão Power: se pressionado e solto em seguida, ligará o roteador. Com o equipamento 
ligado, se o botão é pressionado e solto rapidamente, provoca o processo de desli-
gamento “educado” (não abrupto). Se o botão é pressionado por mais de 5 segundos 
provoca o desligamento imediato do roteador.
 1 Botão Reset Config: se pressionado e solto em seguida provoca o carregamento e o 
“commit” da “rescue configuration”. Se pressionado durante 15 segundos provoca a 
deleção de todas as configurações, carrega a configuração de fábrica e faz “commit” dela;
 1 LED Configuration: pisca verde durante o carregamento da “rescue configuration” ou da 
configuração de fábrica. Pisca vermelho enquanto as configurações estão sendo dele-
tadas e a configuração de fábrica está sendo carregada;
 1 Porta Console: a porta provê um terminal (RS-232) com um conector RJ-45. É usada para 
acessar a CLI do roteador;
Figura 6.6 
Juniper J2320.
87
 
C
ap
ítu
lo
 6
 - 
In
st
al
aç
ão
 d
o 
ro
te
ad
or
 d
a 
RN
P 
 1 Porta Auxiliar: a porta provê um terminal (RS-232) remoto com um conector RJ-45. 
É usada para acessar a CLI do roteador remotamente;
 1 Portas USB: aceitam a conexão de um drive USB que será usado como um meio de arma-
zenamento;
 1 Portas LAN: recebem conexões de rede do padrão 10/100/1000 Base-TX Gigabit Ethernet;
 1 Terminal de aterramento: é o ponto de contato definido para conexão do fio de terra;
 1 Drive Compact Flash Externo: provê um meio de armazenamento secundário para 
arquivos de log, de configuração e imagens de sistema operacional;
 1 Tomada de força: é o ponto de conexão do cabo de força AC que alimentará o equipamento;
 1 Ventiladores (fans) da fonte: proveem resfriamento automático da fonte de alimentação.
88
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
89
 
C
ap
ítu
lo
 7
 - 
Fu
nd
am
en
to
s 
de
 Ju
no
s 
 
ob
je
tiv
os
conceitos
7
Fundamentos de Junos 
Descrever as características básicas do sistema operacional Junos.
 
Características do Junos, plano de controle, plano de encaminhamento e 
processamento de tráfego.
 
 
Software modular
q 1 O sistema operacional da Juniper é o Junos. 
 1 Foi desenvolvido a partir do código aberto do Free BSD e tornou-se uma referência no 
mercado de redes por sua estabilidade e modularidade. 
 1 Alguns grandes fabricantes do mercado estão partindo para a mesma proposta, de 
customizar software livre de modo a adequá-lo às necessidades de seus equipamentos.
 1 As funcionalidades do Junos são alocadas em múltiplos processos de software. 
 2 Cada processo possui uma função específica e roda em seu próprio espaço (prote-
gido) de memória, garantindo que um processo não sofra com falta de recursos e 
não interfira nos recursos de outros. 
 1 A modularidade ajuda a manter problemas isolados. 
 1 Quando um processo falha, o sistema como um todo continua funcionando, perde-se 
apenas a funcionalidade pela qual o processo é responsável.
 1 A arquitetura do Junos também favorece a inserção de novas funcionalidades. 
 1 Em outros sistemas é comum trocar-se toda a imagem do sistema operacional para 
adicionar novas funcionalidades. 
 1 No Junos essa operação é mais simples e consequentemente traz menos riscos de falha. 
Ao adicionar novas funcionalidades no Junos, não se corre o risco de perder outras.
90
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Todas as plataformas que utilizam o Junos usam o mesmo código-fonte em imagens 
específicas. 
 1 Esse design garante que as funcionalidades do software funcionam de maneira 
similar em todas as plataformas que utilizam o Junos OS. 
 1 Esse fator faz com que a configuração e a operação das diferentes plataformas fun-
cionem exatamente da mesma maneira.
Separação entre planos de Controle e de Encaminhamento
q 1 Toda plataforma Juniper tem a mesma filosofia de trabalho: manter uma separação 
bem definida entre as tarefas de controle e de encaminhamento. 
 1 Dessa forma, as plataformas definem uma entidade específica para cada uma dessas 
funções: o plano de controle e o plano de encaminhamento.
RT FT JUNOS
Software
FT
Internal linkControl Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
Frames/
Packets in
Frames/
Packets out
O esquema mostrado na figura exibe a separação mantida entre o plano de controle 
(Control Plane) e o plano de encaminhamento (Forwarding Plane). 
Os processos responsáveis pelo encaminhamento dos pacotesficam totalmente separados 
dos demais, que cuidam dos protocolos de roteamento e tarefas administrativas da caixa. Esse 
design permite ao usuário do equipamento ajustar cada processo conforme sua necessidade.
q 1 O plano de controle é executado pela Routing Engine (RE), enquanto o plano de enca-
minhamento é implementado pela Packet Forwarding Engine (PFE).
 1 A RE se comunica com a PFE através de um canal de comunicação interno exclusivo 
para esse fim. Através desse canal a PFE recebe a Forwarding Table (FT) atualizada. 
Figura 7.1 
Modularidade 
Juniper.
Figura 7.2 
Separação 
entre planos de 
Controle e de 
Encaminhamento.
91
 
C
ap
ítu
lo
 7
 - 
Fu
nd
am
en
to
s 
de
 Ju
no
s 
 
q 1 As mensagens de atualização da FT têm alta prioridade do kernel do Junos.
 1 Enquanto a RE provê a inteligência do sistema, a PFE pode simplesmente executar o 
encaminhamento dos pacotes com alto grau de confiabilidade e performance.
Embora todas as plataformas Juniper utilizem o mesmo conceito de separação entre con-
trole e encaminhamento, a implementação dos componentes que definem a RE e a PFE varia 
de modelo para modelo. Nos equipamentos das séries M e T (mais robustos), a RE e a PFE 
compreendem diferentes hardwares. A PFE é executada em circuitos integrados exclusivos 
(ASICs) enquanto a RE é implementada por um processador.
Nos equipamentos da série J a PFE é implementada em software e conta com recursos 
exclusivos de memória e ciclos de CPU, fazendo com que a PFE tenha o mesmo grau de esta-
bilidade dos modelos maiores. A RE ainda é implementada em um processador. Além disso, 
processadores de rede em cada interface física (PIM) executam serviços de rede específicos, 
de forma a economizar recursos do hardware da RE principal da caixa.
Routine Engine (RE)
qA RE é o cérebro da plataforma, responsável por: 
 1 Gerenciar o sistema. 
 1 Processar e propagar anúncios dos protocolos de roteamento. 
 1 Manter a tabela de rotas (routing table). 
 1 Calcular e manter a tabela de encaminhamento (forwarding table). 
 1 Atualizar as informações de encaminhamento junto à PFE.
RT FT JUNOS
Software
Control Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
A RE também executa os processos de todos os protocolos executados na caixa, bem como 
todos os demais softwares que controlam as interfaces de rede, os componentes do chassi e 
a supervisão do sistema. Esses softwares são executados pelo kernel do Junos, que interage 
com a PFE.
q 1 A RE provê a interface de linha comando (Command Line Interface – CLI) e a interface 
J-Web GUI, através das quais o usuário acessa e controla o roteador.
 1 Por fim, a RE controla as ações da PFE através de informações de encaminhamento 
atualizadas que são passadas àquela entidade. 
 1 Os processos que residem no microcódigo da PFE também são gerenciados pela RE. 
 1 A PFE envia mensagens de status para a RE, que agirá caso alguma mensagem 
reporte uma situação inadequada.
Figura 7.3 
Routing engine.
92
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Packet Forwarding Engine
q 1 A PFE é o componente central do plano de encaminhamento. 
 1 Sua função é despachar os pacotes recebidos com a maior velocidade possível. 
 1 Essa tarefa é baseada na informação de uma FT local da PFE.
 1 A manutenção dessa tabela local evita que a PFE tenha que consultar as tabelas da RE 
para tomar a decisão de encaminhamento de cada pacote. 
 1 Esse design permite que o encaminhamento de pacotes continue funcionando em 
cenários de falha do plano de controle.
FT
Control Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
Frames/
Packets in
Frames/
Packets out
A FT local da PFE é sincronizada com as informações de encaminhamento providas pela RE. 
Além de encaminhar pacotes, a PFE também executa outros serviços avançados como: limi-
tador de tráfego (Policer), filtros de firewall e CoS (Class of Service). Outros serviços podem 
ser oferecidos através de cartões de serviço específicos que podem ser adicionados à caixa, 
como geração de flows.
Processamento de tráfego
Tráfego de trânsito
q 1 Consiste em todo tráfego que entra por uma interface de rede física, tem parâ-
metros comparados com a tabela de encaminhamento e deixa o chassi por uma 
interface de saída.
 1 Para que o encaminhamento do pacote seja feito com sucesso, precisa haver uma 
entrada na FT da PFE. 
 1 O tráfego de trânsito passa somente pelo plano de encaminhamento e nunca é 
processado pela RE diretamente, ou seja, o plano de controle não tratará os pacotes 
referentes ao tráfego de trânsito.
 1 Mantendo o processamento do tráfego de trânsito confinado ao plano de encaminha-
mento, as plataformas que executam o Junos conseguem otimizar seus recursos de 
hardware para as tarefas específicas de controle e de processamento de tráfego.
 1 Tráfegos unicast e multicast são ambos classificados como tráfego de trânsito, sendo 
processados pela PFE e não pela RE. 
Figura 7.4 
Forwarding Engine.
93
 
C
ap
ítu
lo
 7
 - 
Fu
nd
am
en
to
s 
de
 Ju
no
s 
 
CPU
FT
Control Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
Frames/
Packets in
Frames/
Packets out
O tráfego unicast chegará ao roteador por uma interface de entrada e sairá por apenas 
uma interface de saída. O tráfego multicast entrará por uma interface de entrada e poderá 
sair por várias interfaces de saída, dependendo do número e da localização dos receptores 
multicast presentes na rede.
Tráfego de exceção
O outro tipo de tráfego processado pelo roteador é o tráfego de exceção. Diferente do 
tráfego de trânsito, tratado mecanicamente pela PFE, o tráfego de exceção requer alguma 
forma de processamento especial. Alguns exemplos de tráfego de exceção:
q 1 Pacotes endereçados ao próprio chassi, como atualizações de protocolos de rotea-
mento, sessões telnet, pings, traceroutes e respostas a sessões iniciadas pela RE.
 1 Pacotes IP com o campo “IP options” preenchidos (raramente esse tipo de pacote é 
gerado e a PFE não foi desenvolvida para tratar esse caso). 
 2 Pacotes com o campo “IP options” marcado precisam ser enviados para apreciação 
da RE. 
 2 Um exemplo de aplicação que utiliza o campo “IP options” é o acelerador de tráfego.
 1 Tráfego que requer a geração de mensagens ICMP.
Mensagens ICMP são criadas para enviar ao originador de um tráfego alguma condição de 
erro ou para responder mensagens de ping. Um exemplo de erro ICMP é a mensagem 
“Destination unreachable”, gerada quando não há uma entrada na FT que atenda ao serviço 
do pacote ou quando o parâmetro TTL tenha expirado.
Figura 7.5 
Tráfego de trânsito.
94
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
CPU
?
Control Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
Frames / Packets out
Frames / Packets in
q 1 Todo tráfego de exceção é remetido à RE através de um link interno que conecta os 
planos de controle e de encaminhamento. 
 1 O Junos limita a quantidade de tráfego de exceção nesse link interno para proteger a 
RE de ataques de DoS (Denial of Service). 
Durante congestionamentos, Junos dá preferência ao tráfego local de controle, que desem-
penha as tarefas fundamentais para o bom funcionamento do roteador. 
Built-in Rate Limiting
Control Plane
Packet Forwarding Engine
Forwarding Plane
Routing Engine
Frames/
Packets in
CPU
Por segurança, o limitador de tráfego do link interno não é configurável.
Figura 7.6 
Tráfego de exceção
Figura 7.7 
Limitador de 
tráfego no link 
interno.
95
 
C
ap
ítu
lo
 8
 - 
O
pç
õe
s 
de
 a
ce
ss
o 
ao
 Juno
s 
ob
je
tiv
os
conceitos
8
Opções de acesso ao Junos
Descrever as interfaces do usuário, os diversos modos de configuração, os procedimentos 
de gravação e restauração das configurações.
 
Acesso do usuário, CLI do Junos, modos de acesso, Ajuda, Help Topic, Help Reference, 
completando comandos, teclas de edição EMACS, caractere pipe, modos de operação 
e configuração, interface J-Web GUI.
 
A interface de usuário
q 1 O Junos oferece duas formas de acesso de usuário: linha de comando ou interface 
J-Web (http).
 1 A interface de linha de comando do Junos (CLI – Command Line Interface) pode ser 
acessada de duas maneiras. 
 2 A primeira é via porta console out of band (OoB). 
 3 Para tal acesso deve-se utilizar um cabo console para conectar a porta console 
do roteador a um notebook (ou mesmo um PC). 
 3 Esse notebook deverá ter instalado um programa emulador de terminal 
(exemplo: “Tera Term”).
 2 A outra forma de acesso à interface de linha de comando é via interface de rede 
(in band), utilizando um protocolo de acesso como telnet ou SSH. 
Diferentemente do acesso via console, para acessar a caixa via protocolo de acesso é neces-
sário executar uma configuração prévia em alguma interface de rede (a interface precisa ter 
IP configurado, por exemplo).
Muitas plataformas da Juniper oferecem ainda uma porta ethernet dedicada apenas para 
gerência. Essa interface, a exemplo da porta console, também oferece acesso “out of band”. 
Essa porta não oferece serviço ao tráfego de trânsito, e não existe no equipamento J2320.
q 1 O acesso do usuário ao sistema também se dá via uma interface web que vem habili-
tada de fábrica. A Juniper chama essa interface de J-Web.
 1 J-Web é uma interface gráfica (GUI) que um usuário pode acessar utilizando protocolo 
http (Hypertext Transfer Protocol) ou https (http over Secure Sockets Layer). 
Web browsers populares como o Windows Internet Explorer ou o Mozilla Firefox são 
capazes de prover esse acesso.
96
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Essa interface web permite que o usuário configure parâmetros mais comuns do roteador 
através de janelas do tipo wizard. Para configurações mais elaboradas, a J-Web permite 
edição direta do arquivo de configuração da caixa, que é um arquivo texto.
A CLI do Junos
Fazendo login
q 1 O primeiro passo para acessar a interface CLI é fazer o processo de login.
 1 O Junos requer “username” e “password” para prover acesso ao sistema. 
 1 O administrador do sistema cria contas de usuários e as associa a um “perfil de acesso”. 
 1 Toda plataforma Junos possui a conta do usuário root configurada de fábrica, sem 
senha. 
 1 É recomendado que a senha seja configurada logo no primeiro acesso.
Ao se conectar ao equipamento, o usuário recebe um prompt que mostra o nome do 
usuário e “hostname” do roteador (caso haja um configurado). 
Processo de login:
qhost (ttyu0)
 1 login: user
 1 Password: 
--- JUNOS 9.5R1.8 built 2009-04-13 20:03:09 UTC 
 1 user@host>
 2 O usuário root tem acesso completo a todas as funções do roteador. 
 1 Quando se faz o login utilizando o usuário root, tem-se acesso a um shell de Unix. 
 2 Para iniciar a CLI do Junos utiliza-se o comando “cli”. 
 2 Para terminar a sessão usa-se o comando “exit”.
 1 Todos os demais usuários (não root) ao se conectarem no sistema já recebem a CLI do 
Junos, sem necessidade do comando “cli”.
 1 Para que um usuário não root tenha acesso a um shell, deve-se digitar o comando: 
# start shell
Modos de acesso
qA CLI do Junos permite duas modalidades de acesso: 
 1 Modo de operação:
 2 A CLI é usada basicamente para monitoração e troubleshooting do roteador. 
 2 Comandos típicos disponíveis nesse modo: “show”, “monitor”, “ping” e “traceroute”. 
 3 Esses comandos permitem exibir informações do sistema e executar testes, 
mas não permitem alterar a configuração da caixa.
 1 Modo de configuração: 
 2 O usuário pode configurar todos os parâmetros do sistema incluindo interfaces, 
protocolos, nível de acesso de contas de usuário e propriedades do hardware.
97
 
C
ap
ítu
lo
 8
 - 
O
pç
õe
s 
de
 a
ce
ss
o 
ao
 Ju
no
s 
Ajuda
q 1 A CLI do Junos provê acesso a um minimanual (help) em qualquer ponto da linha de 
comando. 
 1 O “help” informa as opções disponíveis no ponto do comando onde a ajuda foi solici-
tada, fornecendo uma breve explicação de cada opção.
 1 A ajuda pode ser invocada através do comando “?”. 
 1 Não é necessário confirmar o comando com “enter”; basta simplesmente digitar “?”. 
Quando o ponto de interrogação é digitado na linha de comando, o Junos lista todos os 
comandos e/ou opções disponíveis.
Invocando ajuda:
user@host> ? 
Possible completions: 
 clear Clear information in the system
 configure Manipulate software configuration information
 file Perform file operations
 help Provide help information 
user@host> clear ? 
Possible completions: 
 arp Clear address resolution information
 bfd Clear Bidirectional Forwarding Detection information
 bgp Clear Border Gateway Protocol information
 dhcp Clear DHCP information 
No exemplo acima, na parte superior, o usuário solicitou ajuda na CLI em branco. O Junos 
então listou todos os comandos disponíveis. Na parte inferior, o usuário solicitou ajuda 
após digitar o comando “clear”. A CLI informou todas as opções que podem ser usadas para 
completar esse comando.
Se o ponto de interrogação é digitado no meio da string de um comando, o Junos mostrará 
todas as opções disponíveis que começam com a string em questão. Por exemplo, se no 
exemplo acima o usuário tivesse digitado “clear a?”, o sistema teria mostrado todas as 
opções do comando “clear” que começam com a letra “a”.
Help Topic
qO comando “help topic” fornece um manual mais completo sobre um determinado 
tópico do sistema. 
No exemplo a seguir, o usuário solicitou informações sobre o tópico “interfaces address”. Na 
saída do comando, a CLI explica como aplicar um endereço à interface e as situações em que 
esse procedimento é necessário.
98
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Help topic:
user@host> help topic interfaces ? 
Possible completions: 
 accept-data Accept packets destined for virtual address 
 accept-source-mac Policers for specific source MAC addresses 
 accounting Packet counts for destination and source 
classes
 accounting-profile Accounting profile 
 acknowledge-timer Maximum time to wait for link 
acknowledgment message
 address Interface address and destination prefix 
user@host> help topic interfaces address 
 Configuring the Interface Address
You assign an address to an interface by specifying the address when 
configuring the protocol family. For the inet family, configure the 
interface’s IP address. For the iso family, configure one or more 
addresses for the loopback interface. For the ccc, tcc, mpls, tnp, and 
vpls families, you never configure an address.
Help Reference
qO comando “help reference” apresenta um manual sumarizado, um pouco mais prático e 
menos teórico, sobre um determinado tópico do sistema.
O exemplo seguinte exibe a aplicação do “help reference” sobre o mesmo tópico de sistema 
do exemplo anterior. 
O sistema explica as opções de configuração disponíveis para o tópico e a sintaxe a ser utili-
zada, assemelhando-se ao comando “man” dos sistemas Unix.
user@host> help reference interfaces address
address
 Syntax
 address address {
 arp ip-address (mac | multicast-mac) mac-address 
<publish>;
 broadcast address;
 ...
99
 
C
ap
ítulo
 8
 - 
O
pç
õe
s 
de
 a
ce
ss
o 
ao
 Ju
no
s 
 Hierarchy Level
 [edit interfaces interface-name unit logical-unit-number family 
family],
 [edit logical-routers logical-router-name interfaces interface-
name unit
 logical-unit-number family family]
...
Existem ainda outras variedades de uso do comando “help” menos populares, que poderão 
ser exploradas ao longo da experiência dos alunos junto à plataforma.
Completando comandos
q 1 O Junos permite a utilização de teclas de completamento de comandos para evitar 
que o usuário precise executar um comando completo. 
 1 Utilizando a tecla de espaço, o Junos completa o comando que está sendo digitado, 
simplificando a operação do sistema.
Se a tecla de espaço é usada em um ponto onde existe ambiguidade de comandos disponí-
veis, um beep é gerado pelo sistema e o comando não é completado.
Outra forma de completar o comando é usar a tecla “Tab”. Essa tecla tem basicamente a 
mesma utilidade da tecla de espaço. Se acionada no meio da digitação de um comando o 
“Tab”, completa a string do comando. 
A diferença de uso entre o “Tab” e a tecla de espaço é que quando existe ambiguidade de 
comandos disponíveis, o “Tab” exibe os comandos ambíguos disponíveis.
Teclas de edição EMACS
O Junos permite ao usuário agilizar a tarefa de digitação com o uso de teclas de edição 
EMACS, que permitem mover o cursor em uma linha de comando para adicionar ou remover 
caracteres específicos.
Sequência
do teclado
Posição do cursor
user@host> show interfaces
1Ctrl+b
 user@host> show interfaces
1Ctrl+a
 user@host> show interfaces
1Ctrl+f
 user@host> show interfaces
1Ctrl+e
 user@host> show interfaces
Figura 8.1 
Edição EMACS.
100
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
As seguintes sequências são suportadas:
q 1 Ctrl + b: move o cursor um caractere para a esquerda.
 1 Ctrl + a: move o cursor para o início da linha de comando.
 1 Ctrl + f: move o cursor um caractere para a direita.
 1 Ctrl + e: move o cursor para o final da linha de comando.
 1 delete + backspace: remove o caractere antes do cursor.
 1 Ctrl + d: remove todos os caracteres do início da linha até o ponto onde está o cursor.
 1 Ctrl + k: remove todos os caracteres entre o cursor e o final da linha de comando.
 1 Ctrl + u: remove todos os caracteres e nega o comando corrente.
 1 Ctrl + w: remove a palavra à esquerda do cursor.
 1 Ctrl + l: repete a linha corrente.
 1 Ctrl + p: repete o comando anterior do histórico de comandos.
 1 Ctrl + n: avança para o comando seguinte no histórico de comandos.
Usando o caractere “pipe”
q 1 O caractere “|” (pipe) executa a mesma função que possui nos sistemas baseados 
em Unix. 
 1 Esse comando permite que a saída de um comando seja recebida e processada por 
um segundo comando. 
 1 Utilizando esse conceito pode-se, por exemplo, filtrar a saída de um comando.
Os comandos disponíveis após o caractere “|” são listados:
 1 compare: disponível no modo de configuração, apenas quando se está usando um 
comando de “show”. Compara mudanças feitas na sessão de configuração corrente com 
o conteúdo do arquivo de configuração do roteador.
 1 count: exibe o número de linhas existentes na saída do comando antes do pipe.
 1 display changed: disponível apenas no modo de configuração. Exibe mudanças de confi-
guração feitas na sessão corrente (para visualização do arquivo em XML).
 1 display detailed: disponível apenas no modo de configuração. Exibe informações adicio-
nais sobre o conteúdo da configuração.
 1 display inheritance: disponível apenas no modo de configuração. Exibe configuração 
herdada.
 1 display omit: disponível apenas no modo de configuração. Exibe linhas da configuração 
da opção “omit”.
 1 display set: disponível apenas no modo de configuração. Exibe os comandos “set” que 
geraram as linhas de configuração.
 1 display xml: exibe a saída do comando anterior ao pipe no formato JUNOScript XML.
 1 except <regular expression>: exibe a saída do comando anterior sem a expressão 
especificada.
 1 find <regular expression>: exibe a saída do comando anterior começando da linha que 
contém a expressão regular especificada.
 1 hold: exibe a saída do comando anterior ao pipe tela a tela (como faz o comando “more” 
do Unix).
101
 
C
ap
ítu
lo
 8
 - 
O
pç
õe
s 
de
 a
ce
ss
o 
ao
 Ju
no
s 
 1 last: exibe a última tela da saída do comando anterior ao pipe.
 1 match <regular expression>: exibe a saída do comando anterior ao pipe, incluindo 
apenas as linhas que contêm a expressão regular especificada.
 1 no-more: exibe a saída do comando anterior ao pipe toda de uma vez, sem pausa entre 
diferentes telas.
 1 request message: exibe a saída para múltiplos usuários.
 1 resolve: converte endereços IP em nomes do DNS.
 1 save <filename>: salva o output do comando anterior ao pipe para o arquivo especificado.
 1 trim: especifica o número de colunas a partir da linha inicial da saída do comando ante-
rior ao pipe.
É possível cascatear múltiplos pipes para processar uma saída de comando já processada 
por um pipe.
102
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
103
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Roteiro de Atividades 3
Atividade 3.1 – Acessar o Juniper via console serial
1. Uma das maneiras de se acessar o roteador é via cabo de console serial. Esse cabo é 
fornecido junto com o equipamento e possui um conector RJ45 em uma das pontas, que 
você deverá conectar na porta de console do roteador e o outro conector DB9 em outra 
ponta, que você deverá conectar na porta serial do computador.
Ao conectar corretamente os cabos, você precisará utilizar um software que irá propiciar o 
acesso à CLI do Junos. Esse software pode ser o HyperTerminal do Windows ou o software 
livre PuTTY.
Após alterar o “connection type” – tipo de conexão – para serial, clique em “open”; vai apa-
recer uma tela preta, onde você deverá digitar a tecla “enter”. Feito isso, você entrará na tela 
de login solicitando um usuário.
O usuário é “root”. Após informar o usuário o sistema solicitará uma senha. Essa senha vem 
em branco de fábrica.
Figura 8.2 
Tela de 
configuração do 
software PuTTY.
104
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
2. Entrando no modo operação;
Quando você acessa o Junos com o usuário “root”, recebe um Shell Linux que fornece a 
maioria dos comando básicos do Unix. Para acessar o console do Junos, você deverá digitar 
o comando “cli” (isso ocorre somente com o usuário root).
root@% cli
Após o comando “cli” você perceberá que o prompt foi alterado, identificando que você está 
no modo “operação”.
root>
3. Utilizando as opções de help do Junos;
O Junos oferece algumas opções de ajuda, que auxiliarão na administração do sistema ope-
racional. A primeira opção é o sinal “?”, logo após cada comando.
root# set system host-name ?
Possible completions:
 <host-name> Hostname for this router
[edit system]
root# set services ?
Possible completions:
 <[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don’t inherit configuration data from these 
groups
> dhcp Configure DHCP server
> finger Allow finger requests from remote systems
> ftp Allow FTP file transfers
> netconf Allow NETCONF connections
> outbound-ssh Initiate outbound SSH connection
> service-deployment Configuration for Service Deployment (SDXD) 
management application
> ssh Allow ssh access
> telnetAllow telnet login
> web-management Web management configuration
> xnm-clear-text Allow clear text-based JUNOScript connections
> xnm-ssl Allow SSL-based JUNOScript connections
 | Pipe through a command
[edit system]
105
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Outra opção de ajuda que o Junos oferece é com o comando “help topic”, que junto ao sinal 
de interrogação fornece uma ajuda mais detalhada sobre uma configuração desejada. 
root# help topic system host-name
 Configuring the Router’s Hostname
 To configure the router’s name, include the host-name statement 
at the
 [edit system] hierarchy level:
 [edit system]
 host-name hostname;
 The router’s name value must be less than 256 characters.
 Related Topics
 * Configuring the Basic Router Properties
 * Example: Configuring a Router?s Name, IP Address, and System ID
[edit]
Outra opção de ajuda que o Junos oferece é com o comando “help reference”, que junto o sinal 
de interrogação, fornece informações mais detalhadas sobre uma configuração desejada.
root# help reference system host-name
 host-name
 Syntax
 host-name hostname;
 Hierarchy Level
 [edit system]
 Release Information
 Statement introduced before JUNOS Release 7.4.
 Description
 Set the hostname of the router.
 Options
 hostname--Name of the router.
 Usage Guidelines
 See Configuring the Router?s Hostname.
 Required Privilege Level
 system--To view this statement in the configuration.
 system-control--To add this statement to the configuration.
[edit]
106
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Atividade 3.2 – Opções da interface de usuário
Parte 1: Obtendo ajuda no Junos
 Verifique as possíveis opções do comando “clear”.
R.: clear ?
Verifique as possíveis opções do comando “show system”.
R.: show system ?
Verifique todas as opções do comando “show system” que comecem com a letra “a”.
R.: show system a?
Consulte o manual do sistema sobre endereços de interfaces.
R.: help topic interfaces address
Cheque outros temas referentes a interfaces para os quais seja possível solicitar o manual 
de informações.
R.: help topic interfaces ?
Cheque outros temas para os quais seja possível solicitar o manual de informações.
R.: help topic ?
Utilize o comando “help reference” para verificar instruções de como aplicar um endereço a 
uma interface.
R.: help reference interfaces address
Parte 2: Familiarizando-se com a CLI do Junos
 1 Pratique o completamento automático de comando com as teclas “Tab” e “Space”.
Exemplo 1: Digite “show system up<Tab>”
Exemplo 2: Digite “show system up<Space>”
Exemplo 3: Digite “show system x<Tab>”
Exemplo 4: Digite “show system x<Space>”
 1 Após aplicar os exemplos acima, explique a diferença entre “Tab” e “Space”:
 1 Verifique o histórico de comandos antigos executando recursivamente a tecla “seta pra 
cima” ou “Ctrl+p”.
 1 Avance para os comandos mais recentes do histórico executando recursivamente a tecla 
“seta pra baixo” ou “Ctrl+n”.
 1 Digite o comando “pow interfaces fe-0/0/0” e tecle <Enter> (isso gerará um erro).
 1 Corrija o comando anterior digitando seguidamente:
107
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
“Ctrl+p”
“Ctrl+a”
Troque “P” por “sh”.
Tecle <Enter>.
Modo de operação
q 1 Ao fazer login no Junos, o usuário típico ganha acesso ao modo de operação, utilizado 
para tarefas de monitoração e controle da plataforma. 
 1 Os comandos do modo de operação seguem uma determinada hierarquia.
O comando “show”, exemplificado na figura seguinte, exibe vários tipos de informação 
sobre o sistema e seu ambiente. A figura mostra uma das possíveis opções da hierarquia do 
comando “show”: a opção “ospf”, que mostra informação sobre o protocolo de roteamento 
dinâmico OSPF. Especificando a subopção “interface” dentro da opção “ospf”, obtemos 
informações sobre as configurações de OSPF de uma ou mais interfaces. O comando final 
fica “show ospf interface”. 
Exemple: user@host> show ospf interface
arp configuration ospf version ...
database interface neighbor ...
clear configure help monitor set show ...
Less Specific
More Specific
 
É possível executar comandos do modo de operação, como o “show”, a partir do modo de 
configuração. Para tal basta usar o comando “run”. Assim, para verificar as configurações de 
OSPF das interfaces da caixa a partir do modo de operação, por exemplo, utiliza-se o “show 
ospf interface”. Para executar o mesmo comando a partir do modo de configuração, usa-se 
o “run show ospf interface”.
Algumas tarefas típicas executadas de dentro do modo de operação:
 1 Monitoramento e verificação do sistema (com comandos de “show”, por exemplo);
 1 Troubleshooting;
 1 Conexão a outros sistemas (com Telnet ou SSH);
 1 Cópia ou criação de arquivos;
 1 Reinício de processos;
 1 Entrada no modo de configuração;
 1 Término de sessão no equipamento.
Figura 8.3 
Hierarquia do Modo 
de Operação.
108
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Comandos do Modo de Operação:
user@host> ?
possible completions:
clear Clear information in the system
configure Manipulate software configuration information
file Perform file operations
help Provide help information
monitor Show real-time debugging information
mtrace Trace multicast path from source to receiver
op Invoke an operation script
ping Ping remote target
quit Exit the management seSSlon
request Make system-level requests
restart Restart software process
cet Set CLI properties, date/time, craft interface message
show Show system information
cch Start secure shell on another host
start Start shell
telnet Telnet to another host
test Perform diagnostic debugging
trace route Trace route to remote host
Modo de configuração
q 1 Esse modo permite a um usuário alterar o arquivo de configuração do sistema.
 1 Diferente da maioria dos fabricantes, os equipamentos Juniper não efetivam as alte-
rações de configuração no exato momento em que os comandos de configuração 
são executados. 
 1 Todas as alterações que um usuário faz são acumuladas em um arquivo, temporariamente. 
 1 O Junos trabalha com os conceitos de Configuração Candidata e Configuração Ativa.
 2 Configuração Ativa: 
 3 Presente no arquivo de configuração que está efetivamente valendo para o 
roteador.
 3 Configuração que o sistema carrega durante o processo de “boot” do equipamento.
 2 Configuração Candidata: 
 3 Fica em um arquivo temporário e poderá tornar-se a configuração ativa, caso o 
usuário queira. 
 3 Quando o usuário entra no modo de configuração do Junos, o software cria 
uma configuração candidata a partir de uma cópia da configuração ativa.
109
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Se o usuário executa algum comando de configuração, altera a configuração candidata. 
Uma vez que o usuário tem certeza que a sua modificação pode ser efetivada, ele executa o 
comando “commit”. Essa ação faz com que a configuração candidata seja copiada em cima 
da configuração ativa. Nesse momento a configuração ativa é alterada efetivamente.
Configuração 
Candidata
commit
configure
rollback n
Configuração 
Ativa
0
1 2 ... 49
 Balde
de bits 
q 1 Para entrar no modo de configuração e inaugurar a criação deum arquivo de configu-
ração candidata deve ser utilizado o comando “configure”. A partir desse momento o 
usuário pode começar a configurar o Junos. 
 1 Após executar todos os comandos de configuração desejados, executa-se o “commit”. 
 1 Nesse momento, o Junos checará toda a configuração candidata procurando por 
possíveis problemas de sintaxe. 
 1 Não encontrando problemas, a configuração candidata é copiada para a configu-
ração ativa. 
 1 As alterações passam a ser válidas. Se a sintaxe não está correta, o sistema gera uma men-
sagem de erro e a configuração candidata não é efetivada até que o erro seja corrigido.
 1 Caso o usuário mude de ideia quanto à configuração recém aplicada, pode-se retornar 
à configuração anterior através do comando “rollback” no modo de configuração. 
 1 Na verdade, o Junos é capaz de salvar os últimos 50 arquivos de configuração. 
Esse número inclui o arquivo de configuração ativo correntemente.
Iniciando o Modo de Configuração
q 1 Para entrar no modo de configuração, executa-se o comando “configure” a partir da 
CLI do modo de operação. 
 1 Se um usuário entra no modo de configuração e outro usuário já está nesse modo, o 
sistema gera uma mensagem indicando o usuário que está editando a configuração 
candidata e a porção da configuração que está sendo editada.
 1 Uma vez no modo de configuração, o prompt da CLI muda do “>” para o “#”. 
Figura 8.4 
Configuração 
Candidata e 
Configuração Ativa.
110
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Além disso, surge no prompt um par de parênteses (“[ ]”), indicando em qual ponto da 
hierarquia do arquivo de configuração o usuário está. 
 1 Ao entrar no modo de configuração o usuário sempre entrará no nível “[edit]”.
Configuração exclusiva
q 1 Por default, múltiplos usuários podem entrar no modo de configuração e executar 
“commit”.
 1 Utilizando o comando “configure exclusive”, o usuário tem acesso ao modo de confi-
guração e impede que outros usuários possam entrar nesse modo. 
 1 Ou seja, o usuário tem a garantia de que somente ele está editando a configuração 
candidata.
Configuração exclusiva x Configuração tradicional:
quser@host> configure
Entering configuration mode
[edit]
user@host#
user@host> configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode
[edit]
user@host#
 1 Quando se usa o “configure exclusive” para editar a configuração candidata, caso o 
usuário saia do modo de configuração sem executar um “commit”, todas as mudanças 
são descartadas, ao contrário do que ocorre quando se usa o comando “configure”, em 
que as mudanças não salvas com o “commit” ficam retidas na configuração candidata. 
 1 Na próxima vez que se entrar no modo de configuração, a configuração candidata 
estará lá, intocada.
 1 Sempre que possível o uso do “configure exclusive” é recomendado.
Configuração privada
Outra forma de entrar no modo de configuração é fazendo uso do comando “configure 
private”. Esse comando permite que múltiplos usuários editem a configuração. Nesse caso, 
ao fazer “commit”, os usuários salvam na configuração ativa apenas as linhas de configu-
ração que cada um editou.
Se um usuário que entrou no modo de configuração através de um “configure private” 
(fazendo um “commit”) muda de ideia e executa um “rollback 0”, apenas as linhas que ele 
mesmo alterou são revistas.
Se dois usuários estão no modo de configuração privada e ambos fazem a mesma modifi-
cação, o segundo “commit” vai falhar, e será exibida mensagem de erro para evitar conflito 
de configuração. Se o usuário que executou o segundo “commit” insiste e executa um novo 
“commit”, a configuração é salva corretamente. 
111
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Em alguns cenários, o administrador do sistema pode querer definir que todas as edições da 
configuração sejam feitas com “configure private” e nunca com “configure”. Ao criar contas 
de usuários é possível limitar os comandos disponíveis. Pode-se então excluir a permissão 
para executar o “configure”, permitindo, por exemplo, o “configure private”.
Se um usuário adentra o modo de configuração e altera a configuração candidata, outros usu-
ários não podem entrar no modo de configuração usando as opções “exclusive” ou “private”. 
As mudanças feitas pelo primeiro usuário precisam ser confirmadas com um “commit” ou 
descartadas para que outros usuários possam entrar nos modos exclusivo ou privado.
Hierarquia do Modo de Configuração
q 1 No modo de configuração, o usuário se movimenta através de uma hierarquia de 
porções da configuração. 
 1 Para alterar um parâmetro, o usuário se movimenta até o ponto correto da hierarquia 
e faz a alteração.
[edit]
user@host# edit protocols ospf area 51 stub
[edit protocols ospf area 0.0.0.51 stub]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
Less Specific
More Specific
[edit]
A hierarquia do arquivo de configuração nada tem a ver com a hierarquia de comandos do 
modo de operação. De maneira análoga, os comandos disponíveis no modo de configuração 
nada têm a ver com os disponíveis no modo de operação.
Por exemplo, na CLI do modo de operação disponibiliza o comando “show” para mostrar 
informações específicas do sistema, enquanto que no modo de configuração também há um 
comando “show”, mas para exibir uma porção específica do arquivo de configuração. Os dois 
comandos de “show” não têm qualquer relação.
O Junos organiza a hierarquia de comandos de configuração em uma estrutura de árvore, 
similar à estrutura de diretórios do Unix e do Windows. Nesse modelo as configurações 
relacionadas ficam agrupadas em um mesmo ponto da árvore. 
q 1 Para modificar uma linha qualquer da configuração candidata utiliza-se sempre o 
comando “set”. 
 1 O comando “show” exibe a configuração candidata ou parte dela.
Figura 8.5 
Hierarquia de 
configuração.
112
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Comandos “set” e “show” no Modo de Configuração:
q[edit system]
user@host# set services web-management http port 8080
[edit system]
user@host# show services
web-management {
 http {
 port 8080;
 }
}
 1 As diferentes porções do arquivo de configuração (candidata ou ativa) são hierarqui-
zadas através de chaves (“{ }”). As chaves facilitam a leitura da estrutura de árvore. 
 1 O final de cada linha de configuração termina sempre com um ponto e vírgula (“;”), asse-
melhando o formato do arquivo a um código de linguagem de programação estruturada.
 1 Nos comandos de “set”, que efetivamente alteram o arquivo de configuração, não é 
necessário incluir nem colchetes nem ponto e vírgula. 
Movendo entre níveis no Modo de Configuração
q 1 Ao entrar no modo de configuração, o usuário encontra-se na raiz da hierarquia. Esse 
nível é chamado “edit”. Nesse momento o prompt de comando assinala a string “[edit]”.
 1 Para mover-se para os níveis mais baixos da hierarquia utiliza-se o comando “edit”, 
especificando o nível ao qual se deseja chegar. 
Após mudar de nível, o prompt muda para indicar o novo nível onde o usuário está posicionado.
[edit]
user@host# edit protocols ospf area 51 stub
[edit protocols ospf area 0.0.0.51 stub]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
[edit]
Para mover-se de volta um nível na hierarquia de configuraçãoutiliza-se o comando “up”:
Figura 8.6 
Comandos “edit”: 
movendo-se na 
Hierarquia de 
Configuração.
113
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
[edit protocols ospf area 0.0.0.51 stub]
user@host# up
[edit protocols ospf area 0.0.0.51]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
[edit]
Para mover-se de volta “n” níveis na hierarquia de configuração utiliza-se o comando “up <n>”.
[edit protocols ospf area 0.0.0.51]
user@host# up 2
[edit protocols]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
[edit]
Para retornar para o nível raiz da hierarquia de configuração utiliza-se o comando “top”.
Figura 8.7 
Comando “up”.
Figura 8.8 
Comando “up <n>”.
114
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
[edit protocols ospf area 0.0.0.51 stub]
user@host# top
[edit]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
[edit]
q 1 O comando “top” pode ser combinado com o comando “edit” para se mover de um 
determinado nível da hierarquia para outro nível completamente diferente, com 
apenas um comando.
 1 Comando “top” combinado com “edit”: avanço rápido entre níveis. 
[edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0]
user@host# top edit system login
[edit system login]
quser@host# top show system services
ftp;
ssh;
 1 O comando “exit” retorna para o nível da hierarquia de configuração que o usuário 
estava antes do nível corrente. 
 1 Se o usuário estiver na raiz (nível “edit”) o comando “exit” sai do modo de configuração.
 1 O comando “exit configuration-mode” sai do modo de configuração independente do 
nível de hierarquia onde o usuário está.
Figura 8.9 
Comando “top”.
115
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
[edit protocols ospf area 0.0.0.51 stub]
user@host# exit
[edit protocols ospf]
user@host# edit area 51 stub
[edit protocols ospf]
user@host# 
area-range area_range interface nssa stub ...
chassis interfaces protocols services system ...
area area_id graceful-restart overload traffic-engineering ...
bgp isis mpls ospf pim rip rsvp vrrp ...
[edit]
Resumo dos comandos para navegação entre os diferentes níveis da hierarquia de configuração:
 1 edit: direciona o usuário para um ponto da hierarquia de configuração.
 1 up: move o usuário um nível acima na hierarquia.
 1 up <n>: move o usuário “n” níveis acima na hierarquia.
 1 top: move o usuário para a raiz da hierarquia.
 1 exit: move o usuário para o nível anterior. 
Alterando linhas da Configuração Candidata
qUma vez posicionado no nível desejado da hierarquia que se quer modificar, o comando 
“set” altera/adiciona uma linha da/na configuração candidata.
Comando “set”:
[edit system services] 
user@host# show 
ssh ; 
telnet; 
[edit system services] 
user@host# set ftp -> FTP service added 
[edit system services] 
user@host# show 
Figura 8.10 
Comando “exit”: 
retorno ao nível 
anterior.
116
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
ftp; 
ssh; 
telnet;
No exemplo anterior, o comando “set” adicionou o comando “ftp” no nível “[edit system 
services]”. É possível executar o mesmo comando sem a necessidade de se mover para 
o ponto da hierarquia a ser alterado. Para tal, poderia ter sido executado o comando 
“set system services ftp” a partir do nível “[edit]”. Ou ainda, poderia ter sido usado o 
comando “set services ftp” a partir do nível “[edit system]”.
q 1 Para desfazer uma ação executada por um comando “set”, utiliza-se o comando “delete”. 
 1 Esse comando remove uma linha de configuração e todas as linhas relacionadas. 
 Comando “delete”:
[edit system services] 
use r@host# show 
ftp ; 
ssh; 
telnet; 
[edit system services] 
user@host# delete telnet
[edit system services] 
user@host# show 
ftp ; 
ssh; 
Dependendo do uso que se deseja fazer do comando “delete”, é possível usar o “wildcard 
delete”. Esse comando é útil quando se deseja remover várias configurações semelhantes. 
O próximo exemplo exibe a utilidade desse recurso.
Comando “wildcard delete”:
[edit]
user@host# wildcard delete interfaces ge-1/*
matched: ge-1/0/0
matched: ge-1/0/1
Delete 2 objects? [yes, no] (no) yes
[edit]
117
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
user@host#
Ativando e desativando configurações
q 1 O Junos permite que um usuário desative uma determinada configuração sem removê-la.
 1 Uma linha de configuração desativada continua presente no arquivo de configuração 
da caixa, mas o roteador irá ignorá-la.
 1 O comando “deactivate” desativa uma porção da configuração, a qual poderá ser 
reativada com o comando “activate”.
Comandos “activate” e “deactivate”:
[edit]
user@host# deactivate interfaces ge-0/0/0
[edit]
user@host# commit
commit complete
[edit]
user@host# show interfaces ge-0/0/0
##
## inactive: interfaces ge-0/0/0
##
unit 0 {
family inet {
address 10.210.11.177/28;
}
family inet6;
}
[edit]
user@host# activate interfaces ge-0/0/0
[edit]
user@host# commit
commit complete
[edit]
user@host# show interfaces ge-0/0/0
unit 0 {
family inet {
118
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
address 10.210.11.177/28;
}
family inet6;
}
Outros comandos auxiliares do Modo de Configuração
Há ainda alguns comandos úteis que facilitam a operação do Junos no modo de configuração. 
São eles:
q 1 rename: altera o nome de uma configuração.
 1 replace: altera um padrão em uma linha de configuração.
 1 copy: copia um padrão de linha de configuração para outra linha.
 1 insert: insere uma linha de configuração em um ponto desejado do arquivo 
de configuração.
Esses comandos serão trabalhados nas atividades de laboratório.
Verificando a Configuração Candidata
q 1 No modo de configuração utiliza-se o comando “show” para verificar as linhas da 
configuração candidata. 
 1 Esse comando exibe a configuração de todo o arquivo da configuração candidata ou 
de uma porção da hierarquia corrente. 
 1 O comando “show | compare” compara a configuração candidata com a ativa.
O exemplo seguinte mostra duas formas de exibir a configuração da hierarquia 
“[edit system services]”.
Comando “show”:
[edit] 
user@host# show system services 
ssh; 
web-management { 
 http { 
 port 8080; 
 }
}
 
[edit] 
user@host# edit system services 
[edit system services] 
119
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
user@host# show 
ssh; 
web-management { 
 http { 
 port 8080; 
 } 
} 
Hint To view the set commands used to build the configuration use 
the show | display set command.
Utilizando o comando “show”, a configuração da hierarquia especificada aparece entre 
chaves (“{ }”). As linhas de configuração da hierarquia aparecem finalizadas por um ponto 
e vírgula (“;”). Essa formatação é a mesma que a CLI usa paraarmazenar as configurações 
setadas pelo usuário.
q 1 Opcionalmente, é possível ver a configuração de uma determinada hierarquia no 
formato de comandos “set”. 
 1 Dessa forma, o usuário tem acesso aos comandos que foram efetivamente utilizados 
para fazer as configurações presentes no arquivo. 
 1 Para visualizar uma porção de configuração nessa formatação descrita, utiliza-se o 
comando “show” com a opção “display set”. 
Comando “show” com opção “display set”:
[edit]
user@host# show system services | display set
set system services ssh
set system services web-management http port 8080
Salvando a Configuração Candidata
q 1 Uma vez editada a configuração candidata com os vários comandos disponíveis no 
modo de configuração, é hora de salvar as alterações. 
 1 A forma mais simples e usual de executar essa tarefa já foi apresentada: “commit”.
 1 Após executar o “commit”, a mensagem “commit complete” confirma que as altera-
ções foram executadas corretamente. 
 1 Caso haja erros de sintaxe, uma mensagem de erro será gerada e a configuração não 
será salva.
Comando “commit”:
120
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
[edit] 
user@host# commit 
commit complete
Uma forma de verificar de antemão se a configuração está sem erros de sintaxe é através do 
comando “commit check”. Esse comando verifica se a configuração candidata está correta, 
mas não salva essa configuração.
Comando “commit check”:
[edit] 
user@host# commit check 
[edit interfaces ge-0/0/10 unit 0] 
 ‘family’ 
 When ethernet-switching family is configured on an interface, no 
 other family type can be configured on the same interface. 
 error: configuration check-out failed
Ao executar determinadas mudanças na configuração do equipamento, a partir de um 
ponto remoto, existe o risco de perda do acesso a ele. Por exemplo, ao alterar uma configu-
ração de roteamento incorretamente, é possível que haja perda de conectividade entre o 
ponto onde está o computador do usuário e o roteador. No mundo real essa situação ocorre 
com certa frequência. 
Normalmente quando isso acontece, a única solução é levar um notebook até a sala onde 
está o roteador, conectar o notebook à porta console e corrigir o problema. Se o usuário que 
está fazendo a configuração não está no prédio onde está o roteador, pode estar caracteri-
zado um problema sério.
O Junos apresenta uma proposta para essa situação: o comando “commit confirmed”. 
Antes de salvar a configuração candidata com o comando “commit”, o usuário tem a opção 
de executar o “commit confirmed <time>”, onde <time> é um número expresso em minutos.
Esse comando faz com que o roteador efetive a configuração candidata durante alguns 
minutos. Se após essa quantidade de minutos especificada o usuário não se pronunciar, 
o roteador volta com a configuração anterior (rollback1 !). Se o usuário quiser confirmar a 
efetivação da configuração candidata, ele deve executar um “commit”.
Comando “commit confirmed”:
[edit] 
user@host# commit confirmed 
commit confirmed will be automatically rolled back in 10 minutes 
unless 
confirmed 
commit complete
121
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Repare que, caso o usuário tenha cometido um erro de configuração que comprometa a conec-
tividade do equipamento, esse procedimento evita que o usuário perca acesso total ao equipa-
mento durante muito tempo, caso esteja fazendo uma alteração de configuração remotamente.
Se o comando é executado sem que seja especificado um valor de tempo, o valor assumido 
é de 10 minutos.
O Junos também permite que um usuário agende um “commit”. Para tal utiliza-se o “commit at”.
Comando “commit at”:
[edit] 
user@host# commit at 21:00:00 
 configuration check succeeds 
 commit at will be executed at 2009-05-11 21:00:00 UTC 
 Exiting configuration mode
q 1 Para checar se há um “commit” agendado no roteador utilize o comando “show 
system commit” no modo de operação.
 1 Para abortar um agendamento de “commit” utilize o comando “clear system commit” 
no modo de operação.
Comandos “show system commit” e “clear system commit”:
user@host> show system commit
commit requested by user via cli at 2009-05-11 21:00:00 UTC
0 2009-05-11 15:32:42 UTC by user via cli
...
user@host> clear system commit
Pending commit cleared
Outra possibilidade é deixar um log registrado do “commit” que será executado. Para tal utiliza-se 
o comando “commit comment”. Dessa forma, o “commit” ficará registrado na saída do comando 
de verificação “show system commit”, que deve ser executado no modo de operação.
Comandos “commit comment” e “show system commit”:
[edit] 
user@host# commit comment “Changed OSPF configuration” 
commit complete
 
user@host> show system commit 
0 2009-05-11 15:32:42 UTC by User via cli 
 Changed OSPF configuration 
Por fim, o Junos permite executar o “commit” e deixar o modo de configuração de uma só 
vez. Para tal utiliza-se o comando “commit and-quit”.
122
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Checando alterações antes de salvar
q 1 Um usuário fez dezenas de mudanças na configuração candidata. Antes de executar o 
“commit”, precisa ter certeza de que tudo foi feito. 
 1 A diferença entre a configuração candidata corrente e a configuração ativa pode ser 
verificada com o comando “show | compare” no modo de configuração.
Comando “show | compare”:
[edit system services] 
user@host# show | compare 
[edit system services] 
+ ftp; 
- telnet;
O uso desse comando é sempre recomendável.
Analogamente, é possível comparar o conteúdo da configuração candidata com outras con-
figurações passadas. Para tal utiliza-se, no modo de operação, o comando “show configura-
tion | compare rollback <n>”, onde <n> denota o índice da configuração passada; índice zero 
se refere à configuração corrente; índice 1 se refere à última configuração; índice 2 se refere 
à penúltima configuração...
O Junos também permite comparar outros arquivos, que não são necessariamente os arquivos 
de configuração. Para executar tal ação, execute “file compare files “<arquivo1> <arquivo2>”.
Restaurando configurações
q 1 O Junos pode guardar automaticamente as últimas 50 versões de arquivos 
de configuração.
 1 Para restaurar qualquer um desses arquivos utiliza-se, no modo de configuração, o 
comando “rollback <n>”, onde <n> denota o índice da configuração a recuperar. Nesse 
caso <n> varia de 0 a 49.
 1 O comando “rollback” reescreve um arquivo de configuração antigo na configuração 
candidata. 
 1 Para confirmar a restauração da configuração no roteador, o usuário precisa executar 
ainda o comando “commit”.
 1 Para alterar a quantidade de configurações salvas automaticamente pelo Junos 
utiliza-se o seguinte comando no modo de configuração:
set max-configurations-on-flash <max> 
123
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Dessa forma, a vida de um arquivo de configuração é retratada na figura a seguir.
Configuração 
Candidata
configure
rollback n
Configuração 
Ativa
0
1 2 ... 49
 Balde
de bits 
Salvando a configuração em arquivo ASCII
q 1 O Junos salva configurações automaticamente, as quais podem ser restauradas com o 
comando “rollback”. 
 1 Às vezes é interessante salvar a configuração do equipamento em um arquivo ASCII, 
ou ainda, pode ser útil salvar apenas parte da configuração em um arquivo ASCII. 
 1 Essas operações podem ser executadas com o comando “save”.
Comando “save”:
[edit] 
user@host# save filename 
Wrote 101 lines of configuration to ‘filename’ 
Este comando salva as linhas da configuraçãocandidata em um arquivo cujo nome foi 
especificado. As linhas que serão salvas no arquivo ASCII são as linhas da hierarquia onde se 
estava ao executar o comando. 
q 1 Para salvar toda a configuração candidata é necessário estar no nível “[edit]”. 
 1 Para salvar as configurações referentes aos serviços do sistema deve-se executar o 
“save” no nível: “[edit system services]”.
 1 Se o diretório do arquivo destino não é especificado, o arquivo é salvo no diretório 
home do usuário: /var/home/<login>.
A seguir podemos conferir formas alternativas para selecionar o destino do arquivo que 
será salvo.
Figura 8.11 
Vida do arquivo de 
Configuração.
124
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Selecionando destino do arquivo:
[edit]
user@host# save path/filename
[edit]
user@host# save ftp://user:password@host/path/filename
[edit]
user@host# save scp://user@host/path/filename
A segunda opção exibida faz com que o roteador salve o arquivo em um diretório de um 
servidor de FTP remoto, utilizando o login “user” e a senha “password”.
A terceira opção mostra o arquivo sendo salvo em um servidor remoto “host”, através de 
um “security copy”, utilizando o login “user”. Nesse caso o sistema remoto solicitará a senha 
através de um prompt.
Carregando arquivo de configuração
O comando “rollback” recupera um arquivo de configuração dentre os arquivos automati-
camente salvos pelo sistema. Além disso, é possível carregar a configuração de um arquivo 
ASCII do usuário. Para tal utiliza-se o comando “load”. 
O “load” pode carregar a configuração completa ou parcial contida em um arquivo ASCII local, de 
um arquivo em um servidor remoto ou do buffer de um programa de emulação de terminal. 
qO comando “load” permite vários argumentos:
 1 factory-default: troca o arquivo de configuração corrente pela configuração default 
de fábrica.
 1 merge: combina a configuração corrente com a configuração carregada.
 1 override: sobrescreve completamente a configuração corrente com a configuração 
carregada.
 1 replace: procura pela “tag replace” no arquivo de configuração que está sendo carre-
gado. O software troca as linhas existentes com o mesmo nome daquelas marcadas 
com “replace” no arquivo carregado.
 1 set: permite que o usuário carregue um arquivo de configuração formatado como um 
conjunto de comandos “set” (uma das formas mais usadas da operação “load”).
Em todas as modalidades do comando “load”, o arquivo repositório é carregado na configu-
ração candidata. Para efetivar as alterações é necessário usar o comando “commit”.
Comando run
q 1 O “run” permite ao usuário executar comandos do modo de operação a partir do 
modo de configuração. 
 1 Esse comando é similar ao comando “do” dos equipamentos de outros fabricantes.
125
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Uso do comando “run”:
[edit interfaces ge-0/0/l2] 
user@host# set unit 0 family inet address 10.250.0.141/16 
[edit interfaces ge-0/0/l2] 
user @host# commit 
commit complete 
[edit interfaces ge-0/0/l2] 
user@host# run ping 10.250.0.149 count 1 
PING 10.250.0.149 (10.250.0.149): 56 data bytes
64 bytes from 10.250.0.149: icmp seq=O ttl=255 time=0.967 ms 
--- 10.250.0.149 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.967/0.967/0.967/0.000 ms
Interface J-Web GUI
q 1 Além da linha de comando, é possível interagir com o equipamento Juniper através de 
uma interface web, a J-Web. 
 1 Essa interface vem habilitada de fábrica. 
 1 Para acessá-la, pode-se usar um web browser qualquer.
 1 A J-Web é ideal para configuração inicial do equipamento. 
 1 Também é possível executar tarefas de monitoração e manutenção através dessa 
interface, que dispõe de menos recursos que a linha de comando.
Ao conectar na J-Web, o usuário se depara com uma série de abas:
 1 A aba “Dashboard” provê uma visão geral do status do sistema, das portas, dos alarmes 
ativos e informações de utilização.
 1 A aba “Configure” dá ao usuário a chance de configurar o sistema através de cliques de 
mouse ou via acesso direto à configuração em formato texto. Um “Help” fica disponível 
em um ícone “?”, o qual pode ser clicado.
 1 A aba “Troubleshoot” provê acesso a ferramentas simples de rede como “ping” e “traceroute”.
 1 A aba “Maintain” permite ao usuário executar upgrades de software e manutenção no 
sistema de arquivos.
126
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Processo de login na J-Web
qPara que seja possível o acesso ao sistema através da J-Web, é necessário que o comando 
“http” ou “https” esteja configurado na hierarquia “[edit system services web-management]”. 
J-Web habilitado:
[edit system]
user@host# show services
ssh;
telnet;
web-management {
http;
}
Se for utilizado o https será necessário gerar e instalar um certificado local para segurança 
da página.
A visão default que aparece para o usuário ao executar o login traz a aba “Monitor”. Nesse 
local o usuário tem acesso às estatísticas em tempo real das interfaces e de outros parâme-
tros do sistema.
A opção “Chassis” mostra a tela da próxima figura.
Figura 8.12 
Login na J-Web.
127
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
A opção “Interfaces” mostra informações sobre as interfaces do roteador.Figura 8.13 
Aba Monitor/ 
Chassis.
128
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Figura 8.14 
Aba Monitor/ 
Interfaces.
129
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
3
Dentro da aba “Monitor/Interfaces” podemos selecionar uma determinada interface, 
conforme mostrado na figura seguinte.
 
Na aba “Manage/Files” o usuário gerencia o sistema de arquivos. As ações disponíveis nessa 
seção estão associadas à manutenção do sistema.
Figura 8.15 
Aba Monitor/
Interfaces/ 
ge-0/0/0.0. 
Figura 8.16 
Aba Manage/Files. 
130
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Nessa seção é possível gerenciar e manter os arquivos de configuração, fazer download 
de arquivos de log, arquivos de dump ou outros arquivos temporários. Também é possível 
remover arquivos para liberar espaço na memória flash do equipamento.
Essa aba permite ainda outras operações:
 1 Recuperar arquivos de configuração históricos e compará-los;
 1 Fazer upgrade ou downgrade do Junos;
 1 Adicionar e verificar licenças;
 1 Agendar reboots do sistema;
 1 Recuperar informações de suporte para reporte ao serviço de assistência técnica da Juniper.
Por fim, a aba “Diagnose” provê utilitários para a investigação de problemas. Pode-se 
fazer troubleshoot de portas individuais através de comandos como “ping” e “traceroute”. 
Também é possível capturar pacotes.
Figura 8.17 
Aba Diagnose/ 
Ping Host.
131
 
C
ap
ítu
lo
 8
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
4
Roteiro de Atividades 4
Atividade 4.1 – Opções de acesso ao Junos
1. Entrando no modo configuração do Junos;
Para entrar no modo configuração digite o comando “configure”.
root> configure
Entering configuration mode
Users currently editing the configuration:
 root terminal d0 (pid 1062) on since 2010-12-23 23:21:41 UTC, idle 
3w5d 01:20
 [edit]
The configuration has been changed but not committed
[edit]
2. Navegando pela árvore de configuração do Junos;
Ao entrar no modo configuração você estará no topo da árvore de configuração do Junos, 
como se estivesse navegando no Windows Explorer, onde para alterar um arquivo que está 
numa pasta chamada relatórios, dentro de meus documentos,você deverá percorrer par-
tindo de “C:\Documents and Settings\glenio.lima\Meus documentos\relatorio”.
Para descer a árvore do arquivo de configuração do Junos, deve-se utilizar o comando “edit”.
root# edit interfaces
[edit interfaces]
root# edit ge-0/0/0
[edit interfaces ge-0/0/0]
root# edit unit 0
[edit interfaces ge-0/0/0 unit 0]
Para subir a árvore do arquivo de configuração do Junos, você deve utilizar o comando “up”.
root# up
[edit interfaces ge-0/0/0]
root# up
[edit interfaces]
root# up
[edit]
132
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
O Junos oferece um comando para você ir ao topo do arquivo de configuração, indepen-
dente de onde você estiver localizado. Esse comando é o “top”.
root#
[edit interfaces ge-0/0/0 unit 0]
root# top
[edit]
3. Conhecendo o comando “show”;
Ao navegar pelo arquivo de configuração do Junos você pode verificar a configuração com o 
comando “show”.
root# show
root-authentication {
 encrypted-password “$1$GwoPLZZp$8HKb9z7J55MJHFt7/tErn.”; ## 
SECRET-DATA
}
services {
 ssh;
 telnet;
 web-management {
 http {
 interface ge-0/0/1.0;
 }
 }
}
syslog {
 file messages {
 any any;
 }
}
4. Conhecendo o comando “set”;
root# set system host-name teste
5. Conhecendo o comando “delete”;
Para excluir alguma configuração na árvore do Junos, você deve fazer a exemplo do 
comando “set”, porém utilizando o comando “delete”. 
root# delete system host-name teste
133
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
ob
je
tiv
os
conceitos
9
Configurações do roteador
Descrever as configurações do roteador, interfaces e usuário, apresentar os logs do 
sistema e os procedimentos de uso e descrever os protocolos NTP e SNMP.
 
Configuração default de fábrica, configuração inicial, configuração de interface, 
nomeação de interfaces, configurações de usuário e autenticação, logs do sistema, 
Network Time Protocol (NTP) e Simple Network Management Protocol (SNMP).
 
 
Configuração default de fábrica
q 1 Toda a plataforma que roda o Junos é vendida com uma configuração default de fábrica. 
 1 O acesso ao sistema com essa configuração é feito somente através da conta do 
usuário root, que vem de fábrica sem senha configurada. 
 1 É necessário definir uma senha de root antes que qualquer mudança seja feita no sistema.
A configuração que vem de fábrica pode variar de uma família de modelo para outra, ou 
mesmo entre diferentes modelos da mesma família. As diferentes plataformas são proje-
tadas para executar papéis específicos em uma rede, e a configuração de fábrica é criada 
sob esse conceito.
Para exemplificar a ideia, podemos pensar na família EX de switches, que é projetada para 
executar funções L2. Essa família vem com todas as interfaces habilitadas com o Rapid 
Spanning Tree (RSPT). Outras plataformas não necessitam desse recurso.
Configuração X default de fábrica
Configuração Y default de fábrica
=
=
A configuração default traz o “log” de sistema habilitado, o qual captura eventos do Junos e 
os escreve nos chamados “arquivos de log”, pré-definidos. A figura seguinte traz um exemplo 
típico de uma configuração de “log” que vem habilitada no sistema.
Figura 9.1 
Configuração 
default de fábrica. 
134
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Configuração de log default: 
[edit]
user@host# show system syslog
user * {
 any emergency;
}
file messages {
 any any;
 authorization info;
}
file interactive-commands {
 interactive-commands any;
}
Sob certas circunstâncias, pode ser necessário voltar à configuração original de fábrica. 
É possível copiar essa configuração para a configuração candidata. Para tal utiliza-se o 
comando “load factory-default”.
Após copiar a configuração de fábrica para a configuração candidata é necessário executar 
um “commit” para efetivá-la. Abaixo vemos que só é possível executar o comando após 
configurar a senha do root, que não vem criada por default. 
Carregando a configuração de fábrica:
[edit]
user@host# load factory-default
warning: activating factory configuration 
[edit] 
user@host# set system root-authentication plain-text-password 
New password: 
Retype new password: 
[edit] 
user@host# commit 
commit complete
135
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
Configurações iniciais
qLigando, desligando e reiniciando o Junos:
 1 Uma vez que um equipamento Juniper é ligado, se a força for perdida por qualquer 
motivo, e retornar em seguida, o hardware ligará automaticamente, sem necessidade 
de intervenção manual.
Como todo sistema operacional moderno, o Junos é multitarefa. 
Para garantir a integridade do sistema de arquivos é importante, sempre que possível, 
desligar o sistema utilizando o procedimento convencional de shutdown. Embora impro-
vável, um reboot à revelia poderá prejudicar a saúde do sistema, dificultando até mesmo o 
próximo reboot.
Para desligar o sistema pelo método convencional usa-se o comando “request system halt”:
user@host> request system halt? 
Possible completions: 
 <[Enter]> Execute this command 
 at Time at which to perform the operation 
 in Number of minutes to delay before operation 
 media Boot media for next boot 
 message Message to display to all users 
 | Pipe through a command 
qEste comando provê opções que permitem ao usuário:
 1 Agendar um shutdown para um momento futuro, que pode ser especificado em 
quantidade de minutos ou em um horário exato.
 1 Especificar a mídia a partir da qual um reboot será feito.
 1 Registrar a mensagem de reboot em um arquivo de mensagens ou no terminal de console.
Para plataformas Junos que oferecem REs redundantes, o usuário pode reiniciar ambas REs 
simultaneamente, utilizando “request system halt both-routing-engines”.
q 1 Uma vez desembalado e ligado, o equipamento Juniper está pronto para receber as 
primeiras configurações. 
 1 Antes de fazer qualquer alteração, o administrador é obrigado a configurar uma 
senha para o usuário root.
 1 As senhas do sistema não podem ter menos que 6 (seis) caracteres e precisam incluir 
uma mudança de caixa (letras maiúsculas e minúsculas), dígitos ou metacaracteres.
Adicionando a senha de root:
[edit] 
user@host# set system root-authentication plain-text-password 
New password: *** 
136
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
error: minimum password length is 6 
error: require change of case, digits or punctuation
O exemplo mostra a senha sendo configurada como texto plano. Ao contrário dos demais 
sistemas do mercado, o Juniper nunca exibe a senha digitada como texto plano. As senhas 
sempre aparecem encriptadas, conforme abaixo:
[edit system]
root# show root-authentication
encrypted-password “$1$ti58nUSg$8xnQtTJeA0dA/.eUjjZOq1”; ## SECRET-DATA
Acima está a hierarquia do arquivo de configuração onde “aparece” a senha do usuário. 
qAlém desse item, também é recomendável que os seguintes itens sejam configurados:
 1 Hostname do equipamento.
 1 Horário do sistema.
 1 Serviços para acesso remoto (Telnet, SSH).
 1 Interface de gerência e rota estática para o tráfego de gerência.
Login como root
A primeira conexão à CLI precisa ser via porta console. Além disso, no primeiro acesso o 
login com a conta de root é obrigatório, e o usuário não será solicitado a inserir uma senha.
Uma vez conectado ao equipamento, o prompt mostrará o nome do usuário (root). Como 
nãohaverá um hostname configurado, o sistema usará o seu default: Amnesiac.
qO equipamento Juniper possui dois tipos de CLI: 
 1 CLI com shell de Unix, que permite acesso a uma série de utilitários do Unix. 
 1 CLI com a interface de comandos Junos, a partir da qual são feitas as configurações 
das funcionalidades do roteador. 
Ao fazer login como root, o usuário terá acesso à CLI de Unix. 
 1 Para acessar a CLI do Junos é usado o comando “cli”. 
 1 Para retornar à CLI de Unix é usado o comando “exit”.
Entrando no Modo de Configuração
q 1 Depois de iniciar a CLI do Junos, o usuário pode entrar no modo de configuração da 
caixa, onde as alterações de configuração podem ser efetivamente realizadas. 
 1 Para tal é usado o comando “configure” no modo de operação da CLI do Junos.
Amnesiac (ttyu0)- Amnesiac prompt indicates a factory-default 
configuration
login: root 
--- JUNOS 9.5R1.8 built 2009-04-13 20:03:09 UTC
137
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
root@% 
root@% c1i - UNIX shell prompt 
root> - Operational mode prompt 
root> configure 
Entering configuration mode 
[edit]
root# 
Definindo parâmetros de identificação
A seguir exemplo de como fazer a configuração de hostname:
[edit] 
root# edit system 
[edit system] 
root# set host-name host 
[edit system] 
root# set root-authentication plain-text-password 
New password: 
Retype new password: 
Definindo parâmetros de hora
A seguir as configurações de data e hora no Junos:
[edit system]
root# set time-zone America/Los_Angeles 
[edit system] 
root# run set date 200905120900.00 
Tue May 12 09:00:00 UTC 2009
138
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Além da data e hora, deve-se confirmar o timezone da região pertinente. 
 1 O timezone configurado de fábrica é o UTC (GMT). 
 1 Uma vez definido o timezone local, a hora do sistema será ajustada de acordo com a 
diferença entre o timezone configurado manualmente e o default. 
 1 É aconselhável configurar o horário do sistema depois de acertar o timezone.
 1 Ao invés de definir o horário local, existe a opção de configurar o roteador para sin-
cronizar o seu horário com um servidor de Network Time Protocol (NTP). 
Essa possibilidade será abordada mais adiante.
Definindo parâmetros de acesso
A seguir podemos conferir a configuração de acesso remoto (serviços Telnet e SSH):
[edit system] 
root# set services telnet 
[edit sy stem] 
root# set services ssh 
q 1 Outro protocolo de acesso que pode ser configurado de modo similar é o http, que 
permite ao usuário acessar o equipamento através da interface J-Web. 
 1 Ao acessar o roteador através de um desses recursos de acesso remoto, pode-se 
utilizar os mesmos logins criados na hierarquia “[edit system login]”, os quais também 
são válidos para acesso via porta console.
Definindo parâmetros de gerência
A seguir está exibida a configuração de endereço IP em uma interface que será usada para 
gerência:
[edit system] 
[root# top 
 
[edit] 
[root# set interfaces interface name unit 0 family inet address 
10.0.1.131/27 
[edit] 
[root# set routing-options static route 10.0.1.0/24 next-hop 
10.0.1.129
Repare que também foi configurada uma rota estática para uma rede de gerência. Por “rede 
de gerência” entenda-se a infraestrutura onde estarão as máquinas que precisarão fazer 
acesso remoto (via telnet ou SSH) ao roteador, e que receberão traps SNMP dele. 
139
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
Se a instituição tiver um protocolo de roteamento dinâmico configurado na sua LAN, esse 
também poderá ser usado para divulgar o endereço IP de gerência do roteador e aprender 
o endereço da rede de gerência. Algumas literaturas consideram boa prática manter o rote-
amento estático para a rede de gerência, para o caso de falha em um protocolo de rotea-
mento. 
No Junos, as rotas estáticas somente estarão disponíveis quando o rpd (Routing 
Protocol Process) estiver rodando.
Verificando as configurações
Após realizar toda a configuração inicial, as alterações executadas podem ser verificadas 
com o comando “show configuration”. Esse comando exibe a configuração ativa com o seu 
formato original, com as diferentes hierarquias separadas com chaves (“{ }”). 
Verificando as configurações:
root@host> show configuration 
## Last commit: 2009-05-11 21:00:46 UTC by root 
version 9.5R1.8; 
system { 
 host-name host; 
 time-zone America/Los_Angeles; 
 root-authentication { 
 encrypted-password “$1$e/FUEOVo$JF6NiAZxuufGFxDs10MAr/”; ## 
SECRET-DATA 
 } 
 services { 
 ssh; 
 telnet; 
 } 
 syslog { 
...
Configuração de resgate
q 1 O Junos possui o recurso da configuração de resgate. 
 1 Trata-se de um arquivo de configuração extra, definido pelo usuário, que fica guar-
dado no sistema e pode ser solicitado em situações de emergência. 
 1 É recomendável que a configuração de emergência possua os elementos mínimos 
necessários para restaurar a conectividade fundamental de rede. 
 1 Por segurança, a configuração de resgate deve incluir uma senha de root. 
Por default, nenhuma configuração de resgate é definida. Os comandos para definição, 
remoção e efetivação da configuração de resgate são mostrados a seguir:
root@host> request system configuration rescue save 
140
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
root@host> request system configuration rescue delete 
[edit] 
root@host# rollback rescue 
load complete 
 
[edit] 
root@host# commit 
commit complete
Configuração de interface 
O uso mais primário de uma interface é a conexão entre diferentes dispositivos de rede. No 
entanto, no Junos, algumas interfaces são definidas para exercer outras funções. 
qOs tipos de interfaces presentes no Junos são listadas a seguir:
 1 Interface de gerência: 
 2 Usada para conectar o roteador Juniper à uma rede de gerência. 
 2 A designação desse tipo de interface varia de acordo com a plataforma. 
 2 Alguns exemplos são “fxp0” e “me0”.
 1 Interfaces internas: 
 2 Usadas para conectar os planos de controle e de encaminhamento. 
 2 A designação desse tipo de interface varia de acordo com a plataforma. 
 2 Alguns exemplos são “fxp1” e “em0”.
 1 Interfaces de rede: 
 2 Usadas para prover conectividade de rede através de uma mídia específica. 
 2 Alguns exemplos de mídia são Ethernet, Sonet, ATM e T1. 
 1 Interface de loopback: 
 2 Interface lógica fixada no roteador, com diversas aplicações.
 1 Interfaces de serviços: 
 2 Usadas para prover um ou mais serviços: encriptação, tuneling, NAT etc. 
 2 Podem ser implementadas via hardware, através de um cartão específico que 
pode ser comprado e adicionado à caixa, ou via software. 
 1 Alguns exemplos de interfaces de serviço e suas respectivas designações:
 2 es: Interface de encriptação.
 2 gr: Interface de Túnel GRE (Generic Rout Encapsulation Tunnel Interface).
 2 ip: Interface de Túnel IP sobre IP.
 1 ls: Interface de link de serviço.
 2 ml: Interface Multilink.
 2 mo: Interface de Monitoramento Passivo.
141
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
q 2 mt: Interface de Túnel Multicast.
 2 sp: Interface de Serviços Adaptativos.
 2 vt: Interface virtual de loopback.
Nomeando interfaces
A figura a seguir apresenta os novos atores introduzidos: Interface, PIC (ou PIM) e FPC.
Exemplo de nome de interface:
ge-0/2/3 = porta 3 de um PIC gigabit Ethernet no slot 2 do FPC 0
A numeração da porta e do slot 
inicia em zero, ao invés de um (1).
Enquanto diferentesplataformas usam nomes
diferentes para os cartões
de linha e os cartões de 
interface, o CLI quase 
sempre usa FPC e PIC.
Line card 
FPC
Interface 
card PIC
PIC
PIC
PIC
Tipo de mídia da interface (ge, so, at, e assim por diante)
Número do slot do cartão de linha (FPC)
Número do slot do cartão de interface (PIC)
Número da porta
q 1 A interface é a porta de rede propriamente dita, onde será conectado um cabo que 
ligará o equipamento a outro nó da rede.
 1 A PIC (Physical Interface Card) ou PIM (Physical Interface Module) é um cartão insta-
lado no roteador, que contém um número determinado de interfaces. 
 1 A FPC (Flexible PIC Concentrator) compreende a porção do hardware do roteador 
onde as PICs são instaladas.
 1 As interfaces no Junos recebem nomes padronizados pelo sistema. 
 1 Os nomes são atribuídos com base no tipo de mídia da interface, no número do slot 
da caixa onde a FPC está encaixada, no número do slot da FPC onde a PIC está insta-
lada, e na posição da interface na PIC. 
Em alguns modelos Juniper, tipicamente nos equipamentos de entrada, o termo PIC é subs-
tituído por PIM (Physical Interface Module). A função de uma PIM é basicamente a mesma 
de uma PIC. As diferenças não serão abordadas aqui, de modo que, para os objetivos desse 
curso, os termos poderão ser intercambiáveis.
Tipicamente, o número do slot (seja da FPC ou da PIC) começa em zero. Analogamente, a pri-
meira interface de uma PIC é a interface zero. Esse número é incrementado de acordo com a 
configuração do hardware. A figura anterior exibe a nomeação de uma interface no Junos. 
A interface “ge-0/2/3” é a quarta interface de sua PIC. 
A PIC onde a interface se encontra é a terceira de sua FPC. A FPC é onde está a PIC, e a pri-
meira do roteador. Finalmente, a mídia da interface é gigabit ethernet. Juntando todas essas 
informações tem-se o nome da interface: ge-0/2/3.
Figura 9.2 
Interface, PIC e FPC.
142
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Interfaces que não são físicas não seguem essa convenção. Normalmente elas seguem uma 
sequência simples como: 0, 1, 2...
q 1 Cada interface física pode possuir uma ou mais interfaces lógicas (subinterfaces). 
 1 Criar subinterfaces é útil em ambientes onde se deseja criar conexões L2 como cir-
cuitos virtuais ou 802.1q. 
 1 Redes Frame Relay e ATM são exemplos de tecnologias que fazem uso de subinter-
faces. 
 1 Algumas tecnologias de encapsulamento suportam apenas uma única unidade lógica, 
como PPP e HDLC. No Junos essas tecnologias utilizam o descritor zero.
 1 O texto abaixo exibe um nome de uma subinterface da interface física ge-0/0/14.
ge-0/0/14.51
Em uma interface que utiliza a tecnologia de encapsulamento PPP, por exemplo, haveria 
apenas uma única interface, e seu identificador seria “.0”.
q 1 O identificador da subinterface e o identificador do circuito virtual L2 não precisam 
ser iguais. 
 1 Por exemplo, uma interface ge-1/1/1 poderia ter, por exemplo, dois DLCIs Frame Relay 
definidos (DLCI 8 e 9) e implementados nas interfaces “ge-1/1/1.20” e “ge-1/1/1.21”. 
Repare que os identificadores do exemplo não casam. No entanto, é boa prática usar o 
mesmo número identificador da subinterface e do circuito L2. Essa prática ajuda no 
troubleshooting e na melhor compreensão da rede.
Múltiplos endereços
q 1 A plataforma Junos permite que uma interface, física ou lógica, tenha mais de um 
endereço IP. 
 1 Para tal, basta executar dois comandos “set” de configuração de endereço. 
 1 Diferente do que se poderia pensar, ao executar um segundo comando “set” para o 
mesmo item de uma hierarquia de configuração, tipicamente o primeiro “set” não é 
desconsiderado, mas os dois comandos passam a valer. 
 1 Essa regra vale, por exemplo, para a configuração do endereço IP na interface.
 1 Se o usuário associa um endereço IP a uma interface (utilizando o comando “set”), 
e percebe que o endereço está errado e decide trocá-lo, pode usar o comando 
“rename”, e não um segundo comando “set”. 
O exemplo aqui descrito é ilustrado abaixo (comando “rename”):
[edit interfaces ge-0/0/1 unit 0]
user@host# set family inet address 10.1.1.1
[edit interfaces ge-0/0/1 unit 0]
user@host# show
family inet {
 address 10.1.1.1/32;
143
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
}
[edit interfaces ge-0/0/1 unit 0]
user@host# rename family inet address 10.1.1.1/32 to address 
10.1.1.1/24
[edit interfaces ge-0/0/1 unit 0]
user@host# show
family inet {
 address 10.1.1.1/24;
}
Outra opção seria retirar o endereço com um “delete” e em seguida colocar o novo IP com o 
comando “set” (não necessariamente nessa ordem).
Propriedades físicas de interfaces
qA lista seguinte mostra as diferentes configurações físicas que podem ser feitas nas interfaces:
 1 Protocolo de encapsulamento L2: pode ser, por exemplo, PPP, HDLC e Frame Relay, 
entre outros.
 1 Modo: em interfaces ethernet pode-se escolher entre modo duplex ou half duplex.
 1 Velocidade: configurável em certos tipos de mídia.
 1 MTU: o Maximum Transmission Unit pode variar o tamanho entre 256 e 9192 bytes.
 1 Clock.
 1 Scrambling: se refere ao embaralhamento do payload dos pacotes (esta funcionali-
dade pode estar ligada ou desligada).
 1 FCS: o Frame Check Sequence pode ser modificado para 32 bits (o default é 16).
Propriedades lógicas de interfaces
qA lista seguinte mostra as propriedades lógicas configuráveis nas interfaces:
 1 Família de protocolo: pode ser inet (para IPv4), inet6 (para IPv6), mpls (para MPLS) etc.
 1 Endereço: cada família configurada na interface tem um ou mais endereços lógicos.
 1 Identificador de circuito virtual: para links Frame Relay, ATM ou tag de VLAN.
 1 Outros: ARP inverso, traps SNMP, exportação de flows, QoS etc.
A hierarquia das configurações é organizada no arquivo de configuração:
interfaces {
 interface-name {
 physical-properties; 
 [...]
 unit unit-number {
144
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 logical-properties; 
 [...] 
 }
 }
}
Todas as interfaces têm esta mesma organização hierárquica. 
q 1 O Junos organiza todas as propriedades físicas debaixo do nome da interface. 
 1 O número de “unit” representa uma interface lógica (ou subinterface) particular. 
 1 O Junos organiza todas as configurações lógicas da interface debaixo da subinterface 
(unit) correspondente.
[edit] 
user@host# show interfaces
ge-0/0/2 {
 unit 0 { 
 family inet { 
 address 172.19.102.1/24;
 address 172.19.102.2/24 {
 preferred; 
 }
 }
 family inet6 { 
 address 3001::1/64;
 }
 }
}
lo0 {
 unit 0 {
 family inet {
 address 192.168.100.1/32;
 address 192.168.200.1/32; {
 primary; 
 }
 }
145
 
C
ap
ítu
lo
 9
 - 
Co
nfi
gu
ra
çõ
es
 d
o 
ro
te
ad
or
 }
}
Observe no código que uma “unit” pode suportar múltiplas famílias de protocolo, o que equi-
vale a dizer que uma subinterface (lógica) suporta vários protocolos de rede, como IPv4 e IPv6.
O código também mostra o uso dos comandos “preferred” e “primary”. A opção “preferred” 
é usada quando há múltiplos IPs de uma mesma sub-rede na mesma subinterface. Essa 
opção permite ao usuário selecionar o endereço que será usado como endereço de origem 
nos pacotes gerados pelo sistema para hosts locais na mesma sub-rede. Por default, se nada 
é definido pelo usuário, o sistema assume que o endereço com o menor valor será o prefe-
rido. No exemplo anterior, se o comando “preferred” não fosse usado, o endereço preferido 
seria o 172.19.102.1. Mas o comando sobrescreveu o comportamento default do roteador, e 
elegeuo 172.19.102.2 como o preferido.
O endereço primário de uma interface, definido pelo comando “primary”, é o endereço 
usado por default como o origem de broadcasts e multicasts que precisam ser enviados 
por aquela interface. Por default o endereço primário da interface é aquele com o menor 
número de endereços. No código anterior, o endereço primário default da interface “lo.0” 
seria 192.168.100.1, mas o comando “primary” sobrescreveu o comportamento default e 
elegeu 192.168.200.1 como endereço primário.
Verificando endereços Primário e Preferido:
user@host> show interfaces ge-0/0/2.0 | find addresses
Addresses, Flags: Is-Primary
Destination: 172.19.102/24, Local: 172.19.102.1,
Broadcast: 172.19.102.255
Addresses, Flags: Preferred Is-Preferred
Destination: 172.19.102/24, Local: 172.19.102.2,
Broadcast: 172.19.102.255
Protocol inet6, MTU: 1500
Flags: Is-Primary
Addresses, Flags: Is-Default Is-Preferred Is-Primary
Destination: 3001::/64, Local: 3001::1
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::217:cbff:fe4e:ab02
Verificando o estado das interfaces
q 1 Para verificar o estado das interfaces do roteador de forma rápida, utiliza-se o 
comando “show interfaces terse”. 
 1 Para verificar o estado de uma única interface particular, pode-se passar o nome da 
interface desejada como parâmetro para o comando. 
146
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
user@host> show interfaces terse ge-O/O/2 
interface Admin Link Proto Local Remote 
ge-O/O/2 up up 
ge-0/0/2.0 up up inet 10.15.173.1/28 
 172.19.102.1/24 
 inet6 3001::1/64 
 
fe80::217:cbff:fe4e:a282/64
147
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
Roteiro de Atividades 5
Atividade 5.1 – Configuração básica (parte 1)
1. Alterar o hostname;
Para se alterar o nome do roteador você deverá utilizar o comando “hostname”. Ele deve ser 
executado a partir do [edit system] da árvore do arquivo de configuração Junos, ou como 
alternativa pode-se chamar o comando “set” a partir do [edit], no topo da árvore do arquivo 
de configuração.
root# set system host-name ROT”X”
[edit]
2. O comando “commit”:
Uma vez definida a senha de root, basta executar o comando “commit”. Ao executar esse 
comando, toda a configuração definida pelo comando “set” e que se encontra no arquivo de con-
figuração candidata será aplicada para o modo de execução, ou seja, essa configuração valerá 
a partir deste momento. Mas antes de aplicar essa configuração, o Junos faz uma verificação 
prévia no intuito de encontrar erros de sintaxe. Um recurso bastante utilizado é o comando 
“compare” em conjunto com o comando “show”. Com estes dois comandos associados, pode-se 
fazer uma análise entre o que é configuração candidata e o que é configuração atual.
A linha que inicia com o sinal “-” indica a configuração que será deletada após o “commit”. Já a 
linha que inicia com o sinal “+” indica as configurações que serão aplicadas após o “commit”.
root@bancadaX# show | compare
[edit system]
- host-name bancadaX;
+ host-name teste;
[edit]
Outro recurso interessante do comando “commit” é a utilização do parâmetro “comment”. 
Seguida desse parâmetro, pode-se inserir uma descrição do que será comitado a partir de agora.
root@bancadaX# commit comment “alteracao do ip da interface ge-
0/0/0 conforme chamado 7001”
3. O comando “rollback”
Outro recurso interessante do Junos é a possibilidade de fazer rollback de configurações. 
Este recurso pode auxiliar o administrador caso ele tenha efetuado alguma configuração 
errada, ou até mesmo caso seja necessário restaurar uma configuração de uma data especí-
fica. O Junos pode guardar até 50 configurações aplicadas com o comando “commit”. 
148
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
4. Para verificar os “commits” realizados no seu sistema basta digitar o comando:
root@bancadaX# run show system commit
0 2011-01-19 12:27:36 UTC by root via cli
 alteracao do ip da interface ge-0/0/0 conforme chamado 7001
1 2011-01-19 11:32:18 UTC by root via cli
2 2011-01-19 02:40:15 UTC by root via cli
3 2011-01-19 02:37:17 UTC by root via cli
4 2011-01-05 20:39:27 UTC by root via cli
5 2010-12-23 23:27:10 UTC by root via cli
6 2010-12-23 23:26:14 UTC by root via cli
7 2010-12-23 23:25:11 UTC by root via cli
8 2010-12-23 23:19:18 UTC by root via cli
9 2010-12-18 01:01:36 UTC by root via button
Com a informação dos “commits” realizados no seu sistema, pode-se restaurá-lo a partir do modo 
de configuração com o comando “rollback” seguido do ID do “commit” que se deseja restaurar.
O ID “0” representa a configuração atual do seu sistema. Já o ID “1” representa a 
penúltima configuração válida do seu sistema.
root@bancadaX# rollback ?
Possible completions:
 <[Enter]> Execute this command
 0 2011-01-19 12:27:36 UTC by root via cli
 1 2011-01-19 11:32:18 UTC by root via cli
 2 2011-01-19 02:40:15 UTC by root via cli
 3 2011-01-19 02:37:17 UTC by root via cli
 4 2011-01-05 20:39:27 UTC by root via cli
root@bancadaX# rollback 1
load complete
[edit]
Após executar o comando “rollback”, deve-se executar o comando “commit” para que as 
configurações restauradas tenham efeito.
root@bancadaX# commit
commit complete
[edit]
149
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
Atividade 5.2 – Configuração básica (parte 2)
1. Trabalhando com o redirecionador PIPE;
Um recurso interessante do Junos é o redirecionar PIPE. Com ele pode-se redirecionar a 
saída padrão de um comando para a entrada padrão de outro comando, a exemplo dos 
sistemas Unix.
Numa circunstância em que se precise filtrar a saída padrão do comando “show interfaces 
terse”, por exemplo, basta usar o respectivo comando com o redirecionador PIPE seguido 
do comando “match”, como exibido abaixo.
root@bancadaX> show interfaces terse | match ge-0/0/0
ge-0/0/0 up down
ge-0/0/0.0 up down inet 192.168.1.1/30
Neste exemplo, filtramos somente o status da interface ge-0/0/0.
2. Trocando a senha de root;
Quando se utiliza o comando “set”, estamos atualizando um arquivo chamado de “candidate 
configuration” ou configuração candidata. Portanto, essas atualizações não surtirão efeito 
antes de se executar o comando “commit”, que será explanado na próxima atividade.
Uma premissa para se executar o comando “commit” é definir uma senha para o usuário 
root, já que ela não é definida quando o equipamento vem com as configurações de fábrica. 
Para se definir uma senha para o usuário root, basta digitar o comando:
root@bancadaX# set system root-authentication plain-text-password
New password:
Nesse momento o Junos solicitará o fornecimento da senha e sua confirmação.
3. Manipulando arquivos e diretórios no Junos;
O Junos possibilita a manipulação de arquivos e diretórios armazenados na flash do equipa-
mento Juniper. Para manipular arquivos e diretórios basta utilizar o comando “file” a partir do 
modo de operação. Uma informação muito útil para manipulação de arquivos e diretórios é 
saber o caminho que se encontra na estrutura de diretório do sistema de arquivos (filesystem).
Para saber o caminho que se encontra na estrutura de diretório do filesystem, basta executar 
o comando “show cli directory” a partir do modo operação. Com a informação do caminho em 
que se encontra, é possível listar os arquivos e diretórioscom o comando “file list”.
root@bancadaX> file list
/cf/root/:
.cshrc
.history
.login
.profile
150
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
.ssh/
backup.txt
conf_17-12-2010
conf_display_set
novo
snmp
teste.txt
ttyp1
Para verificar o conteúdo do arquivo “.login”, que se encontra no diretório “/cf/root”, basta 
utilizar o comando:
root@bancadaX> file show .login
4. Saindo do modo de configuração do Junos;
Para sair do modo configuração, basta digitar o comando “exit”:
glenio@bancadaX# exit
Exiting configuration mode
5. Entrando no modo Shell no Junos;
No Junos, cada usuário de sistema pode ter acesso ao shell do Unix, onde está disponível a 
maioria dos comandos já conhecidos no mundo Unix. Para ter acesso ao shell, basta chamar 
o comando “start shell”, a partir do modo operação.
root@bancadaX> start shell
%
Se o comando tiver sido realizado com sucesso, o prompt de comando mudará, indicando 
assim que você está no shell do Unix.
6. Verificando comandos do Unix;
Agora pode-se verificar alguns comandos do Unix, como, “pwd”, “ls”, “top”, “cd”.
Caso seja necessário voltar para o modo de operação do Junos, basta utilizar o comando “cli”. 
% cli
glenio@bancadaX> 
151
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
Configurações de Usuário e Autenticação
Há duas opções de configurações para acesso de usuário: autenticação local ou autenti-
cação centralizada (usando solução de RADIUS ou TACACS+).
RADIUS or
TACACS+ server
Local authentication
database
Quando se usa autenticação local, as senhas e nomes de usuário são criadas e armazenadas 
em um banco de dados do próprio sistema Junos. 
As seguintes condições são impostas pelo sistema:
 1 As senhas precisam ter um mínimo de 6 caracteres;
 1 As senhas precisam conter pelo menos um metacaractere ou letra maiúscula. 
Quando um usuário é criado no Junos, automaticamente é gerado um diretório “home” 
para ele, como ocorre para os sistemas Unix. Esse diretório serve como um diretório default 
de trabalho para cada usuário localmente definido. O diretório local de trabalho pode ser 
modificado durante uma sessão usando o comando de modo de operação “set cli directory 
<nome do diretório>”.
A opção de autenticação centralizada no Junos pode ser implementada utilizando soluções 
de RADIUS ou TACACS+. Ambos definem uma aplicação cliente-servidor onde os usuários e 
senhas são definidos no servidor. Softwares clientes de RADIUS ou TACACS+ são executados 
no Junos, enquanto o servidor é executado em um hardware remoto da rede.
Essa solução de autenticação remota permite que múltiplos usuários definidos no RADIUS 
ou no TACACS+ sejam mapeados para um template de conta de usuário definido localmente.
Ordem da autenticação
O Junos pode ser configurado para ser um cliente de RADIUS e de TACACS+. A diferença 
entre esses métodos não será tratada neste curso.
É possível priorizar a ordem que o software usará para tentar autenticar o usuário. Dessa 
forma, para cada tentativa de login, o Junos tentará mais de um método de autenticação 
na ordem especificada, até que a autenticação possa ser efetuada. O método seguinte será 
tentado sempre que o método anterior falhar ou rejeitar o acesso do usuário. Só no caso de 
nenhum dos métodos funcionar, o acesso do usuário será negado. 
Figura 9.3 
Autenticação de 
Usuário Junos.
152
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Se nenhum dos métodos de acesso responder (com aceite ou rejeição), o Junos tentará como 
último recurso autenticar o usuário utilizando a base local.
Para verificar a ordem dos métodos de autenticação no modo de configuração, use o 
comando: 
show system authentication-order 
A seguir observamos um exemplo do processo de autenticação e a execução desse 
comando a partir da raiz da hierarquia de configuração do sistema “[edit]”. 
Local authentication 
database
Username = lab 
Password = lab789
Step 1 (lab, lab789)
Step 8 ACCEPT
Ste
p 2
 (la
b, l
ab7
89)
Ste
p 3
 RE
JEC
T
Step 4 (lab, lab789)
Step 5 REJECT
Step 6 (lab, lab789)
Step 7 ACCEPT
RADIUS server 
Username = lab 
Password = lab123
TACACS+server 
Username = lab 
Password = lab456
A configuração da ordem de autenticação pode ser feita com o comando a seguir na raiz da 
hierarquia do modo de configuração: 
set system authentication-order [...] 
Dentro dos colchetes devem ser colocadas as palavras-chave na ordem desejada. Exemplo:
set system authentication-order [radius password]
Para configurar um sistema RADIUS remoto, utilize o comando a seguir na raiz da hierarquia 
do modo de configuração: 
set system radius-server <IP do RADIUS> secret <senha> 
O parâmetro “secret” define um valor usado pelo RADIUS para validar a identidade do rote-
ador.
Para verificar a configuração de RADIUS usa-se o comando “show system radius-server”:
[edit system]
user@host# show radius-server
Figura 9.4 
Ordem de 
autenticação.
153
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
172.18.102.13 secret “$9$9ZKntpBvMX7Nb1RcleW-dbs2gaU”; ## SECRET-DATA
A configuração do TACACS+ é análoga. Para tal use o comando a seguir na raiz da hierarquia 
do modo de configuração: 
set system tacplus-server <IP do TACACS> secret <senha>
O parâmetro “secret” permite que o TACACS+ possa validar a identidade do roteador. Para 
verificar a configuração de TACACS+ usa-se o comando “show system tacplus-server”:
[edit system]
user@host# show tacplus-server
172.17.32.14 secret “$9$m5T31Icyrvn/A0ORlevWLXNb”; ## SECRET-DATA
O usuário “lab”, utilizado no primeiro exemplo desse tópico, está definido também no banco 
de dados local de usuários. A seguir uma forma de verificar a existência desse usuário local:
[edit system]
user@host# show login user lab
class super-user;
authentication {
encrypted-password “$1$dJ3NA9BW$nZGLZAp9kpiG52kru34IT.”; ## SECRET-
DATA
}
A seguir um exemplo de mudança de ordem do método de autenticação. O administrador 
do sistema não quer mais que a base de usuários locais seja usada. Para tal, a opção 
“password” foi retirada do comando “set system authentication-order [...]”.
[edit] 
user@host# show system authentication-order 
authentication-order [ radius tacplus ]; 
154
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Local authentication 
database
Username = lab 
Password = lab789
Step 1 (lab, lab789)
Step 6 REJECT
Ste
p 2
 (la
b, l
ab7
89)
Ste
p 3
 RE
JEC
T
Step 4 (lab, lab789)
Step 5 REJECT
RADIUS server 
Username = lab 
Password = lab123
TACACS+server 
Username = lab 
Password = lab456
[edit]
user@host# show system authentication-order
authentication-order [ radius tacplus ];
Na figura anterior o usuário tentou fazer login no sistema usando a senha “lab789”, que 
difere das senhas definidas no RADIUS e no TACACS+. O sistema tenta fazer autenticação via 
RADIUS, sem sucesso. Em seguida tenta autenticação via TACACS+, sem sucesso novamente. 
Nesse caso o sistema não consultará a base local como último recurso, pois essa opção foi 
excluída da lista de recursos de autenticação, e pelo menos um dos recursos listados 
respondeu (se a conexão com o RADIUS e com o TACACS+ tivesse falhado, a base local seria 
usada como último recurso). O acesso do usuário é negado.
A próxima figura mostra o equipamento com a mesma ordem de autenticação configu-
rada no exemplo anterior. No entanto, o servidor RADIUS está desligado, e o TACACS+ está 
inacessível devido a um problema de rede. Ao tentar consultar cada um desses recursos o 
sistema aguardará a expiraçãode um período de time-out. Passado esse tempo o sistema 
remoto será considerado inacessível.
Figura 9.5 
Ordem de 
autenticação sem 
opção “password”.
155
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
Local authentication 
database
Username = lab 
Password = lab789
Step 1 (lab, lab789)
Step 6 ACCEPT
Ste
p 2
 (la
b, l
ab7
89)
Step 3 (lab, lab789)
Step 4 (lab, lab789)
Step 5 ACCEPT
RADIUS server 
Username = lab 
Password = lab123
TACACS+server 
Username = lab 
Password = lab456
Repare que no exemplo, como nenhum dos recursos listados no parâmetro “authetication-order” 
respondeu, a base local será usada. Esse comportamento evita a situação indesejável de 
um equipamento ficar inacessível quando ocorre uma falha dos servidores centralizados 
de autenticação.
Componentes da autenticação
q 1 Cada comando do modo de operação e do modo de configuração está sujeito à 
aprovação pelo processo de autenticação do sistema. 
 1 O mesmo vale para os recursos da interface J-Web. 
 1 Todos os usuários estão sujeitos às vontades desse processo, à exceção do usuário 
“root”, que tem poder incondicional.
 O perfil de acesso do usuário “root” não pode ser modificado. Por esse motivo é funda-
mental proteger a senha desse usuário.
A figura seguinte introduz as entidades lógicas usadas no processo de autenticação de cada 
comando aplicado por um usuário. Cada um desses atores é explicado a seguir.
allow-commands
allow-configuration
user Class Permissions
deny-commands
deny-configuration
Authorized
or Denied
User
qUm usuário (user) é um membro de uma classe (class). 
Ao utilizar autenticação remota é possível mapear múltiplos logins do TACACS a um mesmo 
“user” do Junos.
Figura 9.6 
Ordem de 
autenticação: 
servidores de 
autenticação 
indisponíveis.
Figura 9.7 
Entidades lógicas 
envolvidas no 
processo de 
autenticação.
156
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Class 
q 1 Uma classe (class) define um conjunto de flags de permissão. 
 1 É possível configurar ou customizar classes. 
 1 O sistema traz quatro classes pré-definidas que podem contemplar a maioria das 
situações desejadas. 
 1 Essas classes e suas respectivas flags de permissão estão listadas a seguir:
 2 super-user: permissão total.
 2 unauthorized: nenhuma permissão.
 2 operator: “clear”, “network”, “reset”, “trace” e “view”.
 2 read-only: “view”.
Permission
qUma permissão (permission) é uma flag associada a um privilégio. Pode-se entender uma 
“permission” como um conjunto de comandos pertinentes a uma determinada tarefa. 
Algumas das permissões que já vêm configuradas no sistema são listadas a seguir:
 1 access: permite ver as configurações de acesso.
 1 access-control: permite modificar as configurações de acesso.
 1 admin: permite ver configurações de contas de usuário.
 1 admin-control: permite modificar configurações de contas de usuário.
 1 all: permissão total.
 1 clear: permite limpar informações aprendidas da rede.
 1 configure: permite acesso ao modo de configuração.
 1 control: permite modificar qualquer configuração.
 1 field: reservada para o suporte Juniper.
 1 firewall: permite ver as configurações de firewall.
 1 firewall-control: permite alterar as configurações de firewall.
 1 floppy: permite ler e escrever informações no drive de floppy.
 1 interfaces: permite ver as configurações de interface.
 1 interface-control: permite modificar as configurações de interface.
 1 rollback: permite a execução do comando “rollback <n>” com “n > 0”.
 1 reset: permite fazer reset em interfaces e processos do sistema.
 1 view: permite ver estatísticas do sistema.
 1 view-configuration: permite ver toda a configuração do sistema. 
Algumas permissões são configuráveis. A lista de permissões que o usuário pode customizar 
varia de plataforma para plataforma.
Comandos extras Allow e Deny
qAlém de associar um “user” a uma “class”, é possível incluir uma ordem específica para o 
sistema permitir ou negar um determinado comando de maneira avulsa, independente 
do que dizem as flags presentes nas “permissions” da “class”. 
A configuração seguinte mostra um exemplo desse tipo de opção.
157
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
[edit system login] 
root@host# show 
class noc-admin { 
 permissions [ clear network reset view ] ; 
 allow-commands “(configure private)” ; 
 deny-commands “(file)” ; 
 allow-configuration “(interfaces) | (firewall)”; 
 deny-configuration “(groups)”;
} 
user nancy { 
 uid 2002; 
 class noc-admin; 
 authentication { 
 encrypted-password “SlSKQXKa/VQSijv77wxLnyf7XRI.1IbTqO”; ## 
SECRET-DATA 
 } 
} 
q 1 No exemplo acima o administrador definiu que a usuária Nancy estará associada à 
classe “noc-admin”. 
 1 As permissões “clear”, “network”, “reset” e “view” foram associadas a esta classe.
 1 Adicionalmente o administrador gostaria que os usuários da classe “noc-admin” 
fossem capazes de ver as configurações, mas apenas de interface e de firewall. 
 1 Para tal, o primeiro passo foi liberar o comando (avulso) “configure private”. 
 1 Esse comando foi adicionado à lista de tarefas que o usuário pode fazer. 
Essa configuração foi adicionada com o “allow-commands”, aplicado sob a hierarquia de 
configuração da “class”, ou seja, “[edit system login class noc-admin]”.
q 1 Em seguida o administrador usou, sob a mesma hierarquia de configuração, o 
comando “allow-configuration”, o qual adiciona ao usuário os privilégios associados 
às permissões “interfaces” e “firewall”. 
 1 A partir de então, a usuária Nancy poderá entrar no modo de configuração e ver as 
configurações das hierarquias “[edit interfaces]” e “[edit firewall]”.
 1 Além disso, o administrador prefere garantir que os usuários da classe “noc-admin” 
não serão capazes de manipular arquivos. 
 1 Para tal, o comando “file” foi excluído da lista de comandos permitidos. 
Essa ação foi feita com o comando “deny-commands”, aplicado à hierarquia de configuração 
da classe.
158
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Finalmente, o administrador usou o comando “deny-configuration” para garantir que os usu-
ários da classe em questão não terão acesso aos privilégios da permissão “groups”, e dessa 
forma não poderão ver as configurações da hierarquia “[edit groups]”.
Logs do sistema
O sistema de log do Junos usa os mesmos princípios do mecanismo de log usado pelos 
sistemas Unix. 
q 1 Esse sistema grava mensagens gerais sobre a operação do Junos, tais como interfaces 
que saem de operação ou usuários que tentam fazer login e não conseguem. 
 1 O Junos grava as mensagens de log em arquivos que ficam armazenados no diretório 
“/var/log”. 
 1 O arquivo de log primário, definido pela configuração que vem de fábrica, é o “/var/
log/messages”. 
 1 As mensagens de log podem trazer uma grande variedade de eventos. 
 1 Cada evento possui alguns parâmetros que o caracterizam. 
 1 Por exemplo: severidade (severity) e facilidade (facility).
 1 A facilidade é listada na frente do evento, e define a classe da mensagem. 
 1 A severidade vem em seguida, e determina a gravidade do evento reportado.
 1 As mensagens de log podem ser gravadas em arquivo (/var/log/messages) ou em 
um servidor remoto (servidor de syslogs), o que é recomendado dado o perigo de se 
perder o arquivo local em um grande evento de falha.
Observamos a seguir exemplos de configuração de syslogs: 
[edit system syslog]
user@host# show
user * } #Mensagens de emergência para todos usuários logados 
(*)
host 10.210.14.174 { #Registra em um host remoto
 any notice;authorization info;
}
file messages { #Arquivo primário syslog (*)
 any any;
 authorization info;
}
file interactive-commands { #Registra todos os comandos CLI (*)
 interactive-commands any;
}
file config-changes { #Registra mudanças na configuração
159
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
 change-log info;
}
(*)indica a configuração padrão de fábrica
qAs configurações de syslogs ficam na hierarquia “[edit system syslog]” e em 
“[edit routing-options options syslog]”. Algumas opções de syslog:
 1 “host <nome>” ou “host <IP>”: especifica o servidor de syslog para o qual deverão ser 
enviadas as mensagens de log.
 1 archive: especifica a política de armazenamento dos arquivos de log. O default é 
manter 10 arquivos com tamanho máximo de 128 KB.
 1 console: seleciona alguns tipos de mensagem para mostrar no terminal de console do 
sistema.
 1 facility: mostra a classe das mensagens.
 1 severity: mostra o nível de gravidade das mensagens de log.
 1 file <nome>: especifica o nome do arquivo de log.
 1 files <número>: especifica o número máximo de arquivos que serão mantidos.
Interpretando mensagens de log
Se o usuário utiliza o formato default de fábrica, as mensagens de log são registradas como 
no exemplo abaixo:
Jul 27 10:48:37 host mgd[4350]: UI_DBASE_LOGOUT_EVENT: User ‘user’ 
exiting configuration mode
Esse formato traz:
q 1 “timestamp”: horário do evento.
 1 “hostname”: nome do sistema.
 1 “process name”: nome do processo que gerou a mensagem.
 1 “message code”: identifica a natureza e o propósito da mensagem. No exemplo o 
código da mensagem é “UI_DBASE_LOGOUT_EVENT”.
 1 “message-text”: provê informações adicionais sobre o código da mensagem.
A opção “explicit-priority” nas configurações de syslog altera o formato default das mensa-
gens de log, que passam a exibir um valor numérico que representa a gravidade do evento. 
Na escala de severidade do Junos, o valor zero representa os eventos mais graves, ao passo 
que o valor 7 (sete) indica as mensagens informativas (menos graves).
Em qualquer tipo de equipamento, de qualquer fabricante, nem sempre é tarefa simples 
interpretar os campos das mensagens de log. Pensando nisso, os desenvolvedores do Junos 
disponibilizaram um “help” local, que ajuda a entender os eventos reportados. 
Abaixo um exemplo de uso do comando de modo de operação “help syslog <message code>”:
user@host> help syslog UI_DBASE_LOGOUT_EVENT 
Name: UI_DBASE_LOGOUT_EVENT 
160
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Message: User ‘<username>’ exiting configuration mode 
Help: User exited configuration mode 
Description: The indicated user exited configuration mode (logged 
out of the configuration database). 
Type: Event: This message reports an event, not an error 
Severity: notice 
Pela descrição da mensagem acima, percebe-se que o usuário “user” deixou o modo de 
configuração. Trata-se de uma mensagem informativa.
Investigando problemas com traceoptions
q 1 “Traceoptions” é o termo que a Juniper usa para o recurso que outros fabricantes 
chamam de “debug”. 
 1 Na maioria dos casos, quando se habilita uma “traceoption”, um arquivo de “trace” é 
criado para armazenar informações sobre um protocolo ou operação específica. 
 1 O Junos enviará os resultados da operação de “trace” para o arquivo criado para esse fim.
 1 Esse arquivo ficará guardado no diretório “/var/log”, como os arquivos de log, ou será 
enviado para um servidor remoto. 
Para especificar um servidor de syslog remoto para receber as mensagens de “tracing”, 
deve-se configurar o seu endereço IP na hierarquia: “[edit system tracing]”. A seguir um 
exemplo dessa configuração de servidor para receber arquivos de “tracing”:
[edit system tracing]
user@host# show
destination-override syslog host 1.1.1.1;
Diferente de outros sistemas, devido ao design do Junos, é possível habilitar “traceoptions” 
com grande nível de detalhamento em uma rede de produção sem impacto significante na 
performance do sistema. Apesar disso, é recomendável sempre desabilitar as “traceoptions” 
assim que seu uso não for mais necessário.
qPara investigar a operação de um determinado protocolo utilizando “traceoptions”, deve-se 
utilizar o comando “traceoptions” na hierarquia “[edit protocols <nome do protocolo>]”.
Na maioria dos casos o administrador será seletivo, pois habilitando todo tipo de mensa-
gens, um volume muito grande de informações é gerado. Para habilitar todo tipo de infor-
mação utiliza-se a palavra-chave “all”.
[edit protocols ospf] 
user@host# show
 
traceoptions { 
 file ospf-trace replace size 128k files 10 no-stamp no-world-
readable; 
 flag event detail; 
161
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
 flag error detail; 
} 
A amostra de configuração exibida reflete um exemplo típico de investigação da operação 
do protocolo OSPF. No exemplo, o administrador solicitou informações de erros e de 
eventos. Não foi usada a opção “all”. Ao invés disso, foi usada a opção “detail”, bastante fun-
cional em casos de troubleshooting.
Abaixo seguem alguns parâmetros que podem ser configurados quando se faz uso 
de “traceoptions”.
 1 file <nome>: especifica o nome do arquivo que armazenará as informações.
 1 size <tamanho>: determina o tamanho máximo de cada arquivo gerado em kilobytes, 
megabytes ou gigabytes. Quando um arquivo nomeado “ospf-trace” atinge esse tamanho, 
ele é renomeado para “ospf-trace.0”, e as informações mais recentes passam a ser 
registradas no novo arquivo “ospf-trace”. Quando o novo arquivo “ospf-trace” atinge seu 
tamanho máximo, ele é renomeado para “ospf-trace.0”, ao passo que o “ospf-trace.0” é 
renomeado para “ospf-trace.1”. E um novo arquivo “ospf-trace” é gerado...
 1 files <número>: especifica o número máximo de arquivos de “trace” que podem existir.
 1 no-stamp: previne que o “timestamp” das mensagens seja colocado no início de cada 
registro, como ocorre no comportamento default do equipamento.
 1 replace: troca um arquivo de “trace” existente, caso um arquivo de “trace” com o nome 
especificado já exista. Por default, se essa opção não é usada, as novas informações 
serão “apendadas” no arquivo existente.
 1 readable: permite que qualquer usuário veja o arquivo.
 1 no-world-readable: permite que o arquivo gerado seja lido apenas pelo usuário que 
programou a sua geração. Por default, se a opção “readable” não é usada, essa opção 
estará habilitada.
q 1 Além de investigar protocolos, as “traceoptions” permitem investigar recursos 
do sistema.
 1 Por exemplo, o comando “traceoptions” poderia ser utilizado abaixo da hierarquia 
“[edit interfaces <nome da interface>]”. Nesse caso, os eventos ou erros referentes a 
uma determinada interface da caixa seriam armazenados no arquivo de “trace”. 
 1 Analogamente, é possível investigar os erros e eventos relacionados a determinados 
processos do sistema.
 1 Se ninguém remove ou desabilita as flags de “trace”, a atividade continua ocorrendo 
em background, e os arquivos de “trace” continuam sendo gerados. 
 1 Os arquivos continuam no disco indefinidamente até que sejam removidos ou sobres-
critos por algum usuário. 
 1 Para desabilitar todas as “traceoptions” de uma hierarquia particular, executa-se o 
comando “delete traceoptions” sob a hierarquia desejada.
 1 Para apagar um arquivo de “trace” criado, utilize o comando do modo de operação: 
“file delete <nome>”.
162
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
qHá ainda outras operações que podem ser feitas nos arquivos com os comandos 
(autoexplicativos):1 file compare
 1 file copy
 1 file list
 1 file rename
Visualizando arquivos de log e trace
qPara ver, via CLI, as informações armazenadas nos arquivos de log do Junos (não o shell 
de Unix) utiliza-se o comando “show log”. 
A seguir exemplos de utilização do comando com opções de filtragem:
user@host> show log messages | match “support info” 
May 31 23:49:16 host mgd[2711J: %INTERACT-6-UI_CMDLINE_READ_LINE: 
User ‘user, command ‘request support information’ 
 • Use multiple instances to evoke a logical AND search: 
user@host> show log messages | find “Apr 1 09:” | match error 
 • Use quotes to evoke a logical OR search: 
user @host> show log messages | match “error|kernel|panic”
Assim como ocorre nos sistemas Unix, os comandos cuja saída consomem mais de uma tela 
são apresentados de maneira pausada. 
q 1 O caractere “|” (pipe) é utilizado da mesma forma que nos sistemas Unix. 
 1 Esse comando permite que a saída de um comando possa ser usada como entrada de 
um segundo comando. 
No exemplo, o comando “match <string>” exibe as linhas da saída do comando anterior, que 
contêm a “string” especificada. Esse recurso é particularmente importante no dia a dia, quando 
se deseja procurar por um tipo de mensagem específica no meio dos registros do sistema.
Conforme mostra o exemplo, os comandos separados por “|” podem ser cascateados em 
vários pedaços. Dessa forma, é possível, por exemplo, filtrar uma saída que já foi filtrada. 
Esse cascateamento permite combinar a busca com lógica AND e OR, conforme mostrado.
Monitorando arquivos de log e trace
q 1 Para acompanhar as mensagens que estão sendo escritas nos arquivos de log ou de trace, 
usa-se o comando do modo de operação “monitor start <nome do arquivo monitorado>”.
 1 Esse comando funciona de maneira análoga ao “tail -f” dos sistemas Unix.
163
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
q 1 É possível monitorar o incremento de vários arquivos diferentes executando o “monitor 
start” várias vezes e variando o parâmetro “<nome do arquivo monitorado>”. 
 1 O Junos mostrará na tela as linhas novas que aparecerem nos arquivos monitorados, 
em tempo real.
Cada linha exibida na tela trará o nome do arquivo monitorado, para que se possa diferen-
ciar as mensagens. Para verificar os arquivos que estão sendo monitorados é utilizado o 
comando do modo de operação “monitor list”.
Para usar o comando “monitor start” em um arquivo, o usuário precisa ter permissão de 
leitura ao arquivo especificado. 
Em muitas situações o usuário está interessado em monitorar em tempo real apenas algum 
tipo particular de mensagem. 
q 1 Pode-se utilizar a opção “match” para filtrar as mensagens apresentadas durante 
a monitoração. 
 1 Abaixo observamos uma situação na qual o usuário deseja ver em tempo real apenas 
as mensagens de log que contenham a string “fail”.
user@host> monitor start messages | match fail
 1 Para encerrar a monitoração utiliza-se o comando “monitor stop”. 
 1 Este comando, quando usado sem nenhuma opção, faz cessar todas as monitorações 
correntes. 
 1 Para certificar-se de que o término da monitoração realmente ocorreu, sempre utilize 
o “monitor list”.
Network Time Protocol (NTP)
q 1 Usa-se o NTP para sincronizar o horário de equipamentos de rede com uma fonte. 
 1 Um servidor de NTP. Essa operação é útil para se garantir que os “timestamps” dos 
arquivos de “log” dos diferentes equipamentos estão com a mesma referência de 
horário, beneficiando as atividades de investigação de problemas.
O NTP é baseado em uma série de hierarquias de servidores de informação de tempo. 
O servidor Stratum1, que marca hora com um relógio atômico, é a fonte de relógio que 
está no topo da cadeia. Se a informação de horário não é crítica para as aplicações da 
instituição, não é necessário obter a informação de tempo junto ao Stratum1. Tipicamente 
a instituição utiliza um servidor Unix ou Windows que serve como a referência de tempo 
para os demais equipamentos.
Em relação ao protocolo NTP, o Junos suporta os modos assimétrico, cliente e servidor, e 
também pode suportar broadcast e autenticação. É uma boa prática de segurança utilizar a 
autenticação, para evitar que um atacante malicioso não comprometa a sincronização dos 
sistemas. A seguir uma configuração típica de NTP no Junos:
[edit system ntp] 
user@host# show 
boot-server 
10.210.14.173; 
server 10.210.14.173; 
164
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Duas máquinas podem se sincronizar apenas quando seus relógios estão 
relativamente próximos. 
 1 Por default, se a diferença de horário entre o equipamento local e o servidor de NTP 
é maior que 128 milisegundos, os relógios são gradualmente sincronizados. Se a dife-
rença é maior que 1000 segundos, os relógios não são sincronizados.
 1 A opção de “boot server” (usada no exemplo anterior) pode ser usada para configurar 
o horário do sistema no momento do “boot”.
Monitorando o NTP
A seguir a saída do comando “show ntp associations”, que exibe o status corrente da sincro-
nização:
[edit] 
user@host# run show ntp associations 
remote refid st t when poll reach delay offset 
jitter 
*10.210.14.173 10.210.8.73 4 u 63 64 377 0.268 -24.258 
7.290 
 1 O símbolo exibido perto do “hostname” indica o estado dos equipamentos envolvidos no 
processo de sincronização. 
 1 O símbolo asterisco (*) indica que o elemento ao lado foi selecionado para sincronização.
 1 Outros símbolos podem aparecer na saída para indicar outros estados. O símbolo que 
deve aparecer em situação normal é o asterisco.
 1 Outros detalhes da sincronização ficam disponíveis na saída do comando “show ntp 
status”.
Simple Network Management Protocol (SNMP)
q 1 Protocolo de gerenciamento padrão da arquitetura TCP/IP, que tem como objetivo 
gerenciar equipamentos de rede. 
 1 Cada equipamento gerenciado roda um software agente. 
 1 A Central de Gerenciamento roda o software gerente, e o agente envia informações 
para a central. 
 1 O agente também responde a solicitações de informação geradas pela central.
Dispositivos executando o Junos podem agir como um agente SNMP. Um agente SNMP troca 
informações de gerência de rede com um SNMP manager, executado em um equipamento 
remoto, chamado Network Management System (NMS).
Agent
(device running JUNOS Software)NMS Poll
Response
Figura 9.8 
SNMP: Manager 
e Agente.
165
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
O agente responde a solicitações de informação geradas pelo manager. Um agente se comu-
nica com o manager usando os seguintes tipos de mensagem:
 1 Get, Getbulk e Getnext: o manager SNMP requisita informações do agente, que responde 
com um “get response”.
 1 Set: o manager SNMP altera valores da MIB SNMP (Management Information Base) do 
agente. O agente confirma a operação com uma mensagem de “set response”.
 1 Trap: o agente SNMP envia mensagens (traps) de notificação ao manager, que não foram 
previamente solicitadas pelo manager. Elas são geradas proativamente pelo agente para 
reportar informações que considera importantes.
A atividade de solicitar informações aos agentes SNMP, que é executada pelo NMS da rede, 
chama-se “polling SNMP”.
MIBs SNMP
Uma MIB é uma coleção de objetos mantidos pelo agente SNMP em uma base de dados hie-
rárquica. O manager SNMP consegue visualizar ou mesmo alterar (em alguns casos) objetos 
da estrutura da MIB do agente.
Parte das MIBs de todos os equipamentos é padronizada pela Internet Engineering Task 
Force (IETF). Isso significa que alguns objetos podem existir em qualquer dispositivo, inde-
pendente do fabricante. Existe, porém,uma porção da MIB chamada “enterprise”. Nessa 
porção cada fabricante está livre para criar seus próprios objetos. 
Cada objeto é identificado dentro da MIB através de um Object Identifier (OID). Durante a ativi-
dade de gerência de rede, o NMS pode executar pollings em OIDs específicos do agente, visando 
obter informações sobre algum recurso da máquina onde esse agente é executado. Para tal, o 
NMS deverá conhecer a estrutura da MIB dos agentes para saber os OIDs disponíveis. As MIBs 
proprietárias da Juniper estão disponíveis para download em: http://www.juniper.net/techpubs.
O Junos oferece suporte para SNMP versões, 1, 2 e 3. A versão é a implementação inicial do 
protocolo e até hoje é uma das mais usadas devido à sua simplicidade. A versão 2 adicionou 
algumas funcionalidades ao protocolo, mas não ganhou tanta popularidade. O SNMP v3 é a 
versão mais atual. Ela funciona exatamente da mesma forma que a versão 1, mas adiciona 
recursos de segurança e criptografia. A versão 3 é a única que garante a integridade, autenti-
cidade e confidencialidade das informações de SNMP. 
Ao consultar dados de SNMP do agente, o NMS precisa formalizar um pedido. Nesse pedido 
o NMS precisa mostrar que conhece a “community” SNMP do agente. Essa “community” 
funciona como uma senha de acesso. Apenas os NMS que a conhecem podem solicitar infor-
mações. Na versão 1 as informações de pacote não são criptografadas, o que permite a um 
capturador de tráfego obter o valor da “community” e dos OIDs facilmente. A versão 3 provê 
mecanismos de proteção para esses dados.
Configurando SNMP
A seguir um exemplo de configuração de SNMP no Junos:
[edit snmp]
user@host# show
description “My JUNOS Device”;
166
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
location “BSU East Campus Closet - Rack 4”; 
contact “Jim Davis - x1865”;
community cardinals { 
 authorization read-only;
 clients {
 10.210.14.0/24; - SNMP request limited to 10.210.14/24 subnet; can 
also restrict to an interface
 }
}
trap-group my-trap-group { 
 version v2;
 categories {
 chassis;
 link;
 }
 targets { 
 10.210.14.173;
 }
}
As configurações são feitas na hierarquia “[edit snmp]”. Alguns parâmetros SNMP configuráveis:
 1 SNMP description: provê informação de identificação do agente em questão.
 1 SNMP location: provê informações de localização do agente (importante em redes grandes).
 1 SNMP Contact: provê informações sobre a equipe que deve ser contatada para o caso de 
falha do agente.
Debaixo da hierarquia “[edit snmp]” também são criadas sub hierarquias com as “communities”. 
Um agente pode ter inúmeras “communities” configuradas. Para cada “community”, o adminis-
trador do Junos define os NMSs que podem fazer consulta usando-a, e o nível de acesso:
 1 read-only: para leitura do valor dos OIDs; 
 1 read-write: leitura ou alteração do valor dos OIDs.
Por fim, o exemplo mostra uma configuração de “trap-group”. Através dessa definição o 
administrador define que o Junos não só aceitará consultas SNMP do NMS como também 
enviará determinadas informações ao NMS de maneira proativa. Na configuração o admi-
nistrador define a versão de SNMP que as “traps” seguirão, o endereço IP da entidade que 
receberá as “traps” e as categorias de mensagem que serão enviadas (no exemplo serão 
enviadas “traps” referentes à “chassi” e “link”).
167
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
5
Monitorando a operação do SNMP
Um NMS provê a interface para a maioria das tarefas de monitoração do SNMP. Para veri-
ficar a operação desse protocolo, diretamente no Junos que está trabalhando como agente 
SNMP, podem ser usadas “traceoptions” dentro da hierarquia “[edit snmp]”. Além disso, 
existem vários comandos “show snmp” que auxiliam a tarefa.
É possível consultar os valores de determinados OIDs do sistema, através do comando de 
modo de operação “show snmp mib walk <hierarquia da MIB SNMP>”. 
q 1 No exemplo seguinte de operação de snmpwalk no Junos, o usuário solicitou informa-
ções sobre as OIDs abaixo da hierarquia jnxOperatingDescr. 
 1 Essas OIDs guardam a descrição de vários recursos de hardware do sistema, tais 
como as FPCs e PICs.
user@host> show snmp mib walk jnxOperatingDescr 
jnxoperatingDescr.1.1.0.0 = midplane 
jnxoperatingDescr.2.1.1.0 = Power Supply 0 
jnxoperatingDescr.2.1.2.0 = Power Supply 1 
jnxoperatingDescr.4.1.1 1 = FAN 0 
jnxoperatingDescr.7.1.0.0 = FPC: EX3200-24T, 8 POE @ 0/*/ * 
jnxoperatingDescr.8.1.1.0 = PIC: 24x 10/100/1000 Base-T @ O/O/* 
jnxOperatingDescr.8.1.2.0 = PIC: 4x GE SFP @ 0/1/ * 
jnxOperatingDescr.9.1.0.0 = RE-EX3200-24-T
No uso desse comando, as OIDs podem ser especificadas pelo nome ou pela hierarquia de números 
do SNMP. Esse curso não tratará do detalhamento da nomenclatura usada nessa hierarquia.
168
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
169
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
6
Roteiro de Atividades 6
Atividade 6.1 – Configurações posteriores
1. Configurando interfaces;
2. Para configurar uma interface de rede GigaEthernet, basta proceder como no exemplo 
seguinte. Vale ressaltar que o Junos trabalha somente com interface virtual, então você 
deve definir a interface virtual (unit) que deseja configurar.
# set interfaces ge-0/0/1 description “Rede LAN 1” 
# set interfaces ge-0/0/1 unit 0 description “LAN 10.0.10.254”
# set interfaces ge-0/0/1 unit 0 family inet address 10.0.10.254/24
# set interfaces ge-0/0/2 description “Rede LAN 2” 
# set interfaces ge-0/0/2 unit 0 description “LAN 10.0.20.254”
# set interfaces ge-0/0/2 unit 0 family inet address 10.0.20.254/24
Nessa mesma atividade coloque o IP da estação Windows 7 com o primeiro IP válido do seu 
Range de IPs.
Este exemplo é para o roteador “A” da primeira bancada. Os demais roteadores serão confi-
gurados conforme os endereços descritos na figura a seguir.
170
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
10.0.80.254/24 10.0.70.254/24
8 7
10.0.60.254/24 10.0.50.254/24
6 5
10.0.40.254/24 10.0.30.254/24
4 3
10.0.20.254/24 10.0.10.254/24
2 1
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
Mesa do 
Instrutor
10.0.160.254/24 10.0.150.254/24
16 15
10.0.140.254/24 10.0.130.254/24
14 13
10.0.120.254/24 10.0.110.254/24
12 11
10.0.100.254/24 10.0.90.254/24
10 9
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
17
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
24 23 22 21 20 19 18
10.0.240.254/24 10.0.230.254/24 10.0.220.254/24 10.0.210.254/24 10.0.200.254/24 10.0.190.254/24 10.0.180.254/24 10.0.170.254/24
3. Verificando o status das interfaces;
Para verificar o status de uma interface Giga Ethernet e descobrir se ela está up ou down, e 
se possui algum erro de pacotes, basta proceder como no exemplo seguinte.
root@bancadaX> show interfaces terse
Interface Admin Link Proto Local 
Remote
ge-0/0/0 up down
ge-0/0/0.0 up down inet 192.168.1.1/30
gr-0/0/0 up up
ip-0/0/0 up up
ls-0/0/0 up up
171
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
6
lt-0/0/0 up up
mt-0/0/0 up up
pd-0/0/0 up up
pe-0/0/0 up up
ge-0/0/1 up up
ge-0/0/1.0 up up inet 10.0.10.254/24
ge-0/0/1.0 up up inet 10.0.20.254/24
ge-0/0/2 up down
ge-0/0/3 up downse-3/0/0 up down
se-3/0/1 up down
dsc up up
gre up up
ipip up up
lo0 up up
lo0.0 up up inet 192.168.0.1/30
lo0.16384 up up inet 127.0.0.1 --> 
0/0
lo0.16385 up up inet 10.0.0.1 --> 
0/0
 10.0.0.16 --> 
0/0
 128.0.0.1 --> 
0/0
 128.0.1.16 --> 
0/0
 inet6 fe80::205:86ff:fe71:e000
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
st0 up up
172
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
tap up up
vlan up up
Outro exemplo:
root@bancadaX> show interfaces brief ge-0/0/0
Physical interface: ge-0/0/0, Enabled, Physical link is Down
 Description: Rede Wan
 Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback: 
Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-
negotiation: Enabled,
 Remote fault: Online
 Device flags : Present Running Down
 Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
 Link flags : None
 Logical interface ge-0/0/0.0
 Description: WAN - 192.168.1.1
 Flags: Device-Down SNMP-Traps Encapsulation: ENET2
 Security: Zone: trust
 Allowed host-inbound traffic : any-service bfd bgp dlsw dvmrp 
igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp
 inet 192.168.1.1/30
Outro exemplo:
Physical interface: ge-0/0/0, Enabled, Physical link is Down
 Interface index: 131, SNMP ifIndex: 133, Generation: 134
 Description: Rede Wan
 Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, 
Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, 
Loopback: Disabled,
 Source filtering: Disabled, Flow control: Enabled, Auto-
negotiation: Enabled, Remote fault: Online
 Device flags : Present Running Down
 Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
 Link flags : None
 CoS queues : 8 supported, 8 maximum usable queues
 Hold-times : Up 0 ms, Down 0 ms
 Current address: 00:24:dc:18:6f:00, Hardware address: 
173
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
6
00:24:dc:18:6f:00
 Last flapped : 2011-01-04 23:17:46 UTC (2w2d 15:46 ago)
 Statistics last cleared: Never
 Traffic statistics:
 Input bytes : 18302503 0 bps
 Output bytes : 4628007 0 bps
 Input packets: 136047 0 pps
 Output packets: 51686 0 pps
 Egress queues: 8 supported, 4 in use
 Queue counters: Queued packets Transmitted packets 
Dropped packets
 0 best-effort 51686 51686 0
 1 expedited-fo 0 0 0
 2 assured-forw 0 0 0
 3 network-cont 0 0 0
 Active alarms : LINK
 Active defects : LINK
 Logical interface ge-0/0/0.0 (Index 69) (SNMP ifIndex 134) 
(Generation 134)
 Description: WAN - 192.168.1.1
 Flags: Device-Down SNMP-Traps Encapsulation: ENET2
 Traffic statistics:
 Input bytes : 18302503
 Output bytes : 4628007
 Input packets: 136047
 Output packets: 51686
 Local statistics:
 Input bytes : 11634932
 Output bytes : 39606
 Input packets: 73031
 Output packets: 943
 Transit statistics:
 Input bytes : 6667571 0 bps
 Output bytes : 4588401 0 bps
174
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 Input packets: 63016 0 pps
 Output packets: 50743 0 pps
…
4. Executando comando do modo operação no modo configuração;
Os comandos que o Junos oferece nos modos de operação e configuração são totalmente 
diferentes. Porém, existe uma alternativa de se executar comandos do modo operação 
mesmo estando no modo configuração. O comando “run” oferece essa alternativa.
root# ping
unknown command.
[edit]
root# run ping 10.0.30.254
PING 10.0.30.254 (10.0.30.254): 56 data bytes
64 bytes from 10.0.30.254: icmp_seq=0 ttl=59 time=66.907 ms
64 bytes from 10.0.30.254: icmp_seq=1 ttl=59 time=55.016 ms
64 bytes from 10.0.30.254: icmp_seq=2 ttl=59 time=67.916 ms
64 bytes from 10.0.30.254: icmp_seq=3 ttl=59 time=72.131 ms
^C
--- 10.0.30.254 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 55.016/68.285/76.322/5.945 ms
root# show interfaces terse
invalid interface type in ‘terse’.
[edit]
root# run show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up down
ge-0/0/0.0 up down inet 192.168.1.1/30
5. Criando usuários de administração do Junos;
Configure dois logins no roteador. Um será usado pelo(s) aluno(s) do PC A da bancada e o 
outro pelo(s) aluno(s) no PC B. Os dois logins terão controle total do roteador.
Os alunos da bancada 1 criarão os logins:
 login: aluno1_pca
 senha: esr1
175
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
6
 login: aluno1_pcb
 senha: esr1
Os alunos da bancada 2 criarão os logins:
 login: aluno2_pca
 senha: esr1
 login: aluno2_pcb
 senha: esr1
E assim por diante para as demais bancadas. Para efetuar a criação dos logins, entre no 
modo de configuração com “configure” e execute:
 set system login user <nome_do_login> class super-user
 set system login user <nome_do_login> authentication plain-text-
password<Enter>
A senha será solicitada duas vezes. Verifique os serviços ativos no roteador com o comando:
#show system service
Caso o SSH não esteja ativo, digite:
# set system service ssh
Abra o Putty e tente fazer um acesso ao roteador pelo protocolo SSH.
176
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Em seguida, entre com login e senha. Repita o procedimento duas vezes, de modo a 
testar os dois logins recém criados. A partir desse momento desconecte o cabo console e 
entregue-o ao seu instrutor. Nos próximos passos, os alunos dos PCs A e B da bancada aces-
sarão o roteador a partir de uma sessão telnet aberta de um dos PCs.
6. Habilitando e verificando logs do Junos;
Verifique as configurações de log do sistema. Entre no modo de configuração com “configure 
private” e execute “show system syslog”. Repare que o Junos, por default, já registra todo 
tipo de mensagem (keyword “any”) em um arquivo chamado “messages”.
Execute o comando “run show log messages” para verificar o conteúdo do arquivo “messages”.
Para as próximas tarefas, verifique a indicação abaixo:
Aluno(s) do PC A da Bancada 1 usarão <logFile> = PCA_Banc1_logFile e <bkpFile> = PCA_
Banc1_BkpFile
Aluno(s) do PC B da Bancada 1 usarão <logFile> = PCB_Banc1_ logFile e <bkpFile> = PCA_
Banc1_BkpFile
Aluno(s) do PC A da Bancada 2 usarão <logFile> = PCA_Banc2_ logFile e <bkpFile> = PCA_
Banc1_BkpFile
Aluno(s) do PC B da Bancada 2 usarão <logFile> = PCB_Banc1_ logFile e <bkpFile> = PCA_
Banc1_BkpFile
Baseando-se na configuração do arquivo “messages”,crie um arquivo de “log” chamado 
<logFile>, que vai registrar apenas mensagens sobre comandos executados na CLI do Junos. 
Para tal, utilize a facilidade “interactive-commands” e a severidade “any”...
 set system syslog file <logFile> interactive-commands any
… em seguida execute “show system syslog” e verifique a configuração adicionada.
Execute “show | compare” para verificar suas alterações. Se estiverem certas, execute “commit”.
Inicie uma monitoração dos logs do arquivo recém criado.
 monitor start <logFile>
Deixe a sessão parada para verificar as mensagens que surgem na tela. Abra outra sessão 
telnet para o roteador, em paralelo, usando o mesmo login e senha. Nessa nova sessão 
execute os seguintes comandos:
 show system uptime
 show interfaces 
 configure private
 show routing-options
 exit configuration-mode
 exit (finaliza a sessão)
Verifique as mensagens que apareceram na sessão onde ficou ligada a monitoração. Observe 
que os comandos executados pelo(s) seu(s) colega(s) de bancada também aparecem.
177
 
C
ap
ítu
lo
 9
 - 
Ro
te
ir
o 
de
 A
ti
vi
da
de
s 
6
Execute o comando “monitor list” no modo de configuração para checar as monitorações 
correntemente ligadas.
Finalize a monitoração com “monitor stop <logFile>”.
Verifique o arquivo de log <logFile> que você definiu. Execute “file list /var/log/?”
Configure o conteúdo que foi registrado nesse arquivo. Execute “file show /var/log/<logFile>”.
7. Configurando SNMP;
O protocolo SNMP é um protocolo bastante utilizado no gerenciamento de ativos de rede, 
principalmente quando se tem definido um SLA bastante exigente, que não permite grandes 
períodos de indisponibilidade.
Para configurar o Junos a aceitar consultar SNMP basta seguir como o exemplo abaixo:
root@teste# set snmp community rnpesr authorization read-only
[edit]
root@teste# set snmp community rnpesr clients 200.130.26.5
[edit]
8. Configurar o cliente NTP;
Servidores NTP são extremamente necessários em redes corporativas que exigem uma 
auditoria mais efetiva. Quando se pensa em auditoria, uma das primeiras configurações que 
devemos fazer nos ativos de rede é a sincronização do time do sistema. Para configurar o 
Junos para sincronizar seu time de sistema com um servidor de hora – NTP (Network Time 
Protocol) – devemos alterar as configurações de NTP a partir da árvore de configuração [edit 
system ntp] ou executando o comando abaixo a partir do topo [edit].
 root@bancadaX# set system ntp server 200.144.121.33
 [edit]
Para verificar se o roteador está sincronizado com o servidor NTP basta executar o comando 
“run show ntp associations” no modo configuração.
root@bancadaX# run show ntp associations
 remote refid st t when poll reach delay 
offset jitter
===========================================================
 200.144.121.33 193.204.114.232 2 - 1 64 1 21.849 
-284920 0.244
[edit]
178
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
179
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
ob
je
tiv
os
conceitos
10
Operação, manutenção e 
monitoração
Conhecer as funcionalidades de monitoração da CLI do Junos e outros recursos 
oferecidos pelo sistema, dominar os procedimentos básicos de manutenção do Junos.
 
Monitoramento da plataforma, operação de interfaces, utilitários de rede, manutenção 
do Junos OS, recuperação de senha, instalação e upgrade do Junos.
 
 
Monitorando a plataforma e operando as interfaces
JUNOS CLI
SNMP LEDs
LCDsJ-Web
q 1 A ferramenta de monitoração primária do Junos é a CLI. 
 1 Através de seus comandos de “show” e “monitor” é possível executar a maior parte 
das tarefas de monitoração do equipamento, bem como obter os subsídios para 
diagnosticar problemas. 
Adicionalmente à CLI, há um número de ferramentas de monitoração secundárias: a inter-
face J-Web, o SNMP, os LEDs de hardware e o painel frontal da caixa. Em relação a esses 
últimos existem particularidades em cada uma das diferentes plataformas Juniper, as quais 
podem ser detalhadas em: http://www.juniper.net/techpubs/
Monitorando a operação geral do sistema
Grande parte das informações do sistema é obtida através dos comandos do modo de ope-
ração “show system <argumento>”. Onde o “<argumento>” pode tomar vários valores. Entre 
os mais comuns estão:
 1 alarms: exibe alarmes ativos no sistemas (esses alarmes saem da lista automaticamente 
quando o problema é sanado).
Figura 10.1 
Ferramentas de 
monitoração.
180
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 1 boot-messages: mostra mensagens geradas durante o último processo de “boot” do sistema.
 1 connections: exibe o estado das conexões TCP e UDP locais.
 1 statistics: mostra estatísticas de protocolos utilizados na caixa.
 1 storage: exibe o estado do espaço disponível no disco do sistema.
Opções do comando “show system”:
user@host> show system ? 
possible completions: 
 alarms Show system alarm status 
 audit Show file system MD5 hash and permissions
 boot-messages Show boot time messages
 buffers Show buffer statistics 
 certificate Show installed X509 certificates
 commit Show pending commit requests (if any) and commit 
history 
 configuration Show configuration information 
 connections Show system connection activity 
 core-dumps Show system core files 
 directory-usage Show local directory information 
 initia15etup Show initial setup information 
 license Show feature licenses information 
 processes Show system process table 
 reboot Show any pending halt or reboot requests 
 rollback Show rolled back configuration 
Monitorando o chassi
A operação do chassi é feita usando-se os comandos do modo de operação “show chassis 
<argumento>”. A lista abaixo exibe alguns dos valores mais populares que o “<argumento>” 
pode tomar:
 1 alarms: exibe alarmes ativos referentes ao chassi, que saem da lista automaticamente 
quando o problema é sanado.
 1 environment: exibe o estado da velocidade do sistema de cooling e de outros recursos de 
ambiente.
 1 hardware: exibe um inventário dos componentes de hardware instalados e seus respec-
tivos números de série.
 1 routing-engine: mostra o estado operacional e detalhes da utilização da RE.
Opções do comando “show chassis”:
user@host> show chassis ? 
181
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
Possible completions: 
 Alarms Show alarm status
 Environment Show component status and temperature, cooling 
system speeds
 Fpc Show Flexible PIC Concentrator status 
 Hardware Show installed hardware components
 Lcd Show LCD display 
 Location Show physical location of chassis 
 mac-addresses Show media access control addresses 
 pic Show physical Interface Card 
state, type, and uptime
 routing-engine Show Routing Engine status
 temperature-thresholds Show chassis temperature threshold settings
Verificando o estado das interfaces
qA família de comandos de modo de operação “show interfaces <opções>” provê vários 
detalhes sobre a operação das diferentes interfaces da caixa. Alguns dos comandos mais 
populares são:
 1 show interfaces <nome da interface>
 1 show interfaces <nome da interface> detail
 1 show interfaces <nome da interface> extensive
 1 show interfaces <nome da interface> terse
O primeiro comando fornece informações sobre a operação de uma determinada interface.O comando seguinte exibe as mesmas informações, mas adicionando novos detalhes. 
O terceiro comando exibe um relatório ainda maior em relação à informação reportada pelos 
dois comandos anteriores. O último comando exibe um resumo do status das interfaces.
O exemplo seguinte exibe ainda outras opções que podem ser utilizadas como argumento 
do comando “show interfaces”:
user@host> show interfaces ge-0/0/0 ? 
Possible completions: 
 <[Enter]> Execute this command
 Brief Display brief output
 descriptions Display interface description strings 
 detail Display detailed output
 extensive Display extensive output 
 media Display media information 
 routing-instance Name of routing instance 
182
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 snmp-index SNMP index of interface 
 statistics Display statistics and detailed output 
 terse Display terse output 
 | Pipe through a command 
Um comando popular que provê informação resumida sobre o estado de todas as interfaces 
do roteador é o “show interfaces terse”, cuja saída é mostrada abaixo:
user@host> show interfaces terse 
Interface Admin Link Proto Local Remote 
ge-O/O/O up up 
ge-O/O/O.O up up inet 172.18.36.1/24 
ge-O/O/1 up up 
ge-O/O/1.O up up inet6 fd73:5d2a:f03b:15eO::1/64 
 fe80::217:cbff:fe4e:a281/64 
ge-O/O/2 up up 
ge-O/O/2.0 down up inet 172.19.25.1/28 
 iso
 mpls 
ge-O/O/3 down up 
ge-0/0/3.0 up down inet 
Esse comando é ideal para fornecer uma ideia geral do funcionamento de todas as cone-
xões presentes. Repare que todas as famílias de protocolos de rede são exibidas, bem como 
todas as interfaces e subinterfaces. O exemplo anterior mostra os estados administrativos e 
operacionais de cada um desses recursos.
Estado das interfaces: informação extensiva
O comando “show interfaces <nome da interface> extensive” mostra as informações mais 
detalhadas sobre uma determinada interface. O exemplo seguinte mostra apenas uma 
porção da saída do comando:
user@host> show interfaces ge-O/O/O extensive 
Physical interface : ge-O/O/O, Enabled, Physical link is Up 
 Interface index : 129, SNMP ifIndex: 32, Generation: 130 
 Link-level type : Ethernet, MTU: 1514, Speed: 100mbps, Loopback: 
Disabled, 
 Source filtering : Disabled, Flow control: Enabled, Auto-
negotiation: Enabled, 
183
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
 Remote fault : Online 
 Device flags : Present Running 
 Interface flags : SNMP-Traps Internal: Ox4000 
 Link flags : None 
 CoS queues : 8 supported, 8 maximum usable queues 
 Hold-times : Up 0 ms, Down 0 ms 
 Current address : 00:17:cb:4e:a2:80, Hardware address: 
00:17:cb:4e:a2:80 
 Last flapped : 2008-10-03 20:46:59 UTC (8w6d 07:27 ago) 
 statistics last cleared: 2008-10-15 21:16:11 UTC (7w1d 06:58 ago) 
 Traffic statistics: 
...
Entre outras informações, esse comando traz informações sobre erros de CRC, estatísticas 
e propriedades físicas e lógicas da interface. Caso a interface tenha sido configurada com 
QoS, estatísticas das filas de QoS também serão mostradas. Dada a quantidade de detalhes 
exibidos, o comando torna-se um grande aliado da tarefa de depuração de problemas.
Monitorando interfaces
O comando do modo de operação “monitor interface <nome da interface>” exibe, em tempo 
real, estatísticas sobre o uso de uma interface específica, tais como: volume de dados rece-
bidos e enviados, erros de CRC e outros, quantidade de pacotes recebidos e enviados, taxa 
de transmissão e recepção etc. Abaixo apenas uma porção da saída do comando:
host Seconds: 23 Time : 
06:11:08 
 Delay: 0/0/2 
Interface: ge-O/O/O.0, Enabled, Link is Up 
Flags: SNMP-Traps 
Encapsulation: ENET2 
Local statistics: Current delta 
 Input bytes: 146945 [13768] 
 Output bytes: 33911 [14327] 
 Input packets: 2383 [185] 
 Output packets: 313 [70] 
184
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Remote statistics: 
 Input bytes: 48 (4824 bps) [0] 
 Output bytes: 240 (0 bps) [0] 
 Input packets: 11 (0 pps) [7] 
 Output packets: 4 (0 pps) [0] 
Traffic statistics: 
 Input byte5: 146993 Output byte5: , [0]
 
Next=’n’, Quit=’q’ or ESC, Freeze=’f’, Thaw=’t’, C1ear=’c’, 
Interface=’i’
Para obter informações similares (porém mais resumidas) de todas as interfaces, pode-se 
usar o comando do modo de operação “show interface traffic”. A seguir uma porção da saída 
desse comando:
user@host> monitor interface traffic
host Seconds: 27 Time: 04:47:57
Interface Link Input packets (pps) Output packets (pps)
ge-0/0/0 Up 22763 (581) 21275 (581)
...
Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, 
Down=^D
Utilitários de rede
Ping e Traceroute
q 1 Junos provê utilitários populares para avaliação da rede, como “ping” e “traceroute”.
 1 Estas ferramentas determinam condições gerais de alcance na rede e o caminho dos 
pacotes para chegar a um determinado destino. 
Os comandos “ping” e “traceroute” no Junos suportam vários argumentos, tais como “IP 
origem” e tamanho dos pacotes gerados.
user@host> ping 10.210.14.173 
PING 10.210.14.173 (10.210.14.173): 56 data bytes
64 bytes from 10.210.14.173: icmp seq=O ttl=64 time=O.345 ms 
64 bytes from 10.210.14.173: icmp seq=1 ttl=64 time=O.292 ms
^C 
--- 10.210.14.173 ping statistics -- 
2 packets transmitted, 2 packets received, 0% packet loss 
185
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
round-trip min/avg/max/stddev = 0.218/0.281/0.345/0.046 ms 
user@host> traceroute 10.210.14.173 
traceroute to 10.210.14.173 (10.210.14.173), 30 hops max, 40 byte pkts 
 1 10.210.14.173 (10.210.14.173) 2.872 ms 0.203 ms 0.150 ms
Por default, o “ping” envia um fluxo contínuo de “echo requests” ICMP a um determinado 
destino. Para parar o fluxo, o usuário precisa teclar “Ctrl + C”, conforme mostrado a seguir. 
Alternativamente, pode-se usar o argumento “count <n>”, que faz com que sejam gerados 
apenas <n> “echo requests” ICMP.
user@host> ping 10.210.11.177 count 5
PING 10.210.11.177 (10.210.11.177): 56 data bytes
64 bytes from 10.210.11.177: icmp_seq=0 ttl=64 time=0.071 ms
64 bytes from 10.210.11.177: icmp_seq=1 ttl=64 time=0.060 ms
64 bytes from 10.210.11.177: icmp_seq=2 ttl=64 time=0.125 ms
64 bytes from 10.210.11.177: icmp_seq=3 ttl=64 time=0.128 ms
64 bytes from 10.210.11.177: icmp_seq=4 ttl=64 time=0.080 ms
--- 10.210.11.177 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.060/0.093/0.128/0.028 ms
Monitor traffic
q 1 O comando “monitor traffic” executa a mesma função do software Unix “tcpdump”. 
 1 Essa ferramenta monitora o tráfego de uma determinada interface, que é originado 
ou que termina na RE local do roteador. 
 1 Se nenhuma interface for especificada, a interface de gerência será monitorada.
user@host> monitor traffic ? 
Possible completions: 
<[Enter]> Execute this command 
detail Display detailed output 
extensive Display extensive output 
interface Name of interface
layer2-headers Display link-level header on each receive dump line
matchingExpression for headers of receive packets to match
186
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
q 1 Problemas de camada 2 podem ser depurados usando o argumento “layer2-headers”.
 1 A opção “matching” permite filtrar a massa de dados capturada usando critérios base-
ados nos campos do pacote do protocolo IP. 
 2 Trata-se de uma das opções mais funcionais para o comando.
 1 A opção “write-file” fica escondida (não aparece quando se executa o comando “?”), 
mas está disponível e consiste em um recurso bastante útil. 
 2 Essa opção permite salvar o conteúdo capturado em um arquivo no formato “.cap”. 
 2 Esse arquivo poderá ser aberto posteriormente em um software de decodificação 
de dados, como o Wireshark (antigo Ethereal).
A opção “write-file” deve ser usada com bastante cuidado. Dependendo do volume 
de dados capturado, o arquivo de saída pode formar um volume absurdamente 
grande e estourar o tamanho do disco do sistema, o que comprometeria grande 
parte das funções do roteador (por esse motivo o comando fica escondido). Ao usar 
a opção “write-file”, sempre utilize a opção “matching” em conjunto, para evitar 
que muitos pacotes sejam registrados. Essa prática ajuda a evitar a geração de um 
grande volume. 
Exemplo de captura de pacotes:
user@host> monitor traffic interface ge-0/0/2 layer2-headers no-resolve 
verbose output suppressed, use <detail> or <extensive> for full 
protocol decode 
Address resolution is OFF. 
Listening on ge-0/0/2, capture size 96 bytes 
06:19:35.121217 In 0:1b:c0:5e:53:a2 > 0:19:e2:50:3f:e3, ethertype IPv4 
(Ox0800), 
length 98: 10.100.200.1 > 10.100.200.2: ICMP echo request, id 5153, 
seq 222, length 64 
06:19:35.121269 Out 0:19:e2:50:3f:e3 > 0:1b:c0:5e:53:a2, ethertype 
IPv4 (Ox0800), 
length 98: 10.100.200.2 > 10.100.200.1: ICMP echo reply, id 5153, seq 
222, length 64 
^C ----- Ctrl+c 
10 packets received by filter 
o packets dropped by kernel 
O exemplo mostra o capturador de pacotes do Junos em ação. Para parar uma captura é 
necessário teclar “Ctrl + C”.
187
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
Clientes de Telnet, SSH e FTP
q 1 O Junos traz previamente instalados clientes de Telnet, SSH e FTP. 
 1 Esses softwares permitem acessar equipamentos remotos a partir da CLI do Junos.
user@host> telnet ? 
Possible completions: 
 <host> Hostname or address or remote host 
 8bit Use 8-bit data path 
 bypass-routing Bypass routing table, use specified interface 
 inet Force telnet to IPv4 destination 
 inet6 Force telnet to IPv6 destination 
 interface Name of interface for outgoing traffic 
 logical-router Name of logical router 
 no-resolve Don’t attempt to print addresses symbolically 
 port Port number or service name on remote host 
 routing-instance Name of routing instance for telnet session 
 source Source address to use in telnet connection 
user@host> telnet 127.0.0.1 
Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is ‘^ ]’. 
host (ttyp0) 
login: user 
Password: 
...
Para transferir arquivos do Junos para um sistema remoto utilizando o cliente FTP, usa-se o 
comando “file copy” conforme abaixo:
user@host> file copy ftp://ftp:ftp@10.210.11.189/junos-jseries-
domestic.tgz /
var/tmp/junos-jseries-domestic.tgz
/var/tmp//...transferring.file.........Ri4PRe/100% of 41 MB 4071 kBps 00m00s
188
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Mantendo o Junos 
Para verificar detalhes sobre a versão de Junos que está sendo executada na caixa, utiliza-se o 
comando do modo de operação “show version”. Pode-se adicionar a esse comando a opção 
“detail” para obter informações adicionais sobre os pacotes e processos incluídos na versão 
do sistema operacional.
user@host> show version 
Hostname: host 
Model: mx480 
JUNOS Base OS boot [9.5Rl.8] 
JUNOS Base OS Software Suite [9.5R1.8] 
JUNOS Kernel Software Suite [9.5R1.8] 
JUNOS Crypto Software Suite [9.5R1.8] 
JUNOS Packet Forwarding Engine Support (M/T Common) [9.5R1.8] 
JUNOS Packet Forwarding Engine Support (MX Common) [9.5R1.8] 
JUNOS Online Documentation [9.5Rl.8] 
JUNOS Routing Software suite [9.5R1.8] 
Alguns pacotes típicos que compõem o sistema:
 1 jkernel: compreende o kernel e o pacote de ferramentas de rede. Contém os arquivos 
básicos de sistema.
 1 jroute: compreende o pacote da routing engine. Contém o software executado na RE.
 1 jpfe: contém o software executado na Packet Forwarding Engine (PFE).
 1 jdocs: contém as documentações do sistema.
 1 jcrypto: pacote de encriptação, contém o software de segurança.
Convenção de nomes de pacotes de Junos
A convenção usada para nomear os pacotes do Junos segue uma padronização 
“package-release-edition”, onde:
 1 Package: é a descrição do conteúdo do pacote; alguns exemplos: jinstall, jkernel e junos-srx.
 1 Release: descreve a versão do Junos considerando vários subcomponentes. O release 
consiste em dois números inteiros e uma letra maiúscula (que indica o tipo de software). 
A letra mais comum é “R”, que indica “Release”. Empresas que se propõem a serem testa-
doras de novos softwares se confrontam com frequência com a letra “B”, que indica “Beta 
software”, ou com a letra “I”, que indica “Internal”. 
Mais dois números fecham o nome do pacote. O número da “build” e do “spin” do código. Assim, 
o pacote “jinstall-9.5R1.8-domestic.tgz” indica: Software Junos versão 9.5, build 1, spin 8.
 1 Edition: tipicamente será “domestic” ou “export”. Versões “domestic” suportam algoritmo 
de encriptação forte, enquanto as versões “export” não suportam.
189
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
Há ainda uma terceira e rara possibilidade: a FIPS. Essa versão provê serviços avançados 
de segurança de redes para clientes que precisam adequar suas operações ao padrão da 
“Federal Information Processing Standards 140-2”.
Todo software Junos é fornecido em pacotes assinados, que contêm assinaturas digitais 
que usam o algoritmo SHA-1 (Secure Hash Algorithm 1). Um pacote só pode ser instalado se 
um procedimento de verificação do pacote executado pelo hardware retorna um resultado 
esperado. Do contrário a instalação falhará. 
O resultado esperado será retornado sempre que a assinatura digital for verificada corretamente.
Recuperação de senha
A perda da senha de root do sistema é um perigo sempre presente. Quando isso ocorre, 
pode-se recuperá-la usando o procedimento descrito a seguir.
Como precaução de segurança, o procedimento de recuperação de senha pode ocorrer 
apenas através de uma sessão criada a partir da porta console. Não é possível fazê-lo via 
sessão de telnet ou de SSH.
qPassos para a recuperação de senha:
 1 Obtenha acesso via console e faça um “reboot” no sistema. 
 1 Durante o processo de “boot” tecle a barra de espaço continuamente. 
 1 Quando o sistema apresentar o prompt “loader>” (ou um prompt “OK”, dependendo 
da plataforma), execute “boot -s” para iniciar o sistema no modo “single-user”.
...TRIMMED...
Hit [Enter] to boot immediately, or space bar for command prompt.
<user presses Spacebar>
Type ‘?’ for a list of commands, ‘help’ for more detailed help.
loader> boot -s
Terminado o processo de boot em modo “single-user”, o sistema perguntará se o usuário 
deseja operar o equipamento através de um shell ou se deseja recuperar a senha de root. 
Nesse ponto, deve-se executar o comando “recovery”:
...TRIMMED...
Enter full pathname of shell or ‘recovery’ for root password 
recovery or RETURN
for /bin/sh: recovery
q 1 Depois de umasérie de mensagens a CLI inicia e apresenta o prompt do modo 
de operação.
 1 Nesse ponto pode-se executar um reset da senha de root com o comando “set system 
root-authentication plain-text-password”. 
 1 Em seguida, é necessário efetivar o comando com o “commit”.
190
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
[edit]
root# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root# commit
commit complete
O próximo passo é deixar o modo de configuração. Nesse momento o sistema perguntará 
se o usuário deseja executar um “reboot”. Escolhendo a opção “Y” (Yes) o sistema reiniciará. 
Com o “reboot” completo, já será possível se conectar com a nova senha de “root”.
[edit]
root# exit
Exiting configuration mode
root> exit
Reboot the system? [y/n] y
Instalação e upgrade do Junos
A instalação de uma nova versão de Junos depende de dois passos: fazer o download da 
imagem a ser instalada e executar a instalação.
O download da imagem do Junos pode ser feito em um portal próprio mantido pela Juniper: 
http://www.juniper.net/support/ 
O download pode ser executado através de um browser web ou de um cliente de FTP. Para 
baixar uma imagem de Junos utilizando um cliente de FTP, aponta-se o software cliente para 
o endereço “ftp.juniper.net”.
Independentemente do método que será usado, para fazer o download é necessário ter um 
contrato de suporte válido com o fabricante e uma conta de acesso ao portal. Cada imagem 
individual de Junos é designada para uma plataforma específica. Ao fazer o download da 
imagem deve-se atentar para o tipo de plataforma para o qual a imagem é designada.
A RNP é um grande cliente da Juniper e possui contrato de suporte para vários de 
seus equipamentos.
Uma vez executado o download, a imagem deve ser gravada no disco do roteador, em um dire-
tório qualquer. Para proceder com o upgrade, o usuário utiliza o comando do modo de operação:
request system software add <diretório/imagem>
Caso a imagem esteja em um servidor de FTP remoto é possível usar o mesmo comando, pas-
sando como argumento os nomes do diretório e do arquivo remotos, IP, senha e usuário do ser-
vidor de FTP. Procedendo dessa forma, o sistema fará a instalação a partir do arquivo remoto.
191
 
C
ap
ítu
lo
 1
0 
- O
pe
ra
çã
o,
 m
an
ut
en
çã
o 
e 
m
on
ito
ra
çã
o
Para ativar o novo software é necessário proceder com o “reboot” do sistema. Esse “reboot” 
pode ser executado em um passo posterior ou automaticamente, usando a opção “reboot” 
como argumento do comando “request system software add”.
user@host> request system software add /var/tmp<image-name> reboot 
 
Verified jinstall-9.5R1.8-domestc.tgz signed by 
PackageProduction_9_5_0
Adding jinstall...
Verified manifest signed by PackageProduction_9_5_0
WARNING: This package will load JUNOS 9.5R1.8 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-instalation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files...
...
Uma vez que o novo Junos é instalado, o usuário é notificado de que o sistema fará um novo 
reboot para completar o processo de upgrade. Nesse ponto o usuário pode usar o terminal 
de console para acompanhar as mensagens geradas, prestando particular atenção para 
mensagens de erro que venham a ocorrer.
Opcionalmente, pode-se verificar as mensagens geradas durante o boot em um momento 
posterior, através do comando de modo de operação: 
show system boot-messages
Dispositivos que rodam o Junos executam códigos binários fornecidos pela Juniper. Cada 
imagem de Junos possui executáveis assinados digitalmente, que são registrados pelo 
sistema somente se a assinatura é validada. O Junos não executará nenhum binário sem o 
devido registro. Esse recurso existe para proteger o hardware contra softwares não autori-
zados e atividades que poderiam comprometer a atividade do equipamento. 
Boas práticas de upgrade
Durante o processo de upgrade existem boas práticas aconselháveis. A primeira delas é 
o uso do diretório “/var/tmp” para local temporário de armazenamento de imagens. Os 
arquivos de imagem que já foram instalados e permaneceram gravados ali podem ser remo-
vidos através do processo de “clean up”. Esse processo é executado pelo sistema quando o 
usuário executa o comando de modo de operação “request system storage cleanup”.
192
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Para determinar os arquivos candidatos a serem removidos, utiliza-se o comando de modo 
de operação: 
request system storage cleanup dry-run
Normalmente o espaço de armazenamento do roteador tem bastante espaço, porém, é 
aconselhável checar a quantidade de espaço disponível antes de fazer um download de uma 
nova imagem. Pode-se verificar o espaço disponível na compact-flash do equipamento com 
o comando do modo de operação: 
show system storage
193
 
C
ap
ítu
lo
 1
0 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
7
Roteiro de Atividades 7
Atividade 7.1 – Instalação do Junos (parte 1)
1. Verificando alarmes do Junos;
O equipamento j2350 da Juniper possui um led chamado “Alarm”, que indica se há alguma 
coisa errada com o equipamento.
Para verificar o motivo do alarme caso o led esteja aceso, basta utilizar os comandos abaixo 
a partir do modo operação. Verifique se existe algum alarme ativado com o comando:
root@bancadaX> show system alarms
1 alarms currently active
Alarm time Class Description
2011-01-21 15:11:06 UTC Minor Rescue configuration is not set
root@teste> show chassis alarms
No alarms currently active
Para simular um alarme, digite o comando abaixo para apagar o arquivo rescue:
> request system configuration rescue delete
> commit
Reinicie o roteador:
>request system reboot
Quando o roteador reiniciar, acenderá uma luz laranja de alarme; para verificar o alarme 
usa-se o comando:
> show system alarms
Para resolver o alarme basta criar um arquivo de rescue:
> request system configuration rescue save
> commit
A luz do alarme deverá apagar.
2. Habilitando e desabilitando serviços;
O Junos fornece alguns serviços de acesso remoto, quer via protocolo Telnet, SSH, interface 
gráfica com algumas opções de configuração e até mesmo serviços DHCP e FTP.
Para habilitar esses serviços, basta proceder como no exemplo seguinte:
root@bancadaX# set system services ssh
root@bancadaX# set system services web-management http interface 
ge-0/0/1.0
194
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
3. Configurando o modo RESCUE;
Como se viu no exemplo anterior, a saída exibida pelo comando “show system alarms” 
informa que existe um alarme devido à configuração de “rescue” não estar habilitada. Essa é 
mais uma funcionalidade do Junos que auxilia o administrador em casos de recuperação em 
desastres. Quando se define uma configuração de “rescue”, salva-se uma cópia da configu-
ração atual em um arquivo na flash do equipamento. Para aplicar essa configuração salva, 
basta apertar ligeiramente uma vez o botão “config” do equipamento.
Essa atividade visa simular uma situação de desastre. Para isso execute o seguinte comando 
a partir do modo configuração para habilitar a configuração de “rescue”.
root@teste# run request system configuration rescue save
[edit]
Em seguida, execute o comando “commit” para que as configurações tenham efeito.root@teste# commit
commit complete
[edit]
Feito isso, perceba que o botão “alarm” do equipamento não está mais com o led aceso.
Agora vamos excluir as configurações da interface ge-0/0/0 com os seguintes comandos:
root@teste# delete interfaces ge-0/0/0
[edit]
root@teste# commit
commit complete
[edit]
Nesse momento deve-se experimentar uma perda de conexão remota ao equipamento. 
Para retornar para a configuração anterior, basta apertar ligeiramente e somente uma 
vez o botão “config” do equipamento. Perceba que as configurações da interface ge-0/0/0 
entrarão em vigor novamente, possibilitando o acesso remoto ao roteador.
Atividade 7.2 – Instalação do Junos (parte 2)
1. Backup e restore
Uma questão muito importante em sistemas corporativos é relativa a backup e restore. Junos 
fornece alguns comandos e opções que facilitam o backup e restore de todo o seu sistema.
Para salvar toda a configuração ativa do seu sistema em um arquivo texto, deve-se utilizar 
o comando “show” a partir do [edit], topo da árvore de configuração do Junos, junto com o 
comando “display set”, que exibirá na tela os comandos que geraram a configuração atual, 
como exibido a seguir.
195
 
C
ap
ítu
lo
 1
0 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
7
root@bancadaX# show | display set
set version 9.5R4.3
set system host-name teste
set system root-authentication encrypted-password
“$1$GwoPLZZp$8HKb9z7J55MJHFt7/
tErn.”
set system login user glenio uid 2007
set system login user glenio class super-user
set system login user glenio authentication encrypted-password
“$1$GlS0hWjY$wwKM
hlH6.gv2RAo9IHwcR/”
set system login user zacaron uid 2006
set system login user zacaron class super-user
set system login user zacaron authentication
encrypted-password “$1$W.X4RTGh$CG2
Rw5JXXBOpSo7WXGuYd1”
set system services ssh
set system services telnet
set system services web-management http interface ge-0/0/1.0
set system syslog file messages any any
set system syslog file auditoria.txt interactive-commands any
set system syslog file auditoria1.txt interactive-commands any
set system ntp boot-server 200.144.121.33
set system ntp server 200.144.121.33
set interfaces ge-0/0/0 description “Rede Wan”
set interfaces ge-0/0/0 unit 0 description “WAN - 192.168.1.1”
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
set interfaces ge-0/0/1 description “Rede Lan”
set interfaces ge-0/0/1 unit 0 description “LAN - 10.0.40.254”
set interfaces ge-0/0/1 unit 0 family inet address 200.130.26.4/24
set interfaces lo0 unit 0 family inet address 192.168.0.1/30
set routing-options static route 0.0.0.0/0 next-hop 200.130.26.254
196
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Com esses comandos em mãos, basta salvar em um arquivo com o comando “save”, 
conforme a seguir:
root@bancadaX# show | save backup_19012011.txt
Wrote 54 lines of output to ‘backup_19012011.txt’
[edit]
Agora, com todas as configurações salvas em um arquivo, pode-se utilizar o cliente “scp” 
do Unix para copiar o arquivo para uma máquina remota, ou até mesmo copiar de uma 
máquina remota o arquivo que se encontra na flash do Juniper, já que o Junos possui um 
servidor de Shell seguro (SSH) para estabelecer conexões remotas. Exemplo:
Para entrar no Shell do Unix, digite o seguinte comando a partir do modo operação:
root@bancadaX> start Shell
Digite o comando “pwd” para verificar a localização no sistema de arquivos:
root@bancadaX% pwd
/cf/root
Digite o comando “ls -lah” para listar os arquivos nesse diretório “/cf/root”:
root@bancadaX% ls -lah
total 70
drwxr-xr-x 3 root wheel 512B Jan 19 18:13 .
drwxr-xr-x 11 root wheel 512B Dec 17 21:12 ..
-rw-r--r-- 1 root wheel 361B Feb 16 2010 .cshrc
-rw------- 1 root wheel 1.3K Jan 19 16:40 .history
-rw-r--r-- 1 root wheel 1.1K Feb 16 2010 .login
-rw-r--r-- 1 root wheel 215B Feb 16 2010 .profile
drwx------ 2 root wheel 512B Dec 15 00:28 .ssh
-rw-r--r-- 1 root wheel 2.6K Dec 15 00:34 backup.txt
-rw-r--r-- 1 root wheel 2.5K Jan 19 18:13 backup_19012011.txt
-rw-r--r-- 1 root wheel 3.9K Dec 18 00:47 conf_17-12-2010
-rw-r--r-- 1 root wheel 3.7K Dec 18 00:47 conf_display_set
-rw-r--r-- 1 root wheel 2.4K Dec 18 01:03 novo
-rw-r--r-- 1 root wheel 4.5K Dec 15 02:25 snmp
-rw-r--r-- 1 root wheel 2.5K Dec 28 20:52 teste.txt
-rw-r--r-- 1 root wheel 6B Dec 14 21:57 ttyp1
197
 
C
ap
ítu
lo
 1
0 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
7
Se o arquivo for encontrado, basta utilizar o cliente “scp” para copiar o arquivo para uma 
máquina remota:
root@bancadaX% scp backup_19012011.txt root@200.130.26.5:/cf/root
root@200.130.26.5’s password:
backup_19012011.txt 
100% 2550 2.5KB/s 00:00
O sistema operacional remoto pedirá a senha para o usuário root; se informada correta-
mente, copiará o arquivo de maneira segura.
Para recuperar um backup efetuado em um arquivo de configuração tipo ASCII, deve-se 
utilizar o comando “load”. Sempre que utilizar esse comando é recomendado fazer um 
backup da configuração atual, pois após executá-lo e em seguida o comando “commit”, toda 
a configuração que se encontra no arquivo de configuração será aplicada e valerá a partir 
desse instante.
A seguir um exemplo de utilização do comando “load”.
O Junos guarda alguns modelos de configuração que podem auxiliar na configuração do roteador 
quando ele vem de fábrica. Esses arquivos estão localizados no diretório “/etc/config/”. 
root@bancadaX# load override backup_19012011.txt
Feito isso, basta executar o comando “commit” para que as configurações passem a ter efeito.
Atividade 7.3 – Upgrade do Junos
1. Recuperando a senha de root;
Obtenha acesso via console e faça um “reboot” no sistema. Durante o processo de “boot” 
tecle a barra de espaço continuamente, até que o sistema apresente o prompt “loader>” (ou 
um prompt “OK”, dependendo da plataforma). Nesse momento execute “boot -s” para iniciar 
o sistema no modo “single-user”.
. . . TRIMMED . . . 
Hit [ENTER] to boot immediately, or space bar for command prompt.
<user presses Spacebar>
Type ‘?’ for a list of commands, ‘help’ for more detailed help.
loader> boot -s
Terminado o processo de “boot” em modo “single-user”, o sistema perguntará se o usuário 
deseja operar o equipamento através de um “shell” ou se deseja recuperar a senha de “root”. 
Neste ponto, deve-se executar o comando “recovery”:
. . . TRIMMED . . . 
Enter full pathname of shell or ‘recovery’ for root password 
recovery or RETURN for /bin/sh: recovery
Depois de uma série de mensagens, a CLI inicia e apresenta o prompt do modo de operação. 
Nesse ponto pode-se executar um reset da senha de root com o comando: 
set system root-authentication plain-text-password
198
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Em seguida é necessário efetivar o comando com “commit”:
[edit]
Root# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
Root# commit
commit complete
O próximo passo é deixar o modo de configuração. Nesse momento o sistema perguntará 
se o usuário deseja executar um “reboot”. Escolhendo a opção “Y” (Yes), o sistema será reini-
ciado. Uma vez que o “reboot” está completo, já será possível se conectar com a nova senha 
de “root”.
[edit]
root# exit
Exiting configuration mode
root> exit
Reboot the system? [y/n] y
2. Fazendo o upgrade do Junos;
Copie o arquivo da pasta “junos” para “/var/tmp/”.
Execute o seguinte comando:
request system software add no-validate /var/tmp/<imagem do Junos>
Após a execuçãodeste comando, se tudo correu bem, o sistema solicitará um reboot.
3. Acessando a interface gráfica;
Usar a sequência de comandos descrita no Capítulo 11 , páginas 27 a 33, título: “Processo de 
login na J-Web”.
199
 
C
ap
ítu
lo
 1
0 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
7
4. Acessando via SSH;
Para acessar o roteador remotamente com o protocolo SSH, basta utilizar o software livre 
PuTTY, informando o IP do roteador remoto, bem como usuário e senha.
Figura 10.2 
Configuração 
PuTTY.
200
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
201
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
ob
je
tiv
os
conceitos
11
Fundamentos de roteamento
Descrever o processo de roteamento de camada 3 e conceituar roteamento estático 
e sua configuração no roteador.
 
Fundamentos de roteamento, roteamento estático. 
 
Conceitos de roteamento
Roteamento, na sua forma mais básica, é o processo de mover dados entre redes de camada 3. 
A figura seguinte exibe um exemplo de topologia de rede contendo vários equipamentos L3 
(roteadores). Entre esses equipamentos estão as chamadas redes L3.
Server A Server B
User A
User B
Data center
Internet
q 1 Apesar dos roteadores serem os equipamentos mais populares para a tarefa de rote-
amento, outros dispositivos podem realizar essa função, como switches e firewalls. 
 1 Até mesmo alguns modems, utilizados em conexões ADSL de pequenos escritórios ou 
residências, são capazes de rotear pacotes L3. 
 1 A internet pode ser definida como um amplo conjunto de redes L3 interligadas.
Figura 11.1 
Redes L3.
202
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Componentes do roteamento
Os componentes do roteamento podem ser divididos em dois grupos: 
1. Os recursos que garantem um ou mais caminhos fim a fim entre os destinos.
2. Os recursos que garantem a inteligência para usar o caminho mais adequado para a 
comunicação.
O processo de roteamento dos equipamentos de rede implementa o segundo item.
User A
User B
Data center
Internet
No exemplo da figura existe um caminho físico entre as duas redes destacadas e a internet. 
Uma vez que esse caminho físico está configurado e opera corretamente, o primeiro recurso 
está garantido.
Para implementar o segundo recurso, todos os dispositivos de camada 3 que participam do 
caminho físico precisam ter as informações de roteamento pertinentes. Além disso, os PCs 
e servidores dentro da rede de usuários e do datacenter precisam configurar o parâmetro 
“default gateway” adequadamente (o “default gateway” será o roteador que atende a cada 
uma dessas redes, ou seja, o primeiro elemento de camada 3 do caminho físico entre os 
usuários de cada rede local e o restante do “mundo”).
O “default gateway” de cada rede local precisa determinar o “próximo hop” apropriado para 
cada pacote de tráfego de trânsito que chega em suas interfaces. Os equipamentos que 
executam o Junos usam os dados armazenados na Forwarding Table (FT) para tomar essa 
decisão. A FT contém um subconjunto das informações contidas na tabela de rotas.
Figura 11.2 
Componentes do 
roteamento.
203
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Rotas diretamente conectadas
10.2.2.0/24
10.1.1.0/24
.1 .1
User A
User B
Data center
Internet
A figura apresenta um cenário de roteamento simples, onde os usuários da rede local da 
esquerda desejam acessar dados na rede do datacenter. Para que um dispositivo consiga 
trocar dados com um equipamento fora da sua própria rede local, a figura do “default 
gateway” se faz necessária, e a configuração desse ator deve estar corretamente executada. 
No cenário da figura, o usuário “A” precisa configurar o parâmetro “default gateway” de sua 
máquina com o endereço IP do roteador na sua LAN (10.1.1.1). Da mesma forma, os equipa-
mentos na LAN do datacenter devem configurar seu “default gateway” com o endereço 10.2.2.1.
O roteador, que funciona como gateway das redes locais da figura, requer a informação de 
roteamento suficiente para determinar o “próximo hop” que conseguirá encontrar a rede de 
destino, referente ao tráfego entre as duas redes locais. Nesse exemplo, o roteador aprendeu 
essa informação através da própria configuração de endereço IP de suas interfaces. Uma vez 
que o equipamento tem um IP na rede 10.2.2.0\24 e outro na rede 10.1.1.0\24, ao receber um 
pacote endereçado para qualquer uma dessas redes, ele já saberá por qual interface o pacote 
deve sair. Portanto, para a comunicação entre as duas redes locais do exemplo, não é neces-
sária a configuração de nenhum protocolo de roteamento.
Dessa forma, ao configurar um endereço IP e uma máscara em uma interface do roteador, 
automaticamente a rota para a rede correspondente passa a popular a tabela de rotas e 
também a FT, sem necessidade de nenhum protocolo de roteamento. Esse tipo de rota 
aparece na tabela de rotas como “rota diretamente conectada”.
Tabela de rotas
Routing
table
OSPFOSPFOSPF
Dire
Static
Forwarding
table
Routing
protocol
databases
Other routing
information
sources
Figura 11.3 
Exemplo de 
roteamento.
Figura 11.4 
Tabela de rotas.
204
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
A tabela de rotas do Junos consolida a informação de rotas recebidas de múltiplas fontes de 
roteamento, incluindo os vários protocolos de roteamento que podem estar em execução na 
máquina, as rotas estáticas (adicionadas manualmente pelo administrador do roteador) e as 
rotas diretamente conectadas. 
q 1 Quando o equipamento recebe múltiplas informações de rotas para um dado 
prefixo é preciso selecionar dentre as várias informações recebidas a que será 
efetivamente usada. 
 1 Essa rota será a rota ativa para o prefixo. 
 1 Opcionalmente pode-se fazer com que o Junos considere mais de uma rota para ser 
ativada, balanceando tráfego entre duas ou mais rotas. 
 1 Cada rota ativa para cada prefixo popula a Forwarding Table. 
 1 A FT determina a interface de saída e a operação de encapsulamento L2, que deverá 
ser usada para cada pacote que sai de uma interface.
Múltiplas tabelas de rotas
q 1 Equipamentos que rodam o Junos podem acomodar várias tabelas de rotas. 
 1 A tabela primária se chama “inet.0”, e armazena as rotas “unicast” de IP versão 4. 
 1 Outras tabelas podem existir. Um exemplo é a “inet6.0”, que o Junos cria quando é 
usada configuração de IP versão 6.
A seguir uma lista das diferentes tabelas de rotas que podem ser criadas pelo Junos 
quando necessário:
 1 inet.0: usada para armazenar rotas “unicast” de IP versão 4.
 1 inet.1: usada para cache de rotas “multicast”.
 1 inet.2: usada para armazenar rotas MBGP para checagem de Reverse Path 
Forwarding (RPF).
 1 inet.3: usada para informação de encaminhamento de MPLS.
 1 inet.4: usada para armazenar rotas MSDP.
 1 inet.6.0: usada para armazenar rotas “unicast” IP versão 6.
 1 mpls.0: usada para armazenar informações de “próximo hop” do protocolo MPLS.
Preferência de rotas: selecionando a rota ativa
q 1 Junos utiliza o recurso de “route preference” para diferenciar rotas recebidas por 
diferentes protocolos de roteamento. 
 1 “Route preference” é equivalente à distância administrativa usada em equipamentos 
de outros fabricantes. 
 1 A tabela abaixo mostra a “route preference” default das fontes mais populares de 
informação de rotas.
205
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Routing information source Default preference
Direct 0
Local 0
Static 5
OSPF internal10
RIP 100
OSPF AS external 150
BGP (EBGP e IBGP) 170
Quanto menor o valor da “route preference”, mais preferível é a rota. O valor da “route 
preference” é o primeiro critério utilizado pelo Junos para escolher entre rotas de diferentes 
fontes recebidas para um mesmo prefixo.
A tabela abaixo exibe a lista completa do valor de “route preference” para todas as fontes de 
informação de roteamento com as quais o Junos trabalha.
Direct 0 SNMP 50
Local 0 Router discovery 55
System routes 4 4 RIP 100
Static and Static LSPs 5 RIPng 100
RSVP-signaled LSPs 7 DVMRP 110
RSVP-signaled LSPs 9 Aggregate 130
OSPF internal 10 OSPF AS external 150
IS-IS Level 1 internal 15 IS-IS Level 1 external 160
IS-IS Level 2 internal 18 IS-IS Level 2 external 165
Redirects 30 BGP (internal and external) 170
Kernel 40 MSDP 175
Os valores podem variar entre 0 e 4.294.967.295. Os comandos a seguir demonstram que 
uma rota estática com “route preference” de 5 é preferida em relação à rota OSPF internal, 
que tem valor 10. O caractere asterisco (*) detalha a rota escolhida para ativação, e que foi 
passada à FT.
user@host> show route 192.168.36.1 exact
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.36.1/32 *[Static/5] 00:00:31
 > to 10.1.1.2 via ge-0/0/10.0
Tabela 11.1 
Preferência de 
rotas.
Tabela 11.2 
Tabela completa 
“route preference”.
206
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
 [OSPF/10] 00:02:21, metric 1
 > to 10.1.1.2 via ge-0/0/10.0
No exemplo de preferência de rotas, as rotas estática e OSPF estão com seus valores de 
“route preference” default. É possível mudar esses valores para uma determinada fonte 
de informação, com a intenção de fazer dessa fonte, por exemplo, a mais preferível (ou a 
menos preferível) em uma situação onde ela não o seria. A exceção são as rotas diretamente 
conectadas e rotas locais que serão sempre preferidas, independente do valor de “route 
preference” das outras fontes de informação.
q 1 Quando o roteador recebe a mesma rota (para um mesmo prefixo), com o mesmo custo, 
de um mesmo protocolo fonte (de modo que o “route preference” fica empatado), o 
“route protocol process” (rpd) ativará mais de uma rota e selecionará aleatoriamente um 
dos caminhos a ser usado por cada pacote que é destinado ou prefixo em questão. 
 1 Essa abordagem proverá distribuição de carga entre as diferentes rotas.
A saída do comando seguinte ilustra essa situação:
user@host> show route 10.1.0.0/16
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.0/24 *[Static/5] 00:00:25
 to 172.20.66.2 via ge-0/0/2.0
 > to 172.20.77.2 via ge-0/0/3.0
10.1.2.0/24 *[Static/5] 00:00:25
 > to 172.20.66.2 via ge-0/0/2.0
 to 172.20.77.2 via ge-0/0/3.0
10.1.3.0/24 *[Static/5] 00:00:25
 to 172.20.66.2 via ge-0/0/2.0
 > to 172.20.77.2 via ge-0/0/3.0
10.1.4.0/24 *[Static/5] 00:00:25
 > to 172.20.66.2 via ge-0/0/2.0
 to 172.20.77.2 via ge-0/0/3.0
Nesse cenário, se desejado, pode-se habilitar o balanceamento de tráfego através das múlti-
plas rotas com base em fluxo de dados. Por definição, o balanceamento seria por pacote. 
O detalhamento das configurações de roteamento está fora do escopo desse curso.
207
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Verificando a tabela de rotas
O comando “show route” exibe a tabela de rotas:
user@host> show route 
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden) 
----- Route table name
+ = Active Route, = Last Active, * = Both 
10.1.1.0/24 *[Static/5] 00:10:24 ------ Route source and preference
 > to 172.29.30.253 via ge-0/0/10.0
 [OSPF/10] 00:03:38, metric 2
 > to 172.18.25.2 via ge-0/0/13.0
172.18.25.0/30 *[Direct/0] 00:11:05
 > via ge-0/0/13.0
172.18.25.1/32 *[Local/0] 00:11:05
 Local via ge-0/0/13.0
172.29.30.0/24 *[Direct/0] 00:11:05
 > via ge-0/0/10.0
172.29.30.1/32 *[Local/0] 00:11:05
 Local via ge-0/0/10.0 ----- Asterisk (*) indicates that he 
route is selected as active
...
Sem usar nenhum argumento, o comando anterior exibe o conteúdo completo de todas as 
tabelas de rotas da caixa. Está destacado que todas as rotas ativas ficam marcadas com um 
asterisco (*). Cada entrada da tabela de rotas mostra a fonte através da qual o equipamento 
aprendeu a informação, bem como a sua “route preference”.
 1 O comando “show route” mostra um sumário das rotas ativas, em “holddown” e escon-
didas.
 1 As rotas ativas são aquelas efetivamente usadas para o encaminhamento do tráfego.
 1 Rotas em “holddown” estão no estado pendente, e futuramente poderão ser usadas, 
se necessário.
 1 Rotas escondidas são aquelas que o sistema não pode usar por alguma razão, tal como 
parâmetro “próximo hop” inválido ou uma “route policy” impede que ela possa ser usada.
É possível filtrar a saída do comando por prefixo de interesse, tipo de protocolo e outros 
atributos. O exemplo seguinte exibe uma forma filtrada do comando, que traz apenas rotas 
aprendidas via protocolo de roteamento OSPF. 
208
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
user@host> show route protocol ospf
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.0/24 [OSPF/10] 04:57:41, metric 2
 > to 172.18.25.2 via ge-0/0/13.0
224.0.0.5/32 *[OSPF/10] 05:00:58, metric 1
 MultiRecv
Repare que apesar do comando retornar apenas duas rotas, o contador de rotas continua 
trazendo o valor total presente na tabela.
Forwarding Table (FT)
Routing
table
OSPFOSPFOSPF
Dire
Static
Forwarding
table
Routing
protocol
databases
Other routing
information
sources
A FT armazena um subconjunto da tabela de rotas. Dentro da FT, pode-se encontrar deta-
lhes usados pelo equipamento que executa o Junos para encaminhar pacotes, como os 
prefixos de destino e suas respectivas interfaces de saída associadas.
O comando “show route forwarding-table” fornece acesso às informações da FT:
user@host> show route forwarding-table
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef 
Netif
default user 0 0:17:cb:4e:ae:81 ucst 520 3 ge-
0/0/0.0
default perm 0 rjct 36 1
0.0.0.0/32 perm 0 dscd 34 1
172.19.0.0/16 user 0 200.1.4.100 ucst 535 3 ge-
0/0/3.0
172.19.52.0/24 user 0 200.1.2.100 ucst 529 3 ge-
0/0/1.0
172.19.52.16/28 user 0 200.1.3.100 ucst 534 3 ge-
Figura 11.5 
Forwarding Table.
209
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
0/0/2.0
…
O exemplo mostra que o kernel do Junos adiciona algumas entradas nessa tabela e as 
mantém permanentemente. Um exemplo é a entrada com o destino “default”, que con-
templa todos os pacotes que não são contemplados por nenhuma outra entrada. Quando 
um pacote é contemplado pela entrada default, é descartado, e uma mensagem ICMP de 
“destination unreachable” é enviada ao remetente do pacote.
Quando o administrador configura uma rota default na tabela de rotas (apontando para o 
destino 0.0.0.0\0), a tabela FT passa a usar essa rotaao invés da entrada default.
qCada entrada na FT mostrada no exemplo possui um tipo (type). A lista abaixo detalha 
“route types” comuns encontradas na FT:
 1 intf: instaladas como resultado da configuração de endereço IP em uma interface. 
 1 perm: instaladas pelo kernel quando a tabela de rotas se inicia.
 1 user: instaladas por um protocolo de roteamento como resultado de uma configuração.
Cada entrada na FT mostrada também possui um tipo de “next hop”. A lista abaixo 
detalha “next hop types” comuns encontrados na FT:
 1 bcst: o “next hop” é um endereço broadcast.
 1 rjct: descarta o pacote e envia mensagem ICMP de “unreachable” para o remetente.
 1 ucst: “next hop” do tipo unicast.
 1 ulst: há mais de um “next hop” (está sendo usado balanceamento).
 1 dscd: descarta o pacote silenciosamente.
 1 hold: o “next hop” ainda será calculado.
 1 locl: endereço de uma interface local.
 1 mcst: o “next hop” é um endereço multicast.
 1 mdsc: pacotes de multicast para serem descartados.
 1 recv: “next hop” do tipo “receive”.
Determinando o Next Hop
Quando um pacote chega por uma interface, o roteador compara o campo IP destino com as 
entradas dentro da FT, a fim de determinar o “next hop” para o qual o pacote será repas-
sado. Se o pacote é destinado ao equipamento local, o Junos irá processá-lo. Se o pacote é 
destinado a outro dispositivo e existe uma entrada válida na FT que o contempla, o Junos 
transmitirá o pacote ao “next hop” através da interface definida pela FT.
FT
Forwarding plane
Packets in Packets out
Quando múltiplos prefixos contemplam o IP destino do pacote, o Junos utiliza aquele que é o 
mais específico (com a maior máscara), como faz o equipamento de qualquer outro fabricante.
Figura 11.6 
Determinando o 
“next hop”.
210
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
user@host> show route forwarding-table 
Routing table: inet 
Internet: 
Destination Type RtRef Next hop Type Index NhRef 
Netif 
default user 0 0:17:cb:4e:ae:81 ucst 520 3 ge-
0/0/0.0 
default perm 0 rjct 36 1 
0.0.0.0/32 perm 0 dscd 34 1 
172.19.0.0/16 user 0 200.1.4.100 ucst 535 3 ge-
0/0/3.0 
172.19.52.0/24 user 0 200.1.2.100 ucst 529 3 ge-
0/0/1.0 
172.19.52.16/28 user 0 200.1.3.100 ucst 534 3 ge-
0/0/2.0 
...
O exemplo acima exibe uma amostra da FT de um equipamento Juniper. Se um pacote 
destinado ao IP 172.19.52.101 chega por uma interface, ele será contemplado por mais 
de uma entrada da FT: a rota default definida pelo usuário, a rota 172.19.0.0\16 e a rota 
172.19.52.0\24. Como essa última possui o prefixo mais específico, será usada para o enca-
minhamento. Assim, o pacote será repassado ao “next hop” 200.1.2.100.
Analogamente, se um pacote endereçado a 172.25.100.27 chega ao roteador, apenas 
uma entrada o contemplará: a rota default definida pelo usuário. Assim, o pacote será 
encaminhado para a interface de saída ge-0/0/0 e será encapsulado no endereço L2 
00:17:cb:4e:ae:81.
Em situações onde nenhuma entrada da FT contempla o IP destino do pacote, o Junos des-
carta o pacote e envia uma mensagem ICMP de “destination unreachable”.
Instâncias de roteamento
O equipamento Juniper agrupa diferentes tabelas de rotas, interfaces e protocolos de 
roteamento em instâncias de roteamento lógica (routing instances). O roteador mantém a 
informação de roteamento em uma instância de roteamento separada da informação de 
todas as outras instâncias. 
O uso de instâncias de roteamento introduz o conceito de um único dispositivo simulando a 
operação de múltiplos roteadores.
211
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Device Running JUNOS software
Routing instance (master) Routing instance (cust-A) Routing instance (cust-B)
inet.0 
inet6.0
ge-0/0/0.0
ge-0/0/1.0
lo0.0
Default route
OSPF
cust-A.inet.0
cust-A.inet6.0
ge-0/0/3.0
ge-0/0/4.0
lo0.1
Default route
OSPF
cust-B.inet.0
cust-B.inet6.0
ge-1/0/0.0
ge-1/0/1.0
lo0.2
Default route
OSPF
O roteador Juniper cria automaticamente uma instância de roteamento default chamada 
“master routing instance”. Por definição, a instância “master” inclui a tabela “inet.0”, usada 
para rotear todo o tráfego unicast de IPv4. 
user@host> show route instance 
Instance Type Primary RIB Active/holddown/hidden 
master forwarding inet.0 3/0/1
Acima observamos a saída do comando “show route instance”.
O Junos também cria outras instâncias de roteamento privadas, que são usadas para 
comunicação interna entre componentes do hardware. O usuário pode ignorar a existência 
dessas entidades lógicas. O exemplo seguinte exibe todas as instâncias de roteamento 
criadas por default pelo Junos.
user@host> show route instance
Instance Type Primary RIB Active/holddown/hidden 
__juniper_private1__ forwarding
 __juniper_private1__.inet.0 2/0/2
 __juniper_private1__.inet6.0 1/0/0
__juniper_private2__ forwarding
 __juniper_private2__.inet.0 0/0/1
__master.anon__ forwarding
master forwarding
 inet.0 7/0/0
Além das instâncias de fábrica, o Junos permite que o usuário configure instâncias de rote-
amento adicionais através da hierarquia “[edit routing-instances]”. Instâncias definidas pelo 
usuário podem ser usadas para uma variedade de propósitos e provê aos administradores 
de rede mais flexibilidade para lidar com o seu ambiente de rede.
Algumas aplicações típicas de instâncias de roteamento incluem: VPN, virtualização e Filter 
Based Forwarding (FBF). A seguir visualizamos os tipos de instâncias que podem ser criadas.
[edit routing-instances <instance-name>] 
user@host# set instance-type ? 
Tabela 11.3 
Visão geral de 
instâncias de 
roteamento.
212
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Possible completions: 
 forwarding Forwarding instance 
 l2vpn Layer 2 VPN routing instance 
 no-forwarding Nonforwarding instance 
 virtual-router virtual routing instance 
 vpls VPLS routing instance 
 vrf virtual routing forwarding instance 
A lista seguinte detalha os tipos de instâncias:
 1 forwarding: usada para implementar FBF para aplicações.
 1 l2vpn: usada em implementações de VPN de camada 2.
 1 no-forwarding: usada para separar grandes redes em entidades administrativas menores.
 1 virtual-router: usada para aplicações com virtualização do sistema.
 1 vpls: usada em implementações de LAN ponto-multiponto em um conjunto de sites de 
uma VPN.
 1 vrf: usada em implementações de VPN de camada 3.
Os tipos de instâncias de roteamento variam entre diferentes plataformas que rodam o 
Junos. Nem todos os tipos são suportados em todas as plataformas. A seguir um exemplo de 
configuração de instância de roteamento.
[edit routing-instances new-instance] ----- Routing instance name is 
user-defined 
user@host# show 
instance-type virtual-router; ----- Routing instance type 
interface ge-0/0/0.0; ----- Define interfaces under [edit interfaces] 
hierarchy and reference them under the routing instance
interface ge-0/0/1.0; 
interface lo0.1; 
routing-options { 
 static { 
 route 0.0.0.0/0 next-hop 172.26.25.1; 
 } 
} 
protocols { 
 ospf { 
 area 0.0.0.0 { 
 
213
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
interface ge-0/O/0.0; 
 
interface ge-0/0/1.0; 
 interface 100.1; 
 } 
 } 
}
Trabalhandocom Instâncias de Roteamento
Uma vez que uma nova instância de roteamento tenha sido configurada e o roteador tenha 
aprendido informações de rotas dentro da instância, o Junos automaticamente gerará uma tabela 
de rotas. Se o roteador está trabalhando com roteamento IPv4, o software criará uma tabela 
de rotas “unicast” de IPv4. O nome dessa tabela terá o formato “<nome da instância>.inet.0”, 
onde “<nome da instância>” é o nome que o usuário definiu para sua instância de roteamento.
Se o usuário usa IPv6 dentro da mesma instância, o software criará uma tabela “unicast” de 
IPv6, cujo nome terá o formato “<nome da instância>.inet.6.0”.
Abaixo temos o conteúdo da tabela de rotas unicast IPv4 da instância de roteamento 
“new-instance”, que foi criada pelo usuário do sistema.
user@host> show route table new-instace.inet.0 
new-instace.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 
0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 02:06:18
 > to 172.26.25.1 via ge-0/0/0.0
172.25.182.0/24 *[Direct/0] 02:06:18
 > via ge-0/0/1.0
172.25.182.5/32 *[Local/0] 02:06:18
 Local via ge-0/0/1.0
172.26.25.0/24 *[Direct/0] 02:06:18
 > via ge-0/0/0.0
172.26.25.5/32 *[Local/0] 02:06:18
 Local via ge-0/0/0.0
214
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
192.168.100.52/32 *[Direct]0] 02:06:18
 > via lo0.1
O comando é o mesmo “show route” já conhecido, mas com o argumento “table <nome da 
tabela desejada>”.
Adicionalmente, o comando já conhecido “show interfaces terse” pode ser alterado de modo 
a exibir apenas as interfaces que fazem parte de uma determinada instância de roteamento. 
O exemplo abaixo ilustra a saída do comando.
user@host> show interfaces terse routing-instance new-instance
Interface Admin Link Proto Local Remote
ge-0/0/0.0 up up inet 172.26.25.5/24
ge-0/0/1.0 up up inet 172.25.182.5/24
lo0.1 up up inet 192.168.100.52 --> 0/0
Adicionalmente os comandos “ping” e “traceroute” podem ser executados a partir de uma 
instância de roteamento específica.
user@host> ping 172.26.25.1 rapid count 25 routing-instance new-
instance
PING 172.26.25.1 (172.26.25.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.26.25.1 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.014/1.875/2.073/0.285 ms
user@host> traceroute 192.168.100.25 routing-instance new-instance
traceroute to 192.168.100.25 (192.168.100.25), 30 hops max, 40 byte 
packets
1 192.168.100.25 (192.168.100.25) 4.536 ms 4.503 ms 2.209 ms
Roteamento estático
qRotas estáticas são usadas em um ambiente de rede para se atingir uma variedade de 
objetivos. São popularmente usadas em duas situações:
 1 Só há um único caminho para se atingir um determinado prefixo.
 1 Há múltiplos caminhos para se chegar a um prefixo, mas se quer forçar a rede a enca-
minhar o tráfego sempre pelo mesmo caminho (exceto em caso de falhas).
215
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Network A
172.29.100.0/24
192.168.63.14172.30.25.0/30
Internet
.1 .1.2
ge-0/0/1
A figura anterior ilustra uma situação onde a rede 172.29.100.0\24 está ligada à internet por 
um único caminho. Nesse caso não há motivo para usar um protocolo de roteamento dinâ-
mico para acessar a internet. Ao invés disso, o usuário configurou uma rota default estática 
(para o destino 0.0.0.0\0), que aponta para a interface ge-0/0/1. Dessa forma, ao executar 
o comando “show route 192.168.63.14”, o sistema calculou dentre as entradas da tabela de 
rotas que a entrada mais específica que contempla esse destino é a rota para 0.0.0.0\0.
q 1 A configuração de rotas estáticas é sempre feita na hierarquia “[edit routing-options]”.
 1 Ao configurar uma rota estática é necessário definir um “next hop” válido. 
 2 Normalmente esse parâmetro é definido através do endereço IP de um roteador 
vizinho que fica na direção do prefixo em questão. 
 1 Em interfaces ponto a ponto (e apenas nessa situação) pode-se especificar o nome da 
interface de saída como o “next hop”, ao invés de usar o IP do equipamento vizinho.
 1 Outra possibilidade é o “next hop” tomar os valores “reject” ou “discard”. 
 2 Um pacote cujo IP destino é contemplado por uma entrada cujo “next hop” é 
“reject” ou “discard” será descartado. 
 1 A diferença entre essas opções é a ação que o Junos toma após o descarte. 
 2 Se a opção usada é o “reject”, o sistema envia uma mensagem ICMP de “destination 
unreachable” para o remetente. 
 2 Se a opção usada é “discard”, o sistema descartará o pacote silenciosamente. 
O endereço IP especificado no “next hop” de uma rota estática deve ser alcançável usando 
uma rota diretamente conectada. Diferente do software de outros fabricantes, o Junos, por 
default, não executa buscas recursivas de “next hop” quando se trata de rotas estáticas.
Uma rota estática sempre estará na tabela de rotas até que o usuário a remova ou até que 
ela se torne inativa. Uma rota estática se torna inativa quando o IP do seu “next hop” se 
torna inacessível (por uma falha na rede, por exemplo).
Configurando Rotas Estáticas
A seguir um exemplo de configuração de roteamento estático:
[edit routing-options] 
user@host# show 
rib inet6.0 { 
 static { 
 route 0::/0 next-hop 3001::1; ----- IPv6 default static route 
 } 
} 
Figura 11.7 
Exemplo de rota 
default estática.
216
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
static { 
 route 0.0.0.0/0 next-hop 172.30.25.1; ----- 1Pv4 default static 
route 
 route 172.28.102.0/24 { 
 next-hop 10.210.11.190; 
 no-readvertise; 
 } 
}
Além dos parâmetros já discutidos, destaca-se o uso da opção “no-readvertise”, que, no 
Junos, proíbe que a rota especificada seja redistribuída em um protocolo de roteamento 
dinâmico. Dessa forma, a rota não será propagada por nenhum protocolo de roteamento.
Monitorando Rotas Estáticas
A seguir uma variação do comando “show route”, que exibe apenas as rotas provenientes de 
configuração manual de rotas estáticas. Para tal foi usado o complemento “protocol static”.
user@host> show route protocol static 
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 
+ = Active Route, - = Last Active, * = Both 
0.0.0.0/0 *[Static/5] 00: 41 :59 
 > to 17 2.30. 25. 1 Vla ge-0/0/ 1 .0 
 ----- Default static route
...
user@host> ping 192.168.63.14 rapid count 25
PING 192.168.63.14 (192.168.63.14): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!
--- 192.168.63.14 ping statistics ---
25 packets transmitted, 25 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.027/0.057/0.145/0.032 ms
Uma vez instaladas as rotas estáticas devidas, a conectividade entre as redes pode ser verifi-
cada através do comando “ping”, exemplificado acima.
Resolvendo Next Hops indiretos
Por definição, diferente dos equipamentos de outros fabricantes, o Junos precisa que o ende-
reço IP do “next hop” de uma rota estática esteja diretamente acessível via um link ponto a 
ponto ou via uma LAN. Ou seja, o Junos não executa buscas recursivas de “next hops” indiretos.
217
 
C
ap
ítu
lo
 1
1 
- F
un
da
m
en
to
s 
de
 r
ot
ea
m
en
to
 
Host A Host B Host C
.1
172.25.1.0/30 172.25.1.4/30 172.20.3.0/24
.2 .5 .6 .1
[edit routing-option] 
user@Host-A# show 
static { 
 route 172.20.3.0/24 { 
 next-hop 172.25.1.6; 
 resolve; 
 } 
}
Conforme ilustrado acima, é possível alterar esse comportamento default do Junose fazer 
com que as buscas recursivas sejam usadas. Para isso deve-se usar a opção “resolve” na rota 
estática em questão.
A figura anterior mostra uma rota estática que define um roteador remoto, 172.25.1.6, que 
não está conectado diretamente ao Host A, como o “next hop” da rede 172.20.3.0\24. Nesse 
caso, ao receber um pacote IP destinado ao prefixo remoto 172.20.3.0\24, o roteador não 
saberá, num primeiro momento, em qual interface está o “next hop” 172.25.1.6. Uma busca 
recursiva será necessária, ou seja, o roteador deverá achar na tabela de rotas uma rota que 
contemple o IP 172.25.1.6. Essa rota também será usada para encaminhar o pacote para o 
172.20.3.0\24. Dessa forma, o pacote será entregue.
Normalmente, o roteamento que usa buscas recursivas funciona bem em ambientes onde 
há um protocolo de roteamento dinâmico que anuncia as redes /30 que endereçam as inter-
faces dos links ponto a ponto. Ou seja, ainda se referindo ao último exemplo, a rota para o 
IP do “next hop” remoto 172.25.1.6 será, tipicamente, uma rota obtida através de protocolo 
dinâmico. Se não fosse assim, o usuário deveria configurar manualmente outra rota estática 
para contemplar o IP do “next hop”, o que não é algo escalável.
Qualified Next Hop
Ao definir uma rota estática é possível utilizar a opção “qualified-next-hop” para definir uma 
rota alternativa independente das rotas previamente definidas. A figura seguinte exibe a 
configuração e o conceito desse tipo de rota.
Network A
172.29.100.0/24
172.30.25.4/30
172.30.25.0/30
secondary
primary
Internet
.1
.1
.5
ge-0/0/1
.2
.6
ge-1/0/0
Figura 11.8 
Resolvendo “next 
hop” indireto.
Figura 11.9 
Qualified Next Hop.
218
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
[edit routing-options]
user@host# show
static {
 route 0.0.0.0/0 {
 next-hop 172.30.25.1; 
 qualified-next-hop 172.30.25.5 
 preference 7;
 }
 }
}
Na figura, o “next hop” 172.30.25.1 assume o tráfego destinado à rota estática default, 
com “route preference” igual a 5 (valor default para rotas estáticas). Em paralelo, o usuário 
definiu uma rota estática “qualified” para o “next hop” 172.30.25.5, definindo para ela a 
“route preference” 7. Dessa forma, todo o tráfego a ser encaminhado pela rota default usará 
o “next hop” 172.30.25.1. Em um cenário onde esse nó falha, a rota “qualified” será então uti-
lizada. Outros fabricantes chamam esse tipo de implementação de rota estática flutuante.
219
 
C
ap
ítu
lo
 1
1 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
8
Roteiro de Atividades 8
Atividade 8.1 – Configurando rota estática
Para esta atividade usaremos a topologia descrita na figura a seguir.
10.0.80.254/24 10.0.70.254/24
8 7
10.0.60.254/24 10.0.50.254/24
6 5
10.0.40.254/24 10.0.30.254/24
4 3
10.0.20.254/24 10.0.10.254/24
2 1
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
Mesa do 
Instrutor
10.0.160.254/24 10.0.150.254/24
16 15
10.0.140.254/24 10.0.130.254/24
14 13
10.0.120.254/24 10.0.110.254/24
12 11
10.0.100.254/24 10.0.90.254/24
10 9
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
17
ROT D
0/1
ROT C
0/1
ROT B
0/1
ROT A
0/1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
0/2 - 172.16.1.2
0/0 - 172.16.2.2
0/0 - 172.16.2.1
0/2 - 172.16.1.1
24 23 22 21 20 19 18
10.0.240.254/24 10.0.230.254/24 10.0.220.254/24 10.0.210.254/24 10.0.200.254/24 10.0.190.254/24 10.0.180.254/24 10.0.170.254/24
Após efetuar as ligações dos cabos conforme descrito para cada bancada, execute os 
comandos de configuração a seguir.
Figura 11.10 
Topologia da 
Atividade 8.1.
220
 
In
tr
od
uç
ão
 à
 re
de
 Ip
ê
Utilizar a ge-0/0/1, ge-0/0/2 e a E1-1/0/0 no exercício.
Comandos roteador “A”:
set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.1/24
set interfaces ge-0/0/1 unit 0 family inet address 10.0.10.254/24
set interfaces ge-0/0/2 unit 0 family inet address 10.0.20.254/24
Verifique se a interface E1-1/0/0 já possui IP configurado:
#show interfaces e1-1/0/0 unit 0 family inet address
Delete a configuração de IP da interface e1:
# delete interfaces e1-1/0/0 unit 0 family inet address <ip já 
existente / mascara>
# commit
# set interfaces e1-1/0/0 unit 0 family inet address <novo ip / 
mascara>
# commit
Comandos roteador “B”:
set interfaces ge-0/0/0 unit 0 family inet address 172.16.2.2/24
set interfaces ge-0/0/1 unit 0 family inet address 10.0.30.254/24
set interfaces ge-0/0/2 unit 0 family inet address 10.0.40.254/24
 1 Para os roteadores “c” e “d” mude os endereços de acordo com a sua bancada. Os endereços 
acima são para as bancadas da frente; para as demais bancadas siga o desenho da figura.
 1 Verifique a conectividade com o PC remoto do outro roteador:
 ping <IP do PC remoto do outro roteador>
 1 Há conectividade? Por quê?
 1 Execute “show route <IP do PC remoto do outro roteador>”. Você deve perceber que não 
existe rota para o endereço IP remoto.
 1 Entre no modo de configuração com “configure private”, e crie as rotas para o PC remoto 
com os seguintes comandos:
Comandos roteador “A”:
set routing-options static route 10.0.30.0/24 next-hop 172.16.1.2
set routing-options static route 10.0.30.0/24 next-hop 172.16.2.2
set routing-options static route 10.0.40.0/24 next-hop 172.16.1.2
set routing-options static route 10.0.40.0/24 next-hop 172.16.2.2
221
 
C
ap
ítu
lo
 1
1 
- R
ot
ei
ro
 d
e 
A
ti
vi
da
de
s 
8
Comandos roteador “B”:
set routing-options static route 10.0.10.0/24 next-hop 172.16.1.1
set routing-options static route 10.0.10.0/24 next-hop 172.16.2.1
set routing-options static route 10.0.20.0/24 next-hop 172.16.1.1
set routing-options static route 10.0.20.0/24 next-hop 172.16.2.1
 1 Para os roteadores “c” e “d” mude os endereços de acordo com a sua bancada. Os endereços 
acima são para as bancadas da frente; para as demais bancadas siga o desenho da figura.
 1 Em seguida verifique a conectividade com “run ping <IP do PC remoto do outro roteador”. 
Há conectividade? Por quê?
 1 Execute o comando “show | compare” para checar a diferença entre a configuração can-
didata e a configuração ativa.
 1 Execute o comando “commit” e saia do modo de configuração. Em seguida teste nova-
mente a conectividade com o PC remoto do outro roteador. Há conectividade?
 1 Entre no modo de configuração com “configure private” e remova a rota estática criada 
com “delete routing-options static route <prefixo> next-hop <NH>”.
 1 Execute “show | compare” e em seguida “commit”.
 1 Teste a conectividade com o PC remoto do outro roteador com “run ping <IP do PC 
remoto do outro roteador >”. Há conectividade?
 1 Retorne a última alteração. 
 1 Execute “rollback 1” e em seguida “show | compare”. Os comandos adicionados à configu-
ração candidata com o “rollback” retornam a rota recém removida?
 1 Se sim, execute “commit”, teste a conectividade e saia do modo de configuração.
 1 Execute “show route” para verificar as rotas recém adicionadas na tabela de rotas.
Qual a “route preference” e a métrica/custo da rota que você adicionou?
 1 Altere a métrica e a distância administrativa da rota que você instalou.
 set routing-options static route <prefixo> metric 33
 set routing-options static route <prefixo> preference 26
 1 Execute