Introdução à rede Ipê

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 (MCTI)

e

responsável

pelo

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.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

Introdução à

Rede Ipê

Gustavo Batista

Introdução à

Rede Ipê

Gustavo Batista

Rio de Janeiro Escola Superior de Redes 2013

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 encontrado 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 [email protected]. 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 [email protected]

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

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

iii

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 iv

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 v

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

vi

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 Junos 131

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 vii

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 viii

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

ix

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

x

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsá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 educacionais 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 contextualizadas 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 problema, 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 aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

xi

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 problemas 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 atividades práticas para fixação do conteúdo. xii

O Capítulo 2 descreve os procedimentos de segurança, as funções e as atividades executadas 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 conhecimentos 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 desejá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, caracterí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.

xiii

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: [email protected]

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

xiv

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 telecomunicaçõ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.

xv

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 universidades 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 apresentação da própria RNP. Nessa ocasião, a despeito de todas as dificuldades e dos riscos envolvidos, optamos pela estratégia de “ensinar a 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

xvi

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

11 A organização usuária dos serviços da RNP passa a fazer parte do sistema autônomo

q

da RNP. 11 A partir de então, todos os pontos da internet mundial passarão a enxergar a instituição como um cliente da RNP. 11 Os endereços IP usados na rede da instituição serão cedidos pela RNP. 11 Todos os equipamentos da rede local que precisarem do serviço da rede Ipê deverão, necessariamente, usar endereço IP da RNP. 22 É proibido o uso dos serviços da RNP sem o atendimento a esse requisito. 11 Caso a instituição deseje manter os serviços de outro provedor além da RNP, os equipamentos servidos pelo outro provedor não poderão usar endereços IP da RNP. 11 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. 11 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:

Capítulo 1 - Operação da rede Ipê

Sistema autônomo

conceitos

objetivos

Operação da rede Ipê

1

Provedor comercial

RNP

LAN organização usuária

Figura 1.1 Hosts com IP RNP não podem usar serviço de outro provedor, e viceversa.

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.

Provedor comercial

RNP

Organização usuária

Figura 1.2 Cenário permitido em instituição com dois provedores.

Hosts com IP de terceiro

Hosts com IP da RNP

Serviços IP fundamentais da RNP Serviços de tráfego da RNP Introdução à rede Ipê

11 As instituições primárias e secundárias poderão cursar todo o seu tráfego pela RNP. 11 Elas estão aptas a utilizar em sua totalidade os serviços IP fundamentais da RNP, a saber: 22 Trânsito Nacional. 22 Trânsito Internacional. 22 Trânsito Acadêmico de Colaboração. 22 Trânsito de Peering. A definição de cada um desses serviços é ilustrada a seguir. 2

q

Trânsito Nacional É definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas,

q

recursos e sistemas localizados em algum ponto do país conectado à rede Ipê, direta ou indiretamente através de uma rede regional.

Cliente Internet Commodity Nacional

PoP BACKBONE

Figura 1.3 Exemplo de Trânsito Nacional.

Trânsito Internacional É definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas,

q

recursos e sistemas localizados em algum ponto fora do país através da internet global.

Cliente Internet Commodity Internacional

PoP BACKBONE

Figura 1.4 Exemplo de Trânsito Internacional.

Trânsito Acadêmico de Colaboração É definido como a facilidade de serviço que permite ao cliente da RNP acessar pessoas,

q

recursos e sistemas localizados em algum ponto nas redes acadêmicas no Brasil e em outros países.

Cliente

PoP BACKBONE

Figura 1.5 Exemplo de Trânsito Acadêmico de Colaboração.

Trânsito de Peering É 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-

q


Internet Acadêmica Internacional

lecidos entre a rede Ipê e essas redes. 3

PTT

Cliente Empresa Privada

PoP BACKBONE

Figura 1.6 Exemplo de Trânsito de Peering.

A figura seguinte resume os serviços fundamentais aos quais o cliente da RNP tem acesso: Cliente B Cliente A RedeComep

Empresa Privada

4

PoP

3

Rede Acadêmica Estadual

3

PTT

1

2

Provedor Internet Commodity Nacional

BACKBONE

Internet Acadêmica Internacional

Provedor Internet Commodity Internacional Figura 1.7 Serviços fundamentais RNP.

Os números das setas estão associados aos serviços da seguinte maneira: 11 Trânsito Nacional: seta 1; 11 Trânsito Internacional: seta 2; 11 Trânsito Acadêmico: setas 3;

Introdução à rede Ipê

11 Trânsito de Peering: seta 4.

Outros serviços da RNP 11 Serviços de comunicação e colaboração: 22 Conferência web. 22 fone@RNP. 22 Videoconferência. 22 Telepresença.

4

q

11 Serviços de Disponibilização de Conteúdos Digitais:

q

22 Videoaula@RNP. 22 Vídeo sob Demanda. 22 Transmissão de Sinal de TV. 22 Transmissão de Vídeo ao Vivo. 11 Serviços de Gestão de Identidade: 22 Comunidade Acadêmica Federada (CAFe). 22 eduroam. 22 Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu). 11 Serviços de Hospedagem Estratégica: 22 Internet Data Center (IDC). 11 Apoio aos serviços: 22 Service Desk. Os serviços disponibilizados pela RNP às suas organizações usuárias são resultados de processos 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 facilitar 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: 11 Serviços de Comunicação e Colaboração: 22 Conferência web. 22 fone@RNP. 22 Videoconferência. 22 Telepresença. 11 Serviços de Disponibilização de Conteúdos Digitais: 22 Videoaula@RNP. 22 Vídeo sob Demanda. 22 Transmissão de Sinal de TV. 22 Transmissão de Vídeo ao Vivo.

22 Comunidade Acadêmica Federada (CAFe). 22 eduroam. 22 Infraestrutura de Chaves Públicas para Ensino e Pesquisa (ICPEdu). 11 Serviços de Hospedagem Estratégica: 22 Internet Data Center (IDC).


11 Serviços de Gestão de Identidade:

5

Serviços de comunicação e colaboração A RNP oferece aos seus clientes os seguintes serviços de comunicação e colaboração:

q

11 Conferência web. 11 fone@RNP. 11 Videoconferência. 11 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 compartilhamento 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.


Figura 1.8 Conferência Web.

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 realizar chamadas telefônicas gratuitas para outras instituições distantes geograficamente no Brasil ou no exterior, dentro ou fora da rede VoIP da RNP.

6

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 11 O sistema de estatísticas do fone@RNP (http://estatisticasfone.rnp.br/) visa pro-

q

porcionar uma visão detalhada do uso e da economia que o serviço traz para suas instituições clientes. 11 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.

Figura 1.9 Estatísticas do fone@RNP.


11 A adesão ao sistema é feita como parte da homologação da instituição no serviço.

7

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.

Figura 1.10 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. Verdadeiro estado da arte na tecnologia de videoconferência, o serviço oferece recursos tecnoló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-

8

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.11 Telepresença.

Mais informações sobre o serviço em: http://portal.rnp.br/web/servicos/telepresenca1

Serviços de disponibilização de conteúdos digitais 11 Videoaula@RNP.

q

11 Vídeo sob Demanda. 11 Transmissão de Sinal de TV. 11 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).

9

Figura 1.12 Videoaula@RNP.

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 restritos, que podem ser postados por integrantes das organizações clientes da RNP e assistidos 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 infraestrutura 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 instituiçõ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 permitem que os vídeos


solicitados fiquem temporariamente armazenados, agilizando o acesso regional ao conteúdo.

10

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 economia de banda e a redução do tempo de acesso, já que o cliente não precisa de equipamentos 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 servidores 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 simultâ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.

11

Serviços de Gestão de Identidade A RNP oferece aos seus clientes os seguintes serviços para a gestão de identidade:

q

11 Comunidade Acadêmica Federada (CAFe). 11 eduroam. 11 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 brasileiras 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 educaçã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 potencialmente compartilhados na CAFe. Mais informações sobre o serviço em: http://portal.rnp.br/web/servicos/cafe


Figura 1.14 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.

12

Lançada no Brasil em 2012, a iniciativa internacional já reúne instituições de aproximadamente 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 implantaçã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 eficiê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

Figura 1.15 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

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, quinzenalmente, 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),


com garantia de alta disponibilidade, segurança e operação ininterrupta.

diretamente conectado ao backbone de educação e pesquisa multigigabit da rede Ipê. 13

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 Service Desk 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 entidade. Essa infraestrutura possui um Autonomous System Number (ASN) que a identifica e a formaliza como uma unidade que compõe a Internet Global. 11 A infraestrutura da rede Ipê permitirá atender às aplicações de ensino superior e

q

pesquisa de forma eficiente. 11 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. 11 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. Caso a instituição possua campi ou filiais remotos, a conexão à rede Ipê desses atores poderá ocorrer de duas maneiras:


11 Conexão física e lógica das filiais à rede Ipê se dá diretamente via PoP RNP.

14

11 Conexão física das filiais é via PoP, mas a conexão lógica é com a sede.

q

As duas categorias de conexão são exibidas nas figuras seguintes:

Figura 1.16 Conexão da filial diretamente com o PoP.

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

Figura 1.17 Conexão lógica da filial com a sede.

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. 11 Nesse modelo, a filial é conectada fisicamente ao PoP, mas uma conexão lógica é

q

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


construída de modo que todo o tráfego da filial seja forçado a passar pela sede.

15

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. O uso desses serviços não será permitido nas seguintes condições:

q

11 Transmissão de materiais considerados ilegais por caracterizarem: 22 Transgressão de direitos autorais. 22 Agressão à criança e ao meio ambiente. 22 Atentado à privacidade ou discriminação racial ou religiosa. 22 Disseminação de propaganda comercial, política ou religiosa. 22 Transmissão de material de propaganda não solicitado pelo destinatário (spam). 22 Atividades estritamente comerciais. 22 Atividades que contribuam para o esgotamento excessivo dos recursos da rede, sejam computacionais, comunicacionais ou humanas. 22 Promoção de corrupção ou destruição de dados de usuários. 22 Atividades prejudiciais à utilização dos serviços de rede por outros usuários. 22 Interligação ou abrigo em seu espaço de endereçamento de uma terceira instituição, não qualificada para usar serviços da RNP.

Figura 1.18 Interligação proibida de instituição não qualificada.

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

Figura 1.19 Interligação típica entre organização usuária e Pop.

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: 11 Uplink da organização usuária (seta na parte inferior da figura);

Porta console Interface de equipamento 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.

11 Downlink da organização usuária (seta na parte superior da figura). Em geral essas duas interfaces fazem parte de uma sub-rede IP com dois endereços

q

(rede /30). Um dos endereços é associado ao downlink e o outro é associado ao uplink. 11 O primeiro procedimento a ser executado para verificação da saúde da conexão local

q

é a verificação do estado do roteador Juniper da instituição e da interface de uplink. 11 Para tal deve-se proceder com as seguintes verificações: 22 Verificar se o roteador está ligado e operacional. 22 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. 22 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. 11 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”. 11 Há algum erro explícito de hardware e/ou software? Deve-se abrir um chamado no PoP detalhando o ocorrido. 11 Deve-se verificar as condições operacionais das interfaces de uplink e de LAN do roteador.

q


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.

22 Isso pode ser feito no equipamento Juniper com o comando “show interfaces terse”. 17

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

up

up

fe-0/0/2

up

down

fe-0/0/3

up

down

inet

10.0.31.1/24

11 As interfaces de produção devem estar no estado “up up”.

q

11 Se a interface de uplink não estiver no estado “up up”, deve-se abrir um chamado no PoP, detalhando o fato. 11 Nesse caso, pode-se passar também alguma mensagem de erro explícita que tenha sido percebida ao se executar o “show log messages”. 11 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. 11 Nesse caso não há ação do PoP. A atividade corretiva é de responsabilidade da instituiçã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. 11 Um teste básico de roteamento consiste em executar o comando ping alterando o

q

IP de origem para o endereço de LAN do roteador. 11 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.


Comando ping simples:

18

11 No Juniper, faz-se simplesmente “ping ”.

q

Figura 1.20 Ping simples no Juniper: comando “ping 10.1.1.1”.

Comando ping endereçado pela LAN:

q

Figura 1.21 Ping com origem na LAN no Juniper: comando “ping 10.1.1.1 from 192.168.1.1”.


11 No Juniper, faz-se “ping from ”.

19

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. 11 Um chamado no PoP pode ser aberto de três maneiras:

q

22 Via e-mail. 22 Via trouble-ticket (boa parte dos PoPs já suportam essa modalidade de acionamento). 22 Via telefone. 11 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. 22 Nesses casos, deve-se informar ao profissional do PoP todos os testes já executados. 22 É esperado que o profissional do PoP registre o problema e inicie a sua investigação. 11 Em casos menos graves pode-se abrir o chamado por e-mail. 22 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 reportando 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 delegada, é 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 11 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. 11 Em casos de acionamento de operadoras, o PoP contatará os representantes daquele Introdução à rede Ipê

órgão periodicamente e manterá a instituição informada de toda e qualquer novidade.

20

11 É 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 detalhadas sobre o caso.

q

Acompanhamento de problemas relacionados ao backbone 11 Se a conexão local está funcionando, mas ocorre falha no uso do serviço, é provável

q

que a falha esteja fora da alçada do PoP da RNP. 11 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. 11 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. 11 A GO disponibiliza na web page da RNP o Panorama do Tráfego.

q

11 Esta ferramenta informa, entre outras coisas, a saúde dos enlaces do backbone da RNP. 11 Este recurso está disponível, on-line, a qualquer hora. 11 O Panorama do Tráfego: 22 Mostra o nível de utilização de todos os enlaces de dados que compõem o backbone. 22 É atualizado a cada cinco minutos. 11 Os enlaces possuem as seguintes situações: 22 ADEQUADO (nível de utilização adequado). 22 ACIMA (nível de utilização acima do adequado, mas ainda não saturado). 22 SATURADO (enlace de dados com excesso de uso. Já atingiu a saturação). 22 INDISPONÍVEL (enlace de dados indisponível no momento).

Figura 1.22 Panorama do Tráfego da rede Ipê.

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.


A figura seguinte mostra uma foto da ferramenta:

21

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.

Latência

Por exemplo, uma instituição cliente do PoP do Pará (PA) que possui uma aplicação que

Tempo passado desde a saída de um pacote de dados de sua origem até a chegada em seu destino.

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:

22

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 justifique bem alguma percepção de lentidão por parte de uma instituição atendida pelo PoP-AP, ele pode indicar atenção, pois um maior uso do canal poderá rapidamente deteriorar a qualidade da comunicação de todos os clientes desse PoP.

Figura 1.23 Panorama do tráfego: tráfego de enlace de dados.

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.

23

24


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?

Figura 1.24 Panorama da Atividade 1.1.

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.

Capítulo 1 - Roteiro de atividade 1

Atividade 1.2 – Falha de conectividade da organização usuária

25

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:

26

2 Orientar a instituição sobre os procedimentos adequados para tratar os incidentes de segurança e como se relacionar com o CAIS.

conceitos

CAIS, serviços do CAIS, segurança.

Centro de Atendimento a Incidentes de Segurança (CAIS) 11 Compreende uma equipe técnica fortemente qualificada na área de segurança de redes.

q

11 Nacional e internacionalmente reconhecido por sua atuação na detecção, resolução e prevenção de incidentes de segurança. 11 Elabora, promove e dissemina práticas de segurança em redes. 11 Participa largamente de organismos internacionais na área de segurança. 11 Interage com equipes de resposta a incidentes de segurança de diversos países. 22 Essas equipes são conhecidas pela sigla CSIRT (Computer Security Incident Response Team). 22 No Brasil, várias instituições acadêmicas já contam com seu próprio CSIRT. 11 Na área internacional, o CAIS ainda coordena o grupo de trabalho de segurança da rede acadêmica CLARA. 11 No Brasil, presta diversos serviços à comunidade acadêmica. 11 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 prevençã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).

Capítulo 2 - Segurança na rede Ipê

objetivos

Segurança na rede Ipê

27

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: 11 Tratamento de incidentes.

q

11 Disseminação da cultura de segurança. 11 Infraestrutura de segurança. 11 Gestão de segurança da informação. 11 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. 11 Incidentes podem ser comunicados ao CAIS através do e-mail: [email protected].

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: 11 Destruição, corrupção ou roubo de dados.

q

11 Redução de performance ou indisponibilidade da rede de uma instituição. 11 Ao se deparar com um ataque que produza impactos imediatos, como indisponibilidade ou lentidão de serviço, a instituição deverá contatar imediatamente o PoP, descrevendo os sintomas experimentados. 11 Os PoPs e a gerência de operações da RNP possuem ferramental adequado para caracterizar o tipo de ataque ocorrido. 11 A partir do ataque reportado, a gerência de operações da RNP e o PoP atuarão juntos na sua investigação. 11 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. 11 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: 11 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: [email protected], ou através de um for-

28

mulário específico disponível no portal do CAIS em: http://www.rnp.br/cais/atendimento.html

O que é o atendimento a incidentes? 11 É 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.

q

11 Qualquer incidente de segurança pode ser reportado ao CAIS.

q

11 Por incidente de segurança entenda-se qualquer evento que promova a quebra da política de uso da RNP. 11 A política estabelece que as organizações usuárias da RNP, para a promoção de suas atividades de ensino e pesquisa, podem: 22 Utilizar os serviços de rede disponíveis, suas facilidades de trânsito nacional e internacional. 22 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 à discriminaçã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 instituiçã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. 11 Caso ocorram incidentes de segurança dentro da instituição, ela deve se preocupar em

q

corrigir o problema, sob pena de deixar de usufruir dos serviços de rede disponíveis. 11 Algumas consequências indiretas também podem ocorrer, como: 22 Bloqueio, por parte de terceiros, da entrega de e-mails enviados a partir da instituição. 22 Enquadramento em leis internacionais de proteção à propriedade intelectual.

O trabalho do CAIS 11 Os incidentes de segurança mais comuns tratados pelo CAIS são: 22 Envio de mensagens de e-mail não solicitadas (spam). 22 Ataques a sistemas (procura por vulnerabilidades e invasão). 22 Golpes de fraudes bancárias, cartões de crédito (phishing). 22 Troca de páginas web. 22 Download de material protegido por copyright (P2P e outros). 22 Disseminação de malware.

q


22 Comprometimento da imagem da instituição ou mesmo da RNP.

29

11 Os incidentes de segurança mais sérios (e menos frequentes) tratados pelo CAIS são:

q

22 Pedofilia. 22 Difamação. 22 Solicitações judiciais.

Recomendações à Organização Usuária 11 A organização usuária também tem seu papel no tratamento dos incidentes de segurança.

q

11 É recomendado que a instituição mantenha uma equipe ou profissional responsável pela segurança de suas redes e sistemas. 11 Caberá a essa entidade investigar as ocorrências registradas em sua instituição e corrigir os problemas de segurança em sua alçada. 11 É recomendado que essa entidade notifique o CAIS em relação aos ataques recebidos, bem como os responsáveis pelas redes atacantes, solicitando providências (nesse caso, sempre copiando o CAIS nas mensagens). 11 A equipe/profissional responsável pela segurança das redes da instituição deverá também adotar práticas de prevenção: 22 Executar a gerência de redes e sistemas. 22 Manter os sistemas atualizados, originais e protegidos por antivírus. 22 Permitir somente o envio de e-mails através de servidores específicos. 22 Identificar e bloquear abusos na rede (P2P). 22 Definir uma topologia de rede que facilite a gerência e controle, utilizando DMZ e firewall. 22 Ter cuidados especiais com senhas de servidores. 22 Acompanhar listas de segurança e vulnerabilidades em produtos instalados (roteadores, servidores web, apache, php, mysql).

A ajuda do CAIS Na prática, o CAIS oferece os seguintes serviços: 11 Notificação às instituições clientes sobre quaisquer incidentes de segurança que

q

cheguem ao conhecimento da comunidade acadêmica nacional de segurança. 11 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. 11 Manutenção e disponibilização de dados estatísticos sobre o atendimento a incidentes na RNP. 11 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 11 Estabeleça um ponto de contato único como contato de segurança: abuse@, seguranca@ ou security@. 11 Informe esse contato à RNP e ao CAIS. 11 Repasse as mensagens recebidas nestes e-mails aos responsáveis pelas questões de segurança.

30

q

11 Mantenha a data e hora de seus sistemas ajustados por NTP, para garantir a precisão

q

do horário nos logs de eventuais ataques. 11 Caso a instituição tenha sofrido algum incidente de segurança: 22 Colete todos os dados relacionados ao incidente. 22 Certifique-se de incluir data, hora e fuso horário. 22 Notifique o atacante, com cópia ao CAIS. 22 Caso a instituição tenha sido origem de um incidente de segurança: 33 Trate o caso com responsabilidade. 33 Busque identificar o problema, resolvê-lo, e responder ao solicitante, copiando


o CAIS na resposta.

31

32


3 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 11 Tipicamente a organização usuária se ligará ao PoP RNP através de um enlace de

conceitos

objetivos

Infraestrutura de rede

q

dados provido por uma operadora de telecomunicações. 11 Esse ator alugará um meio físico para prover o contato da instituição com a rede Ipê. 11 Esse meio será implementado por uma dentre diversas tecnologias. 22 O que ocorre usualmente é que o meio físico é uma fibra óptica, um cabo de cobre ou um radioenlace (sem fio). 11 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.

RNP

Figura 3.1 Ligação de instituição via fibra óptica.


PoP 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-

Capítulo 3 - Infraestrutura de rede

As figuras abaixo exibem cada um dos casos:

tura. Ou seja, em termos práticos, o link é implementado passando por uma ou mais estações da operadora em questão. 33

RNP


Figura 3.2 Ligação de instituição via rádio.

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

PoP Operadora


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.

34

PoP RNP

Figura 3.3 Ligação de instituição via satélite.

11 Nos casos exibidos o enlace de dados é contratado pela RNP junto a uma operadora

q

de telecomunicações. 11 O contrato firmado entre essas duas partes estabelece parâmetros de qualidade que deverão ser atendidos, como: 22 Largura de banda disponível, tempo de resposta, taxa de erro de bit (BER) etc. 11 Cabe à RNP executar a gestão desse contrato, garantindo o seu cumprimento e aplicando as punições necessárias quando os itens acordados não forem atendidos. 11 Em qualquer dos casos, invariavelmente, a organização usuária receberá, em suas dependências, alguma infraestrutura de equipamentos da operadora. 11 A organização terá que zelar pelo bom funcionamento desses equipamentos, mantendo-os em condições recomendadas. 11 No caso mais simples, de organização usuária atendida por rede cabeada, a operadora 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

Figura 3.4 Conexão instituição: operadora.

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

A infraestrutura adequada para abrigar esses dispositivos será apresentada adiante. 11 A conexão entre o roteador e o modem quase sempre se dá via interface serial do roteador. 11 Existe uma grande variedade de conectores que podem compor o cabo que faz essa conexão. 11 O conector V.35 é um dos mais populares.

q


pertence à operadora de telecomunicações.

35

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 visibilidade 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 porventura 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 roteador 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 operadora 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 apresentados mais à frente neste curso.


Uso e especificação de switches e roteadores

36

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.

Os fabricantes de rede dividem a linha de equipamentos em: 11 Produtos para escritório (Office).

q

11 Produtos para empresa (Enterprise). 11 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: 11 Equipamentos de mesa; 11 Equipamentos de rack. Dentre os equipamentos de mesa estão os servidores de torre e os PCs (que constantemente abrigam serviços).

Figura 3.6 Equipamentos de mesa (Fonte: www.sevenl.net).

Em algumas empresas, os equipamentos de mesa são rejeitados, porque não é possível tantes de CPDs de maneira difícil de organizar. 11 Os racks são armários próprios para receber equipamentos de telecomunicações. 11 Proveem infraestrutura específica para passagem de cabos, acomodação de fontes extras, ventiladores, barra de aterramento e réguas de energia. 11 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. 11 Normalmente um equipamento ocupa toda a largura do rack e parte de sua altura. 11 O espaço de altura dos racks é dividido em RUs (rack units). 11 Ao comprar um equipamento deve-se atentar para a informação de espaço físico

q


organizá-los em racks. Constantemente os equipamentos de mesa ocupam espaços impor-

necessário em rack. 37

Figura 3.7 Rack de 19´´para telecomunicações.

Alguns tamanhos típicos de rack são 8, 12 e 16 RUs. O equipamento Juniper J2350, por exemplo, possui 1,5 RU.

40 RUs Figura 3.8 Divisão de rack em RUs.

1,5 RU

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 computador 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 redundante é 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. 11 Os equipamentos também possuem a tecnologia de “hot swap”, que permite trocar


uma fonte queimada sem parada do equipamento. 11 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. 11 Nesses casos a fonte backup assume, mas não haverá backup para ela. 11 Se esse componente falhar, haverá parada de serviço. 11 Conclusão: não adianta ter fontes redundantes enquanto não se intervém na fonte defeituosa. 38

q

É 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. 11 Existem três desenhos básicos: barramento, anel e estrela.

q

11 A maioria das topologias de rede possui uma dessas três configurações ou uma combinação delas.

Figura 3.10 Topologia anel.


Figura 3.9 Topologia barramento.

39

Figura 3.11 Topologia estrela.

11 Ao definir a topologia da rede dois conceitos ajudam a melhorar a robustez dela:

q

redundância e hierarquia. 11 O conceito de redundância fica claro na topologia em anel. Uma topologia preocupada com a redundância evita que as VLANs (ou redes) dependam de um único link para se manterem disponíveis. 11 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

Figura 3.12 Modelo de referência: rede redundante e hierarquizada.


Acesso

40

Nesse modelo de referência os equipamentos foram divididos em camadas. 11 Cada camada provê serviço para todas as camadas mais abaixo. 11 A camada de acesso conecta os usuários à rede e provê comutação de frames entre usuários da mesma VLAN.

q

11 A camada de distribuição concentra os equipamentos de acesso e segmenta dife-

q

rentes grupos de trabalho. 22 Um bom arranjo dessa camada ajuda a isolar problemas de rede. 22 Essa camada também pode implementar políticas de segurança. 11 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. 22 Essa camada concentra os equipamentos de distribuição. 22 Sua função é rotear pacotes entre os equipamentos de distribuição e as redes externas o mais rápido possível. 11 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 11 Uma prática muito simples que ajuda enormemente a tarefa de manter a rede organi-

q

zada e documentada é a identificação de cabos. 11 Uma rede que se estende por um espaço físico muito extenso e que possua muitos

Figura 3.13 Exemplo de ambiente caótico (Fonte: www. bernabauer.com)

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, desaprovisionamento ou troubleshooting da infraestrutura física de cabeamento.


cabos rapidamente se transforma em um caos completo.

41

Figura 3.14 Cabo identificado (Fonte: www. midiasolucao.com.br).

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, é recomendado estabelecer um processo de mudança das conexões da rede.

Infraestrutura para abrigar os equipamentos e mantê-los 11 Não existem padrões para a infraestrutura que abrigará os equipamentos da RNP.

q

11 A orientação é que a instituição se preocupe com a documentação técnica dos equipamentos que receberá em suas dependências. 11 Esses documentos especificarão as condições ideais que permitirão aos equipamentos uma vida útil ótima. A seguir veremos os pontos que devem ser verificados.

Localização e dimensões da sala 11 A localização da sala deve ser tal que evite a propagação de ruído dos equipamentos

q

ao restante do ambiente, evitando prejuízo para a população da instituição. 11 A dimensão da sala deve ser tal que permita ao equipamento de ar-condicionado que a atende refrigerá-la com eficiência. 22 Salas grandes são mais difíceis de refrigerar. 22 Temperatura é um dos itens mais importantes para o bom funcionamento de equipamentos 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.

42

Equipamentos de apoio 11 Alguns equipamentos de apoio ajudam a aumentar a disponibilidade dos equipamentos. 22 Exemplos: nobreaks e geradores. 11 Os nobreaks protegem os equipamentos contra picos de luz, cobrindo o fornecimento de energia durante falhas curtas de fornecimento elétrico.

q

11 Dependendo da criticidade das aplicações da rede a instituição pode lançar mão de

q

um gerador, que permite a manutenção de energia elétrica mesmo durante longas falhas da concessionária de energia. 11 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 11 Todo equipamento instalado na sala de equipamentos traz em sua documentação

q

técnica a quantidade de BTUs que será consumida. 11 É 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á a capacidade 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 11 Todo equipamento de redes e de telecomunicações deve ser aterrado em

q

infraestrutura adequada. 11 É fortemente indicado que a instituição que abrigará equipamentos em suas dependências providencie uma malha de terra adequada. 11 É 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 11 A saúde e vida útil do cabeamento utilizado nas redes dependem significativamente

q

da disposição física utilizada. 11 Os cabos devem ser instalados de modo a evitar tensão no corpo dos cabos e nos 11 Deve-se evitar dobrar o cabo em ângulos muito pequenos. 11 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.


conectores.

43


Figura 3.15 Boas práticas de cabeamento (Fonte: taquara.olx.com.br).

44

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

roteadores.

Switches L2 11 Os switches L2 têm a função de distribuir e segmentar os pontos de rede e as LANs

conceitos

Switches L2 e L3, comutação L2, empilhamento, subdivisão da rede em VLANs,

q

do ambiente. 11 A função fundamental desses elementos é receber um frame, avaliar o campo “endereço MAC destino” e tomar a decisão de encaminhamento. 11 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. 11 Cabe ao switch apenas avaliar em qual ponto de rede está o destinatário do frame.

Capítulo 4 - Switches e roteadores

objetivos

Switches e roteadores

45

Pacote

Default Gateway

Roteamento L3

Rede L2 (comutação) Em qual porta física está o destino?

Figura 4.1 Roteamento L3 versus encaminhamento L2.

Destino

Em qual porta física está o destino? O dimensionamento de um switch depende principalmente: 11 Da quantidade de interfaces requeridas; 11 Da velocidade dessas interfaces; 11 Da quantidade de LANs (VLANs) que trafegarão dados pelo equipamento; 11 Da necessidade de redundância de hardware (fontes, CPUs, backplanes etc); 11 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 tremendamente 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 11 Os switches L3 podem fazer as funções de L3 e/ou de L2. 11 Cabe ao administrador de rede fazer essa definição. 11 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. 11 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.

46

q

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 Figura 4.2 Interação L2-L3 tradicional com switch e roteador.

VLAN A

VLAN B

VLAN C

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 B

VLAN C

Uma aplicação típica do switch L3 no mundo real pode ser vista nas próximas figuras. 11 Os servidores das VLANs 10 e 20 não acessam a internet nem a rede Ipê, no entanto

q

essas duas VLANs trocam grande volume de tráfego entre si. 11 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.3 Switch L3 faz o papel de default gateway de várias redes/sub-redes/ VLANs.

47

Rede Ipê

Default Gateway das VLANs 10, 20 e 30

Link saturado

VLAN 30

VLAN 20

Figura 4.4 Usuários da VLAN 30 reclamam de lentidão.

VLAN 10

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. 11 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. 11 O switch L3 se tornou o default gateway das VLANs 10 e 20. 11 O tráfego entre as VLANs 10 e 20 não compete mais com o tráfego entre VLAN 30 e


rede Ipê.

48

q

Rede Ipê

Default Gateway da VLAN 30

Link OK

Default Gateway das VLANs 10 e 20

VLAN 30

VLAN 20

VLAN 10

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 serviç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 11 Os switches L2 também executam protocolos para otimizar o serviço de encaminhamento. 22 Exemplo: protocolo spanning-tree. 11 Os switches se utilizam desse protocolo para evitar que ocorram loops de encaminhamento na rede. 11 Um loop de encaminhamento tem o poder de parar completamente uma rede, e isso efetivamente ocorre no mundo real.

q


Figura 4.5 Switch L3 elimina o problema.

49

11 Em ambientes onde existe mais de um caminho possível para se chegar a um host é

q

fundamental a presença do spanning-tree, tanto que todos os fabricantes de equipamentos de rede já deixam esse protocolo habilitado de fábrica. 11 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. Root Bridge

Links operando

Figura 4.6 Spanning-tree: evita loops de rede.

Links bloqueados

A operação do spanning-tree não será detalhada neste curso. Em resumo, seu objetivo é fazer com que só exista um caminho válido entre dois pontos

q

quaisquer de uma rede L2.

Empilhamento 11 Quando o número de usuários de uma rede local aumenta muito, é necessário lançar

q

mão de outros recursos para fazer a rede escalar. 11 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. 11 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. 11 O empilhamento consiste em criar um único equipamento lógico a partir de dois ou mais switches físicos.


11 A comunicação entre os switches pode se dar via porta Ethernet ou via cabeamento

50

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 endereços IPs e pelo mesmo hostname.

Figura 4.7 Switches empilhados (Fonte: www. kathmann.com).

Subdivisão da rede em VLANs de distribuição A divisão da rede em VLANs é uma das boas práticas em rede local. Há vários motivos

q

para realizá-la. Aqui citaremos cinco: 11 Aumento da confidencialidade dos dados das diferentes redes. 11 Economia de recursos dos elementos de rede e de links. 11 Economia de recursos dos hosts através da redução dos domínios de broadcast. 11 Flexibilidade para configuração de políticas de roteamento e segurança. 11 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

SW1

Figura 4.8 Divisão da rede em VLANs.

200.1.1.0/26

200.1.1.128/25

Depto. financeiro

Depto. de docentes

Laboratório de alunos

(VLAN 10)

(VLAN 20)

(VLAN 30)


200.1.1.64/26

SW2

51

11 A boa prática diz que os hosts com maior interesse de tráfego devem ficar na mesma

q

VLAN (rede). 11 Dessa forma o tráfego entre esses hosts não competirá pelos recursos de rede com outros hosts. 11 O tráfego de uma VLAN fica isolado do tráfego das demais. 11 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 broadcast 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 estritamente 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 interface 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 administrador 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 11 Os roteadores são os protagonistas das redes baseadas em arquitetura TCP/IP ou IP/MPLS. 11 A função fundamental desses elementos é receber os pacotes IP, interpretar o campo “IP destino” e decidir como encaminhar o pacote.

52

q

11 Essa decisão é a chave para o bom desempenho da rede e das aplicações que dela

q

se utilizam. 11 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 fornecido pelo provedor de serviço, cenário que dispensa a necessidade de um roteador.

Internet Provedor de serviço Cliente com rede única

10.1.1.0/24

10.1.1.14

10.1.1.19

10.1.1.12

11 Quando os roteadores da rede fazem uso de um protocolo de roteamento, diz-se que

q

o roteamento ali é dinâmico. 11 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). 11 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.

53

Vários caminhos levam do ponto A ou B

Figura 4.10 Vários caminhos disponíveis: roteamento dinâmico.

11 O roteamento estático também é utilizado na rede Ipê, para executar o serviço de

q

encaminhamento de pacotes em partes da rede onde não há decisão de encaminhamento a ser feita. 11 O roteamento estático, diferente do dinâmico, não caracteriza troca de informações entre roteadores. 11 A informação de roteamento é inserida manualmente no roteador por um administrador de rede.

Há um único caminho possível do ponto A ou B

Figura 4.11 Apenas um caminho disponível: roteamento estático.

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 vantagem 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”. 54

O dimensionamento de um roteador depende: 11 Do volume de tráfego que será cursado em suas interfaces; 11 Da quantidade de interfaces que o roteador pode suportar; 11 Da necessidade de redundância de hardware (fontes, CPUs, backplanes); 11 Da capacidade do seu backplane (hardware de encaminhamento interno por onde passará o tráfego de todas as interfaces); 11 Dos protocolos que serão usados e do tamanho da rede envolvida. O backplane do hardware está intrinsecamente ligado à soma das capacidades das interfaces 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, evitando 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.

Figura 4.12 Roteador Juniper Série J: pequeno porte (Fonte: www.juniper.net).

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

11 Os principais protocolos de roteamento dinâmico executados na rede Ipê e em vários outros provedores comerciais são OSPF e BGP. 11 Em redes de organizações menores pode-se utilizar outros protocolos mais simples que consomem menos recursos de hardware (e consequentemente requerem equipamentos mais baratos). 11 Um exemplo de protocolo de roteamento simples é o RIP. 11 Exemplos de outros protocolos menos populares, mas não menos eficientes que os citados: 22 IS-IS.

q Capítulo 4 - Switches e roteadores

dos pacotes IP recebidos.

22 EIGRP. 55

O funcionamento detalhado de cada um desses protocolos de roteamento não é tema deste curso.

Roteador de borda 11 O roteador de borda provê a comunicação de todas as VLANs da rede local com

q

a internet. 11 Esse elemento é candidato natural a receber a configuração das políticas de roteamento da instituição, tais como restrições de acesso a sites não autorizados. 11 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”. 11 Quando a conexão da instituição não tiver um enlace de backup, esse roteador executará roteamento estático, o mais recomendado para esse cenário. 11 Se houver mais de um enlace através do qual se possa chegar à internet, esse elemento deverá executar um protocolo de roteamento dinâmico.

Internet

Rede local

VLAN 21

Roteador de borda

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 configuram 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. 56

Figura 4.13 Roteador de borda.

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 conhecimentos 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 3

2 Sw2

R1

R2

f0/1 6

f0/1

Sw4 f0/2 3

f0/0

5

Sw3

Sw1 1 4 Servidor Web PC 1 10.0.1.1/24

10.0.0.1/24

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 acontecimentos. 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 é verificar qual dos 6 passos não está ocorrendo. Para cada passo investigado, caso a conectividade 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 traduzir 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.

PC 2 10.0.1.2/24

57

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

58

Estudo de caso Solicitação, atribuição e administração de blocos IP

RNP / Internet

R1

R2 fe-0/0/2 fe-0/0/2

fe-0/0/0 fe-0/0/1

SW1

SW2

SW3

VLANs 10 e 20

VLAN 30

VLAN 40

fe-0/0/0

SW4

VLAN 50

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 11 10 – Desktops administrativos: máquinas de diretores, secretárias e da área financeira. 11 20 – Laboratórios: PCs e outros equipamentos IP usados nas aulas práticas. 11 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. 11 40 – Serviços: base de dados de matrículas e dados dos alunos, servidor de FTP, servidor de e-mail, DNS e outros. 11 50 – Desktops das salas dos respectivos professores.


Figura 4.15 Cenário do estudo de caso.

fe-0/0/1

59

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. 11 Intervalo 1: 200.33.1.0/25; 11 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 documentaçã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.

60

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.

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.

Capítulo 4 - Roteiro de Atividades 2

3. Os hosts da VLAN “Serviços” possuem licenças de software associadas a seus endereços

61

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 servidores (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.

62

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): 11 Solução mais adequada às demandas de crescimento de cada VLAN; 11 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: 11 A sub-rede da VLAN 40 tem que ser 200.33.1.64 (condição do enunciado). Como o enunciado 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. 11 Para as demais VLANs: aloca-se o endereço da maior VLAN para a menor, sempre verificando 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

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.


demandas de crescimento de cada VLAN”.

63

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 alterados, 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 objetivos 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”.

64

A sub-rede “b”, que resta, pode ser dividida em duas sub-redes /27, que chamaremos redes “d” e “e”.

/26

/27

_________________________________________________________________________

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 objetivo é 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.

65

66


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

conceitos

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 administrador 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 serviços estão funcionando a contento. 11 Os serviços podem ser hospedados na própria rede local ou em redes remotas, que

q

pertencem a terceiros. 11 A vantagem de se manter serviços na rede de terceiros é a simplificação da tarefa de sua administração. 11 Nesse caso, a responsabilidade pela manutenção da boa saúde dos servidores fica com os administradores da rede remota. 11 A grande desvantagem é que a qualidade do serviço prestado na rede local fica à mercê da capacidade daquela equipe remota. 11 A desvantagem descrita faz com que os administradores da rede local sejam levados a manter alguns serviços fundamentais na própria rede local. 11 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ço não serão explorados aqui, de modo que faremos apenas uma análise suficiente para os objetivos deste curso. 11 O DNS pode ser descrito como uma grande e importante base de dados distribuída

q

Capítulo 5 - Serviços e gerenciamento da rede da instituição

objetivos

Serviços e gerenciamento da rede da instituição

pela internet. 67

11 Essa base é responsável por um dos serviços mais importantes da internet contem-

q

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. 11 Além de usado para consultas a nomes de serviços remotos, o DNS também é usado

q

para descobrir o IP de serviços de rede local. 11 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. 11 O servidor de DNS tem importância particular para instituições que possuem nome de domínio registrado junto ao Nic.br. 22 Nic.br é o órgão responsável pelo registro de domínios no Brasil, administrado pelo Comitê Gestor da Internet no Brasil (CGI.br). 11 Todo domínio com final “.br” deve ser conhecido pelos servidores DNS do Nic.br, ou seja, deve estar registrado junto ao órgão.

11 Todo domínio precisa de pelo menos um servidor DNS autoritativo. 11 Aos clientes da RNP é sugerido um mínimo de dois servidores para esse fim (por segurança).


11 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. 22 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. 68

q

Figura 5.1 Organograma Nic.br.

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.

rnp.br

Servidor DNS domínio “.br”

5

Y.

p. br ?

Y. S

rn

p.

IP

w w w .rn

N

2

Ins tituição

4

r?

b p.

.rn w w w

IP

de

br

de

lo ua

Q

D

Y.

ao

é

te

Y

!

un

ua lo

rg

Servidor DNS domínio “rnp.br”

Q

Pe

IP

3

O

.br

Servidor DNS instituição 6

Qual o IP de www.rnp.br ?

O IP é Y.Y.Y.Y !

1

Figura 5.2 Consulta recursiva para localizar www.esr.rnp.br.

11 Vantagens de uma instituição em manter o servidor DNS autoritativo do seu domínio

q

sob sua própria administração: 22 Flexibilidade na administração do serviço.

11 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. 11 Outro problema pode ser gerado toda vez que um serviço do domínio precisar mudar de endereço IP. 11 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 responsá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.


22 Responsabilidade pela manutenção do serviço.

69

MX O serviço de DNS descrito provê acesso aos registros do tipo A (address). 11 Além do acesso aos registros “A”, o servidor autoritativo de um domínio também

q

pode prover consultas ao registro MX, usado na execução do serviço de e-mail. 11 Exemplo: 22 Um usuário da internet, proprietário da conta de e-mail “huguinho@cartoons. com”, deseja enviar uma mensagem de e-mail para “[email protected]”. 22 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. 22 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 comunicará via protocolo SMTP com o servidor de e-mail de rnp.br, e a mensagem será transferida. Rede Local

Servidor DNS Local

DNS

Qual é IP do serviço de correio de rnp.br ?

3 4 O IP é X.X.X.X

5

Qual é IP do serviço de correio de rnp.br ?

Serviço DNS Internet

O IP é X.X.X.X

2 Servidor de Correio local

Servidor de Correio rnp.br 6

1

e-mail para [email protected]


7


Legenda:

Figura 5.3 Consulta ao registro MX para envio de e-mail.


DNS SMTP POP3

70

Web 11 Esse serviço é o mais popular da internet. 11 Praticamente todas as instituições com um domínio registrado possuem um servidor web que hospeda seu sítio e serviços on-line. 11 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.

q

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 11 Provê as mesmas funcionalidades do servidor de FTP, porém aplicando criptografia,

q

para garantir a confidencialidade e integridade dos dados transferidos. 11 Esse serviço possibilita transferir e armazenar arquivos na rede local. 11 A aplicabilidade desse serviço na rede local é vasta. 11 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. 11 O serviço de SFTP é o mais adequado para prover transferência de arquivos com tamanho da ordem de megabytes ou gigabytes.

E-mail 11 O servidor de e-mail é o responsável por receber todas as mensagens destinadas aos

q

usuários da rede local, bem como transmitir para os servidores de e-mail remotos todas as mensagens de e-mail desses mesmos usuários. 11 Esse serviço utiliza dois tipos de protocolo: 22 Um para a comunicação entre servidores de e-mail. 22 Outro para comunicação entre servidor de e-mail e cliente. 11 Os diferentes servidores se comunicam via protocolo SMTP. 11 A comunicação entre os softwares clientes e seus servidores pode se dar via protocolos IMAP ou POP3 para a recepção de mensagens.

Existem outros protocolos menos conhecidos para prover essa interação. Uma das principais 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.


11 Para o envio de mensagens é usado também o SMTP.

71

Servidor de Correio destinatário

Servidor de Correio remetente

SMTP POP3 ou IMAP SMTP

Figura 5.4 Serviço de e-mail: servidores e clientes de e-mail.

Destinatário

Remetente

11 Muitas instituições não possuem mão de obra adequada para administrar um

q

servidor de e-mail. 11 Nesses casos pode-se fazer uso de um serviço de e-mail comercial, administrado por uma entidade externa. 11 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). 11 Quando o serviço de e-mail fica hospedado em um ambiente externo, a sua disponibilidade e qualidade ficam a cargo de terceiros.

Internet

Servidor de correio destinatário

Servidor de correio externo

SMTP

Rede local

POP3 ou IMAP SMTP


Remetente

Repositório de arquivos 11 Esse serviço é provido através dos ditos “HDs virtuais”, serviço largamente oferecido na internet de graça. 11 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.

72

Destinatário

Figura 5.5 Serviço de e-mail hospedado remotamente.

q

11 O compartilhamento é feito sem que o usuário remoto necessite de qualquer recurso

q

especial, basta uma conexão à internet. 11 É 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 11 Esses três recursos são largamente utilizados na borda da rede local.

q

11 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 roteador ou switch L3.

Internet

Rede DMZ

Rede corporativa

A figura anterior explicita o uso clássico do firewall. 11 Os serviços hospedados na rede DMZ (zona desmilitarizada) devem estar acessíveis

q

a partir da internet. 11 Os serviços e hosts da rede corporativa não podem ser acessados por entidades na internet. 11 Esses objetivos são alcançados através de regras construídas no firewall. 11 A operação básica dos firewalls é comparar todos os pacotes que passam pelas suas interfaces com regras configuradas manualmente pelo administrador de redes. 11 Se o pacote estiver contemplado nas regras de permissão ele receberá serviço. Do contrário, será descartado. 11 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.

73

10.0.1.1

10.0.1.1

200.1.1.1

10.0.1.2

200.1.1.2

10.0.1.3

200.1.1.3

10.0.1.2

Internet

10.0.1.3 Figura 5.7 Operação do NAT: conversão de endereços.

10.0.1.1

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

10.0.1.2

Internet

10.0.1.3 Figura 5.8 Operação do PAT: conversão de endereço e porta.

11 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. 22 O efeito prático é que apenas um endereço IP válido é consumido.


22 Todos os demais endereços IP são privados e não serão enxergados na internet.

74

11 NAT e PAT também podem ser implementados em roteadores, embora alguns autores defendam que essa tarefa deve ser realizada no firewall. 11 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 é concebida de modo a torná-lo adequado a essa tarefa. 11 O modelo Juniper J2350 fornecido às organizações usuárias suporta NAT e PAT.

q

Procedimento de solicitação de bloco IP 11 Uma vez qualificada pelo CG-RNP para ser cliente da rede Ipê, a organização usuária

q

terá direito a um bloco IP fornecido pela RNP. 11 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. 11 O contato técnico ganhará um acesso à extranet da RNP e terá que preencher um questioná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. 22 Nesse mesmo questionário é solicitado um bloco IP. 11 A solicitação de bloco também pode ocorrer posteriormente ao processo de qualificação. 11 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. 22 Nesse caso, o pedido será feito por e-mail. 22 Uma mensagem com o número de IPs adicionais necessários e a justificativa do pedido deverá ser enviada para [email protected]. 22 O solicitante receberá uma resposta automática do sistema de trouble-ticket da GO e deverá aguardar um retorno. 22 A GO avaliará a justificativa do pedido, que poderá ser atendido integral ou parcialmente, 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 solicitação de endereços IPv6 é feita através do mesmo procedimento.

Adequação do tamanho do bloco às necessidades da IFES 11 Endereços IPv4 são recursos escassos e devem acabar nos próximos anos. Por isso,

q

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. 11 A instituição não poderá escolher o bloco IP que usará, mas o tamanho do seu bloco.

conveniência. 11 A solicitação do tamanho do bloco deriva da quantidade de hosts que precisam de endereços e da perspectiva de escalabilidade da rede. 11 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 11 O serviço de DNS reverso, como o nome sugere, executa uma tarefa oposta ao DNS tradicional, mas de modo similar. 11 Em determinadas situações é importante para uma aplicação descobrir um nome a partir do endereço IP, e não o contrário. 22 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

q


11 Os números IP propriamente ditos serão definidos pela RNP de acordo com a sua

encontra no pacote da mensagem. 75

11 O serviço de DNS tradicional utiliza os registros do tipo A (address). O DNS reverso

q

funciona através de consultas aos registros PTR dos servidores de DNS. 11 Uma das aplicações mais latentes do DNS reverso atualmente está ligada ao serviço de e-mail. 22 Ao enviar um e-mail, o software cliente tem total liberdade para editar os campos do remetente, data, hora e destinatário da mensagem. 22 Esses dados não são questionados pelo protocolo que fará a transmissão do e-mail, o SMTP. 22 Dessa forma, nada impede que um software malicioso envie um e-mail preenchendo o campo do remetente com um valor falso. 11 É 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. 11 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 averiguar se o endereço IP do remetente coincide com a informação contida no serviço de DNS reverso. 11 O exemplo a seguir ilustra a utilidade do DNS reverso para o serviço de e-mail: 22 O servidor de e-mail do domínio “rnp.br” recebeu um e-mail de luizinho@cartoons. com para [email protected]. 22 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). 11 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. 11 Esse servidor responderá que o hostname procurado é “mail.cartoons.com”. Com isso, a autenticidade da mensagem é reconhecida. 11 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. 11 Dependendo da configuração do servidor destino, a mensagem poderá ser entregue, descartada ou movida para uma pasta de spam. 11 O resultado prático é que se o DNS reverso de uma instituição não está registrado corretamente, vários e-mails enviados por usuários daquela instituição não serão entregues. 22 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

76

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 11 O cliente da RNP precisará configurar entre 2 e 5 servidores autoritativos para responder pelo seu domínio.

q

11 Em seguida, deverá enviar um e-mail para [email protected] informando os hostnames

q

dos servidores e a faixa de IP pelas quais eles respondem. 11 Dúvidas sobre a configuração do servidor DNS propriamente dito poderão ser esclarecidas junto ao PoP da RNP. 11 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 11 A gerência da rede é uma das tarefas mais importantes do dia a dia da administração

q

de redes. 11 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. 11 Ocorre assim menor tempo de reação a problemas ou a potenciais problemas. 11 Alguns recursos tipicamente monitorados são: 22 Utilização de CPU e memória de servidores, roteadores e switches. 22 Conectividade IP de servidores, roteadores e switches. 22 Processos específicos de servidores. 22 Utilização do enlace de dados do roteador de borda. 22 Status de componentes de hardware de servidores, roteadores e switches, como fontes, ventiladores e processador. 11 O PoP da RNP executa a monitoração do enlace de dados que conecta a organização usuária à rede Ipê. 11 Grande parte dos PoPs já disponibiliza essa informação on-line em seu website. 11 A gerência dos recursos e serviços nas redes locais da instituição não é atribuição da RNP nem de seus PoPs.

11 Todo serviço que agregue valor à atividade da instituição ou que suporte suas ativi-

q

dades é candidato potencial a ser gerenciado. 11 Isso inclui os serviços de e-mail, DNS, portais web, SAP e outras plataformas de serviço. 11 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 11 A documentação da rede é um dos maiores desafios que acompanham a atividade de

q

administração de rede. 11 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 disponibilidade que ambientes desorganizados. Esse dado é facilmente justificado. Um bom processo de documentação é recomendável e contribui para o bom desempenho dos serviços e para redução do “downtime”, simplificando troubleshooting e aprovisionamentos.


Serviços que devem ser gerenciados

77

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 11 Existem diversas ferramentas projetadas para realizar o gerenciamento de redes.

q

11 Há boas opções de soluções proprietárias bem como competentes ferramentas de software livre. 11 As ferramentas proprietárias têm a desvantagem de serem caras. 11 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. Cacti

q

11 Ferramenta totalmente gráfica baseada em consultas SNMP. 11 Praticamente qualquer recurso de rede compatível com o protocolo SNMP (popular no mercado de tecnologia) pode ter um gráfico plotado. 11 Inclui interfaces de rede, utilização de CPU, memória, área de swap de servidores etc.


11 Os gráficos são armazenados em base de dados do tipo RRD.

78

Figura 5.9 Cacti.

MRTG

q

11 Ferramenta totalmente gráfica com a mesma proposta do Cacti, mas possui menos recursos. 11 Também utiliza o protocolo SNMP como principal recurso.

Figura 5.10 MRTG.

NFSen

q

11 Ferramenta gráfica que recebe e processa mensagens de “flow” dos equipamentos de rede. 11 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. 11 As ferramentas baseadas em SNMP permitem definir, por exemplo, que uma interface de determinado roteador tem uso de 8Mbps em um determinado horário. 11 Já as ferramentas baseadas em flow, como o NFSen, permitem saber adicionalmente que desse total: 22 1Mbps vem do servidor de e-mail, 2Mbps são de aplicações de backup e 5Mbps

Figura 5.11 NFSen.


de tráfego de internet.

79

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.

80

lPara mais informações sobre o evento: http:// www.rnp.br/wrnp/

6 Descrever os requisitos de instalação física do roteador Juniper.

conceitos

Componentes básicos dos roteadores J2350 e J2320.

Requisitos de instalação do roteador 11 A organização usuária cliente da RNP receberá em suas dependências um roteador

q

da RNP. 22 Esse equipamento será um modelo Juniper 2350. 22 Ele fará a interface entre a rede da instituição e a rede de acesso do PoP RNP. 11 Cada plataforma Juniper possui um guia de hardware que provê as instruções detalhadas 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 verificado no documento “J Series Services Routers Hardware Guide”.

Requisitos físicos 11 O roteador da série J é preparado para ser instalado em um rack.

q

11 Para abrigar o equipamento, um rack deve atender aos requisitos: 22 Rack de 19 polegadas, como definido pelo documento EIA-310-D, publicado pela European Telecommunications Standards (ETSI). 11 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. O modelo J2320 possui as seguintes dimensões: 11 4,45 cm de altura, 38,35 cm de comprimento e 44,48 cm de largura.

q

Capítulo 6 - Instalação do roteador da RNP

objetivos

Instalação do roteador da RNP

81

q

11 O equipamento consome 1 RU do rack. 11 Seu peso varia de 6,8 a 7,6 Kg, dependendo da quantidade de placas instaladas. O modelo J2350 possui as seguintes dimensões: 11 6,63 cm de altura, 38,35 cm de comprimento e 44,48 cm de largura. 11 O equipamento consome 1,5 RU do rack. 11 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) é recomendado colocá-lo na parte inferior.

Requisitos de ventilação O sistema de cooling dos roteadores J2350/J2320 funciona gerando o fluxo de ar de uma

q

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. 11 A velocidade dos ventiladores é ajustada automaticamente dependendo da

q

temperatura corrente. 11 As entradas de ar que abastecem os ventiladores devem ser limpas periodicamente. 11 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.

82

Figura 6.1 Roteador J2350: ventilação lateral (Fonte: http:www. juniper.net)

Tabela 6.1 Requisitos de ambiente.

Tabela 6.2 Especificações elétricas.

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. 11 Antes de adicionar novas PIMs (Physical Interface Module) ao chassi, é preciso veri-

q

ficar se a combinação de PIMs e módulos não excederá a capacidade de força e calor do equipamento. 11 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.


Figura 6.2 Como NÃO transportar uma placa.

83

Figura 6.3 Como transportar uma placa.

Descarga eletrostática 11 Placas que são retiradas do equipamento contêm partes sensíveis à descarga

q

eletrostática. 11 Placas PIMs (ou outras) podem sofrer danos sob voltagens da ordem de 30 V. 11 Uma pessoa pode facilmente gerar uma energia estática dessa magnitude quando manuseia um material plástico ou uma embalagem de espuma, por exemplo. 11 Para evitar prejuízos desnecessários, deve-se observar as precauções contra descarga eletrostática: 22 Sempre use uma pulseira (ou tira) eletrostática ao manusear placas do roteador. 22 Certifique-se de que a pele está em contato com a pulseira. 11 Se possível, verifique periodicamente a resistência do material usado. Esse valor deve sempre estar entre 1 e 10 mega ohms. 11 Ao manusear um componente do hardware, certifique-se de que o fio da pulseira eletrostática está em contato com um dos pontos de descarga eletrostática do chassi. 11 Evite o contato do hardware com a sua roupa. Ela também pode emitir voltagem suficiente para danificar o equipamento. 11 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.

84

Ponto de aterramento de proteção em chassis Parafuso com arruela prisioneira Terminal de aterramento

Figura 6.4 Aterramento.

Componentes básicos do roteador J2350

POWER LED

CONFIG LED

Auxiliary port

Phisical Interface Module (PIM)

PIN blanks

STATUS LED ALARM LED Power RESET Console button CONFIG port button

Figura 6.5 Juniper J2350.

LAN ports

USB ports

ESD point

O roteador J2350 é um equipamento da série J. O hardware tem as seguintes características principais: 11 Ocupa 1,5 RU de rack.

q

11 512 MB de DRAM (expansível até 1GB). 11 512 MB de compact flash disc (expansível até 1GB). 11 400 Mbps de vazão. O roteador possui: 11 Duas portas USB, que permitem que um drive USB seja usado como unidade de armazenamento secundária; 11 4 portas Ethernet 10/100/1000 Mbps fixas; 11 5 Slots para PIMs (há grande variedade de PIMs disponíveis).


HA LED

85

Componentes básicos do roteador J2320

POWER LED

CONFIG LED

Console port

Phisical Interface Module (PIM)

PIN blanks

STATUS LED ALARM LED HA LED Power RESET Auxiliary button CONFIG port button

ESD point

LAN USB ports ports

O roteador J2320 é o equipamento de entrada da série J. O hardware tem as seguintes características principais: 11 Ocupa 1 RU de rack.

q

11 256 MB de DRAM (expansível até 1GB). 11 256 MB de compact flash disc (expansível até 1GB). 11 Possui uma porta USB, que permite que um drive USB seja usado como unidade de armazenamento secundária. 11 400 Mbps de vazão. 11 4 portas Ethernet 10/100/1000 Mbps fixas. 11 3 slots para PIMs (há grande variedade de PIMs disponíveis). Os demais componentes da série J2300 são descritos a seguir: 11 Ponto ESD (eletrostatic discharge): usado para conectar uma pulseira eletrostática; 11 LED Alarm: se aceso, indica que há um alarme ativo. Pode ser um alarme crítico, majoritário ou minoritário. Para mais detalhes será necessário se conectar ao sistema; 11 LED Power: se aceso, indica que o equipamento está ligado; 11 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 desligamento “educado” (não abrupto). Se o botão é pressionado por mais de 5 segundos provoca o desligamento imediato do roteador. 11 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;

86

11 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 deletadas e a configuração de fábrica está sendo carregada; 11 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.

11 Porta Auxiliar: a porta provê um terminal (RS-232) remoto com um conector RJ-45. É usada para acessar a CLI do roteador remotamente; 11 Portas USB: aceitam a conexão de um drive USB que será usado como um meio de armazenamento; 11 Portas LAN: recebem conexões de rede do padrão 10/100/1000 Base-TX Gigabit Ethernet; 11 Terminal de aterramento: é o ponto de contato definido para conexão do fio de terra; 11 Drive Compact Flash Externo: provê um meio de armazenamento secundário para arquivos de log, de configuração e imagens de sistema operacional; 11 Tomada de força: é o ponto de conexão do cabo de força AC que alimentará o equipamento;


11 Ventiladores (fans) da fonte: proveem resfriamento automático da fonte de alimentação.

87

88


7 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 11 O sistema operacional da Juniper é o Junos.

conceitos

q

11 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. 11 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. 11 As funcionalidades do Junos são alocadas em múltiplos processos de software. 22 Cada processo possui uma função específica e roda em seu próprio espaço (protegido) de memória, garantindo que um processo não sofra com falta de recursos e não interfira nos recursos de outros. 11 A modularidade ajuda a manter problemas isolados. 11 Quando um processo falha, o sistema como um todo continua funcionando, perde-se apenas a funcionalidade pela qual o processo é responsável. 11 A arquitetura do Junos também favorece a inserção de novas funcionalidades. 11 Em outros sistemas é comum trocar-se toda a imagem do sistema operacional para adicionar novas funcionalidades. 11 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.

Capítulo 7 - Fundamentos de Junos

objetivos

Fundamentos de Junos

89

Figura 7.1 Modularidade Juniper.

11 Todas as plataformas que utilizam o Junos usam o mesmo código-fonte em imagens

q

específicas. 11 Esse design garante que as funcionalidades do software funcionam de maneira similar em todas as plataformas que utilizam o Junos OS. 11 Esse fator faz com que a configuração e a operação das diferentes plataformas funcionem exatamente da mesma maneira.

Separação entre planos de Controle e de Encaminhamento 11 Toda plataforma Juniper tem a mesma filosofia de trabalho: manter uma separação

q

bem definida entre as tarefas de controle e de encaminhamento. 11 Dessa forma, as plataformas definem uma entidade específica para cada uma dessas funções: o plano de controle e o plano de encaminhamento.

Routing Engine

RT

FT

Control Plane

JUNOS Software Internal link

Forwarding Plane

Frames/ Packets in

FT Packet Forwarding Engine

Figura 7.2 Separação entre planos de Controle e de Encaminhamento.

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 pacotes ficam 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. 11 O plano de controle é executado pela Routing Engine (RE), enquanto o plano de encaminhamento é implementado pela Packet Forwarding Engine (PFE). 11 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. 90

q

11 As mensagens de atualização da FT têm alta prioridade do kernel do Junos.

q

11 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 controle 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 estabilidade 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) A RE é o cérebro da plataforma, responsável por:

q

11 Gerenciar o sistema. 11 Processar e propagar anúncios dos protocolos de roteamento. 11 Manter a tabela de rotas (routing table). 11 Calcular e manter a tabela de encaminhamento (forwarding table). 11 Atualizar as informações de encaminhamento junto à PFE.

Routing Engine

RT

FT

JUNOS Software

Control Plane Forwarding Plane Figura 7.3 Routing engine.

Packet Forwarding 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 com a PFE. 11 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. 11 Por fim, a RE controla as ações da PFE através de informações de encaminhamento atualizadas que são passadas àquela entidade. 11 Os processos que residem no microcódigo da PFE também são gerenciados pela RE. 11 A PFE envia mensagens de status para a RE, que agirá caso alguma mensagem reporte uma situação inadequada.

q


a supervisão do sistema. Esses softwares são executados pelo kernel do Junos, que interage

91

Packet Forwarding Engine

q

11 A PFE é o componente central do plano de encaminhamento. 11 Sua função é despachar os pacotes recebidos com a maior velocidade possível. 11 Essa tarefa é baseada na informação de uma FT local da PFE. 11 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. 11 Esse design permite que o encaminhamento de pacotes continue funcionando em cenários de falha do plano de controle.

Routing Engine

Control Plane Forwarding Plane

Frames/ Packets in


Frames/ Packets out

Figura 7.4 Forwarding Engine.

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: limitador 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 11 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. 11 Para que o encaminhamento do pacote seja feito com sucesso, precisa haver uma entrada na FT da PFE. 11 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. 11 Mantendo o processamento do tráfego de trânsito confinado ao plano de encaminhamento, 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.


11 Tráfegos unicast e multicast são ambos classificados como tráfego de trânsito, sendo

92

processados pela PFE e não pela RE.

q

Routing Engine

CPU Control Plane Forwarding Plane

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: 11 Pacotes endereçados ao próprio chassi, como atualizações de protocolos de rotea-

q

mento, sessões telnet, pings, traceroutes e respostas a sessões iniciadas pela RE. 11 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). 22 Pacotes com o campo “IP options” marcado precisam ser enviados para apreciação da RE. 22 Um exemplo de aplicação que utiliza o campo “IP options” é o acelerador de tráfego. 11 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.

93

Routing Engine


Frames / Packets in

? Frames / Packets out

Figura 7.6 Tráfego de exceção


11 Todo tráfego de exceção é remetido à RE através de um link interno que conecta os

q

planos de controle e de encaminhamento. 11 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 desempenha as tarefas fundamentais para o bom funcionamento do roteador.

Routing Engine


Frames/ Packets in

Built-in Rate Limiting



Por segurança, o limitador de tráfego do link interno não é configurável.

94

Figura 7.7 Limitador de tráfego no link interno.

8 Descrever as interfaces do usuário, os diversos modos de configuração, os procedimentos de gravação e restauração das configurações.

conceitos

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 11 O Junos oferece duas formas de acesso de usuário: linha de comando ou interface

q

J-Web (http). 11 A interface de linha de comando do Junos (CLI – Command Line Interface) pode ser acessada de duas maneiras. 22 A primeira é via porta console out of band (OoB). 33 Para tal acesso deve-se utilizar um cabo console para conectar a porta console do roteador a um notebook (ou mesmo um PC). 33 Esse notebook deverá ter instalado um programa emulador de terminal (exemplo: “Tera Term”). 22 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 é necessá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. 11 O acesso do usuário ao sistema também se dá via uma interface web que vem habilitada de fábrica. A Juniper chama essa interface de J-Web. 11 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.

q

Capítulo 8 - Opções de acesso ao Junos

objetivos

Opções de acesso ao Junos

95

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 11 O primeiro passo para acessar a interface CLI é fazer o processo de login.

q

11 O Junos requer “username” e “password” para prover acesso ao sistema. 11 O administrador do sistema cria contas de usuários e as associa a um “perfil de acesso”. 11 Toda plataforma Junos possui a conta do usuário root configurada de fábrica, sem senha. 11 É 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: host (ttyu0)

q

11 login: user 11 Password: --- JUNOS 9.5R1.8 built 2009-04-13 20:03:09 UTC 11 user@host> 22 O usuário root tem acesso completo a todas as funções do roteador. 11 Quando se faz o login utilizando o usuário root, tem-se acesso a um shell de Unix. 22 Para iniciar a CLI do Junos utiliza-se o comando “cli”. 22 Para terminar a sessão usa-se o comando “exit”. 11 Todos os demais usuários (não root) ao se conectarem no sistema já recebem a CLI do Junos, sem necessidade do comando “cli”. 11 Para que um usuário não root tenha acesso a um shell, deve-se digitar o comando: # start shell

Modos de acesso A CLI do Junos permite duas modalidades de acesso: 11 Modo de operação: 22 A CLI é usada basicamente para monitoração e troubleshooting do roteador. 22 Comandos típicos disponíveis nesse modo: “show”, “monitor”, “ping” e “traceroute”.


33 Esses comandos permitem exibir informações do sistema e executar testes,

96

mas não permitem alterar a configuração da caixa. 11 Modo de configuração: 22 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.

q

Ajuda 11 A CLI do Junos provê acesso a um minimanual (help) em qualquer ponto da linha de

q

comando. 11 O “help” informa as opções disponíveis no ponto do comando onde a ajuda foi solicitada, fornecendo uma breve explicação de cada opção. 11 A ajuda pode ser invocada através do comando “?”. 11 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 configure

Clear information in the system 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.

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 O comando “help topic” fornece um manual mais completo sobre um determinado

q

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.


Se o ponto de interrogação é digitado no meio da string de um comando, o Junos mostrará

97

Help topic:

user@host> help topic Possible

interfaces

?

completions:

accept-data

Accept packets

accept-source-mac

Policers

accounting

for

Packet counts

destined

for

specific

virtual address

source

MAC addresses

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 O comando “help reference” apresenta um manual sumarizado, um pouco mais prático e

q

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 utilizada, 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

;

broadcast address; ...

98

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family family], [edit logical-routers logical-router-name interfaces interfacename 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 11 O Junos permite a utilização de teclas de completamento de comandos para evitar

q

que o usuário precise executar um comando completo. 11 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.

user@host> show interfaces

Sequência do teclado

1Ctrl+a user@host> show interfaces 1Ctrl+f user@host> show interfaces

Figura 8.1 Edição EMACS.

1Ctrl+e user@host> show interfaces

Posição do cursor Capítulo 8 - Opções de acesso ao Junos

1Ctrl+b user@host> show interfaces

99

As seguintes sequências são suportadas: 11 Ctrl + b: move o cursor um caractere para a esquerda.

q

11 Ctrl + a: move o cursor para o início da linha de comando. 11 Ctrl + f: move o cursor um caractere para a direita. 11 Ctrl + e: move o cursor para o final da linha de comando. 11 delete + backspace: remove o caractere antes do cursor. 11 Ctrl + d: remove todos os caracteres do início da linha até o ponto onde está o cursor. 11 Ctrl + k: remove todos os caracteres entre o cursor e o final da linha de comando. 11 Ctrl + u: remove todos os caracteres e nega o comando corrente. 11 Ctrl + w: remove a palavra à esquerda do cursor. 11 Ctrl + l: repete a linha corrente. 11 Ctrl + p: repete o comando anterior do histórico de comandos. 11 Ctrl + n: avança para o comando seguinte no histórico de comandos.

Usando o caractere “pipe” 11 O caractere “|” (pipe) executa a mesma função que possui nos sistemas baseados

q

em Unix. 11 Esse comando permite que a saída de um comando seja recebida e processada por um segundo comando. 11 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: 11 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. 11 count: exibe o número de linhas existentes na saída do comando antes do pipe. 11 display changed: disponível apenas no modo de configuração. Exibe mudanças de configuração feitas na sessão corrente (para visualização do arquivo em XML). 11 display detailed: disponível apenas no modo de configuração. Exibe informações adicionais sobre o conteúdo da configuração. 11 display inheritance: disponível apenas no modo de configuração. Exibe configuração herdada. 11 display omit: disponível apenas no modo de configuração. Exibe linhas da configuração da opção “omit”. 11 display set: disponível apenas no modo de configuração. Exibe os comandos “set” que geraram as linhas de configuração.


11 display xml: exibe a saída do comando anterior ao pipe no formato JUNOScript XML.

100

11 except : exibe a saída do comando anterior sem a expressão especificada. 11 find : exibe a saída do comando anterior começando da linha que contém a expressão regular especificada. 11 hold: exibe a saída do comando anterior ao pipe tela a tela (como faz o comando “more” do Unix).

11 last: exibe a última tela da saída do comando anterior ao pipe. 11 match : exibe a saída do comando anterior ao pipe, incluindo apenas as linhas que contêm a expressão regular especificada. 11 no-more: exibe a saída do comando anterior ao pipe toda de uma vez, sem pausa entre diferentes telas. 11 request message: exibe a saída para múltiplos usuários. 11 resolve: converte endereços IP em nomes do DNS. 11 save : salva o output do comando anterior ao pipe para o arquivo especificado. 11 trim: especifica o número de colunas a partir da linha inicial da saída do comando anterior ao pipe. É possível cascatear múltiplos pipes para processar uma saída de comando já processada


por um pipe.

101

102


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

103

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 operacional. A primeira opção é o sinal “?”, logo após cada comando.

root# set system host-name ? Possible completions:

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

104

> ssh

Allow ssh access

> telnet

Allow telnet login

> web-management

Web management configuration

> xnm-clear-text

Allow clear text-based JUNOScript connections

> xnm-ssl

Allow SSL-based JUNOScript connections

| [edit system]

Pipe through a command

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.

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]


Options

105

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.:5 clear ? Verifique as possíveis opções do comando “show system”. R.:5 show system ? Verifique todas as opções do comando “show system” que comecem com a letra “a”. R.:5 show system a? Consulte o manual do sistema sobre endereços de interfaces. R.:5 help topic interfaces address Cheque outros temas referentes a interfaces para os quais seja possível solicitar o manual de informações. R.:5 help topic interfaces ? Cheque outros temas para os quais seja possível solicitar o manual de informações. R.:5 help topic ? Utilize o comando “help reference” para verificar instruções de como aplicar um endereço a uma interface. R.:5 help reference interfaces address

Parte 2: Familiarizando-se com a CLI do Junos 11 Pratique o completamento automático de comando com as teclas “Tab” e “Space”. Exemplo 1: Digite “show system up” Exemplo 2: Digite “show system up” Exemplo 3: Digite “show system x” Exemplo 4: Digite “show system x” 11 Após aplicar os exemplos acima, explique a diferença entre “Tab” e “Space”:

11 Verifique o histórico de comandos antigos executando recursivamente a tecla “seta pra Introdução à rede Ipê

cima” ou “Ctrl+p”.

106

11 Avance para os comandos mais recentes do histórico executando recursivamente a tecla “seta pra baixo” ou “Ctrl+n”. 11 Digite o comando “pow interfaces fe-0/0/0” e tecle (isso gerará um erro). 11 Corrija o comando anterior digitando seguidamente:

“Ctrl+p” “Ctrl+a” Troque “P” por “sh”. Tecle .

Modo de operação 11 Ao fazer login no Junos, o usuário típico ganha acesso ao modo de operação, utilizado

q

para tarefas de monitoração e controle da plataforma. 11 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 Less Specific

clear

configure

arp

database

configuration

interface

monitor

ospf

neighbor

set

show

...

version

...

...

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: 11 Monitoramento e verificação do sistema (com comandos de “show”, por exemplo); 11 Troubleshooting; 11 Conexão a outros sistemas (com Telnet ou SSH); 11 Cópia ou criação de arquivos; 11 Reinício de processos; 11 Entrada no modo de configuração; 11 Término de sessão no equipamento.


Figura 8.3 Hierarquia do Modo de Operação.

help

107

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 11 Esse modo permite a um usuário alterar o arquivo de configuração do sistema. 11 Diferente da maioria dos fabricantes, os equipamentos Juniper não efetivam as alterações de configuração no exato momento em que os comandos de configuração são executados. 11 Todas as alterações que um usuário faz são acumuladas em um arquivo, temporariamente. 11 O Junos trabalha com os conceitos de Configuração Candidata e Configuração Ativa. 22 Configuração Ativa:


33 Presente no arquivo de configuração que está efetivamente valendo para o roteador. 33 Configuração que o sistema carrega durante o processo de “boot” do equipamento. 22 Configuração Candidata: 33 Fica em um arquivo temporário e poderá tornar-se a configuração ativa, caso o usuário queira. 33 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. 108

q

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.

commit Configuração Candidata

configure

Configuração Ativa

rollback n

0

1

2

49

...

Figura 8.4 Configuração Candidata e Configuração Ativa.

Ba lde d e b its

11 Para entrar no modo de configuração e inaugurar a criação de um arquivo de configu-

q

ração candidata deve ser utilizado o comando “configure”. A partir desse momento o usuário pode começar a configurar o Junos. 11 Após executar todos os comandos de configuração desejados, executa-se o “commit”. 11 Nesse momento, o Junos checará toda a configuração candidata procurando por possíveis problemas de sintaxe. 11 Não encontrando problemas, a configuração candidata é copiada para a configuração ativa. 11 As alterações passam a ser válidas. Se a sintaxe não está correta, o sistema gera uma mensagem de erro e a configuração candidata não é efetivada até que o erro seja corrigido. 11 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.

Esse número inclui o arquivo de configuração ativo correntemente.

Iniciando o Modo de Configuração 11 Para entrar no modo de configuração, executa-se o comando “configure” a partir da CLI do modo de operação. 11 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. 11 Uma vez no modo de configuração, o prompt da CLI muda do “>” para o “#”.

q


11 Na verdade, o Junos é capaz de salvar os últimos 50 arquivos de configuração.

109

11 Além disso, surge no prompt um par de parênteses (“[ ]”), indicando em qual ponto da

q

hierarquia do arquivo de configuração o usuário está. 11 Ao entrar no modo de configuração o usuário sempre entrará no nível “[edit]”.

Configuração exclusiva 11 Por default, múltiplos usuários podem entrar no modo de configuração e executar

q

“commit”. 11 Utilizando o comando “configure exclusive”, o usuário tem acesso ao modo de configuração e impede que outros usuários possam entrar nesse modo. 11 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: user@host> configure

q

Entering configuration mode [edit] user@host# user@host> configure exclusive warning: uncommitted changes will be discarded on exit Entering configuration mode [edit] user@host# 11 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. 11 Na próxima vez que se entrar no modo de configuração, a configuração candidata estará lá, intocada. 11 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 configuraçã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

110

mesmo alterou são revistas. Se dois usuários estão no modo de configuração privada e ambos fazem a mesma modificaçã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.

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

11 No modo de configuração, o usuário se movimenta através de uma hierarquia de porções da configuração. 11 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# [edit]

Less Specific

chassis interfaces bgp isis

protocols services system ...

mpls ospf

pim rip rsvp vrrp ...

area area_id graceful-restart overload traffic-engineering More Specific

area-range area_range

interface

nssa

stub

...

...

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. 11 Para modificar uma linha qualquer da configuração candidata utiliza-se sempre o comando “set”. 11 O comando “show” exibe a configuração candidata ou parte dela.

q


Figura 8.5 Hierarquia de configuração.

111

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;

} } 11 As diferentes porções do arquivo de configuração (candidata ou ativa) são hierarquizadas através de chaves (“{ }”). As chaves facilitam a leitura da estrutura de árvore. 11 O final de cada linha de configuração termina sempre com um ponto e vírgula (“;”), assemelhando o formato do arquivo a um código de linguagem de programação estruturada. 11 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 11 Ao entrar no modo de configuração, o usuário encontra-se na raiz da hierarquia. Esse

q

nível é chamado “edit”. Nesse momento o prompt de comando assinala a string “[edit]”. 11 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# [edit]

chassis

bgp


area

112

interfaces protocols

isis

area_id

area-range

mpls

ospf

pim

graceful-restart

area_range

services system

rip

rsvp

overload

interface

vrrp

...

...

traffic-engineering

nssa

stub

...

...

Para mover-se de volta um nível na hierarquia de configuração utiliza-se o comando “up”:

Figura 8.6 Comandos “edit”: movendo-se na Hierarquia de Configuração.

[edit protocols ospf area 0.0.0.51 stub] user@host# up [edit protocols ospf area 0.0.0.51] user@host# [edit]

chassis

bgp

area Figura 8.7 Comando “up”.


isis

area_id

area-range

mpls

ospf

pim rip

graceful-restart

area_range

services

system

...

vrrp

...

rsvp

overload

interface

traffic-engineering

nssa

stub

...

...

Para mover-se de volta “n” níveis na hierarquia de configuração utiliza-se o comando “up ”.

[edit protocols ospf area 0.0.0.51] user@host# up 2 [edit protocols] user@host# [edit]

chassis


bgp isis

area

area-range

ospf

pim

graceful-restart

area_range

system

...

vrrp

...

rip rsvp

overload

interface

traffic-engineering

nssa

stub

...

...

Para retornar para o nível raiz da hierarquia de configuração utiliza-se o comando “top”. Capítulo 8 - Roteiro de Atividades 3

Figura 8.8 Comando “up ”.

area_id

mpls

services

113

[edit protocols ospf area 0.0.0.51 stub] user@host# top [edit] user@host# [edit]

chassis


bgp isis

area

area_id

area-range

mpls

ospf

services

pim rip

graceful-restart

area_range

system

...

vrrp

...

rsvp

overload

interface

nssa

traffic-engineering

stub

... Figura 8.9 Comando “top”.

...

11 O comando “top” pode ser combinado com o comando “edit” para se mover de um

q

determinado nível da hierarquia para outro nível completamente diferente, com apenas um comando. 11 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]

user@host# top show system services ftp; ssh; 11 O comando “exit” retorna para o nível da hierarquia de configuração que o usuário estava antes do nível corrente. 11 Se o usuário estiver na raiz (nível “edit”) o comando “exit” sai do modo de configuração. 11 O comando “exit configuration-mode” sai do modo de configuração independente do


nível de hierarquia onde o usuário está.

114

q

[edit protocols ospf] user@host# edit area 51 stub [edit protocols ospf area 0.0.0.51 stub] user@host# exit [edit protocols ospf] user@host# [edit] chassis


bgp isis

area

area_id

area-range

ospf

pim rip

graceful-restart

area_range

system

...

vrrp

...

rsvp

overload

interface

traffic-engineering

nssa

stub

...

...

Resumo dos comandos para navegação entre os diferentes níveis da hierarquia de configuração: 11 edit: direciona o usuário para um ponto da hierarquia de configuração. 11 up: move o usuário um nível acima na hierarquia. 11 up : move o usuário “n” níveis acima na hierarquia. 11 top: move o usuário para a raiz da hierarquia. 11 exit: move o usuário para o nível anterior.

Alterando linhas da Configuração Candidata Uma vez posicionado no nível desejado da hierarquia que se quer modificar, o comando

q

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

mpls

services

115

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]”. 11 Para desfazer uma ação executada por um comando “set”, utiliza-se o comando “delete”. 11 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/*

116

matched: ge-1/0/0 matched: ge-1/0/1 Delete 2 objects? [yes, no] (no) yes

[edit]

q

user@host#

Ativando e desativando configurações 11 O Junos permite que um usuário desative uma determinada configuração sem removê-la.

q

11 Uma linha de configuração desativada continua presente no arquivo de configuração da caixa, mas o roteador irá ignorá-la. 11 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

user@host# commit commit complete [edit] user@host# show interfaces ge-0/0/0 unit 0 { family inet {


[edit]

117

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: 11 rename: altera o nome de uma configuração.

q

11 replace: altera um padrão em uma linha de configuração. 11 copy: copia um padrão de linha de configuração para outra linha. 11 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 11 No modo de configuração utiliza-se o comando “show” para verificar as linhas da configuração candidata. 11 Esse comando exibe a configuração de todo o arquivo da configuração candidata ou de uma porção da hierarquia corrente. 11 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] 118

q

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 para armazenar as configurações setadas pelo usuário. 11 Opcionalmente, é possível ver a configuração de uma determinada hierarquia no

q

formato de comandos “set”. 11 Dessa forma, o usuário tem acesso aos comandos que foram efetivamente utilizados para fazer as configurações presentes no arquivo. 11 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 11 Uma vez editada a configuração candidata com os vários comandos disponíveis no

q

11 A forma mais simples e usual de executar essa tarefa já foi apresentada: “commit”. 11 Após executar o “commit”, a mensagem “commit complete” confirma que as alterações foram executadas corretamente. 11 Caso haja erros de sintaxe, uma mensagem de erro será gerada e a configuração não será salva. Comando “commit”:


modo de configuração, é hora de salvar as alterações.

119

[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 configuraçã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 caracterizado 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 ”, onde é 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]

120

user@host# commit confirmed commit confirmed will be automatically rolled back in 10 minutes unless confirmed commit complete

Repare que, caso o usuário tenha cometido um erro de configuração que comprometa a conectividade do equipamento, esse procedimento evita que o usuário perca acesso total ao equipamento 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 11 Para checar se há um “commit” agendado no roteador utilize o comando “show

q

system commit” no modo de operação. 11 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]

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ó


user@host# commit comment “Changed OSPF configuration”

vez. Para tal utiliza-se o comando “commit and-quit”. 121

Checando alterações antes de salvar 11 Um usuário fez dezenas de mudanças na configuração candidata. Antes de executar o

q

“commit”, precisa ter certeza de que tudo foi feito. 11 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 configurações passadas. Para tal utiliza-se, no modo de operação, o comando “show configuration | compare rollback ”, onde 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 “ ”.

Restaurando configurações 11 O Junos pode guardar automaticamente as últimas 50 versões de arquivos de configuração. 11 Para restaurar qualquer um desses arquivos utiliza-se, no modo de configuração, o comando “rollback ”, onde denota o índice da configuração a recuperar. Nesse caso varia de 0 a 49. 11 O comando “rollback” reescreve um arquivo de configuração antigo na configuração candidata. 11 Para confirmar a restauração da configuração no roteador, o usuário precisa executar ainda o comando “commit”. 11 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

122

q

Dessa forma, a vida de um arquivo de configuração é retratada na figura a seguir.

Configuração Candidata

configure

Configuração Ativa

rollback n

0

1

2

...

49

Ba lde d e b its

Figura 8.11 Vida do arquivo de Configuração.

Salvando a configuração em arquivo ASCII 11 O Junos salva configurações automaticamente, as quais podem ser restauradas com o

q

comando “rollback”. 11 À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. 11 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ção candidata em um arquivo cujo nome foi especificado. As linhas que serão salvas no arquivo ASCII são as linhas da hierarquia onde se

11 Para salvar toda a configuração candidata é necessário estar no nível “[edit]”. 11 Para salvar as configurações referentes aos serviços do sistema deve-se executar o “save” no nível: “[edit system services]”. 11 Se o diretório do arquivo destino não é especificado, o arquivo é salvo no diretório home do usuário: /var/home/. A seguir podemos conferir formas alternativas para selecionar o destino do arquivo que será salvo.

q Capítulo 8 - Roteiro de Atividades 3

estava ao executar o comando.

123

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 automaticamente 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. O comando “load” permite vários argumentos:

q

11 factory-default: troca o arquivo de configuração corrente pela configuração default de fábrica. 11 merge: combina a configuração corrente com a configuração carregada. 11 override: sobrescreve completamente a configuração corrente com a configuração carregada. 11 replace: procura pela “tag replace” no arquivo de configuração que está sendo carregado. O software troca as linhas existentes com o mesmo nome daquelas marcadas com “replace” no arquivo carregado. 11 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 configuração candidata. Para efetivar as alterações é necessário usar o comando “commit”.


Comando run

124

11 O “run” permite ao usuário executar comandos do modo de operação a partir do modo de configuração. 11 Esse comando é similar ao comando “do” dos equipamentos de outros fabricantes.

q

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 11 Além da linha de comando, é possível interagir com o equipamento Juniper através de

q

uma interface web, a J-Web. 11 Essa interface vem habilitada de fábrica. 11 Para acessá-la, pode-se usar um web browser qualquer. 11 A J-Web é ideal para configuração inicial do equipamento. 11 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: 11 A aba “Dashboard” provê uma visão geral do status do sistema, das portas, dos alarmes 11 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. 11 A aba “Troubleshoot” provê acesso a ferramentas simples de rede como “ping” e “traceroute”. 11 A aba “Maintain” permite ao usuário executar upgrades de software e manutenção no sistema de arquivos.


ativos e informações de utilização.

125

Processo de login na J-Web Para que seja possível o acesso ao sistema através da J-Web, é necessário que o comando

q

“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

126

local o usuário tem acesso às estatísticas em tempo real das interfaces e de outros parâmetros do sistema. A opção “Chassis” mostra a tela da próxima figura.

Figura 8.12 Login na J-Web.

A opção “Interfaces” mostra informações sobre as interfaces do roteador.


Figura 8.13 Aba Monitor/ Chassis.

127


128

Figura 8.14 Aba Monitor/ Interfaces.

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.

129

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: 11 Recuperar arquivos de configuração históricos e compará-los; 11 Fazer upgrade ou downgrade do Junos; 11 Adicionar e verificar licenças; 11 Agendar reboots do sistema; 11 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.

130

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 partindo 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]

root# up [edit interfaces ge-0/0/0] root# up [edit interfaces] root# up [edit]


Para subir a árvore do arquivo de configuração do Junos, você deve utilizar o comando “up”.

131

O Junos oferece um comando para você ir ao topo do arquivo de configuração, independente 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”;

132

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

9 objetivos

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.

conceitos

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 11 Toda a plataforma que roda o Junos é vendida com uma configuração default de fábrica.

q

11 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. 11 É 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 projetadas 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

Figura 9.1 Configuração default de fábrica.

=

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.

Capítulo 9 - Configurações do roteador

Spanning Tree (RSPT). Outras plataformas não necessitam desse recurso.

133

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]

134

user@host# commit commit complete

Configurações iniciais Ligando, desligando e reiniciando o Junos:

q

11 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 imprová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]>


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

|


Este comando provê opções que permitem ao usuário:

q

11 Agendar um shutdown para um momento futuro, que pode ser especificado em quantidade de minutos ou em um horário exato. 11 Especificar a mídia a partir da qual um reboot será feito. 11 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”. 11 Uma vez desembalado e ligado, o equipamento Juniper está pronto para receber as

q

primeiras configurações.

senha para o usuário root. 11 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: ***


11 Antes de fazer qualquer alteração, o administrador é obrigado a configurar uma

135

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. Além desse item, também é recomendável que os seguintes itens sejam configurados:

q

11 Hostname do equipamento. 11 Horário do sistema. 11 Serviços para acesso remoto (Telnet, SSH). 11 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ão haverá um hostname configurado, o sistema usará o seu default: Amnesiac. O equipamento Juniper possui dois tipos de CLI:

q

11 CLI com shell de Unix, que permite acesso a uma série de utilitários do Unix. 11 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. 11 Para acessar a CLI do Junos é usado o comando “cli”. 11 Para retornar à CLI de Unix é usado o comando “exit”.

Entrando no Modo de Configuração 11 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. 11 Para tal é usado o comando “configure” no modo de operação da CLI do Junos.

Amnesiac (ttyu0)- Amnesiac prompt indicates a factory-default Introdução à rede Ipê

configuration

136

login: root

--- JUNOS 9.5R1.8 built 2009-04-13 20:03:09 UTC

q

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

[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


A seguir as configurações de data e hora no Junos:

137

11 Além da data e hora, deve-se confirmar o timezone da região pertinente.

q

11 O timezone configurado de fábrica é o UTC (GMT). 11 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. 11 É aconselhável configurar o horário do sistema depois de acertar o timezone. 11 Ao invés de definir o horário local, existe a opção de configurar o roteador para sincronizar 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 11 Outro protocolo de acesso que pode ser configurado de modo similar é o http, que

q

permite ao usuário acessar o equipamento através da interface J-Web. 11 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.

138

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 roteamento estático para a rede de gerência, para o caso de falha em um protocolo de roteaNo Junos, as rotas estáticas somente estarão disponíveis quando o rpd (Routing mento. 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 11 O Junos possui o recurso da configuração de resgate. 11 Trata-se de um arquivo de configuração extra, definido pelo usuário, que fica guardado no sistema e pode ser solicitado em situações de emergência. 11 É recomendável que a configuração de emergência possua os elementos mínimos necessários para restaurar a conectividade fundamental de rede. 11 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

q


...

139

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. Os tipos de interfaces presentes no Junos são listadas a seguir: 11 Interface de gerência: 22 Usada para conectar o roteador Juniper à uma rede de gerência. 22 A designação desse tipo de interface varia de acordo com a plataforma. 22 Alguns exemplos são “fxp0” e “me0”. 11 Interfaces internas: 22 Usadas para conectar os planos de controle e de encaminhamento. 22 A designação desse tipo de interface varia de acordo com a plataforma. 22 Alguns exemplos são “fxp1” e “em0”. 11 Interfaces de rede: 22 Usadas para prover conectividade de rede através de uma mídia específica. 22 Alguns exemplos de mídia são Ethernet, Sonet, ATM e T1. 11 Interface de loopback: 22 Interface lógica fixada no roteador, com diversas aplicações. 11 Interfaces de serviços: 22 Usadas para prover um ou mais serviços: encriptação, tuneling, NAT etc. 22 Podem ser implementadas via hardware, através de um cartão específico que pode ser comprado e adicionado à caixa, ou via software.


11 Alguns exemplos de interfaces de serviço e suas respectivas designações:

140

22 es: Interface de encriptação. 22 gr: Interface de Túnel GRE (Generic Rout Encapsulation Tunnel Interface). 22 ip: Interface de Túnel IP sobre IP. 11 ls: Interface de link de serviço. 22 ml: Interface Multilink. 22 mo: Interface de Monitoramento Passivo.

q

q

22 mt: Interface de Túnel Multicast. 22 sp: Interface de Serviços Adaptativos. 22 vt: Interface virtual de loopback.

Nomeando interfaces A figura a seguir apresenta os novos atores introduzidos: Interface, PIC (ou PIM) e FPC.

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

Enquanto diferentes plataformas usam nomes diferentes para os cartões de linha e os cartões de interface, o CLI quase sempre usa FPC e PIC.

Exemplo de nome de interface:

Interface card PIC

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

Line card FPC

PIC PIC

PIC

11 A interface é a porta de rede propriamente dita, onde será conectado um cabo que

q

ligará o equipamento a outro nó da rede. 11 A PIC (Physical Interface Card) ou PIM (Physical Interface Module) é um cartão instalado no roteador, que contém um número determinado de interfaces. 11 A FPC (Flexible PIC Concentrator) compreende a porção do hardware do roteador onde as PICs são instaladas. 11 As interfaces no Junos recebem nomes padronizados pelo sistema. 11 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á instalada, e na posição da interface na PIC. Em alguns modelos Juniper, tipicamente nos equipamentos de entrada, o termo PIC é substituí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 primeira 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 primeira 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.

141

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... 11 Cada interface física pode possuir uma ou mais interfaces lógicas (subinterfaces).

q

11 Criar subinterfaces é útil em ambientes onde se deseja criar conexões L2 como circuitos virtuais ou 802.1q. 11 Redes Frame Relay e ATM são exemplos de tecnologias que fazem uso de subinterfaces. 11 Algumas tecnologias de encapsulamento suportam apenas uma única unidade lógica, como PPP e HDLC. No Junos essas tecnologias utilizam o descritor zero. 11 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”. 11 O identificador da subinterface e o identificador do circuito virtual L2 não precisam

q

ser iguais. 11 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 11 A plataforma Junos permite que uma interface, física ou lógica, tenha mais de um endereço IP. 11 Para tal, basta executar dois comandos “set” de configuração de endereço. 11 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. 11 Essa regra vale, por exemplo, para a configuração do endereço IP na interface. 11 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

142

[edit interfaces ge-0/0/1 unit 0] user@host# show family inet { address 10.1.1.1/32;

q

} [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 A lista seguinte mostra as diferentes configurações físicas que podem ser feitas nas interfaces:

q

11 Protocolo de encapsulamento L2: pode ser, por exemplo, PPP, HDLC e Frame Relay, entre outros. 11 Modo: em interfaces ethernet pode-se escolher entre modo duplex ou half duplex. 11 Velocidade: configurável em certos tipos de mídia. 11 MTU: o Maximum Transmission Unit pode variar o tamanho entre 256 e 9192 bytes. 11 Clock. 11 Scrambling: se refere ao embaralhamento do payload dos pacotes (esta funcionalidade pode estar ligada ou desligada). 11 FCS: o Frame Check Sequence pode ser modificado para 32 bits (o default é 16).

Propriedades lógicas de interfaces A lista seguinte mostra as propriedades lógicas configuráveis nas interfaces:

q

11 Família de protocolo: pode ser inet (para IPv4), inet6 (para IPv6), mpls (para MPLS) etc. 11 Endereço: cada família configurada na interface tem um ou mais endereços lógicos.

11 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 {


11 Identificador de circuito virtual: para links Frame Relay, ATM ou tag de VLAN.

143

logical-properties;

[...]

} } } Todas as interfaces têm esta mesma organização hierárquica. 11 O Junos organiza todas as propriedades físicas debaixo do nome da interface. 11 O número de “unit” representa uma interface lógica (ou subinterface) particular. 11 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 {

144

address 192.168.100.1/32;

address 192.168.200.1/32; {

primary; }

}

q

} } Observe no código que uma “unit” pode suportar múltiplas famílias de protocolo, o que equivale 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 preferido. 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 elegeu o 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

Addresses, Flags: Is-Preferred Destination: fe80::/64, Local: fe80::217:cbff:fe4e:ab02

Verificando o estado das interfaces 11 Para verificar o estado das interfaces do roteador de forma rápida, utiliza-se o comando “show interfaces terse”. 11 Para verificar o estado de uma única interface particular, pode-se passar o nome da interface desejada como parâmetro para o comando.

q


Destination: 3001::/64, Local: 3001::1

145

user@host> show interfaces terse ge-O/O/2 interface


ge-O/O/2 ge-0/0/2.0

up

up

up

up


fe80::217:cbff:fe4e:a282/64

146

Remote

inet 10.15.173.1/28 172.19.102.1/24

inet6 3001::1/64

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 configuraçã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-

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


0/0/0 conforme chamado 7001”

147

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


3


4


5


6


7


8


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]>


0


1


2


3


4


root@bancadaX# rollback 1 load complete


[edit]

148

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]

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 equipamento 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

root@bancadaX> file list /cf/root/: .cshrc .history .login .profile


que se encontra, é possível listar os arquivos e diretórios com o comando “file list”.

149

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

150

Configurações de Usuário e Autenticação Há duas opções de configurações para acesso de usuário: autenticação local ou autenticação centralizada (usando solução de RADIUS ou TACACS+).

Local authentication database

RADIUS or TACACS+ server

Figura 9.3 Autenticação de Usuário Junos.

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: 11 As senhas precisam ter um mínimo de 6 caracteres; 11 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 ”. 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

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


ou no TACACS+ sejam mapeados para um template de conta de usuário definido localmente.

nenhum dos métodos funcionar, o acesso do usuário será negado. 151

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]”.

9)

78

b , la

2 ep

b (la

St

p

Ste

Step 1 (lab, lab789) Step 8 ACCEPT

T

JEC

E 3R

RADIUS server Username = lab Password = lab123

Step 4 (lab, lab789) Step 5 REJECT Ste p6 (la b, lab Ste 78 p7 9) AC CE PT

TACACS+server Username = lab Password = lab456

Local authentication database Username = lab Password = lab789 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 secret O parâmetro “secret” define um valor usado pelo RADIUS para validar a identidade do roteador. Para verificar a configuração de RADIUS usa-se o comando “show system radius-server”:

[edit system] user@host# show radius-server

152

Figura 9.4 Ordem de autenticação.

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 secret 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.”; ## SECRETDATA } 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 ];

153

[edit] user@host# show system authentication-order authentication-order [ radius tacplus ]; 9)

78

b , la

2 ep

b (la

St

CT


EJE

R p3

Ste

Step 1 (lab, lab789) Step 6 REJECT

Step 4 (lab, lab789) Step 5 REJECT


Local authentication database Username = lab Password = lab789 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 configurada 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ção de um período de time-out. Passado esse tempo o sistema


remoto será considerado inacessível.

154

Figura 9.5 Ordem de autenticação sem opção “password”.

b

, la

p

Ste

Step 1 (lab, lab789)


9) 78

lab 2(

Step 3 (lab, lab789)

Step 6 ACCEPT

Ste

p4

Ste

p5


(la b

, la

AC

CE

b7

89 )

PT

Local authentication database Username = lab Password = lab789 Figura 9.6 Ordem de autenticação: servidores de autenticação indisponíveis.

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 11 Cada comando do modo de operação e do modo de configuração está sujeito à

q

aprovação pelo processo de autenticação do sistema. 11 O mesmo vale para os recursos da interface J-Web. 11 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 é fundamental proteger a senha desse usuário. A figura seguinte introduz as entidades lógicas usadas no processo de autenticação de cada

user

Class

Figura 9.7 Entidades lógicas envolvidas no processo de autenticação.

Permissions

deny-commands deny-configuration

allow-commands allow-configuration

User Um usuário (user) é um membro de uma classe (class).

Authorized or Denied

q

Ao utilizar autenticação remota é possível mapear múltiplos logins do TACACS a um mesmo “user” do Junos.


comando aplicado por um usuário. Cada um desses atores é explicado a seguir.

155

Class 11 Uma classe (class) define um conjunto de flags de permissão.

q

11 É possível configurar ou customizar classes. 11 O sistema traz quatro classes pré-definidas que podem contemplar a maioria das situações desejadas. 11 Essas classes e suas respectivas flags de permissão estão listadas a seguir: 22 super-user: permissão total. 22 unauthorized: nenhuma permissão. 22operator: “clear”, “network”, “reset”, “trace” e “view”. 22 read-only: “view”.

Permission Uma permissão (permission) é uma flag associada a um privilégio. Pode-se entender uma

q

“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: 11 access: permite ver as configurações de acesso. 11 access-control: permite modificar as configurações de acesso. 11 admin: permite ver configurações de contas de usuário. 11 admin-control: permite modificar configurações de contas de usuário. 11 all: permissão total. 11 clear: permite limpar informações aprendidas da rede. 11 configure: permite acesso ao modo de configuração. 11 control: permite modificar qualquer configuração. 11 field: reservada para o suporte Juniper. 11 firewall: permite ver as configurações de firewall. 11 firewall-control: permite alterar as configurações de firewall. 11 floppy: permite ler e escrever informações no drive de floppy. 11 interfaces: permite ver as configurações de interface. 11 interface-control: permite modificar as configurações de interface. 11 rollback: permite a execução do comando “rollback ” com “n > 0”. 11 reset: permite fazer reset em interfaces e processos do sistema. 11 view: permite ver estatísticas do sistema. 11 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 Alé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.

156

q

[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 } } 11 No exemplo acima o administrador definiu que a usuária Nancy estará associada à

q

classe “noc-admin”. 11 As permissões “clear”, “network”, “reset” e “view” foram associadas a esta classe. 11 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. 11 Para tal, o primeiro passo foi liberar o comando (avulso) “configure private”. 11 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]”. 11 Em seguida o administrador usou, sob a mesma hierarquia de configuração, o

q

às permissões “interfaces” e “firewall”. 11 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]”. 11 Além disso, o administrador prefere garantir que os usuários da classe “noc-admin” não serão capazes de manipular arquivos. 11 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.


comando “allow-configuration”, o qual adiciona ao usuário os privilégios associados

157

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. 11 Esse sistema grava mensagens gerais sobre a operação do Junos, tais como interfaces

q

que saem de operação ou usuários que tentam fazer login e não conseguem. 11 O Junos grava as mensagens de log em arquivos que ficam armazenados no diretório “/var/log”. 11 O arquivo de log primário, definido pela configuração que vem de fábrica, é o “/var/ log/messages”. 11 As mensagens de log podem trazer uma grande variedade de eventos. 11 Cada evento possui alguns parâmetros que o caracterizam. 11 Por exemplo: severidade (severity) e facilidade (facility). 11 A facilidade é listada na frente do evento, e define a classe da mensagem. 11 A severidade vem em seguida, e determina a gravidade do evento reportado. 11 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 { interactive-commands any; } file config-changes { 158

#Registra todos os comandos CLI (*)

#Registra mudanças na configuração

change-log info; } (*)indica a configuração padrão de fábrica

As configurações de syslogs ficam na hierarquia “[edit system syslog]” e em

q

“[edit routing-options options syslog]”. Algumas opções de syslog: 11 “host ” ou “host ”: especifica o servidor de syslog para o qual deverão ser enviadas as mensagens de log. 11 archive: especifica a política de armazenamento dos arquivos de log. O default é manter 10 arquivos com tamanho máximo de 128 KB. 11 console: seleciona alguns tipos de mensagem para mostrar no terminal de console do sistema. 11 facility: mostra a classe das mensagens. 11 severity: mostra o nível de gravidade das mensagens de log. 11 file : especifica o nome do arquivo de log. 11 files : 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: 11 “timestamp”: horário do evento.

q

11 “hostname”: nome do sistema. 11 “process name”: nome do processo que gerou a mensagem. 11 “message code”: identifica a natureza e o propósito da mensagem. No exemplo o código da mensagem é “UI_DBASE_LOGOUT_EVENT”. 11 “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 mensagens de log, que passam a exibir um valor numérico que representa a gravidade do evento. 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 ”:

user@host> help syslog UI_DBASE_LOGOUT_EVENT Name:

UI_DBASE_LOGOUT_EVENT


Na escala de severidade do Junos, o valor zero representa os eventos mais graves, ao passo

159

Message:

User ‘’ 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 11 “Traceoptions” é o termo que a Juniper usa para o recurso que outros fabricantes

q

chamam de “debug”. 11 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. 11 O Junos enviará os resultados da operação de “trace” para o arquivo criado para esse fim. 11 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. Para investigar a operação de um determinado protocolo utilizando “traceoptions”, deve-se utilizar o comando “traceoptions” na hierarquia “[edit protocols ]”. Na maioria dos casos o administrador será seletivo, pois habilitando todo tipo de mensagens, um volume muito grande de informações é gerado. Para habilitar todo tipo de informaçã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-worldreadable; flag event detail; 160

q

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 funcional em casos de troubleshooting. Abaixo seguem alguns parâmetros que podem ser configurados quando se faz uso de “traceoptions”. 11 file : especifica o nome do arquivo que armazenará as informações. 11 size : 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... 11 files : especifica o número máximo de arquivos de “trace” que podem existir. 11 no-stamp: previne que o “timestamp” das mensagens seja colocado no início de cada registro, como ocorre no comportamento default do equipamento. 11 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. 11 readable: permite que qualquer usuário veja o arquivo. 11 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. 11 Além de investigar protocolos, as “traceoptions” permitem investigar recursos

q

do sistema. 11 Por exemplo, o comando “traceoptions” poderia ser utilizado abaixo da hierarquia “[edit interfaces ]”. Nesse caso, os eventos ou erros referentes a uma determinada interface da caixa seriam armazenados no arquivo de “trace”. 11 Analogamente, é possível investigar os erros e eventos relacionados a determinados processos do sistema. 11 Se ninguém remove ou desabilita as flags de “trace”, a atividade continua ocorrendo 11 Os arquivos continuam no disco indefinidamente até que sejam removidos ou sobrescritos por algum usuário. 11 Para desabilitar todas as “traceoptions” de uma hierarquia particular, executa-se o comando “delete traceoptions” sob a hierarquia desejada. 11 Para apagar um arquivo de “trace” criado, utilize o comando do modo de operação: “file delete ”.


em background, e os arquivos de “trace” continuam sendo gerados.

161

Há ainda outras operações que podem ser feitas nos arquivos com os comandos

q

(autoexplicativos): 11 file compare 11 file copy 11 file list 11 file rename

Visualizando arquivos de log e trace Para ver, via CLI, as informações armazenadas nos arquivos de log do Junos (não o shell

q

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. 11 O caractere “|” (pipe) é utilizado da mesma forma que nos sistemas Unix.

q

11 Esse comando permite que a saída de um comando possa ser usada como entrada de um segundo comando. No exemplo, o comando “match ” 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 11 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 ”. 11 Esse comando funciona de maneira análoga ao “tail -f” dos sistemas Unix.

162

q

11 É possível monitorar o incremento de vários arquivos diferentes executando o “monitor

q

start” várias vezes e variando o parâmetro “”. 11 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 diferenciar 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. 11 Pode-se utilizar a opção “match” para filtrar as mensagens apresentadas durante

q

a monitoração. 11 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 11 Para encerrar a monitoração utiliza-se o comando “monitor stop”. 11 Este comando, quando usado sem nenhuma opção, faz cessar todas as monitorações correntes. 11 Para certificar-se de que o término da monitoração realmente ocorreu, sempre utilize o “monitor list”.

Network Time Protocol (NTP) 11 Usa-se o NTP para sincronizar o horário de equipamentos de rede com uma fonte.

q

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

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;


Em relação ao protocolo NTP, o Junos suporta os modos assimétrico, cliente e servidor, e

server 10.210.14.173; 163

q

11 Duas máquinas podem se sincronizar apenas quando seus relógios estão relativamente próximos. 11 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 diferença é maior que 1000 segundos, os relógios não são sincronizados. 11 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 sincronizaçã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 11 O símbolo exibido perto do “hostname” indica o estado dos equipamentos envolvidos no processo de sincronização. 11 O símbolo asterisco (*) indica que o elemento ao lado foi selecionado para sincronização. 11 Outros símbolos podem aparecer na saída para indicar outros estados. O símbolo que deve aparecer em situação normal é o asterisco. 11 Outros detalhes da sincronização ficam disponíveis na saída do comando “show ntp status”.

Simple Network Management Protocol (SNMP) 11 Protocolo de gerenciamento padrão da arquitetura TCP/IP, que tem como objetivo

q

gerenciar equipamentos de rede. 11 Cada equipamento gerenciado roda um software agente. 11 A Central de Gerenciamento roda o software gerente, e o agente envia informações para a central. 11 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).

164

NMS

Poll

Response

Agent (device running JUNOS Software)

Figura 9.8 SNMP: Manager e Agente.

O agente responde a solicitações de informação geradas pelo manager. Um agente se comunica com o manager usando os seguintes tipos de mensagem: 11 Get, Getbulk e Getnext: o manager SNMP requisita informações do agente, que responde com um “get response”. 11 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”. 11 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 hierá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, independente 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 atividade 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, autenticidade 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 inforcapturador 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”;


mações. Na versão 1 as informações de pacote não são criptografadas, o que permite a um

165

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: 11 SNMP description: provê informação de identificação do agente em questão. 11 SNMP location: provê informações de localização do agente (importante em redes grandes). 11 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 administrador do Junos define os NMSs que podem fazer consulta usando-a, e o nível de acesso: 11 read-only: para leitura do valor dos OIDs; 11 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

166

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 administrador 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”).

Monitorando a operação do SNMP Um NMS provê a interface para a maioria das tarefas de monitoração do SNMP. Para verificar 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 ”. 11 No exemplo seguinte de operação de snmpwalk no Junos, o usuário solicitou informa-

q

ções sobre as OIDs abaixo da hierarquia jnxOperatingDescr. 11 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.

167

168


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.

169

Mesa do Instrutor

ROT D

ROT C

ROT B

ROT A

0/1

0/1

0/1

0/1

10.0.80.254/24 10.0.70.254/24 10.0.60.254/24 10.0.50.254/24 10.0.40.254/24 10.0.30.254/24 10.0.20.254/24 10.0.10.254/24

8

7

6

5

4

3

2

1

ROT D

ROT C

ROT B

ROT A

0/1

0/1

0/1

0/1

10.0.160.254/24 10.0.150.254/24 10.0.140.254/24 10.0.130.254/24 10.0.120.254/24 10.0.110.254/24 10.0.100.254/24 10.0.90.254/24

16

15

14

13

12

11

10

9

ROT D

ROT C

ROT B

ROT A

0/1

0/1

0/1

0/1

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

24

23

22

21

20

19

18

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

170

ge-0/0/0

up

down

ge-0/0/0.0

up

down inet

gr-0/0/0

up

up

ip-0/0/0

up

up

ls-0/0/0

up

up

192.168.1.1/30

17

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

down

se-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

-->

up

up

inet

10.0.0.1

-->

10.0.0.16

-->

128.0.0.1

-->

128.0.1.16

-->

0/0 lo0.16385 0/0

0/0

0/0

0/0

lo0.32768

up

up

lsi

up

up

mtun

up

up

pimd

up

up

pime

up

up

pp0

up

up

st0

up

up

fe80::205:86ff:fe71:e000


inet6

171

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, Autonegotiation: 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, Autonegotiation: 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: 172

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

packets:

136047

0 pps

Output packets:

51686

0 pps

Input

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

packets:

136047

Output packets:

51686

Input

Input

bytes

:

11634932

Output bytes

:

39606

packets:

73031

Output packets:

943

Input

Transit statistics: Input

bytes

:

6667571

0 bps

Output bytes

:

4588401

0 bps


Local statistics:

173

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;

174

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

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 class super-user set system login user authentication plain-textpassword 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.

175

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 acessarã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 = PCA_Banc1_logFile e = PCA_ Banc1_BkpFile Aluno(s) do PC B da Bancada 1 usarão = PCB_Banc1_ logFile e = PCA_ Banc1_BkpFile Aluno(s) do PC A da Bancada 2 usarão = PCA_Banc2_ logFile e = PCA_ Banc1_BkpFile Aluno(s) do PC B da Bancada 2 usarão = PCB_Banc1_ logFile e = PCA_ Banc1_BkpFile Baseando-se na configuração do arquivo “messages”, crie um arquivo de “log” chamado , 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 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 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

176

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.

Execute o comando “monitor list” no modo de configuração para checar as monitorações correntemente ligadas. Finalize a monitoração com “monitor stop ”. Verifique o arquivo de log que você definiu. Execute “file list /var/log/?” Configure o conteúdo que foi registrado nesse arquivo. Execute “file show /var/log/”. 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 offset

refid

st t when poll reach

delay

jitter

===========================================================

[edit]

0.244

193.204.114.232

2 -

1

64

1

21.849 Capítulo 9 - Roteiro de Atividades 6

200.144.121.33 -284920

177

178


10 objetivos

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.

conceitos

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

Figura 10.1 Ferramentas de monitoração.

J-Web

LEDs

LCDs

11 A ferramenta de monitoração primária do Junos é a CLI.

q

11 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 interface 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 operação “show system ”. Onde o “” pode tomar vários valores. Entre os mais comuns estão: 11 alarms: exibe alarmes ativos no sistemas (esses alarmes saem da lista automaticamente

Capítulo 10 - Operação, manutenção e monitoração

SNMP

quando o problema é sanado). 179

11 boot-messages: mostra mensagens geradas durante o último processo de “boot” do sistema. 11 connections: exibe o estado das conexões TCP e UDP locais. 11 statistics: mostra estatísticas de protocolos utilizados na caixa. 11 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 ”. A lista abaixo exibe alguns dos valores mais populares que o “” pode tomar: 11 alarms: exibe alarmes ativos referentes ao chassi, que saem da lista automaticamente quando o problema é sanado. 11 environment: exibe o estado da velocidade do sistema de cooling e de outros recursos de Introdução à rede Ipê

ambiente.

180

11 hardware: exibe um inventário dos componentes de hardware instalados e seus respectivos números de série. 11 routing-engine: mostra o estado operacional e detalhes da utilização da RE. Opções do comando “show chassis”:

user@host> show chassis ?

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 A família de comandos de modo de operação “show interfaces ” provê vários

q

detalhes sobre a operação das diferentes interfaces da caixa. Alguns dos comandos mais populares são: 11 show interfaces 11 show interfaces detail 11 show interfaces extensive 11 show interfaces 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.

do comando “show interfaces”:

user@host> show interfaces ge-0/0/0 ? Possible completions: <[Enter]>


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


O exemplo seguinte exibe ainda outras opções que podem ser utilizadas como argumento

181

snmp-index

SNMP index of interface

statistics

Display statistics and detailed output

terse

Display terse output

|


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

ge-O/O/O

up

up

ge-O/O/O.O

up

up

ge-O/O/1

up

up

ge-O/O/1.O

up

up

Local

Remote

inet

172.18.36.1/24

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 conexõ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 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

182

Link-level type : Ethernet, MTU: 1514, Speed: 100mbps, Loopback: Disabled, Source filtering negotiation: Enabled,

: Disabled, Flow control: Enabled, Auto-

Remote fault

: Online

Device flags

: Present Running

Interface flags : SNMP-Traps Internal: Ox4000 Link flags

: None

CoS 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 ” exibe, em tempo real, estatísticas sobre o uso de uma interface específica, tais como: volume de dados recebidos 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

Flags:

ge-O/O/O.0, Enabled,

0/0/2

Link is Up

SNMP-Traps

Encapsulation: ENET2 Local statistics: Input bytes:

Current

146945

[13768]

33911

[14327]

Output bytes: Input packets: Output packets:

2383

313

[185]

[70]

delta


Interface:

Delay:

183

Remote statistics: Input bytes:

48

Output bytes:

(4824 bps)

240 (0 bps)

Input packets:

Output packets:

[0]

[0]

11

(0 pps)

[7]

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=Û, Down=^D

Utilitários de rede Ping e Traceroute 11 Junos provê utilitários populares para avaliação da rede, como “ping” e “traceroute”. 11 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

184

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

q

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 ”, que faz com que sejam gerados apenas “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 11 O comando “monitor traffic” executa a mesma função do software Unix “tcpdump”.

q

11 Essa ferramenta monitora o tráfego de uma determinada interface, que é originado ou que termina na RE local do roteador. 11 Se nenhuma interface for especificada, a interface de gerência será monitorada.

Possible completions: <[Enter]>


detail

Display detailed output

extensive

Display extensive output

interface

Name of interface

layer2-headers

Display link-level header on each receive dump line

matching

Expression for headers of receive packets to match


user@host> monitor traffic ?

185

11 Problemas de camada 2 podem ser depurados usando o argumento “layer2-headers”.

q

11 A opção “matching” permite filtrar a massa de dados capturada usando critérios baseados nos campos do pacote do protocolo IP. 22 Trata-se de uma das opções mais funcionais para o comando. 11 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. 22 Essa opção permite salvar o conteúdo capturado em um arquivo no formato “.cap”. 22 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 or 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

186

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

Clientes de Telnet, SSH e FTP 11 O Junos traz previamente instalados clientes de Telnet, SSH e FTP.

q

11 Esses softwares permitem acessar equipamentos remotos a partir da CLI do Junos.

user@host> telnet ? Possible completions:

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 ‘^]’.

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:[email protected]/junos-jseriesdomestic.tgz / var/tmp/junos-jseries-domestic.tgz /var/tmp//...transferring.file.........Ri4PRe/100% of 41 MB 4071 kBps 00m00s


host (ttyp0)

187

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: 11 jkernel: compreende o kernel e o pacote de ferramentas de rede. Contém os arquivos básicos de sistema. 11 jroute: compreende o pacote da routing engine. Contém o software executado na RE. 11 jpfe: contém o software executado na Packet Forwarding Engine (PFE). 11 jdocs: contém as documentações do sistema. 11 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: 11 Package: é a descrição do conteúdo do pacote; alguns exemplos: jinstall, jkernel e junos-srx. 11 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 testadoras de novos softwares se confrontam com frequência com a letra “B”, que indica “Beta Introdução à rede Ipê

software”, ou com a letra “I”, que indica “Internal”.

188

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. 11 Edition: tipicamente será “domestic” ou “export”. Versões “domestic” suportam algoritmo de encriptação forte, enquanto as versões “export” não suportam.

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. Passos para a recuperação de senha:

q

11 Obtenha acesso via console e faça um “reboot” no sistema. 11 Durante o processo de “boot” tecle a barra de espaço continuamente. 11 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.

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 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 11 Depois de uma série de mensagens a CLI inicia e apresenta o prompt do modo de operação. 11 Nesse ponto pode-se executar um reset da senha de root com o comando “set system root-authentication plain-text-password”. 11 Em seguida, é necessário efetivar o comando com o “commit”.

q


deseja operar o equipamento através de um shell ou se deseja recuperar a senha de root.

189

[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 diretório qualquer. Para proceder com o upgrade, o usuário utiliza o comando do modo de operação:

request system software add Caso a imagem esteja em um servidor de FTP remoto é possível usar o mesmo comando, passando como argumento os nomes do diretório e do arquivo remotos, IP, senha e usuário do servidor de FTP. Procedendo dessa forma, o sistema fará a instalação a partir do arquivo remoto.

190

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 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:

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 autorizados 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 removidos 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”.


show system boot-messages

191

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

192

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 2011-01-21 15:11:06 UTC

Class Minor

Description 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

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


A luz do alarme deverá apagar.

193

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 configuraçã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

194

comando “display set”, que exibirá na tela os comandos que geraram a configuração atual, como exibido a seguir.

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


set interfaces ge-0/0/0 unit 0 description “WAN - 192.168.1.1”

195

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

196

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

-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

2010 .cshrc

6B Dec 14 21:57 ttyp1

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 [email protected]:/cf/root [email protected]’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 corretamente, 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. Type ‘?’ for a list of commands, ‘help’ for more detailed help.

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:


loader> boot -s

set system root-authentication plain-text-password 197

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á reiniciado. 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/ Após a execução deste 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”.

198

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.

199

200


11 Descrever o processo de roteamento de camada 3 e conceituar roteamento estático e sua configuração no roteador.

conceitos

objetivos

Fundamentos de roteamento

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 Internet

User B Data center

Figura 11.1 Redes L3.

11 Apesar dos roteadores serem os equipamentos mais populares para a tarefa de roteamento, outros dispositivos podem realizar essa função, como switches e firewalls. 11 Até mesmo alguns modems, utilizados em conexões ADSL de pequenos escritórios ou residências, são capazes de rotear pacotes L3.

q

Capítulo 11 - Fundamentos de roteamento

User A

11 A internet pode ser definida como um amplo conjunto de redes L3 interligadas. 201

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.

Internet

User A

User B Data center

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.

202

Figura 11.2 Componentes do roteamento.

Rotas diretamente conectadas Internet

User A .1

.1

User B Data center Figura 11.3 Exemplo de roteamento.

10.2.2.0/24 10.1.1.0/24 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 equipamentos 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 é necessá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

Tabela de rotas Routing protocol databases

Figura 11.4 Tabela de rotas.

Other routing information sources

OSPF OSPF OSPF Routing table Dire

Static

Forwarding table


aparece na tabela de rotas como “rota diretamente conectada”.

203

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. 11 Quando o equipamento recebe múltiplas informações de rotas para um dado

q

prefixo é preciso selecionar dentre as várias informações recebidas a que será efetivamente usada. 11 Essa rota será a rota ativa para o prefixo. 11 Opcionalmente pode-se fazer com que o Junos considere mais de uma rota para ser ativada, balanceando tráfego entre duas ou mais rotas. 11 Cada rota ativa para cada prefixo popula a Forwarding Table. 11 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 11 Equipamentos que rodam o Junos podem acomodar várias tabelas de rotas.

q

11 A tabela primária se chama “inet.0”, e armazena as rotas “unicast” de IP versão 4. 11 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: 11 inet.0: usada para armazenar rotas “unicast” de IP versão 4. 11 inet.1: usada para cache de rotas “multicast”. 11 inet.2: usada para armazenar rotas MBGP para checagem de Reverse Path Forwarding (RPF). 11 inet.3: usada para informação de encaminhamento de MPLS. 11 inet.4: usada para armazenar rotas MSDP. 11 inet.6.0: usada para armazenar rotas “unicast” IP versão 6. 11 mpls.0: usada para armazenar informações de “próximo hop” do protocolo MPLS.

Preferência de rotas: selecionando a rota ativa 11 Junos utiliza o recurso de “route preference” para diferenciar rotas recebidas por diferentes protocolos de roteamento. 11 “Route preference” é equivalente à distância administrativa usada em equipamentos de outros fabricantes. 11 A tabela abaixo mostra a “route preference” default das fontes mais populares de


informação de rotas.

204

q

Tabela 11.1 Preferência de rotas.

Routing information source

Default preference

Direct

0

Local

0

Static

5

OSPF internal

10

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


Tabela 11.2 Tabela completa “route preference”.

Direct

> to 10.1.1.2 via ge-0/0/10.0 205

[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. 11 Quando o roteador recebe a mesma rota (para um mesmo prefixo), com o mesmo custo,

q

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


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

206

Nesse cenário, se desejado, pode-se habilitar o balanceamento de tráfego através das múltiplas 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.

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

11 O comando “show route” mostra um sumário das rotas ativas, em “holddown” e escondidas. 11 As rotas ativas são aquelas efetivamente usadas para o encaminhamento do tráfego. 11 Rotas em “holddown” estão no estado pendente, e futuramente poderão ser usadas, se necessário. 11 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.


aprendeu a informação, bem como a sua “route preference”.

207

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 protocol databases

Other routing information sources

OSPF OSPF OSPF Forwarding table

Routing table Dire

Static

Figura 11.5 Forwarding Table.

A FT armazena um subconjunto da tabela de rotas. Dentro da FT, pode-se encontrar detalhes 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

perm

0

ucst

520

3 ge-

0/0/0.0


default

dscd

36

1

34

1

0.0.0.0/32

perm

0

172.19.0.0/16

user

0 200.1.4.100

ucst

535

3 ge-

user

0 200.1.2.100

ucst

529

3 ge-

user

0 200.1.3.100

ucst

534

3 ge-

0/0/3.0 172.19.52.0/24 0/0/1.0 172.19.52.16/28

208

rjct

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 contempla 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 rota ao invés da entrada default. Cada entrada na FT mostrada no exemplo possui um tipo (type). A lista abaixo detalha

q

“route types” comuns encontradas na FT: 11 intf: instaladas como resultado da configuração de endereço IP em uma interface. 11 perm: instaladas pelo kernel quando a tabela de rotas se inicia. 11 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: 11 bcst: o “next hop” é um endereço broadcast. 11 rjct: descarta o pacote e envia mensagem ICMP de “unreachable” para o remetente. 11 ucst: “next hop” do tipo unicast. 11 ulst: há mais de um “next hop” (está sendo usado balanceamento). 11 dscd: descarta o pacote silenciosamente. 11 hold: o “next hop” ainda será calculado. 11 locl: endereço de uma interface local. 11 mcst: o “next hop” é um endereço multicast. 11 mdsc: pacotes de multicast para serem descartados. 11 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á repasdestinado 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.

Forwarding plane Figura 11.6 Determinando o “next hop”.

Packets in

FT

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.


sado. Se o pacote é destinado ao equipamento local, o Junos irá processá-lo. Se o pacote é

209

user@host> show route forwarding-table Routing table: inet Internet: Destination

Type RtRef

Next hop

Type Index NhRef

user

0

0:17:cb:4e:ae:81 ucst

perm

0

Netif default

520

3

ge-

0/0/0.0 default

rjct dscd

36

1

34

1

0.0.0.0/32

perm

0

172.19.0.0/16

user

0

200.1.4.100

ucst

535

3

ge-

user

0

200.1.2.100

ucst

529

3

ge-

172.19.52.16/28 user

0

200.1.3.100

ucst

534

3

ge-

0/0/3.0 172.19.52.0/24 0/0/1.0

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 encaminhamento. 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 descarta 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

210

operação de múltiplos roteadores.

Device Running JUNOS software Routing instance (cust-A)

Routing instance (cust-B)

inet.0

cust-A.inet.0

cust-B.inet.0

inet6.0

cust-A.inet6.0

cust-B.inet6.0

ge-0/0/0.0

ge-0/0/3.0

ge-1/0/0.0

ge-0/0/1.0

ge-0/0/4.0

ge-1/0/1.0

lo0.0

lo0.1

lo0.2

Default route

Default route

Default route

OSPF

OSPF

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 master

Primary RIB forwarding

Active/holddown/hidden

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 _ _master.anon_ _

forwarding

master

forwarding inet.0

0/0/1

7/0/0

Além das instâncias de fábrica, o Junos permite que o usuário configure instâncias de roteamento 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 ]


Tabela 11.3 Visão geral de instâncias de roteamento.

Routing instance (master)

user@host# set instance-type ? 211

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: 11 forwarding: usada para implementar FBF para aplicações. 11 l2vpn: usada em implementações de VPN de camada 2. 11 no-forwarding: usada para separar grandes redes em entidades administrativas menores. 11 virtual-router: usada para aplicações com virtualização do sistema. 11 vpls: usada em implementações de LAN ponto-multiponto em um conjunto de sites de uma VPN. 11 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; }


}

212

protocols { ospf { area 0.0.0.0 {

interface ge-0/O/0.0; interface ge-0/0/1.0;

interface 100.1;

} } }

Trabalhando com 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 “.inet.0”, onde “” é 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 “.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

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


> via ge-0/0/1.0

213

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 ”. 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 newinstance 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 Rotas 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:


11 Só há um único caminho para se atingir um determinado prefixo.

214

11 Há múltiplos caminhos para se chegar a um prefixo, mas se quer forçar a rede a encaminhar o tráfego sempre pelo mesmo caminho (exceto em caso de falhas).

q

Network A 172.29.100.0/24

Figura 11.7 Exemplo de rota default estática.

ge-0/0/1 .1

.2

.1

Internet

172.30.25.0/30

192.168.63.14

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. 11 A configuração de rotas estáticas é sempre feita na hierarquia “[edit routing-options]”.

q

11 Ao configurar uma rota estática é necessário definir um “next hop” válido. 22 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. 11 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. 11 Outra possibilidade é o “next hop” tomar os valores “reject” ou “discard”. 22 Um pacote cujo IP destino é contemplado por uma entrada cujo “next hop” é “reject” ou “discard” será descartado. 11 A diferença entre essas opções é a ação que o Junos toma após o descarte. 22 Se a opção usada é o “reject”, o sistema envia uma mensagem ICMP de “destination unreachable” para o remetente. 22 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).

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 } }


Configurando Rotas Estáticas

215

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


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

216

Uma vez instaladas as rotas estáticas devidas, a conectividade entre as redes pode ser verificada 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 endereç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.

Host A

Host B .1

Figura 11.8 Resolvendo “next hop” indireto.

.2

Host C .5

172.25.1.0/30

.6

.1

172.25.1.4/30

172.20.3.0/24

[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 Junos e 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 interfaces 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 rota alternativa independente das rotas previamente definidas. A figura seguinte exibe a configuração e o conceito desse tipo de rota.

172.30.25.0/30

Network A 172.29.100.0/24 Figura 11.9 Qualified Next Hop.

ge-0/0/1 .2 .1

primary

.1 Internet

.6 ge-1/0/0

secondary

172.30.25.4/30

.5


Ao definir uma rota estática é possível utilizar a opção “qualified-next-hop” para definir uma

217

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

218

Roteiro de Atividades 8 Atividade 8.1 – Configurando rota estática Para esta atividade usaremos a topologia descrita na figura a seguir.

Mesa do Instrutor

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT D

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT C

ROT B

0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

ROT A 0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

0/1

0/1

10.0.80.254/24 10.0.70.254/24 10.0.60.254/24 10.0.50.254/24 10.0.40.254/24 10.0.30.254/24 10.0.20.254/24 10.0.10.254/24

8

7

6

5

4

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT D

3

1

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT C

ROT B

0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

2

ROT A 0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

0/1

0/1

10.0.160.254/24 10.0.150.254/24 10.0.140.254/24 10.0.130.254/24 10.0.120.254/24 10.0.110.254/24 10.0.100.254/24 10.0.90.254/24

15

14

13

12

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT D

11

9

0/0 - 172.16.2.2 0/0 - 172.16.2.1

ROT C

ROT B

0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

10

ROT A 0/2 - 172.16.1.2 0/2 - 172.16.1.1

0/1

0/1

0/1

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

24

23 Figura 11.10 Topologia da Atividade 8.1.

22

21

20

19

18

17

Após efetuar as ligações dos cabos conforme descrito para cada bancada, execute os


16

comandos de configuração a seguir. 219

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 # commit # set interfaces e1-1/0/0 unit 0 family inet address # 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 11 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. 11 Verifique a conectividade com o PC remoto do outro roteador:

ping 11 Há conectividade? Por quê?

11 Execute “show route ”. Você deve perceber que não existe rota para o endereço IP remoto. 11 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

220

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

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 11 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. 11 Em seguida verifique a conectividade com “run ping
11 Execute o comando “show | compare” para checar a diferença entre a configuração candidata e a configuração ativa. 11 Execute o comando “commit” e saia do modo de configuração. Em seguida teste novamente a conectividade com o PC remoto do outro roteador. Há conectividade?

11 Entre no modo de configuração com “configure private” e remova a rota estática criada com “delete routing-options static route next-hop ”. 11 Execute “show | compare” e em seguida “commit”. 11 Teste a conectividade com o PC remoto do outro roteador com “run ping ”. Há conectividade?

11 Retorne a última alteração. 11 Execute “rollback 1” e em seguida “show | compare”. Os comandos adicionados à configuração candidata com o “rollback” retornam a rota recém removida?

11 Se sim, execute “commit”, teste a conectividade e saia do modo de configuração. 11 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?

set routing-options static route metric 33 set routing-options static route preference 26 11 Execute “show route” para verificar as alterações. 11 Entre no modo de configuração com “configure private”, acesse a hierarquia “[edit routing-options]” e execute “show” para verificar os comandos gerados no arquivo de configuração.


11 Altere a métrica e a distância administrativa da rota que você instalou.

221

222


12 Descrever o filtro de firewall do Juniper e introduzir os procedimentos de configuração do firewall.

conceitos

objetivos

Filtros de firewall

Filtros de firewall, RPF Unicast.

Visão geral 11 O conceito de filtro de firewall no Junos se assemelha ao que o mercado de redes

q

chama de lista de acesso. 11 Esse recurso é utilizado para controlar o tráfego que passa através de um equipamento Juniper (saindo ou entrando). 11 Cada pacote é examinado individualmente.

Diferente de um firewall statefull, que enxerga as diferentes conexões e permite ao usuário escolher uma ação sobre todos os pacotes de um determinado fluxo. O filtro de firewall do Junos não enxerga fluxos, comportamento definido como firewall stateless. 11 Graças à natureza stateless do firewall do Junos, o usuário precisa configurar explicitamente qual será o comportamento do filtro de firewall em ambas as direções do tráfego para cada conexão.

q

Capítulo 12 - Filtros de firewall

Figura 12.1 Filtro de firewall.

223

11 Em contraste, o firewall statefull requer apenas que o usuário determine a ação a ser

q

tomada em um dado tipo de conexão. 11 Feito isso, todos os pacotes dessa conexão, em ambas as direções do tráfego, sofrerão a mesma ação (bloquear ou permitir). Os filtros de firewall no Junos têm duas utilidades clássicas: 11 O bloqueio de certos tipos de tráfego de entrada ou saída de uma interface; 11 A monitoração de determinado tráfego.

Diagrama de bloco de um filtro de firewall 11 O bloco fundamental de um filtro de firewall é uma entidade lógica chamada

q

“term” (termo). 11 Um filtro contém um ou mais termos. 11 O termo define condições e ações. A execução das ações definidas no termo será feita sobre todos os pacotes que satisfizeram as condições do termo. O termo pode definir zero ou mais ações. Além disso, pode ter zero ou mais condições. A partir daí, a operação é simples: se todas as condições (match) do termo são verdadeiras, o Junos executará as ações especificadas dentro do termo. Se o termo não possui nenhuma condição definida, apenas ações, o Junos considera que todos os pacotes deverão provocar a execução das ações do termo. Filtros de firewall consistem de um ou mais termos; o software avalia os termos sequencialmente até que encontre uma ação de terminação.

my-filter

term firstterm from

Nomes de termos e filtros definidos pelo usuário.

then match no match

from

Comandos descrevem as condições de comparação (match).

then

term secondterm from

then match

Comandos descrevem as ações que devem ser tomadas se ocorrer uma comparação com o comando from

no match

term Default Introdução à rede Ipê

discard

224

Ação default para os pacotes não permitidos explicitamente.

Conforme mostrado na figura, a entidade lógica que agrupa os vários termos é chamada “filter” (filtro).

Figura 12.2 Filtro de firewall: diagrama de blocos.

11 Ao definir o filtro, o usuário deve escolher com critério a ordem dos termos, pois ela

q

influenciará na operação do filtro. 11 Todo filtro no Junos requer a definição de pelo menos um termo. A figura revela ainda que os filtros no Junos sempre incluem um termo default, ainda que o usuário não o tenha definido. Esse termo diz ao Junos o que fazer com um pacote que não satisfaz as condições de nenhum dos outros termos. Esse termo default informa ao Junos que o pacote deve ser descartado. Assim, o administrador do sistema deve ter sempre em mente que caso um pacote não atenda a nenhum dos “matchs” do filtro, será descartado.

Condições Match 11 Geralmente uma condição “match” cai dentro de uma dentre três categorias: compa-

q

ração numérica, comparação de endereço ou comparação de bit. 11 As condições de um termo são definidas através da opção “from”. 11 Os critérios avaliados pelo “match” podem ser valores em campos do cabeçalho dos pacotes IP. Mas nem todos os campos desse cabeçalho estarão disponíveis. 11 Quando o usuário especifica o campo do pacote IP que será avaliado, o Junos procura em cada pacote, no campo determinado, um valor para verificar se o critério “match” definido é atendido.

from

Comandos descrevem as condições de comparação (match).

from

then match

O Junos não verifica se o tal campo faz sentido no pacote que está sendo avaliado. Por exemplo, o usuário pode definir que o Junos deve tomar uma ação baseado na existência da flag ACK no pacote TCP. Dessa forma, o Junos irá procurar pelo bit que define o ACK, na posição do pacote onde esse bit está sempre presente. No entanto, o Junos não verificará se o pacote é TCP. Se o pacote que passa pela interface for UDP, que não tem o conceito de ACK, ocorrerá um problema semântico da análise do filtro. Assim, cabe ao usuário ter ciência desse comportamento do sistema e cuidar para que as análises sejam coesas. No exemplo anterior, o usuário deveria utilizar dois “matches”: o primeiro informando que o pacote tem que ser TCP, e um segundo dizendo que o bit ACK deve estar configurado. 11 Alguns problemas semânticos também podem ocorrer quando há pacotes fragmentados. 11 Quando um pacote é fragmentado, todos os seus fragmentos são transmitidos e tratados separadamente pelo filtro do Junos. 11 Nem todos os fragmentos contêm os mesmos campos de camada 4. 11 Alguns campos só estão presentes no primeiro fragmento. 11 Ao definir um “match” baseado em um campo de camada 4, o Junos tentará encontrar esse campo no pacote, mesmo que ele não exista.

q


Figura 12.3 Filtro de firewall: diagrama de blocos.

term firstterm

225

11 Esse comportamento pode trazer resultados imprevisíveis quando se está utilizando

q

um firewall stateless como o do Junos. 11 Muito cuidado deve ser tomado ao se definir filtros baseados em determinados campos de camada 4.

Ações do filtro de firewall 11 O administrador especifica as ações de um termo com a opção “then”.

q

11 Em geral, as ações de um termo podem ser ações terminadoras ou ações modificadoras. Pensando em um filtro que tenha vários termos, uma ação terminadora faz com que a análise de todos os termos subsequentes seja cancelada. Ao verificar dentro de um termo uma ação terminadora, o sistema executa a ação e não se faz necessário verificar o conteúdo dos demais termos. As ações terminadoras são: “accept”, “reject” e “discard”.

term firstterm from

then match

then

Comandos descrevem as ações que devem ser tomadas se ocorrer uma comparação com o comando from

11 A ação “accept” faz com que o sistema permita que o pacote avaliado seja

q

processado normalmente. 11 A ação “discard” faz com que o pacote avaliado seja descartado silenciosamente. 11 A ação “reject” faz com que o sistema seja descartado e uma mensagem de ICMP seja enviada ao remetente informando sobre o descarte. A ação “reject” admite argumentos opcionais que permitem ao usuário enviar uma mensagem ICMP (destination unreachable) diferente para o remetente ou mesmo enviar um “TCP reset” ao invés da mensagem ICMP. A ação “reject tcp-reset” executa essa ação. Além das três ações terminadoras, o usuário tem a opção de usar uma ação modificadora. As ações modificadoras são: “count”, “log”, “syslog”, “forwarding-class”, “loss-priority” e “policer”. Diferente das ações terminadoras, quando o sistema encontra uma ação modificadora, ela é executada e o processamento dos termos subsequentes do filtro acontece normalmente. Esse processamento somente será interrompido por uma ação terminadora. 11 Vale lembrar que se após processar todos os termos de um filtro o sistema não encontra nenhuma ação terminadora, o pacote será encaminhado para o termo default criado pelo sistema, e o pacote em análise será descartado.


11 É boa prática definir um termo final sem condições e com uma ação terminadora. 11 As ações “count”, “log” e “syslog” servem para gravar informações sobre os pacotes processados pelo filtro. 11 As ações “forwarding-class” e “loss-priority” são usadas quando se está trabalhando com diferentes classes de serviço (CoS). 11 A ação “policer” permite invocar um “traffic policer”, que será apresentado mais tarde nesse curso. 226

q

Figura 12.4 Cláusula Then: Ação!

Definindo um filtro de firewall O uso de um filtro de firewall inclui dois passos: definir um filtro e aplicar o filtro

q

em uma interface. Os filtros de firewall são definidos na hierarquia “[edit firewall]”. O Junos separa os diferentes protocolos de rede em famílias. Ao definir um filtro é necessário especificar para qual família de protocolo o filtro é válido. Em geral, o filtro de firewall atuará em pacotes IP versão 4, que correspondem à família “inet”. Para definir um filtro de IPv4 utiliza-se a hierarquia “[edit firewall inet]”. O exemplo seguinte ilustra a estrutura básica de um filtro.

my-filter

term firstterm from

then match no match

term secondterm from

then match no match

term Default discard Figura 12.5 Estrutura do filtro.

q

11 Após definir o filtro, é necessário aplicá-lo em uma interface. 11 Um filtro pode ser aplicado nas direções “in” ou “out” (para processar pacotes entrando ou saindo de uma interface).

Filtros de firewall de entrada (Input) controlam o tráfego entrando na interface.

Output

Output

Input

Filtros de firewall de saída (Output) controlam o tráfego saindo da interface.

Um filtro pode ser aplicado em mais de uma interface. O mesmo filtro também pode ser aplicado nas duas direções (“in” e “out”) de uma interface. Um filtro também pode ser aplicado na interface de loopback do equipamento para filtrar tráfego destinado ao sistema. Um filtro é aplicado em uma interface através da hierarquia (considerando filtro para protocolo IPv4):

[edit interfaces unit family inet filter] Para aplicar o filtro a uma interface dentro da hierarquia acima, utiliza-se: 11 set input (para definir o filtro atuando nos pacotes entrantes da interface) ou;


Figura 12.6 Aplicando filtro nas interfaces.

Input

11 set output (para pacotes saindo da interface). 227

Um filtro definido para um determinado protocolo de rede só pode ser utilizado em “units” desse mesmo protocolo. Ou seja, não é possível, por exemplo, aplicar um filtro de IPv6 em uma “unit” que não seja IPv4. Se um filtro é definido sob a hierarquia “[edit firewall inet6]”, não será possível aplicá-lo em uma hierarquia “[ edit interfaces unit family inet ]” (unit IPv4). Ou seja, a “family” do filtro precisa casar com a “family” da interface. Ao adicionar um filtro a uma interface através de uma sessão remota (Telnet ou SSH) é sempre uma boa prática utilizar a opção “commit confirmed”. É comum o administrador, por um erro de configuração, perder acesso a uma interface após aplicar um filtro.

Para pensar O uso do “commit confirmed” pode economizar muitas horas de trabalho e deslocamentos desnecessários.

Exemplo de filtro Definindo um bloqueio do protocolo ICMP. Nome do filtro: bloqueios.

set firewall filter bloqueios term block_icmp from address 10.0.0.0/24 set firewall filter bloqueios term block_icmp from protocol icmp set firewall filter bloqueios term block_icmp then discard set firewall filter bloqueios term permit then accept A seguir, outro exemplo, desta vez com o protocolo http.

MYNET

R1

.100

ge-0/0/1.0

.1

.2

172.27.102.0/24

.1

Internet

172.30.25.0/30

Figura 12.7 Exemplo de filtro (parte I).

Na figura anterior, o usuário deseja filtrar todo o tráfego de protocolo http que entra pela interface ge0/0/1.0, exceto o tráfego destinado ao servidor da figura. A configuração seguinte exibe um exemplo de filtro que pode fazer essa tarefa.


MYNET

228

.100

R1 .1

ge-0/0/1.0 .2

172.27.102.0/24

Figura 12.8 Exemplo de filtro (parte II).

O filtro criado possui dois termos. No primeiro a condição é que o tráfego seja http e o destino seja o servidor. Se essas duas condições forem contempladas, o tráfego será permitido e o processamento termina (na ação terminadora “accept”). Se alguma das condições não for aceita, o processamento seguirá para o segundo termo. O segundo termo diz que se o tráfego for http, deve ser descartado (ação terminadora “discard”). Se a condição do segundo termo também não é contemplada, o pacote entra no termo default, que não aparece explicitado na configuração. Trata-se de um termo que é automaticamente considerado pelo sistema. O termo default descartará o tráfego por definição (com a ação terminadora “discard”). Repare que nesse exemplo específico o único tráfego permitido é http para o IP do servidor. Qualquer outro tráfego será bloqueado (o que pode não ser o desejo do administrador). Sempre que necessário evitar o termo default (que descarta todos os pacotes por default), utilize um último termo sem condições e com a ação “accept”.

Filtrando tráfego local O filtro exibido no exemplo anterior é chamado filtro de tráfego. Esse filtro protege uma rede de acessos não autorizados. Mas um filtro também pode ser usado para proteger o acesso ao roteador. Esse é chamado filtro de acesso local. Esse tipo de filtro tem a mesma estrutura do filtro de tráfego, mas é aplicado à interface lo0 (Loopback 0). A figura seguinte ilustra o ponto de atuação do filtro de acesso local quando aplicado à interface lo0.

Routing Engine


Frames and Packets in

Packet Forwarding Engine Os filtros de tráfego local são aplicados de modo a proteger a RE. A PFE aplica esse filtro antes de passar o tráfego ao plano de controle. Ao aplicar um filtro de tráfego local é importante considerar o tráfego provindo dos protocolos de roteamento e outros tráfegos de controle. Essa observação ganha importância graças ao comportamento do termo default, inserido automaticamente pelo sistema. Ao aplicar um filtro de tráfego local é fundamental o uso do “commit confirmed”. É comum ocorrerem problemas graves após uma configuração equivocada de um filtro de tráfego local. A seguir um exemplo de filtro de tráfego local que limita o tráfego SSH à RE.


Figura 12.9 Filtrando tráfego local.

Io0

229

Definition

Application

filter limit-ssh-access {

lo0 {

term ssh-accept {

source-prefix-list {

trusted; } protocol tcp; destination-port ssh; }

unit 0 {

from {

then {

discard; }

family inet {

filter {

input limit-ssh-access; } address 10.255.71.48/32; } } }

}

term else-accept {

then accept; } } O primeiro termo define que os endereços IP presentes na lista de prefixos chamada “trusted” têm permissão para entrar na RE. O segundo termo bloqueia qualquer outro tráfego de SSH. O terceiro termo permite acesso a qualquer outro tráfego. Repare que se o termo “else-accept” não fosse incluído, o software descartaria todo o tráfego de controle e gerência que não foi especificado explicitamente. Isso inclui os anúncios de rotas OSPF, BGP e de outros protocolos provindas de roteadores vizinhos, bem como mensagens SNMP ou NTP de plataformas de gerência. Um sério distúrbio poderia ser causado. Para completar a configuração, a seguir vemos a criação de uma “prefix-list”, definição feita na hierarquia “[edit policy-options]”.

[edit policy-options] user@host# show prefix-list trusted { 172.27.102.0/24; }

Implementando policing com filtros de firewall 11 Além de aceitar ou descartar pacotes, os filtros de firewall podem ser usados para limitar determinados padrões de tráfego.


22 Essa tarefa é chamada de policing.

230

11 Para executar a tarefa de policing no Junos é necessário criar um policer e usá-lo em conjunto com um filtro de firewall. 11 O policer é criado na hierarquia “[edit firewall]”, sendo preciso aplicá-lo a uma interface.

q

Ba l d e d e b it

Figura 12.10 Policer em ação.

O filtro usado para a tarefa de policing tem a mesma estrutura dos demais filtros. Ele consiste em um conjunto de termos, os quais definem condições e ações relacionadas. A diferença é que normalmente se usa a opção policer no(s) primeiro(s) termo(s). Para melhor entendimento, a seguir vemos o uso de um policer associado a um filtro de firewall.

[edit firewall] user@host# show policer p1 { if-exceeding { bandwidth-limit 400k;

burst-size-limit lOOk; } then discard; } family inet { filter rate-limit-subnet { term match-subnet {

from {

source-address {

}

}

then {

policer p1; }

}


192.100.1.0/24;

231

term else-accept {

then accept;

} } } No exemplo anterior, um policer foi definido de modo a limitar um determinado padrão de tráfego a uma largura de banda média de 400 Kbps, com direito a 100 Kbytes de burst. 11 O parâmetro “burst-size-limit” pode ser entendido como um pico que pode exceder a velocidade média assinalada. 11 Uma forma recomendada para se calcular o burst é multiplicar a largura de banda máxima que se quer permitir (valor de pico do tráfego) pela quantidade de tempo de duração do pico. 11 Por exemplo, imagine uma interface com capacidade para 1 Gbps. 22 O administrador quer permitir que determinado padrão de tráfego use apenas 10 Mbps. 22 No entanto, o administrador admite que a aplicação possa gerar picos de 100 Mbps com duração de 5 milisegundos. Assim, teremos o cálculo do “burst-size-limit”: 33 burst-size-limit = (100.000.000 bits /segundo) x (5/1000 segundos) = 500.000 bits 22 Convertendo o valor acima em bytes: 33 burst-size-limit = 500.000 / 8 = 62500 bytes Dessa forma, para o administrador executar o policer como definido no exemplo, a configuração ficaria:

firewall { policer class-example { if-exceeding { bandwidth-limit 10m; burst-size-limit 62500; } then forwarding-class best-effort; } family inet {


filter example1 {

232

term policer-example { from { protocol tcp; } then {

q

policer class-example; forwarding-class assured-forwarding; accept; } } } } } Para o restante dos conceitos, será considerado o exemplo a seguir:

[edit firewall user@host # show policer pl if-exceeding { bandwidth-limit 400k; burst-size-limit 100k; } then discard; } family inet { filter rate -limit-subnet { term match-subnet { from { source-address { 192.100.1.0/24; } }

policer pl: } } term else-accept { then accept;


then {

} 233

} } 11 Acima há um policer chamado “p1”, que descarta tráfego que exceda o consumo de

q

uma largura de banda média de 400 Kbps com picos de 100 Kbytes. 11 Ao definir os limites do policer, pode-se usar as letras “k”, “m” e “g” para indicar milhares, milhões e bilhões de bytes (ou bits/segundo). 11 Uma vez definido o policer, é possível invocá-lo a partir de um termo de filtro de firewall. 11 Esse termo definirá o padrão de tráfego que estará sujeito à ação do policer. No exemplo acima, o filtro “rate-limit-subnet” submete todo o tráfego originado pela rede 192.100.1.0\24 ao policer definido previamente. Será descartado o volume de tráfego daquela sub-rede que demandar mais recursos do que os definidos pelo policer. Todos os demais tráfegos, originados de outras redes, serão aceitos normalmente e poderão usar toda a largura de banda da interface onde o filtro for aplicado.

Estudo de caso: filtros de firewall A próxima figura exibe a topologia de um estudo de caso.

MYNET

R1 .1

ge-0/0/1.0 .2

172.27.102.0/24

.1

Internet

172.30.25.0/30

Os seguintes objetivos deverão ser contemplados: Para o tráfego saindo da interface ge-0/0/1.0: 11 Todo o tráfego de qualquer fonte que não seja da rede 172.27.102.0\24 deve ser descartado e registrado em arquivo de log; 11 Todo o tráfego restante deve incrementar um contador e ser permitido. Para o tráfego entrando na interface ge-0/0/1.0: 11 Todo tráfego com IP origem da rede 172.27.102.0\24 deve ser descartado e registrado. 11 Todo tráfego da internet respondendo a conexões TCP iniciadas do servidor MyNET deve ser atendido.


11 Todo tráfego ICMP dos tipos “echo-reply”, “time-exceeded” e “destination unreachable” deve ser permitido. 11 Qualquer outro tráfego deve incrementar um contador e ser descartado. Para alcançar os objetivos traçados, o filtro seguinte foi definido para ser aplicado na saída da interface.

[edit firewall family inet filter output-ff] user@R1# show

234

Figura 12.11 Estudo de caso (parte I).

term deny-spoofed { from { source-address {

0.0.0.0/0;

172.27.102.0/24 except; ----- Excludes specified prefix

} } then{ log; discard; } } term else-accept { then ( count outbound-accepted; accept; } } O exemplo seguinte define o filtro a ser aplicado na interface de entrada:

[edit firewall family inet filter input-ff] user@Rl# show term deny-spoofed { from { source-prefix-list {

internal-prefixes;

}

then { log; discard; } }


}

term allow--established-sessions 235

from { protocol tcp; tcp-established; } then accept; } term allow-some-icmp { from { protocol icmp; icmp-type [ echo-reply time-exceeded unreachable ]; } then accept; } term else-discard then { count inbound-discarded; discard; } } [edit policy-options] user@Rl# show prefix-list internal-prefixes { 172.27.102.0/24; } Na configuração aplicada foram usadas as opções “count” e “log”. O “count” mantém um contador cumulativo de pacotes e de bytes. Para cada contador de um filtro o sistema mantém um único conjunto de estatísticas. Assim, se um mesmo filtro é aplicado em múltiplas interfaces, todos os pacotes contemplados pelo “count” incrementarão um mesmo contador.


O próximo passo é aplicar os filtros definidos nas direções de entrada e saída da interface.

236

[edit interfaces ge-0/0/1] user@R1# show unit 0 { family inet { filter {

input input-ff;

output output-ff;

}

address 172.30.25.2/30;

} } MYNET

Output

R1 .1

Input

172.27.102.0/24 Figura 12.12 Estudo de caso (parte II).

Filtros de firewall de saída (Output) controlam o tráfego saindo da interface. Filtros de firewall de entrada (Input) controlam o tráfego entrando na interface.

Os contadores de um filtro, definidos pela opção “count”, podem ser “zerados” com o comando “clear firewall filter ”. Opcionalmente, pode-se “zerar” apenas um único contador do filtro com o comando:

clear firewall counter

Monitorando os resultados de um filtro 11 Alguns comandos podem ser utilizados para monitorar a atuação dos filtros aplicados.

q

11 Os comandos de monitoração começam sempre com “show firewall”. Conforme exibido a seguir, é possível verificar os pacotes descartados e registrados com a opção “log”. Para isso, utiliza-se o comando “show firewall log”:

user@R1> show firewall log Log : Filter Action Interface Protocol

Src Addr

Dest Addr

07:23:16 pfe D

ge-0/0/1.0

TCP

172.27.102.10

172.27.102.100

07:23:13 pfe D

ge-0/0/1.0

TCP

172.27.102.10

172.27.102.100

07:23:10 pfe D

ge-0/0/1.0

TCP

172.27.102.10

172.27.102.100

07:19:38 pfe D

ge-0/0/3.0

ICMP

192.168.100.2

192.168.24.1

07:19:38 pfe D

ge-0/0/3.0

ICMP

192.168.100.2

192.168.24.1

07:19:37 pfe D

ge-0/0/3.0

ICMP

192.168.100.2

192.168.24.1

...


Time

237

O comando “show firewall counter”, conforme mostrado a seguir, verifica o valor dos contadores do filtro aplicado (definidos pela opção “count”).

user@R1> show firewall counter filter input-ff inbound-discarded

Filter: input-ff Counters: Name inbound-discarded

Bytes

Packets

1296

23

user@R1> show firewall counter filter output-ff outbound-accepted

Filter: output-ff Counters: Name outbound-accepted

Bytes

Packets

1694502

20256

Repare no exemplo que o nome do filtro pode ser passado como argumento do comando, caso se deseje verificar os contadores de um único filtro.

Verificação de RPF Unicast 11 Reverse-Path-Forwarding (RPF) é um recurso utilizado por operadoras de telecomunicações e administradores de rede para evitar a prática do “IP spoofing”, uma das formas mais comuns de ataque. 22 Como outros tipos de pragas virtuais, o “IP spoofing” é um ataque em que o atacante envia um grande volume de pacotes contra a vítima. 22 Os pacotes desse volume de dados são gerados com um endereço de IP origem falso, para evitar a identificação do atacante. 11 Quando um administrador habilita a verificação de RPF em uma interface, o roteador sempre checará a tabela de rotas antes de dar serviço a um pacote que entrou pela interface. 22 Essa checagem visa garantir que o pacote realmente deveria vir de onde veio. 11 O exemplo a seguir define como funciona o recurso: 22 Um roteador está com a verificação RPF habilitada na interface ge-0/0/1.0.


22 Esse equipamento recebe um pacote com IP origem 10.10.10.10 nessa interface.

238

22 O roteador se fará a seguinte pergunta: 33 “Se eu tivesse que encaminhar um pacote para o 10.10.10.10, por onde eu enviaria?” 22 Para responder a essa pergunta, o roteador analisará a tabela de rotas. 33 Se a resposta for “interface ge-0/0/1.0”, o pacote receberá serviço normalmente. 33 Se a resposta for outra, o pacote será descartado, pois ficará caracterizada uma potencial ocorrência de IP spoofing.

q

Passou RPF Falhou RPF Tabela de rotas

Ba l d e d e b it

Figura 12.13 Verificação RPF.

Uma mesma interface pode ter a verificação RPF configurada juntamente com um filtro de firewall, sem problemas.

Problemas com a verificação RPF Para que a verificação RPF funcione a contento, é fundamental que ela seja habilitada apenas em interfaces que não possuem redundância. Interfaces que possuem redundância admitem assimetria de tráfego, ou seja, é possível que os pacotes saiam por uma interface e entrem por outra, dependendo da conveniência dos protocolos de roteamento em uso. Dessa forma, às vezes a checagem RPF pode descartar um pacote legítimo apenas porque ele não está entrando pela interface pela qual sai. A figura seguinte ilustra o problema.

R2

Internet

R4

R1

172.30.17.0/24

Caminho ativo Caminho factível

O problema pode ser corrigido com o uso da opção “feasible-paths”, conforme mostrado no exemplo de configuração seguinte.

R1 Figura 12.15 RPF com “feasible-paths” habilitado.


Figura 12.14 RPF em interfaces redundantes.

R3

239

O uso dessa opção faz com que o sistema considere todas as rotas recebidas pelo roteador para fazer a verificação, e não só a rota ativa na tabela de rotas. Normalmente, em topologias redundantes, o roteador terá duas ou mais rotas para entregar o pacote, mas só uma estará ativa. 11 Apesar da possibilidade de uso do recurso “feasible-paths”, o uso de verificação RPF

q

é recomendado apenas nas periferias da rede, onde se tem certeza que há um único caminho para se atingir uma rede. 11 Considerando a figura da topologia do exemplo anterior, um bom lugar para a verificação RPF seria a interface de R4, que conecta na LAN 172.30.17.0\24, e a interface de R1, que se liga à internet. 11 Existem outras opções de configuração de RPF que variam de acordo com a plataforma.

Filtros de “fail” 11 Quando um pacote não passa na verificação de RPF, é descartado por default.

q

11 Opcionalmente pode-se definir um filtro de “fail”. 11 Dessa forma, todos os pacotes que forem reprovados no teste de RPF serão submetidos às ações contidas no filtro de “fail”. 11 Essas ações podem inclusive ser um “accept”, para liberar o tráfego, ou um “policer”, para limitar a sua taxa de dados. 11 Esse filtro tem a mesma estrutura e as mesmas possibilidades de um filtro de firewall. A seguir um filtro de “fail” configurado para permitir tráfego reprovado no teste de RPF apenas quando este for proveniente de um servidor DHCP ou Bootstrap (BOOTP).

firewall { family inet { filter rpf-dhcp {

term dhcp {

from { source-address{

0.0.0.0/32; ----- Must permit traffic

with a source address of 0.0.0.0/32 and a destination address of 255.255.255.255/32 for DHCP or BOOTP traffic } destination-address {


255.255.255.25!’V32 } } then accept; } 240

}

} } Repare que esse filtro libera apenas tráfego com IP origem 0.0.0.0\32 e destino 255.255.255.255\32. Esses parâmetros são usados pelos protocolos DHCP e BOOTP. A seguir está ilustrado um exemplo de configuração de RPF de um equipamento.

ge-0/0/1 { unit 0 { family inet {

rpf-check; ----- Enables RPF check on interface

filter {

input input-ff; output output-ff

}

address 172.30.25.2/30;

} } } ge-0/0/2 { unit 0 { family inet {

rpf-check fail-filter rpf-dhcp; ----- RPF fail-filter

application (definition shown on previous slide)

address 172.19.2.1/30;

} } }

unit 0 { family inet {

rpf-check fail filter rpf-dhcp;

address 172.27.102.1/24;

} }


ge-0/0/3 {

} 241

O exemplo mostra a verificação de RPF no seu modo mais simples, sendo aplicada na interface ge-0/0/1.0. Nas interfaces ge-0/0/2.0 e ge-0/0/3.0, a verificação foi habilitada em conjunto com um filtro


de fail nomeado “rpf-dhcp”.

242

Roteiro de Atividades 9 Atividade 9.1 – Configurando filtro de firewall Alunos dos PCs do roteador A devem fazer um “firewall filter” que permita que IPs que estão nos PCs do roteador B possam fazer SSH para a interface ge-0/0/1, mas não possam fazer telnet ou ping. Qualquer outro IP que tente acessar a interface ge-0/0/1, usando qualquer protocolo, deve conseguir. Depois de criado, esse filtro deve ser aplicado na interface ge-0/0/1. Idem para os PCs dos roteadores C e D e para as demais bancadas. 1. Criando firewall filter: set firewall family inet filter bloqueios term block_icmp from address 10.0.30.0/24 set firewall family inet filter bloqueios term block_icmp from address 10.0.40.0/24 set firewall family inet filter bloqueios term block_icmp from protocol icmp set firewall family inet filter bloqueios term block_icmp then reject set firewall family inet filter bloqueios term block_telnet from address 10.0.30.0/24 set firewall family inet filter bloqueios term block_telnet from address 10.0.40.0/24 set firewall family inet filter bloqueios term block_telnet from port telnet set firewall family inet filter bloqueios term block_telnet then reject set firewall family inet filter bloqueios term permitindo then accept 2. Aplicando filtro na interface ge-0/0/1:

set interfaces ge-0/0/1 unit 0 family inet filter input bloqueios Para verificar se o filtro está corretamente configurado, após o comando “commit”, o arquivo de configuração deverá ser semelhante ao mostrado a seguir.

root@ROTA# show firewall family inet { filter bloqueios { term block_icmp { from {

10.0.30.0/24; 10.0.40.0/24; } protocol icmp; } then { reject;


address {

243

} } term block_telnet { from { address { 10.0.40.0/24; 10.0.30.0/24; } port telnet; } then { reject; } } term permitindo { then accept; } } }

[edit]

Atividade 9.2 – Configurando polices de firewall Você deverá elaborar um “firewall filter” que permita aos PCs do outro roteador da sua bancada fazer “ping” para IPs da sua LAN, mas permitindo que esse tráfego fique apenas com uso médio que não ultrapasse 20 Kbps e picos de 60 Kbps que durem no máximo 100msec. 1. Calculando burst-size: (60000 bits) x (0,1 seg) = 6000 bits = 750 bytes 2. Criando policer:


top

244

set firewall policer Limit_Traffic if-exceeding bandwidth-limit 20k set firewall policer Limit_Traffic if-exceeding burst-size-limit 750 set firewall policer Limit_Traffic then discard

3. Criando firewall filter:

set firewall family inet filter ICMP_Limit term Limite_de_Trafego from source-address 10.0.30.0/24 set firewall family inet filter ICMP_Limit term Limite_de_Trafego from source-address 10.0.40.0/24 set firewall family inet filter ICMP_Limit term Limite_de_Trafego from protocol icmp set firewall family inet filter ICMP_Limit term Limite_de_Trafego then policer

Limit_Traffic


set firewall family inet filter ICMP_Limit term else then accept

245

246


13 Descrever os procedimentos de resolução de problemas em interfaces seriais e Ethernet, e apresentar as principais interfaces WAN usadas pelas operadoras de telecomunicações.

conceitos

Troubleshooting genérico de interfaces, troubleshooting específico de interfaces serial e Ethernet, interfaces E1, E3 e Sonet/SDH.

Desativando e desabilitando interfaces Em se tratando de interfaces, o Junos permite duas operações que tiram a interface de

q

ação, mas com abordagens diferentes: a desativação e a desabilitação de interface. Como já apresentado, é possível desativar um comando da configuração de modo que ele seja desconsiderado no momento em que é executado um “commit”. A tag “inactive:” identifica um comando presente no arquivo de configuração, mas que está desativado. 11 Para desativar um comando ou identificador utiliza-se o comando “deactivate” no

q

modo de configuração. 11 Para reativar um comando ou identificador utiliza-se o comando “activate” no modo de configuração. Como qualquer outra linha do arquivo de configuração, uma interface também pode ser desativada. Abaixo está ilustrado um exemplo de desativação de interface:

[edit] user@host# run show interfaces so-2/0/0 terse Interface Admin Link so-2/0/0 so-2/0/0.0

Proto

up up

up

Local

up inet

[edit] user@host# deactivate interfaces so-2/0/0 [edit]

10.2.1.21/30

Remote

Capítulo 13 - Troubleshooting em interfaces

objetivos

Troubleshooting em interfaces

247

user@host# show interfaces ... inactive: so-2/0/0 { ... [edit] user@host# run show interfaces se-2/0/0 terse Intertace


Remote

so-2/0/0 up up 11 O exemplo anterior mostra que uma interface desativada tem todas as suas unidades (interfaces lógicas) excluídas da lista de interfaces presentes. 11 É como se elas não mais existissem; o Junos ignora todos os comandos do arquivo de configuração que estejam com a tag “Inactive”. 11 Para reativar a interface, bastaria executar o comando “activate interfaces so-2/0/0”. 11 Opcionalmente uma interface pode ser desabilitada com o comando “disable”, que deve ser colocado na hierarquia “[edit interfaces ]”. 11 Quando se utiliza o comando “disable” na linha do arquivo de configuração que define uma interface, o Junos mantém a interface ativa ao executar o “commit”, mas o software a trata como estando no estado “down” ou “administrativamente desabilitada”. O exemplo a seguir exibe a situação:

[edit] user@host# run show interfaces so-2/0/0 terse Interface Admin Link Proto Local Remote so-2/0/0

up

up

so-2/0/0.0 up up inet 10.2.1.21/30

[edit] ps@cartman-re0# set interfaces so-2/0/0 disable [edit] user@host# show interfaces so-2/0/0 disable;


unit 0 {

248

family inet { address 10.2.1.21/30; } }

q

[edit] user@host# run show interfaces so-2/0/0 terse Interface Admin Link Proto Local Remote so-2/0/0

down up

so-2/0/0.0 up down inet 10.2.1.21/30

Exemplos de configuração de interfaces A seguir três exemplos típicos de configuração de interfaces: uma interface ATM, uma Gigabit Ethernet e uma Sonet/Frame Relay.

ATM interface with multiple units [edit interfaces] user@host# show at-0/2/1 description “SY to HK and DE”; atm-options { vpi

0 {

maximum-vcs 200; } } unit 0 { description “to HK”; vci 100; family inet {

address 10.0.15.1/24;

}

unit 101 { description “to DE”; vci 101;

family inet {

address 172.16.0.1/24; } }


}

Gigabit Ethernet with inet and mpls support 249

[edit interfaces] user@host# show ge-0/0/2 unit 0 { family inet { address 10.0.13.1/24; } family mpls; }

SONET interface running Frame Relay with keepalives (LMI) disabled [edit interfaces] user@host# show so-0/1/3 no-keepalives; Cada exemplo acima faz uso de pelo menos uma interface lógica (unit), na qual é configurada uma família de protocolo L3 (family), que define o tipo de pacotes L3 que poderão trafegar por ali. Outras propriedades lógicas das interfaces são configuradas na hierarquia “unit” das interfaces. Para verificar os comandos “set” que foram usados para configurar uma interface, pode-se usar o artifício do “| display set”. A seguir está ilustrada a utilidade deste recurso:

[edit interfaces] user@host# show at-0/2/1 | display set set interfaces at-0/2/1 description “SY to HK and DE” set interfaces at-0/2/1 atm-options vpi 0 maximum-vcs 200 set interfaces at-0/2/1 unit 0 description “to HK” set interfaces at-0/2/1 unit 0 vci 100 set interfaces at-0/2/1 unit 0 family inet address 10.0.15.1/24 set interfaces at-0/2/1 unit 101 description “to DE” set interfaces at-0/2/1 unit 101 vci 101


set interfaces at-0/2/1 unit 101 family inet address 172.16.0.1/24

Troubleshooting genérico de interfaces Veremos alguns comandos úteis para tarefas preliminares de troubleshooting de interfaces, que tipicamente serão comandos “show”. 11 O primeiro recurso a se conhecer desta família de comandos é o “show interfaces terse”. 11 Esse comando exibe a lista de todas as interfaces instaladas no dispositivo e seus respectivos estados administrativos e operacionais.

250

q

user@host> show interfaces so* terse Interface


Remote

so-1/1/0

down

up

----- Administratively disabled

so-1/1/0.0

up

down inet 1.1.1.1/30 iso

so-1/1/1

up

down

----- Data link Layer down

so-1/1/1.0

up

down inet 2.2.2.2/30 iso

so-1/1/2

up

up

so-1/1/2.0

up

up

----- Data link layer up inet 3.3.3.3/30

... 11 O “wildcard” asterisco (*) é um recurso que pode ser usado para filtrar a saída

q

do comando. 11 No exemplo, o usuário solicitou apenas as interfaces com nome começando com a string “so”. 11 O código exibe ainda o significado de algumas combinações de estado de interfaces que não estão operando. 11 Uma interface física que foi desabilitada aparece com os estados administrativo e operacional respectivamente “down” e “up”, e suas respectivas interfaces lógicas como “admin up” e “link status down”. 11 A interface física fica com “link status up” porque o enlace físico está saudável (não tem alarmes). 11 As interfaces lógicas mantêm “link status down”, porque a interface L2 não consegue estabelecer comunicação com o equipamento na outra ponta. 11 Quando uma interface não foi desabilitada e o encapsulamento L2 entre o dispositivo local e o dispositivo remoto não está funcionando, a interface física fica em “admin up” e “link status up” e a sua interface lógica fica em “admin up” e “link status down”.

funcionando. 11 A interface lógica fica com “link status down” porque a comunicação de camada 2 está quebrada. 11 Em uma situação de funcionamento normal da interface, tanto a interface física quanto a lógica ficam em “admin up” e “link state up”. 11 O próximo comando para auxiliar a tarefa de troubleshooting é o “show interfaces ”. 11 Esse comando exibe informações genéricas sobre uma interface especificada ou sobre todas as interfaces. A seguir um exemplo do comando. A interface ilustrada é uma Sonet OC-3.


11 Novamente, a interface física mantém “link status up”, porque o enlace físico está

lab@host> show interfaces so-0/1/2 251

Physical interface: so-0/1/2, Enabled, Physical link is Up Interface index: 134, SNMP ifIndex: 28 ----- Physical de.’ice indexes Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback: None, FCS: 16, Payload scrambler: Enabled Device flags

: Present Running

Interface flags : Point-To-Point SNMP-Traps Internal: 0x4000 ----Device configuration and operational flags Link flags

: Keepalives

Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3 Keepalive: Input 90939 (00:00:07 ago), Output: 90879 (00:00:04 ago) LCP state: Opened NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured, mpls: Not-configured CHAP state: Closed CoS queues: Last flapped


: 2009-02-17 03:13:49 UTC (1w3d 11:12 ago) ----- Trafic

load and alarm status Input rate

: 0 bps (0 pps)

Output rate

: 280 bps (0 pps)

SONET alarms

: None

SONET defects : None Logical interface so-0/1/2.0 (index 67) (SNMP ifIndex 75) ----- Logical device indexes Flags: Point-To-Point SNMP-Traps Ox4000 Encapsulation: PPP Protocol inet, MTU: 4470 Flags: None Addresses, Flags: Is-Preferred Is-Primary ----- Logical device


settings

252

Destination: 10.0.31/24, Local: 10.0.31.2, Broadcast: 10.0.31.255 O exemplo ilustrado destaca as diferentes partes do relatório gerado pelo comando, inclusive uma parte dedicada às interfaces lógicas que porventura estiverem definidas. 11 No Junos, cada interface física e lógica é referenciada por dois índices. 11 Esses índices são associados às interfaces no momento do boot do sistema e dependem da ordem na qual as interfaces são ativadas pelo Junos.

q

11 O índice SNMP ifIndex é usado para identificar a interface junto aos softwares que

q

fazem consultas via SNMP. 11 O outro índice é usado pelo próprio Junos para fazer referência às interfaces quando estão executando tarefas internas. O índice de identificação interna das interfaces físicas é chamado “ifd”, ao passo que o índice que identifica uma interface lógica é o “ifl”. É importante verificar que o ifIndex associado a interfaces lógicas é diferente do associado à interface física. Sempre que possível, o ifIndex é conservado mesmo após vários reboots do sistema ou após eventos de adições ou remoções de novas PICs ou FPCs. Esse comportamento evita que as plataformas de gerência precisem ser reconfiguradas devido a mudanças no valor do índice. Uma vez em operação, as interfaces apresentam algumas flags que proveem informações sobre as condições de sua operação. A lista abaixo exibe algumas das possíveis flags e seus significados: 11 Down: a interface não está operando. 11 Up: interface está habilitada e operacional. 11 Hear-Own-Xmit: a interface está “escutando” suas próprias transmissões (há loop em algum ponto). 11 Link-Layer-Down: a comunicação do protocolo L2 com a outra ponta do link não ocorre. 11 Loopback: interface está na condição de loopback físico. 11 Loop-Detected: a camada L2 está recebendo os frames por ela transmitidos e suspeita de loop. 11 No-Carrier: indica que o sinal de carrier não está presente (em mídias que suportam reconhecimento de carrier). 11 No-Multicast: a interface não suporta tráfego multicast. 11 Present: a interface está presente e reconhecida. 11 Promiscuos: interface está no modo promíscuo e admite frames enviados para outros destinos. 11 Quench: interface enfrenta saturação no seu buffer de saída. 11 Recv-All-Multicasts: não há filtro de multicast na interface. 11 Running: a interface está ativada e habilitada.

11 Disabled: interface foi desabilitada. 11 Hardware-Down: interface não está funcional ou encontra-se incorretamente conectada. 11 Point-To-Point: interface é ponto a ponto. 11 SNMP-Traps: o envio de traps SNMP pela interface está habilitado. 11 Give-Up: após repetidas falhas o protocolo L2 parou de tentar conexão. 11 Keepalives: mensagens de keepalive estão habilitadas no protocolo L2. 11 Loose-LCP: protocolo PPP não está usando o “Link Control Protocol” para indicar a saúde da conexão PPP. 11 Loose-LMI: protocolo Frame Relay não está usando “Local Management Interface” para indicar a saúde da conexão Frame Relay.


11 Admin-Test: interface está no modo de teste.

253

11 Loose-NCP: protocolo PPP não usa o “Network Control Protocol” para indicar se o dispositivo está “up”. 11 No-Keepalives: mensagens de keepalive estão desabilitadas na interface. A saída do comando também sumariza o nível de carga na interface, exibido em bits e pacotes por segundo, bem como qualquer alarme que esteja ativo. A porção final do reporte do comando exibe a configuração e o estado de cada interface lógica definida.

Verificando erros na interface O comando “show interfaces extensive” mostra todo o relatório

q

dos comandos “show interfaces” anteriores e mais um grande conjunto de informações, dentre elas a informação de diferentes contadores de erros na interface. A seguir está ilustrada parte da saída do comando:

user@host> show interfaces so-0/l/l extensive Physical interface: so-0/1/1, Enabled, Physical link is Up Interface index: 133, SNMP ifIndex: 25, Generation: 16 ... Statistics last cleared: Never ----- When counters were last cleared ... Input errors ----- Input errors Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Bucket drops: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, HS link CRC errors: 0, HS link FIFO overflows: 0 Output errors: Carrier transitions: 1, Errors: 0, Drops: 0, Aged packets: 0, ---- Output errors HS link FIFO underflows: 0, MTU errors: 0 ... SONET alarms

: None


SONET defects : None SONET PHY

Seconds

Media errors

PLL Lock 0 0 OK SEF 143 157 OK Note: Policed discards count the receipt of unrecognized protocol types (for example, CDP or STP)

254

Count State

11 Os contadores exibidos no comando podem ser zerados a qualquer momento com o

q

comando “clear interfaces statistics ”. 11 Se nenhum nome de interface é especificado, todas as interfaces terão seus contadores zerados. A lista a seguir exibe e explica alguns dos contadores de erro das interfaces no Junos: 11 Errors: exibe o número de frames entrantes na interface que chegaram com erro de FCS. 11 Policed Discards: exibe o número de frames entrantes que foram descartados porque o código do protocolo L3 não foi reconhecido ou não é de interesse. Um exemplo clássico de descarte nesta situação são os pacotes do protocolo Cisco CDP, que não são válidos no equipamento Juniper. 11 L3 Incompletes: exibe o número de pacotes entrantes cujo cabeçalho L3 não foi aprovado no teste de verificação executado pelo Junos. Um causador desse problema pode ser, por exemplo, um pacote que chega com menos de 20 bytes no seu cabeçalho IP. 11 L2 Channel Errors: exibe o número de frames entrantes considerados errados porque não foi possível encontrar uma interface lógica para tratá-los. Esse contador pode incrementar, por exemplo, quando um frame PPP chega em uma interface física que só tem interfaces lógicas HDLC. 11 L2 Mismatch Timeouts: exibe o número de frames entrantes descartados porque estavam mal formados (por exemplo, muito pequenos) e foram classificados como ilegíveis. 11 SRAM Errors: esse contador é incrementado quando um erro de hardware ocorre na memória RAM da PIC. Esse valor deve sempre ser zero. Se ele incrementa a PIC não está funcionando adequadamente. 11 Carrier Transitions: exibe o número de vezes que a interface saiu do estado “down” para “up”. Esse número não deve ser incrementado rapidamente, apenas quando o cabo da interface é desconectado ou quando o sistema remoto é desligado. Se esse contador incrementa rapidamente (mais de uma vez a cada 30 segundos), fica caracterizada uma falha na linha de transmissão, no sistema remoto ou na PIC local. 11 Drops: exibe o número de pacotes descartados na fila de saída da interface. Esse contador é incrementado normalmente em situações de saturação ou uso de policer. 11 Aged Packets: exibe a quantidade de pacotes que permaneceram muito tempo na SDRAM compartilhada. Esse contador não deveria ser incrementado nunca. Se é incrementado,

Monitorando interface 11 O comando “monitor interface ” é um dos mais úteis no tratamento de problemas. 11 Ele provê o acompanhamento em tempo real de vários contadores da interface, como bytes entrando, bytes saindo, erros de entrada e de saída, aged packets, policed discards, L3 incompletes etc. A seguir está exibida a saída deste comando:

user@router

Seconds: 55

Time: 19:12:00

Interface: ge-0/2/0, Enabled, Link is Down Encapsulation: Ethernet, Speed: 1000 mbps

Delay: 0/0/66

q


fica caracterizado um bug de software ou um mau funcionamento do hardware.

255

Traffic statistics:

Current Delta

Input bytes:

17707053 (0 bps)

[0]

Output bytes:

10369709 (0 bps)

[0]

Input packets:

292046 (0 pps)

[312]

Output packets:

147886 (0 pps)

[0]

Error

statistics:

Input errors:

0

[0]

Input drops:

0

[0]

Input framing errors:

0

[0]

14355

[0]

261

[0]

0

[0]

L2 mismatch timeouts

156

[0]

Carrier transitions:

2

[1]

Output errors:

0

[0]

Output drops

0

[0]

Aged packets:

0

[0]

104547

[0]

Broadcast packets

40494

[0]

Multicast packets

67917

[0]

Policed discards: L3 incompletes: L2 channel errors:

Active alarms

: LINK

Active defects : LINK Input MAC/Filter statistics: Unicact packets

Teste de loop O caminho físico que implementa o enlace de dados de uma organização usuária até o PoP da RNP é normalmente composto de um certo número de segmentos de cabo (spams) interconectados por dispositivos que regeneram e repetem o sinal adiante. Quando uma falha ocorre no enlace é possível localizar a fonte do problema através de testes em cada


segmento e testes fim a fim. 11 O teste de loop é o processo através do qual o fornecedor de um enlace de dados identifica o trecho do enlace que protagoniza uma falha. 11 O teste de loop consiste em conectar a interface de transmissão na interface de recepção em qualquer um dos dispositivos que interliga os diferentes segmentos do enlace. 11 Quando um loop é executado no caminho, o roteador Juniper detectará a situação, pois perceberá que os seus pacotes de keepalive transmitidos estão sendo recebidos na sua própria recepção. 256

q

Loop detected! TX

RX

Telco sets loopback

RX

Normalmente, um teste de loop é executado recursivamente em cada um dos dispositivos que compõem o circuito de dados. Se um loop é configurado em um determinado segmento do enlace e o roteador na ponta do circuito não verifica a presença de sinal na recepção, fica caracterizado o isolamento do problema entre o roteador da ponta do enlace e o ponto onde foi executado o loop. 11 Normalmente a operadora de telecomunicações que provê o enlace pode testar

q

todos os segmentos do circuito que são internos à sua rede, antes de visitar as dependências do cliente. 11 Se os testes de loop apontam que o problema é no último segmento (que liga o cliente ao primeiro ponto da rede da operadora) o cliente passa a ser envolvido, e uma visita às suas dependências pode ser necessária. 11 Os testes de loop também podem ser utilizados para localizar segmentos do enlace que protagonizam a aparição de taxas de erro de CRC na recepção do roteador.

Tipos de teste de loop 11 A maioria das PICs aceitas pelo Junos suportam testes de loop local interno, onde o

q

sistema internamente copia o tráfego de transmissão na recepção. 11 Quando possível, é sempre melhor executar o teste de loop local externo, utilizando um plug externo. 11 A interface de transmissão é conectada externamente na interface de recepção através desse plug. 22 Esse esquema permite testar os circuitos físicos de transmissão e a recepção da PIC. 11 O plug externo poderá executar a atenuação necessária para evitar a queima do receptor. Interfaces ponto a ponto (tecnologias de não broadcast como Sonet, SDH e E1) também suportam testes de loop remoto. A figura a seguir ilustra a diferença dos loops local e remoto.


Figura 13.1 Teste de loop.

TX

257

O circuito pode entrar em loop em qualquer lugar do caminho Loopback local

Porta está OK (internamente)

Loopback remoto

A configuração do loop remoto na interface do equipamento faz com que o equipamento remoto receba tudo que é enviado ao roteador. Nenhuma sinalização é gerada para o equipamento remoto para dizer que o loop está ocorrendo. Por isso, normalmente esse tipo de teste é executado em conjunto com técnicos da operadora de telecomunicações, que deseja testar o circuito. Para o teste de loop local, o parâmetro “clocking” da PIC de transmissão deve ser configurado para “internal”, que é a opção default.

Configurando testes de loop Quase todo teste de loop requer configuração para a maioria dos tipos de PIC. Essa configuração apenas não será necessária no teste de loop local externo (com um plug externo) e no teste onde a operadora executa o loop na rede dela. A seguir um exemplo de configuração de um loop local interno. O comando “show interfaces” confirma que a interface opera em condição de loop local.

[edit interfaces so-0/1/1] user@Tokyo# show no-keepalives; encapsulation frame-relay; sonet options { loopback local; } unit 100 {


dlci 100;

258

family inet { address 10.0.22.1/24; } }

Porta e circuito estão OK

Figura 13.2 Loop Local e Remoto.

[edit interfaces so-0/1/1] user@Tokyo# run show interfaces so-0/1/1 | match loop Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal , SONET mode, Speed: OC3, Loopback: Local, 11 Quando o loop é realizado na interface de algum equipamento da operadora, não

q

há nenhuma indicação, no roteador, de que um loop está ocorrendo, salvo quando o protocolo de camada 2 em uso possui recurso de detecção de loop, como por exemplo o PPP. 11 A interface usada no exemplo anterior utiliza Frame Relay com recurso de keepalives (LMI) desligado. 11 Dessa forma, um loop na infraestrutura da operadora não será detectado automaticamente.

Protocolos L2 e testes de loop Muitos protocolos de camada 2 fazem uso de mecanismo de keepalive que, dentre outras tarefas, pode detectar a presença de um teste de loop. Independente de loop local ou remoto, a detecção de um loop resulta na declaração de “interface down” na camada 2. Quando isso ocorre, as rotas referentes à interface em questão são removidas da tabela de rotas, inclusive a rota diretamente conectada referente ao endereço IP da interface. Esse comportamento previne testes de “ping” via essa interface (o teste de “ping” em interfaces com loop será tratado a seguir). Na maioria das vezes, o comportamento acima descrito pode ser evitado através da configuração do comando “no-keepalives”, mas, como mostrado a seguir, essa opção pode ser usada apenas em interfaces com protocolo de enlace: Frame Relay, ATM e HDLC. O protocolo PPP, mesmo com a opção de keepalive desabilitada, consegue detectar um loop automaticamente devido a algumas negociações que ocorrem no nível 3. A única forma de evitar que a interface fique “down” em links com PPP é mudar a configuração de encapsulamento L2 durante o teste de loop. A tecnologia de Ethernet não possui conceito de keepalive e não suporta o conceito

[edit interfaces so-0/1/1] user@London# run show interfaces so-0/1/1 Physical link is Up ... Link-leve1 type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, Loopback None, FCS: 16, Payload scrambler: Enabled


de loop remoto. Esse conceito é válido apenas em mídias não broadcast.

259

Device flags: Present Running Loop-Detected ... Logical interface so-0/1/1.0 (Index 70) (SNMP if Index 26) ... Protocol inet, MTU: 4470 Flags: Protocol-Down [edit interfaces so-0/1/1] user@London# show no keepalives; unit 0 { family inet { address 10.0.22.2/24; } }

Ping e testes de loop 11 Em equipamentos de outros fabricantes, uma vez configurado o loop remoto, a

q

execução de um “ping” no IP da interface local fará com que todo o circuito “loopado” seja testado. 11 O “ping” sairá da interface de transmissão em direção à rede da operadora e será devolvido pelo loop da operadora até a interface de recepção local. 10.0.10.1

Figura 13.3 Comportamento de loop em equipamentos de outros fabricantes.

Loopback

11 Plataformas Junos não têm esse comportamento.

q

11 Um “ping” enviado ao IP do equipamento local não deixa a interface, e assim não pode ser usado para testar o estado operacional da linha.


10.0.10.1

Loopback

O exemplo seguinte mostra como a linha com loop pode ser testada no Junos.lab@router> ping 10.0.10.2

PING 10.0.10.2 (10.0.10.2): 56 data bytes 36 bytes from 10.0.10.1: Time to live exceeded

260

Figura 13.4 Comportamento de loop em equipamentos Juniper.

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 211b 0 0000 01 01 708c 10.0.10.1 10.0.10.2

JUNOS Device 10.0.10.1

Figura 13.5 Teste de linha com “ping” no Junos.

Loopback

Ping to remote IP 10.0.10.2 11 Ao utilizar o equipamento Juniper com um loop externo na linha (loop local externo, loop

q

remoto em equipamento da operadora ou um loop remoto da interface local) deve-se fazer um “ping” para um IP remoto que normalmente é atendido pela interface local. 11 No exemplo, esse endereço é o 10.0.10.2. 11 Se a linha estiver saudável, o pacote de “ping” retornará à interface local e novamente será enviado à rede da operadora, mas sofrerá um decremento no campo TTL (Time To Live). 11 Esse processo se repetirá continuamente até que o campo TTL atinja o valor zero. Se a linha estiver saudável, um erro de “Time To Live exceeded” será gerado. 11 Se a linha tiver uma indisponibilidade física no trecho testado, os “pings” serão perdidos. Se o trecho testado sofrer com taxas de erro, uma parte dos pacotes de “ping” gerará o erro de “TTL Exceeded”; a outra parte não retornará o erro. No caso de linha com taxas de erro, o tamanho dos pacotes de “ping” e o uso da opção “rapid” no comando de “ping” podem afetar o resultado. Pacotes maiores e enviados em intervalos pequenos têm menor probabilidade de completar o percurso em caso de linha com erro. Outro fator que pode ser variado durante os testes é o TTL. No “ping” do Juniper, o valor de TTL default é 255. Dessa forma, um erro de TTL expirado indica que houve 255 transmissões e recepções executadas com sucesso. Configurar o valor de TTL para um valor menor pode


ser útil ao tentar caracterizar a qualidade da linha.

261

Troubleshooting específico de interfaces serial e ethernet Interfaces de LAN e convenção de nomes Plataformas Junos suportam vários tipos de tecnologia ethernet. As mídias ethernet

q

suportadas e as respectivas convenções de nomes utilizadas são: 11 Fast Ethernet: fe-F/P/P. 11 Gigabit Ethernet: ge-F/P/P. 11 10-Gigabit Ethernet: xe-F/P/P. 11 Management Ethernet: fxp0 (10, 100 ou 1000 Mbps). As interfaces Fast Ethernet podem operar nos modos half duplex ou full duplex. As interfaces Gigabit funcionam apenas no modo full-duplex. Abaixo estão os comandos mais comuns utilizados no ataque a problemas com inter-

q

faces de tecnologia ethernet, comandos de troubleshooting para interfaces ethernet (exceto “loopback”). Cada um destes comandos é detalhado a seguir: 11 ping 11 loopback (local) 11 show interfaces extensive 11 show interfaces media 11 show arp 11 monitor traffic 11 monitor interface 11 clear statistics 11 request ... 11 restart ...

Comando “ping” Usado largamente para verificar a conectividade de elementos na LAN. A recepção de um “echo reply” de um elemento da LAN valida o bom funcionamento das camadas 1, 2 e 3 dos segmentos de rede que ligam o roteador ao host em questão.

Comando “show arp” O “show arp no-resolve” exibe as entradas da tabela ARP do roteador. O uso da opção “no-resolve” garante que o roteador não tentará traduzir os IPs da tabela em nomes. O conteúdo da tabela ARP permite verificar alguns problemas de LAN como, por exemplo, dois hosts usando um mesmo endereço MAC.


Comandos de monitoração de interface Alguns comandos de “show” já mostrados também ajudam na investigação de problemas de interfaces ethernet. Alguns deles são listados abaixo: 11 show interfaces extensive: verifica o estado geral da interface, de seus contadores de performance e de suas flags. Um problema típico que pode ocorrer em interfaces Ethernet são erros na interface de entrada devido a cabo com tamanho além do máximo permitido pelo padrão ou equipamento remoto com configuração de duplex em 262

“autoconfiguration”. Em ambos os casos, os contadores de erro sofrerão incrementos, e este comando permitirá o diagnóstico. 11 monitor interface: exibe estatísticas em tempo real de uma interface física. A saída se atualiza a cada um segundo. Dentre outras coisas, esse comando acompanha a evolução de vários contadores de erro, como frames mal formados, ou com erro de CRC. 11 monitor traffic: versão resumida do “monitor interface”.

Interfaces E3 Verificando o funcionamento físico da porta Para verificar o bom funcionamento da porta E3, pode-se fazer um loop físico entre as portas de transmissão e recepção. Ao fazer essa operação, deve-se tomar o cuidado de usar um atenuador para evitar uma alta potência na porta de recepção do roteador. Uma vez que a porta de transmissão está conectada na porta de recepção (loop), o usuário deve verificar a presença da flag “Loop-Detected” na interface em questão. Essa flag deverá ser vista na saída dos diferentes comandos “show interfaces”. Além disso, a saída do “monitor interface” deverá mostrar o contador de “input packet count” igual ao contador “output packet count”. Se esses comportamentos esperados ocorrerem, pode-se afirmar que a transmissão e a recepção da interface estão ocorrendo a contento. Ainda, se o protocolo de nível 2 HDLC estiver em uso na interface, o contador de “input keepalive packet” deverá ser igual ao contador de “output keepalive packet”. Se algum dos itens destacados nos dois parágrafos acima não ocorre, a PIC pode estar com problemas. Para isolar o problema, é preciso trocar as configurações e o cabeamento para outra porta E3 e executar novo teste. Para mover a configuração de uma porta para outra de maneira rápida, o comando “rename” pode ser usado conforme o exemplo abaixo:

[edit interfaces] user@host# rename t3-1/0/0 to t3-1/0/1

Checando compatibilidade com equipamento remoto Um enlace E3 possui certos parâmetros que precisam estar configurados nos dois equipamentos que terminam o enlace. Se a configuração é alterada em uma das duas pontas, o link

11 Frame Checksum: o enlace E3 usa um campo de 16 bits para a tarefa de cheksum. É possível configurar esse campo para utilizar 32 bits, o que torna a verificação mais confiável. Porém, alguns equipamentos antigos suportam apenas o campo de 16 bits. Um descasamento dessa configuração implicará um problema na conectividade física. 11 HDLC Scrambling: ao usar encapsulamento HDLC é possível usar a opção de embaralhamento (scrambling). Essa opção fica desabilitada por default. Se ativada, a funcionalidade provê mais estabilidade para o enlace. Porém, se a configuração dessa opção (ativada ou desativada) não está igual em ambos os equipamentos, o enlace não funcionará. 11 Line buildout: para fazer com que o sinal chegue a um destino que esteja a mais de 70 metros do roteador, utiliza-se a opção “long-buildout” na hierarquia “[edit interfaces t3-options”.


pode deixar de funcionar. A lista abaixo exibe alguns desses casos:

263

Verificando alarmes ativos em interfaces E3/T3 A seguir vemos a saída do comando “show interfaces” para uma interface T3. A saída do comando para uma interface E3 é similar.

user@router> show interfaces t3-1/0/0 Physical interface: t3-1/0/0, Enabled, Physical link is Down Interface index: 9, SNMP ifIndex: 10 Link-level type: Cisco-HDLC, MTU: 4474, Clocking: Internal Speed: T3, Loopback: None, CRC: 16, Mode: C/Bit parity Device flags

: Presente Running Down

Interface flags: Hardware-Down Link-Layer-Down Point-To-Point SNMP-Traps Link flags

: Keepalive5

Keepalive Input: 116 (00:02:32 ago), Input rate

: 0 bps

Active alarms

: LOF, LOS

Output: 185 (00:00:02 ago)

(0 pps), Output rate: 0 bps (0 pps)

Active defects : LOF, LOS Logical interface t3-1/0/0.0 (Index 12) (SNMP ifIndex 32) Flags: Device-down Point-To-Point SNMP-Traps, Encapsulation: Cisco-HDLC Protocol inet, MTU: 4470 Addresses, Flags: Dest-route-down Is-Preferred Is-Primary Destination: 2.2.2.0/30, Local: 2.2.2.2 A parte superior da saída exibe o estado da conectividade física da interface. A parte em destaque no meio exibe configuração de camada 2, a qual deve casar com as configurações na outra ponta do enlace. Finalmente, a parte inferior mostra alarmes ativos e os defeitos ativos na camada física. Em uma interface saudável, não se esperam alarmes ativos. A lista abaixo mostra alguns dos alarmes mais populares e seus significados. Quase todos implicarão em acionamento do provedor do enlace de dados. 11 AIS (Alarm Indication Signal): mostra um problema com o equipamento conectado à


interface E3. O proprietário desse equipamento (tipicamente uma operadora de telecomunicações) deverá ser envolvido. 11 LoF (Loss of Frame): indica perdas de bit(s) dos frames recebidos. Pode estar ocorrendo um problema de sincronismo na linha ou incompatibilidade na configuração da formatação de frames. 11 LoS (Loss of Signal): indica que o sinal está fraco ou não pode ser identificado na interface E3. Pode-se verificar os cabos para checar sua integridade. Tipicamente esse problema implicará em acionamento da operadora de telecomunicações que provê o enlace. 264

11 IDLE: esse alarme indica que a linha ainda não foi provisionada para o serviço. 11 Yellow: indica que o equipamento detectou um problema com o sinal que está sendo recebido do equipamento remoto. Além dos alarmes, alguns eventos de erro físico podem ser registrados: 11 BPV (Bipolar Violation): ocorrência de erro físico, como um pulso com a mesma polaridade do pulso anterior (com codificação B3ZS – bipolar 3 zero substitution). 11 EXZ (excessive zeros): indica a ocorrência de uma sequência muito grande de zeros. 11 LCV (Line Code Violation): contador que registra a ocorrência dos erros BPV e EXZ de forma cumulativa. 11 PCV (p-bit code violation): o bit de verificação “P” no frame DS-3 não casa com o código calculado localmente. 11 CCV (c-bit code violation): conta as violações de código reportadas através do bit de verificação “C” do frame DS-3.

Verificando performance da camada 3 – Comando “ping” O comando “ping” pode ser usado para testar a disponibilidade e a performance de um circuito de dados E3. O comando permite que se altere o padrão dos bits transmitidos para verificar a reação do circuito a diferentes tipos de dados. A opção “size” é o primeiro recurso disponível no comando “ping”, que pode ser usado em casos de problemas de performance. Essa opção altera o tamanho dos pacotes do “ping” e permite ao usuário conhecer a reação da rede a pacotes grandes e pequenos. Em alguns casos é possível verificar, por exemplo, que pacotes grandes estão sofrendo taxas de descarte elevadas, ao passo que pacotes pequenos estão recebendo serviço normalmente. A opção “pattern” permite a geração de pacotes de “ping” com um padrão de bits particularmente especificado. Em alguns casos é possível verificar que o circuito apresenta performance normal para pacotes com muitos bits “1” e baixa performance para pacotes com muitos bits “0”. A seguir vemos a execução do comando “ping” fazendo uso das opções “size” e “pattern”. Esse procedimento é útil para verificar a performance de circuitos E3 ou E1.

• All 1s pattern is maximum density on T1/DS1 ping 10.0.2.1 pattern ffff count 10000 rapid size 1500 • All zeros pattern is minimum density on Ti/DS1 interface

• Repeat with Ox5555, Ox8080, and Ox1111

Interfaces E1 11 A investigação de problemas em interfaces E1 é bastante similar ao procedimento utilizado para interfaces E3. 11 Os recursos de loop e ping podem ser usados para avaliar o bom funcionamento da PIC física e da rede do provedor do enlace de dados.

q


ping 10.0.2.1 pattern 0000 count 10000 rapid size 1500

265

11 Além disso, em problemas de indisponibilidade de link, deve-se verificar se as configu-

q

rações físicas das interfaces E1 nos equipamentos das duas pontas do enlace utilizam os mesmos parâmetros. Serão apresentadas as similaridades e diferenças da investigação nesses dois tipos de interfaces. Antes de apresentar os itens de verificação usados para investigação das interfaces E1, apresentaremos algumas particularidades da sua configuração. O feixe de dados E1 é um padrão da hierarquia digital PDH, que opera na taxa de 2048 Mbps. O feixe implementa um dos esquemas mais básicos de multiplexação por divisão de tempo dentre os utilizados em telecomunicações. 11 O feixe é composto por 32 canais de 64 Kbps cada, divididos no tempo (32 x 64 = 2048).

q

11 Na interface Juniper as características físicas específicas da interface E1 são configuradas sob a hierarquia de configuração “[edit interfaces e1-options]”. 11 Por default, as interfaces E1 no Junos utilizam o modo de “framed” definido pelo padrão G.704. 11 Opcionalmente pode-se utilizar o modo “unframed”. 22 Quando utilizado o modo “unframed”, os 32 canais do feixe E1 são usados para transferência de dados. 11 No modo “framed” dois canais são utilizados para sinalização e reporte de alarmes e os outros 30 canais são utilizados para dados. 11 Ou seja, apenas 1984 Kbps são efetivamente usados para a transmissão de dados úteis. O Junos se refere ao primeiro canal do feixe como slot 1. Outros fabricantes se referem a esse recurso como slot 0.

Alarmes e mídia E1 11 Alarmes e defeitos podem causar a inutilização da interface e justificar problemas de performance. 11 Dependendo da idade do defeito, ele pode ser promovido a alarme. 11 Um alarme E1 pode receber a classificação vermelha (red) ou amarela (yellow), dependendo da sua gravidade. 11 A seguir vemos a saída do comando “show interfaces media ”, que mostra as características de camada 1 e 2 da interface, além de contadores de erro, alarmes e defeitos ativos.

user@host> show interfaces media e1-1/1/0 Physical interface : e1-1/1/0, Enabled, Physical link is Up


Interface index: 30, SNMP ifIndex: 130

266

Llnk level type: PPP, MTU: 4474, Clocking: Internal Speed: E1, Loopback: None, CRC: 16, Framing: G704 Device flags: Present Running Interface flags: Point-To-Point SNMP-Traps

q

Link flags

: Keepalives

Input rate : 0 bps (0 pps), Output rate: 0 bps (0 pps) Active alarms

: None

Active defects

: None

E1 errors: BPV: 2, EXZ: 1, LCV: 2, PCV: 7, CS: 0, FEBE: 561 11 A lista seguinte destaca alguns alarmes populares das interfaces E1, que existem

q

também nas interfaces E3: 22 LOS: Loss of Signal. 22 LOF: Loss of Frame. 22 AIS: Alarm Indication Signal. 22 YLW: Yellow. 11 Abaixo seguem os contadores de erros típicos que podem ocorrer na camada física. Alguns deles são definidos também para as interfaces E3 (não serão novamente definidos). 22 BPV: Bipolar Violation. 22 EXZ: Excessive Zeros. 22 LCS: Line Code Violation. 22 PCV: P-bit Code Violation. 22 CS (Controlled Slip Error): reporta a replicação ou perda de parte do payload do frame E1. 33 Esse erro pode ocorrer, por exemplo, quando há falta de sincronismo entre o relógio dos equipamentos transmissor e receptor. 22 OOF (Out of Frame Defect): conta a ocorrência de uma densidade particular de erros de frame. 33 Ocorre nas interfaces E1 da Juniper quando o equipamento detecta três frames consecutivos com erro.

Verificando performance da Camada 3 – Comando “ping” Assim como ocorre com as interfaces E3, o comando “ping” pode ser usado para testar a disponibilidade e a performance de um circuito de dados E1. O comando permite alterar o

A opção “size” é o primeiro recurso disponível no comando “ping”, que pode ser usada em casos de problemas de performance. Essa opção altera o tamanho dos pacotes do “ping” e permite ao usuário conhecer a reação da rede a pacotes grandes e pequenos. Em alguns casos é possível verificar, por exemplo, que pacotes grandes estão sofrendo taxas de descarte elevadas, ao passo que pacotes pequenos estão recebendo serviço normalmente. A opção “pattern” permite a geração de pacotes de “ping” com um padrão de bits particularmente especificado. Em alguns casos é possível verificar que o circuito apresenta performance normal para pacotes com muitos bits “1” e baixa performance para pacotes com muitos bits “0”.


padrão dos bits transmitidos para verificar a reação do circuito a diferentes tipos de dados.

267

A seguir a execução do comando “ping” fazendo uso das opções “size” e “pattern” (mesmo exemplo utilizado na avaliação da interface E3).

All 1s pattern is maximum density on T1/DS1 ping 10.0.2.1 pattern ffff count 10000 rapid size 1500 All zeros pattern is minimum density on Ti/DS1 interface ping 10.0.2.1 pattern 0000 count 10000 rapid size 1500 Repeat with Ox5555, Ox8080, and Ox1111

Interfaces Sonet/SDH A hierarquia de transmissão digital Sonet/SDH incorpora uma grande variedade de funcionalidades de manutenção e operação, que facilitam a investigação de problemas nesse tipo de linha. A interpretação dos erros Sonet/SDH é útil para determinar a fonte de problemas na rede SDH. Além disso, os valores contidos nos vários contadores são informativos quando corretamente interpretados, e ajudam na localização do problema. Esse tópico cobre os comandos disponíveis para as interfaces Sonet/SDH. A conexão SDH caracteriza a configuração de “framing sdh” sob a hierarquia “[edit chassis]”.

chassis { fpc 0 { pic 0 { framing sdh; } } } As interfaces Sonet/SDH dos roteadores Juniper funcionam como PTEs (Path Terminating Equipment), e possuem visibilidade fim a fim do enlace de dados. Ao perceber problemas, o equipamento reporta alarmes e erros, que podem ser verificados com comandos adequados. Os alarmes e erros indicam a natureza dos problemas.

Monitorando interfaces Sonet/SDH O comando “monitor interface” também pode ser usado para a investigação das condições das interfaces Sonet/SDH.

user@host> monitor interface so-l/l/l


enterprise

268

Seconds: 168

Time: 15:48:50 Interface: so-1/1/1, Enabled, Link is Down Encapsulation: Cisco-HDLC, Keepalives, Speed: OC3 Traffic statistics: Input bytes:

Current Delta 375527568 (0 bps)

Output bytes:

6612857 (0 bps)

Input packets:

224001 (0 pps

Output packets:

102090 (0 pps)

[0] [475] [0]

Encapsulation statistics: Input keepalives:

0

[0]

176

[17]

Input errors:

0

[0]

Input drops:

0

[0]

179

[17]

47

[0]

L3 incompletes:

0

[0]

L2 channel errors:

0

[0]

L2 mismatch timeouts:

0

[0]

Output keepalives: Error statistics:

Input framing errors: Policed discards:

Carrier transitions:

1

[0]

Output errors:

0

[0]

Output drops:

0

[0]

F2

: 0x00

Z3

: 0x00

Z4

: 0x00

Interface warnings: . Received keepalive count is zero . Framing errors are increasing, check FCS configuration and link As estatísticas mostradas na segunda coluna são cumulativas desde o último boot da máquina ou desde a última vez que o administrador zerou os contadores da interface. Para limpar esses contadores, pode-se a qualquer momento usar o comando “clear interfaces statistics”. As estatísticas da terceira coluna são cumulativas, desde a execução do comando “monitor interface”. Se as diferentes estatísticas de erro são incrementadas, pode-se verificar se as das duas pontas do enlace. Se a configuração está correta, deve-se verificar o cabeamento da interface e acionar o provedor do enlace de dados para a verificação de possíveis problemas físicos na linha de transmissão.

Verificando o estado da interface Sonet/SDH Os comandos “show interfaces ” e “show interfaces extensive” podem ser usados para a verificação do estado geral da interface. Em condições normais, a primeira linha deve exibir a mensagem “Physical Link is Up”. Do contrário, a interface não está apta a transferir e receber dados.


configurações de FCS (Frame Checksum) e “scrambling” estão casadas nos equipamentos

269

O “show interfaces” permite verificar os alarmes e defeitos ativos para a interface. Além disso, as configurações das camadas 1 e 2 são verificadas, bem como flags da interface.

user@host> show interfaces so-1/1/1 Physical interface: so-1/1/1, Enabled, Physical link is Down Interface index: 17, SNMP ifIndex: 16 Description: router-02 pos 4/0 Link-level type: Cisco-HDLC, MTU: 4474, Clocking: Internal, SONET mode Speed: OC3, Loopback: None, CRC: 32, Payload scrambler: Enabled Device flgas

: Presente Running Down

Interface flags : Hardware-Down Link-Layer-Down Point-To-Point SNMPTraps Link flags

: Keepalives

Keepalive Input : 621 (00:02:57 ago), Output: 889 (00:00:05 ago) Input rate

: 0 bps (0 pps), Output rate: 0 bps (0 pps)

Active alarms : LOL, LOF, LOS, SEF, AIS-L, AIS-P, PLM-p Logical interface so-1/1/1.0 (Index 18) (SNMP ifIndex 30) Description: router-02 pos 4/0 Flags: Device-down Point-To-Point SNMP-Traps, Encapsulation: Cisco-HDLC Protocol inet, MTU: 4470

Addresses, Flags: Dest-route-down Is-Preferred Is-Primary

Destination: 10.10.10.48/30, Local: 10.10.10.50

Protocol iso, MTU: 4469

Entendendo a rede Sonet/SDH A tecnologia Sonet/SDH define uma hierarquia digital para agregação de feixes de dados. Os feixes populares definidos pela hierarquia SDH (padrão europeu) são: 11 STM-1: 155 Mbps (pode ser composto por diversos frames PDH, como E1s e E3s). 11 STM-4: 622 Mbps (4 x STM-1). 11 STM-16: 2,5 Gbps (4 x STM-4). 11 STM-64: 10 Gbps (4 x STM-16).


11 O padrão de hierarquia digital americano difere um pouco do SDH, mas sua essência é a mesma. As diferenças técnicas não são tema deste curso. 11 Os feixes populares definidos pela hierarquia Sonet (nome dado ao padrão americano) são: 22 OC-3: 155 Mbps (pode ser composto por diversos frames PDH, como E1s e E3s) 22 OC-12: 622 Mbps (4 x OC-3) 22 OC-48: 2,5 Gbps (4 x OC-12) 22 OC-192: 10 Gbps (4 x OC-48) 270

q

PTE

JUNOS Platform

STE

LTE

Regenerator

ADM

Section

Section

STE

STE

LTE

Regenerator Regenerator Section

Section

Line

Section

Line

PTE

ADM

JUNOS Platform Section Line

Path

Regenerator = Repeater ADM = Add/drop multiplexer STE = Section-terminating equipment LTE = Line-Terminating equipment JUNOS platforms are PTE = Path-Terminating equipment

A rede Sonet/SDH típica é composta pelos equipamentos terminais, chamados PTE (Path Terminating Equipment), pelos equipamentos terminais de seção, chamados STE (Section Terminating Equipment) e pelos multiplexadores add/drop. Os regeneradores são considerados STEs, sendo responsáveis por uma determinada seção de uma rota Sonet/SDH. Sua função é simplesmente regenerar o sinal recebido e copiá-lo, já regenerado, na direção do próximo span. Um STE verifica se o sinal que chega do equipamento anterior está saudável. Para tal, um cabeçalho específico do frame Sonet/SDH é utilizado, chamado RSOH “regenerator section overhead”. O STE avalia e utiliza apenas essa parcela do cabeçalho do frame. O STE é capaz ainda de rescrever alguns bytes do cabeçalho caso um alarme seja gerado. Os multiplexadores add/drop são considerados elementos LTE (Line Terminating Equipment). Os LTEs têm mais inteligência que os STEs, mas eles ainda não fazem o processamento final do payload do frame Sonet/SDH (embora sejam capazes de adicionar e remover payloads do feixe). O caminho entre dois LTEs é chamado “line span”. Os LTEs avaliam apenas os bytes do cabeçalho Sonet/SDH referentes à sua atuação. Essa parcela do cabeçalho Sonet/SDH, usada pelo LTE, é chamada MSOH “multiplex section overhead”. A interface Sonet/SDH da plataforma Junos faz o papel de PTE. Basicamente os PTEs fazem o papel de terminais do caminho. Ou seja, o PTE é o destino final do frame. É ali que o payload será interpretado e processado. O caminho entre dois PTEs dentro da rede SDH é chamado “path”. Além do payload, o PTE dedica atenção ao POH “path overhead”, a parte do cabeçalho dedicada a informações sobre o caminho atravessado pelo frame. A figura seguinte (fonte: http://www.teleco.com.br/tutoriais/tutorialrsdh/pagina_2.asp) registra a estrutura do frame STM-1, o feixe de mais baixa hierarquia do padrão SDH.


Figura 13.6 Esquema da rede SDH.

271

1

2

3

4

5

6

7

8

9

10

270

1 2

RSOH

3 4

POH

5 6

MSOH

7

Figura 13.7 Estrutura do frame STM-1.

8 9

Cabeçalho

Informação útil

O PTE também executa algumas funções do STE e do LTE. Antes de processar o payload, o PTE precisa garantir a saúde do frame. Para tal, ele observa a mesma parte do cabeçalho que é avaliada pelo STE para concluir se o frame está íntegro. O PTE também utiliza o “line overhead” para determinadas tarefas. O LTE também avalia o “section overhead” para garantir a saúde dos frames que recebem. Toda a tarefa de troubleshooting é executada sob a perspectiva do PTE (plataforma Junos). Embora existam situações onde não é possível identificar a exata fonte do problema a partir do PTE, será sempre possível dizer se o problema é local ou de rede. Os comandos básicos usados para verificar problemas no path Sonet/SDH são os já conhecidos: 11 “monitor interfaces ” 11 “show interfaces extensive” Exemplo: rompimento de fibra óptica:

Active alarms: LOL, PLL, LOS Active defects: LOL, PLL, LOF, LOS, SEF, AIS-L, AIS-P, PLM-P SONET PHY:

Seconds

Count

State

PLL Lock

51

0

PLL Lock Error

PHY Light

51

0

Light Missing

LOL and LOS Platform A


Section

272

ADM A

Section

RA

RB

Section

RC

Section

ADM B

Section

Platform B

Section

Line Path

Figura 13.8 Exemplo LOS e LOL.

Quando ocorre uma interrupção de fibra óptica entre o roteador B e o multiplexador add/ drop B, vide figura, os seguintes alarmes serão gerados na rede: 11 LOL (Loss of Light): indica ausência de luz na conexão física da porta de recepção do STE que recebe um frame. Esse alarme causa uma cascata de outros alarmes, tal como LOS, LOF e outros descritos abaixo. 11 LOS (Loss of Signal): indica ausência de sinal na interface física de recepção do PTE. 11 LOF (Loss of Frame): indica a detecção de erros verificados nos bytes A1 e A2 do cabeçalho dos frames recebidos pelo PTE. 11 AIS: o Junos envia um alarme AIS para a rede SDH para sinalizar uma condição de erro. Um AIS-L indica que ocorreu um LOF ou LOS em algum STE do caminho upstream. Um AIS-P indica que um LOS ou LOF é detectado em um LTE do caminho upstream. Nesses casos é necessário interagir com o responsável pela rede SDH para identificar o elemento que gerou os alarmes. 11 RDI: o Junos envia uma mensagem de “remote defect indicator” para sinalizar uma condição de erro. No padrão Sonet/SDH, um RDI-L é enviado de um LTE para outro quando um deles detecta um AIS-L, LOS ou LOF. Um RDI-P é enviado de um PTE para outro quando um deles detecta um AIS-P, AIS-L, LOS ou LOF. 11 REI: o Junos envia um “remote error indicator” para sinalizar uma condição de erro. Um REI-L é enviado ao LTE quando um erro é detectado no byte B2. Um REI-P é enviado ao PTE remoto quando um erro é detectado no byte B3.

RDI-P RDI-L

LOS RA

ADM A

ADM B

RB

Platform B

AIS-P

AIS-L

Section

Section Line

Figura 13.9 Exemplo de sinalização RDI.

Section

Section

Line

Section Line

Path A presença dos alarmes citados requer interação com o responsável pela rede Sonet/SDH. As razões pelas quais um simples cabo interrompido produz um alarme de LOL ou de LOS são explicáveis pelos próprios nomes dos alarmes, podendo gerar alguma confusão o fato de outros contadores incrementarem (como o AIS) na linha e no path Sonet/SDH. Esses contadores são usados para ajudar a localizar os pontos de falha. Este curso não detalhará as especificidades de cada um dos contadores de erro da hierar-


Platform A

AIS

quia Sonet/SDH. Para os casos práticos, sempre que o provedor da rede Sonet/SDH precisar ser acionado, é útil informar os contadores que estão incrementando na interface do Junos. 273

274


Bibliografia 11 COMER, Douglas E. Internetworking with TCP/IP – Volume I: Principles, Protocols and Architecture. Fourth Edition, Prentice Hall, 2000. 11 Comitê Gestor RNP. Redê Ipê: Política de Uso. Outubro de 2007. Disponível em http://www.rnp.br/_arquivo/conexao/doc0108d.pdf 11 FAUSTINO, Jean Carlo. O serviço nacional de VoIP da RNP. VIII International Information and Telecommunication Technologies Symposium. 11 Juniper Networks. J Series Services Routers Hardware Guide Release 9.6. Disponível em http://www.juniper.ie/techpubs/hardware/junos-jseries/ junos-jseries96/ 11 Juniper Networks. Troubleshooting Junos Platforms 9.a - Student Guide. 11 Juniper Networks. Junos Routing Essentials 9.a - Student Guide. 11 Juniper Networks. Introduction to Junos Software 9.a - Student Guide. 11 Juniper Networks, J2300, J4300, and J6300 Services Router, Getting Started Guide, Release 8.5 11 STEVENS, W. Richard. TCP/IP Illustrated Volume 1: The Protocols. Addison Wesley, 1994. 11 ALBITZ, P.; LIU, C. DNS and Bind. O’Reilly & Associates, 1993. 11 LOPES, Raquel V.; SAUVÉ, Jacques P.; NICOLLETTI, Pedro S. Melhores práticas para gerência de redes de computadores. Campus, 1 ed., 2003. 11 STALLINGS, William. SNMP, SNMPv2, SNMPv3 e RMON 1 e 2. Addison-Wesley, 3 ed., 1999. 11 FEIT, Sidnie. SNMP: A guide to Network Management. McGraw-Hill,

Bibliografia

1 ed., 1995.

275

276


Gustavo Batista graduou-se em Engenharia de Telecomunicações pela Universidade Federal 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.

LIVRO DE APOIO AO CURSO

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 e problemas de interface do roteador Juniper da RNP, além de conceitos básicos de roteamento e utilização

ISBN 978-85-63630-33-9

9 788563 630339

Introdução à rede Ipê

Recommend Documents