Apostila Curso CCNP Route 300-101_v3-m

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br

DlteC do Brasil®

www.dltec.com.br [email protected] | 41 3045.7810

DLTEC DO

APOSTILA/E-BOOK DO CURSO CCNP ROUTE

BRASIL

300-101

Apostila/E-Book do Curso CCNP ROUTE 300-101 DlteC do Brasil® Todos os direitos reservados©

Apostila/E-B     

  

 





ook do Curso C  

  

CNP ROUTE 



Página 1  



 


Sobre o E-book/Apostila O conteúdo desse documento é uma adaptação da matéria online de leitura do curso. O presente material traz conteúdo teórico do curso online, porém temos que deixar claro que não é um curso e sim uma adaptação do nosso material online para e-book/apostila . Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com professores) e vídeo aulas não fazem parte desse e-book, pois são exclusivos para alunos devidamente matriculados em nosso site oficial.

Para maiores informações sobre nossos treinamento visite o site:

>>> http://www.dltec.com.br <<<


  

 






  




Página 2  



 


Direitos Autorais Aviso Importante! Esse material é de propriedade da DlteC do Brasil Ltda e é protegido pela lei de direitos autorais 9610/98. É expressamente proibida cópia física ou em meio digital, reprodução parcial, reprografia, fotocópia ou qualquer forma de extração de informações deste sem prévia autorização da DlteC do Brasil conforme legislação vigente. Seu uso pessoal e intransferível é somente para o cliente que adquiriu o referido e-book/apostila. A cópia e distribuição são expressamente proibidas e seu descumprimento implica em processo cível de danos morais e materiais previstos na legislação contra quem copia e para quem distribui, sejam cópias físicas e/ou digitais. Copyright © 2016.


  

 






  




Página 3  



 


Índice Capítulo 01 - Introdução .............................................................................................................. 5 Capítulo 02 - Princípios de Redes e Roteamento......................................................................... 11 Capítulo 03 - Implementando o EIGRP ....................................................................................... 60 Capítulo 04 - Implementando o OSPF Multiarea ...................................................................... 103 Capítulo 05 - Redistribuição e Otimização de Roteamento ....................................................... 130 Capítulo 06 - Controle de Encaminhamento de Tráfego ............................................................ 154 Capítulo 07 - Implementando o BGP ........................................................................................ 168 Capítulo 08 - Implementando Roteamento em IPv6 ................................................................. 206 Capítulo 09 - Conectando Sites Remotos .................................................................................. 258 Capítulo 10 - Segurança em Roteadores e Serviços de Rede ..................................................... 291


  

 






  




Página 4  



 


Capítulo 01 - Introdução Olá, Essa apostila/E-Book é uma adaptação em texto do nosso material online de estudo (matéria online do curso ccnp route). Alguns itens dessa revisão 300-101 do CCNP Route sãonova parte integrante do CCENT e ICND-2, ou seja, do pré-requisito que é o CCNA R&S, por isso alguns tópicos aparecem a seguir na listagem fazendo referência a esses materiais, pois estamos seguindo a mesma linha de redação dos materiais oficiais da Cisco. A seguir você tem uma relação dos tópicos da prova do CCNP ROUTE 300-101 versus capítulos da apostila/e-book, sendo que alguns que são pré-requisitos estarão relacionados ao CCENT, ICND-2 e CCNA R&S.. Esperamos que você aproveite o material e bons estudos.


  

 






  




Página 5  



 


Blueprint do CCNP ROUTE 300-101 Vamos começar esse material com o blueprint atual divulgado pela Cisco em seu site oficial (www.cisco.com/go/certifications). Muitos dos tópicos são parte do CCNA R&S (CCENT e ICND2), portanto referenciamos os tópicos com os capítulos do livro e também com o CCENT e ICND-2, pois ambos compõe o CCNA R&S (pré-requisito do CCNP R&S). Procuramos cobrir todos os tópicos que são novidade para um CCNA R&S, porém alguns assuntos repetidos e idênticos não vamos abordar, por isso é importante que você tenha o prérequisito exigido pelo CCNP R&S. Apostila/E-Book ou Conteúdo do CCNA R&S

Tópico do Exame 1.0 Network Principles 10%

II e VIII

1.1 Identify Cisco Express Forwarding concepts

Capítulo II

1.1.a FIB

Capítulo II

1.1.b Adjacency table

Capítulo II

1.2 Explain general network challenges

Capítulo II

1.2.a Unicast

Capítulo II

1.2.b Out-of-order packets

Capítulo II

1.2.c Asymmetric routing 1.3 Describe IP operations

Capítulo II Capítulo II

1.3.a ICMP Unreachable and Redirects

Capítulo II

1.3.b IPv4 and IPv6 fragmentation

Capítulo II

1.3.c TTL

Capítulo II

1.4 Explain TCP operations

Capítulo II

1.4.a IPv4 and IPv6 (P)MTU

Capítulo II

1.4.b MSS

Capítulo II

1.4.c Latency

Capítulo II

1.4.d Windowing

Capítulo II

1.4.e Bandwidth-delay product

Capítulo II

1.4.f Global synchronization

Capítulo II

1.5 Describe UDP operations

Capítulo II

1.5.a Starvation

Capítulo II

1.5.b Latency 1.6 Recognize proposed changes to the network

Capítulo II Capítulo II

1.6.a Changes to routing protocol parameters

Capítulo II

1.6.b Migrate parts of the network to IPv6

Capítulo VIII

1.6.c Routing protocol migration


  

 





Capítulo II


  




Página 6  



 


Apostila/E-Book ou Conteúdo do CCNA R&S

Tópico do Exame 2.0 Layer 2 Technologies 10%

ICND-2

2.1 Configure and verify PPP 2.1.a Authentication (PAP, CHAP) 2.1.b PPPoE (client side only) 2.2 Explain Frame Relay

ICND-2

2.2.a Operations 2.2.b Point-to-point 2.2.c Multipoint

Tópico do Exame

Apostila/E-Book ou Conteúdo do CCNA R&S Vários

3.0 Layer 3 Technologies 40% 3.1 Identify, configure, and verify IPv4 addressing and subnetting

CCENT

3.1.a Address types (Unicast, broadcast, multicast, and VLSM) 3.1.b ARP 3.1.c DHCP relay and server

CCENT / Capítulo X

3.1.d DHCP protocol operations 3.2 Identify IPv6 addressing and subnetting 3.2.a Unicast 3.2.b EUI-64

Capítulo VIII

3.2.c ND, RS/RA 3.2.d Autoconfig (SLAAC) 3.2.e DHCP relay and server 3.2.f DHCP protocol operations 3.3 Configure and verify static routing

CCENT

3.4 Configure and verify default routing

CCENT / Capítulos III IV e VII

3.5 Evaluate routing protocol types 3.5.a Distance vector

Capítulo II

3.5.b Link state 3.5.c Path vector 3.6 Describe administrative distance 3.7 Troubleshoot passive interfaces

Capítulos II III e IV

3.8 Configure and verify VRF lite

Capítulo VI

3.9 Configure and verify filtering with any protocol 3.10 Configure and verify redistribution between any routing protocols or routing sources 3.11 Configure and verify manual and autosummarization with any routing protocol

Capítulo VI


  

 






  

Capítulo V Capítulos II III IV e VII




Página 7  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br 3.12 Configure and verify policy-based routing

Capítulo VI

3.13 Identify suboptimal routing 3.14 Explain ROUTE maps

Capítulo V

3.15 Configure and verify loop prevention mechanisms 3.15.a Route tagging and filtering 3.15.b Split-horizon

Capítulo II

3.15.c Route poisoning 3.16 Configure and verify RIPv2 3.17 Describe RIPng

Capítulo VIII

3.18 Describe EIGRP packet types 3.19 Configure and verify EIGRP neighbor relationship and authentication 3.20 Configure and verify EIGRP stubs

Capítulo III

3.21 Configure and verify EIGRP load balancing 3.21.a Equal cost 3.21.b Unequal cost 3.22 Describe and optimize EIGRP metrics 3.23 Configure and verify EIGRP for IPv6

Capítulo VIII

3.24 Describe OSPF packet types 3.25 Configure and verify OSPF neighbor relationship and authentication 3.26 Configure and verify network types, area types, and router types 3.26.a Point-to-point, multipoint, broadcast, nonbroadcast 3.26.b LSA types, area type: backbone, normal, transit, stub, NSSA, totally stub

Capítulo IV

3.26.c Internal router, backbone router, ABR, ASBR 3.26.d Virtual link 3.27 Configure and verify OSPF path preference 3.28 Configure and verify OSPF operations 3.29 Configure and verify OSPF for IPv6 3.30 Describe, configure, and verify BGP peer relationships and authentication

Capítulo VIII

3.30.a Peer group

Capítulo VII

3.30.b Active, passive 3.30.c States and timers 3.31 Configure and verify eBGP (IPv4 and IPv6 address families)

Capítulos VII e VIII

3.31.a eBGP 3.31.b 4-byte AS number 3.31.c Private AS

Capítulo VII

3.32 Explain BGP attributes and best-path selection


  

 






  




Página 8  



 



Tópico do Exame 4.0 VPN Technologies 10%

IX

4.1 Configure and verify GRE IX

4.2 Describe DMVPN (single hub) 4.3 Describe Easy Virtual Networking (EVN)


Tópico do Exame

CCENT Capítulo X

5.0 Infrastructure Security 10% 5.1 Describe IOS AAA using local database 5.2 Describe device security using IOS AAA with TACACS+ and RADIUS

Capítulo X

5.2.a AAA with TACACS+ and RADIUS 5.2.b Local privilege authorization fallback 5.3 Configure and verify device access control 5.3.a Lines (VTY, AUX, console) 5.3.b Management plane protection 5.3.c Password encryption

CCENT / Capítulo X

5.4 Configure and verify router security features 5.4.a IPv4 access control lists (standard, extended, time-based) 5.4.b IPv6 traffic filter 5.4.c Unicast reverse path forwarding


  

 





Capítulo X


  




Página 9  



 


Tópico do Exame


6.0 Infrastructure Services 10%

Vários

6.1 Configure and verify device management 6.1.a Console and VTY 6.1.b Telnet, HTTP, HTTPS, SSH, SCP 6.1.c (T)FTP 6.2 Configure and verify SNMP 6.2.a v2 CCENT / ICND-2 / Capítulo X

6.2.b v3 6.3 Configure and verify logging 6.3.a Local logging, syslog, debugs, conditional debugs 6.3.b Timestamps 6.4 Configure and verify Network Time Protocol (NTP) 6.4.a NTP master, client, version 3, version 4 6.4.b NTP authentication 6.5 Configure and verify IPv4 and IPv6 DHCP 6.5.a DHCP client, IOS DHCP server, DHCP relay

CCENT / Capítulo IX

6.5.b DHCP options (describe) 6.6 Configure and verify IPv4 Network Address Translation (NAT) 6.6.a Static NAT, dynamic NAT, PAT 6.7 Describe IPv6 NAT

Capítulo VIII

6.7.a NAT64 6.7.b NPTv6 6.8 Describe SLA architecture 6.9 Configure and verify IP SLA 6.9.a ICMP

Capítulo VI

6.10 Configure and verify tracking objects 6.10.a Tracking objects 6.10.b Tracking different entities (for example, interfaces, IPSLA results) 6.11 Configure and verify Cisco NetFlow 6.11.a NetFlow v5, v9

ICND-2 / Capítulo X

6.11.b Local retrieval 6.11.c Export (configuration only)


  

 






  




Página 10  



 


Capítulo 02 - Princípios de Redes e Roteamento Nesse capítulo estudaremos os princípios e fundamentos de Redes, Roteamento e encaminhamento cobrados

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Encaminhamento de pacotes. Visão geral dos protocolos de roteamento. Funcionamento dos processos de encaminhamento Process Switching, Fast Switching e CEF. Tabelas do CEF: adjacência e de encaminhamento. Operação e desafios do IP. Operação e desafios do TCP. Operação e desafios do UDP.

na revisão atual do CCNP 300-101.

 



No CCNA o foco era a operação e manutenção de redes de pequeno e médio porte, já no CCNP encontraremos cenários mais complexos, por isso nessa revisão conceitos mais avançados como CEF e operações do TCP foram adicionados.



  

Sumário do Capítulo 1

Princípios de Roteamento _________ 13

1.1

Classificação dos Protocolos de

Roteamento _________________________ 13

Aproveite o capítulo e bons estudos!

1.1.1 1.1.2 1.1.3

1.2

Protocolos Vetores de Distância ____ 13 Protocolos Link State _____________ 14 Protocolos Path Vector ___________ 15

Comparando o EIGRP, OSPF e BGP __ 15

1.3 Conceitos e Configurações do Protocolo RIP Versão 2 _________________________ 16 1.4 Que Protocolo de Roteamento Escolher? ____________________________ 18 1.5 Montando a Tabela de Roteamento e Encaminhando de Pacotes ______________ 19 1.6

Revisão Prática de Roteamento IP __ 21

1.7 Qual a Melhor Forma de Migrar o Protocolo de Roteamento de uma Rede em Operação? ___________________________ 23 2 Encaminhando Pacotes - Process Switching, Fast Switching e CEF ________ 25

3


  

 





2.1

Fast Switching __________________ 26

2.2

CEF - Cisco Express Forwarding _____ 27

Modelos de Design de Rede ________ 31


  




Página 11  



 


4

3.1

Modelo Hierárquico em Três Camadas 31

3.2

Enterprise Composite Model _______ 32

Conceitos Avançados de TCP/IP _____ 36

4.1

Protocolo IP e seus Desafios _______ 36

4.1.1 Os Quatro "casts" - Unicast, Multicast, Broadcast e Anycast ______________________ 38 4.1.2 fora de ordem - Out Of Order Packets Pacotes 40 4.1.3 Roteamento assimétrico __________ 41 4.1.4 ICMP Unreachable e Redirects _____ 42 4.1.4.1 Destination Unreachable ________ 43 4.1.4.2 ICMP Redirect _________________ 44 4.1.5 MTU - Maximum Transmission Unit _ 45 4.1.6 Fragmentação de Pacotes IPv4 e IPv6 45 4.1.6.1 Path MTU discovery - (P)MTU ____ 47 4.1.6.2 Testando Manualmente o MTU do Caminho com o Ping para IPv4 ___________ 48 4.1.7 TTL ____________________________ 50

4.2

Protocolo TCP ___________________ 52

4.2.1 4.2.2 4.2.3 4.2.4

MSS - Maximum Segment Size _____ 54 Janelamento (Windowing) _________ 55 Outros Recursos do TCP ___________ 56 Slow Start e Global Synchronization _ 57

4.2.5 4.2.6

Latência _______________________ 57 Produto Bandwidth-delay _________ 58

4.3

Protocolo UDP __________________ 58

4.3.1 4.3.2

TCP Starvation e UDP Dominance ___ 59 Latência _______________________ 59


  

 






  




Página 12  



 


1

Princípios de Roteamento

1.1 Classificação dos Protocolos de Roteamento Aqui não tem muita novidade em relação ao CCNA R&S, podemos ter protocolos Internos (IGP - Internal Gateway Protocol) ou Externos (EGP - External Gateway Protocol). É só lambrar os IGPs são utilizados dentroo EGP de um domínionadeInternet roteamento ou sistema autônomo (AS que - Autonomous System), enquanto é utilizado para rotear entre diferentes sistemas autônomos, sejam eles empresas ou provedores de serviços de Internet (ISP - Internet Service Providers). Atualmente o único EGP em uso é o BGP ou BGP-4 (versão 4), o qual também possui uma versão que pode ser utilizada como IGP chamada iBGP ou Internal Border Gateway Protocol. Além disso, cada protocolo pode ser classificado de acordo com seu algoritmo de roteamento como: Vetor de Distância ou Distance Vector: Protocolos RIP e EIGRP Link State ou SPF: Protocolos OSPF e IS-IS Vetor de Caminho ou Path Vector: Protocolos BGP e iBGP   

O termo "Híbrido" (Balanced Hybrid) continua a ser utilizado para o EIGRP, porém a nova documentação oficial do CCNP ROUTE passou a classificá-lo apenas como "Vetor de Distância Avançado" (Advanced Distance Vector), uma subclassificação do Vetor de Distância. Na tabela abaixo temos um resumo dos protocolos e suas características. Protocolo Tipo de Algoritmo IGP ou EGP ? RIPv1, RIPv2 e RIPng Distance-Vector IGP EIGRP e EIGRPv6 Advanced-Distance-Vector IGP OSPFv2 e OSPFv3 Link-State IGP IS-IS Link-State IGP iBGP Path-Vector IGP BGP Path-Vector EGP 1.1.1 Protocolos Vetores de Distância

Um protocolo vetor de distância como, por exemplo, o RIP envia de 30 em 30 segundos TODA tabela de roteamento para seus vizinhos, não se importando se os vizinhos precisem ou não daquela informação. Isso torna o roteamento não tão eficiente e também gera riscos de Loops de Roteamento serem gerados por receberem informações erradas ou desnecessárias. Para1.evitar de roteamento os protocolos Distance Vector dois adicionais: Splitloops Horizon : esse recurso não permite que uma rota utilizam aprendida emrecursos uma interface seja anunciada para trás na mesma interface. É como se você contasse uma piada para alguém e no momento seguinte essa pessoa pega e fala para você "quer ouvir uma piada que acabei de aprender?", não tem sentido certo? 2. Poison Reverse: já esse recurso permite que uma rota recebida em uma interface seja anunciada para trás na mesma interface com métrica infinita, ou seja, o poison reverse "mata" uma rota que está com problemas marcando com uma métrica inacessível para os outros roteadores.


  

 






  




Página 13  



 


Outro ponto importante é que redes muito grandes com protocolos vetor de distância podem ter um tempo de convergência alto, ou seja, podem demorar mais para encaminhar corretamente para 100% da rede. Falando mais especificamente sobre o RIP, para IP versão 4 ele possui duas versões: RIP v1 e RIP v2. A versão 1 do RIP não deve ser utilizada por não suportar CIDR e VLSM (prefixos e máscaras de sub-rede com comprimento variável), além disso envia suas atualizações ou updates de roteamento em broadcast. Já o RIPv2 suporta VLSM, enviapara seus troca updates Multicast para endereço o224.0.0.9 e tem a possibilidade de autenticação de em mensagens entreo vizinhos, que melhora segurança da troca de informações de roteamento. Apesar de parecer estranho o RIP voltar nessa revisão do CCNP saiba que ele ainda é muito utilizado principalmente em redes com dispositivos mais antigos ou legados. Para o protocolo IPv6 utilizamos o RIP next generation (RIPng) que funciona de forma análoga ao RIP versão 2, porém adaptado para transportar e fazer updates utilizando endereços IPv6. O segundo protocolo vetor de distância que vamos estudar no CCNP é o Enhanced Interior Gateway Routing Protocol ou EIGRP. O EIGRP é um protocolo proprietário da Cisco até 2013, data em que a Cisco publicou uma RFC que possibilita que outros fabricantes implementem o EIGRP. Ele é classificado como "advanced distance-vector routing protocol" porque tem as características básicas de um protocolo distance-vector routing protocol, porém ele não envia tabelas roteamento periodicamente para vizinhos, ao invés disso envia rápida. "triggered (Updatesdegerados em caso de alterações/falhas) e tem a convergência Paraupdates" o IPv6 temos o EIGRPv6, que assim como o RIPng é uma adaptação do EIGRP para o protocolo IP versão 6. O EIGRP pode anunciar também serviços de rede, por exemplo, informações sobre planos de discagem para uma rede de comunicações unificadas, utilizando o Cisco "Service Advertisement Framework" (SAF) . O algoritmo de roteamento utilizado pelo EIGRP e EIGRPv6 para calcular a melhor rota é o Diffusing Update Algorithm (DUAL), já o RIPv1/2 e o RIPng utilizam o algoritmo de Bellman-Ford. 1.1.2 Protocolos Link State

Os protocolos Link State (estado do enlace) tem seu funcionamento conforme o algoritimo de "Dijkstra" ou "Shortest Path First" (caminho mais curso primeiro). Eles atuam de forma diferente dos vetores de distância, precisando formar vizinhanças ou adjacências mais complexas antes de trocar informações chamadas LSAs ou link-state advertisements, portanto os roteadores Link State NÃO TROCAM TABELAS de roteamento e sim anúncios Link State para montar um banco de dados topológico que vai levar a um mapa daquela rede ou área que os roteadores pertencerem. É como se os roteadores tivessem um "google maps" e soubessem exatamente o caminho que o pacote vai seguir dentro do domínio de roteamento ou área SPF. Se compararmos com os vetores de distância eles são bem mais simples nesse quesito, pois eles conhecem apenas seus vizinhos diretamente conectados.


  

 






  




Página 14  



 


De maneira global os protocolos tipo SPF tem tempo de convergência menor que os vetores de distância, com exceção do EIGRP que é mais avançado e tem tempo de convergência equivalente e até superiores em alguns casos. Os dois protocolos Link State mais famosos são: Open Shortest Path First (OSPF): sua métrica é o custo, o qual tem como base a largura de banda das interfaces entre dois roteadores. Ele é muito popular como IGP pela sua escalabilidade, convergência rápida e interoperabilidade entre diversos fabricantes por ser um protocolo aberto. Para o IPv4 utilizamos o OSPF ou OSPFv2 e 



para o IPv6 utilizamos o OSPFv3. –to–Intermediate System (IS-IS): Intermediate System funcionamento similar ao do OSPF, porém não foi tão difundido.

tem

princípio

de

1.1.3 Protocolos Path Vector

Como o nome já diz, o Path Vector ou Vetor de Caminho utiliza o caminho que os pacotes utilizarão para chegar até um determinado destino. Essa informação normalmente é uma sequência de números de sistema autônomo (ASN - Autonomous System Number) por onde o pacote trafega da srcem até seu destino. O BGP ou Border Gateway Protocolo é o protocolo vetor de caminho utilizado na Internet e não pense que ele utiliza somente o caminho como métrica, vamos estudar mais para frente que ele pode utilizar diversos parâmetros como escolha de caminho. Atualmente utilizamos a versão 4 do BGP (BGP-4) para redes IPv4. Se for necessário rotear IPv6 utilizamos uma melhoria do BGP chamada "Multiprotocol BGP" (MP-BGP) , a qual suporta diversos protocolos roteados inclusive IPV4 e IPv6. 1.2 Comparando o EIGRP, OSPF e BGP Os principais fatores que devem ser levados em conta na escolha de um protocolo de roteamento são a velocidade de convergência e suporte a VLSM, o que tanto o EIGRP, o OSP F e o BGP atendem esses requisitos básicos de escolha. Porém temos que entender também as principais diferenças entre esses protocolos: EIGRP: inicialmente um protocolo proprietário, portando não interopera com roteadores e dispositivos de rede de outros fabricantes que não tenham o EIGRP implementado em seu sistema operacional. Suas maiores vantagens são a simplicidade de configuração e manutenção para a equipe de suporte que administra a rede. OSPF: protocolo aberto, ou seja, pode ser configurado entre dispositivos de fabricantes diferentes, porém é um pouco mais complexo de configurar e manter que o EIGRP. BGP: também é um protocolo aberto, porém mais utilizado para conectar a redes externas como a Internet, além disso é bem mais complexo de configurar e manter que os dois anteriores. Sua maior vantagem é a grande estabilidade em redes de grande porte. 






  

 






  




Página 15  



 


Veja na tabela a seguir uma comparação entre os três protocolos. Característica

EIGRP

OSPF

BGP

Classificação do protocolo

Vetor de Distância Avançado

Link state

Vetor de caminho (path vector)

Sumarização de Rotas

Automática e manual

Manual

Automática e manual

Suporte a VLSM e CIDR Tempo de Convergência

SIM Muito rápida

SIM Rápida

SIM Lenta

Temporizadores: Update (hello/dead)

Disparado por eventos (LAN 5/15 e WAN 60/180)

Disparado por Disparada por eventos com eventos (60/180) atualizações a cada 30 minutos (NBMA 30/120 e LAN 10/40)

Porte da Rede Suportada Grande porte

Grande porte

Porte muito grande (Internet)

Portanto, o protocolo a ser utilizado depende se a rede vai ser inteira Cisco ou teremos roteadores de outros fabricantes, porte da rede, conexão direta com a Internet (Sistema Autônomo - obrigatoriamente via BGP), etc. Uma vez definido o modelo de rede (arquitetura a ser utilizada) e o tipo de protocolo de roteamento (podendo ser um ou mais) é hora de instalar os equipamentos e realizar as configurações que estudaremos ao longo do curso. 1.3 Conceitos e Configurações do Protocolo RIP Versão 2 Apesar do RIPv2 ser um protocolo de roteamento antigo e ter sido retirado do CCNA ele voltou ao CCNP ROUTE por ainda ser encontrado em campo, principalmente em redes com múltiplos fabricantes e legadas de infraestruturas antigas. Roteadores baseados UNIX ou LINUX, ou seja, roteadores que estão dentro de servidores baseados em Linux ou Unix rodando apenas o RIP também é outra possibilidade de encontrarmos em campo, por isso a importância ainda nos dias de hoje de entendermos e configurarmos o RIPv2. O RIP é um protocolo de roteamento aberto (definido em RFC) e possui duas versões: 



Versão 1 (RIP v1): protocolo classfull, envia atualizações em broadcast, envia a informação da máscara de sub-rede em seus anúncios e não suporta VLSM ounão CIDR. Versão 2 (RIP v2): protocolo classless, envia atualizações em multicast (224.0.0.9) e suporta VLSM e CIDR, pois envia a rede e a máscara em seus anúncios de roteamento.

Ambas as versões são consideradas “Distance Vector Routing Protocols” (protocolos de roteamento baseados em vetores de distância), utilizam como métrica o número de saltos (hop count) e tem distância administrativa 120.


  

 






  




Página 16  



 


Como vetores de distância eles trocam informações sobre toda sua tabela de roteamento em suas atualizações de roteamento periodicamente de 30 em 30 segundos. Mesmo que a rede já tenha convergido e não haja nenhum problema os updates são enviados. Caso ocorram problemas antes dos 30 segundos o RIP pode enviar flash updates para acelerar o processo de convergência frente a uma falha na rede, por exemplo, o roteador acabou de enviar um update e 15 segundos depois ocorre uma falha ao invés de esperar o próximo update o RIP envia uma flash update. Para evitarTimer loops. de roteamento utiliza o Split Horizon, Poison Reverse e contadores como Holdown Tanto o RIP v1 como o v2 suportam balanceamento de carga entre rotas de mesmo custo ou Equal Cost Load Balancing por padrão entre 4 rotas. O balanceamento é configurado em modo de configuração do RIP com o comando "maximum-paths". Na configuração de exemplo está configurado para o roteador balancear carga entre no máximo duas rotas de mesma métrica, ou seja, que tenham mesmo número de saltos. Sua configuração inicial é simples, primeiro precisamos entrar no modo de configuração do RIP com o comando "router rip", em seguida basta definir as redes classfull diretamente conectadas com o comando network e inserir o comando “no auto-summary” para evitar problemas de redes descontínuas que pode ser causado pela sumarização automática que normalmente é padrão no RIP. Veja um exemplo de configuração abaixo. dltec(config)#router rip dltec(config-router)#version 2 dltec(config-router)#network 10.0.0.0 dltec(config-router)#network 192.168.1.0 dltec(config-router)#no auto-summary dltec(config-router)#passive-interface fast 0/0 dltec(config-router)#maximum-paths 2 dltec(config-router)#default-information srcinate dltec(config-router)#redistribute ospf 1 metric 2

Por padrão, o RIP vem configurado como versão 1 e a opção “version 2” ativa a versão 2 que é nosso objetivo no CCNP ROUTE. Em seguida com as redes anunciadas no comando Network sabemos que as redes que estiverem configuradas nas interfaces que tenham endereço dentro das faixas 10.0.0.0/8 (10.0.0.1 a 10.255.255.254) e 192.168.1.0/24 (192.168.1.1 a 192.168.1.254) terão suas redes anunciadas pelo RIP. O comando "no auto-summary" evita que o RIP anuncie somente as redes 10.0.0.0 e 192.168.1.0, pois sem ele é isso que o RIP fará e não anunciará sub-redes. Com o comando "no auto-summary" todas as sub-redes configuradas nas interfaces citadas no parágrafo anterior serão anunciadas no processo de roteamento dentro dos updates periódicos. O comando “passive interface” faz com que o RIP não envie atualizações na interface determinada pelo comando, porém ela continua recebendo as atualizações. No exemplo da configuração temos "passive-interface fast 0/0", portanto todas as interfaces menos a fast 0/0 vão enviar updates com a tabela de roteamento, porém a rede configurada nela vai ser mantida nos updates das demais interfaces. Para que o roteador não anuncie uma rede ou não anunciamos no comando network ou teremos que fazer um filtro que estudaremos mais para frente através de uma distribute-list ou route-map.


  

 






  




Página 17  



 


Já o comando “maximum-paths”, como já citado anteriormente, é utilizado para definir quantas rotas poderão balancear carga, sendo que se o valor for configurado como “1” não haverá balanceamento de cargas. O comando “default-information srcinate ” é utilizado para redistribuição de uma rota padrão automaticamente pelo roteador que está conectado com a Internet, normalmente a rota para a Internet é configurada via rota estática. Nesse comando podemos utilizar a opção "always" no final dele para que sempre a rota padrão seja anunciada, mesmo que não haja uma rota estática configurada ou que ela esteja down, por exemplo. A redistribuição (comando redistribute ospf 1 metric 2) será estudada no “Capítulo 5 Redistribuição e Otimização de Roteamento”. Mas você pode "supor" o que esse comando faz interpretando a sintaxe, ele redistribui as rotas do OSPF com process-ID 1 dentro do RIP com métrica 2 (como se tivessem 2 saltos), simples assim. Abaixo seguem alguns comandos show e debug para que você utilize quando montar sua topologia e verificar se está tudo funcionando corretamente: - Show ip route [rip]: verificar a tabela de roteamento (RIP identificado por R). - Show ip protocols: verificar os parâmetros, rotas anunciadas, temporizadores, distância administrativa e outras informações do RIP. - Show ip rip database: verifica as rotas aprendidas e sumarizações. - Show ip rip neighbors: verifica os vizinhos do RIP. - Debug ip rip: analisar em tempo real a troca de Updates do RIP. No IPv6 temos o RIPng (Next Generation), o qual foi baseado no RIP versão 2, portanto ambos seguem a mesma filosofia de roteamento, porém o RIPng suporta apenas prefixos IPv6. 1.4 Que Protocolo de Roteamento Escolher? Nesse material você vai estudar sobre os protocolos RIPv2, RIPng, OSPFv2, OSPFv3, EIGRP, EIGRPv6, BGP, iBGP e MP-BGP. Por isso, uma das questões que pode aparecer na prova é: "Qual protocolo ou tipo de f amília vamos ter que utilizar em um determinado cenário?" Para isso você será cobrado sobre os seguintes quesitos de comparação e escolha entre esses protocolos: Scalability ou Escalabilidade: a questão aqui é "Quanto sua rede vai crescer?", pois o RIP, por exemplo, suporta apenas 15 saltos em série, já um BGP é utilizado na maior rede do mundo que é a Internet. Interoperabilidade ou "Vendor Interoperability": apesar da Cisco ter aberto o código do EIGRP nem todos os fabricantes o suportam, portanto a escolha do protocolo a ser utilizado deve também levar em conta se sua rede é "pura Cisco" ou tem outros fabricantes (Vendors). Familiaridade da equipe de TI com o protocolo: não adianta migrar a rede ou implantar um protocolo que a equipe não sabe como operar. Tempo de convergência: o tempo para uma rede convergir ou então para voltar de uma falha pode também influenciar nas aplicações de rede, por isso esse fator muitas vezes é crucial na escolha do protocolo de roteamento. O RIP e o BGP podem levar minutos para convergir dependendo o tamanho da rede, ao passo que o OSPF e EIGRP podem levar segundos para a mesma topologia. Capacidade de fazer sumarização: em redes de grande porte esse pode ser um fator importante para economizar memória e processamento dos roteadores, pois quanto mais entradas de roteamento mais capacidade será exigida dos roteadores. Portanto, quanto menos rotas tivermos melhor será o desempenho, por isso a importância da sumarização. 










  

 






  




Página 18  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br 



Necessidade de IGP ou EGP: se a empresa é um Autonomous System (AS) e possui conexão com outros ASs será necessário o BGP-4 para o roteamento entre os diversos ASs. Dentro do mesmo sistema autônomo já podemos utilizar um IGP como EIGRP ou OSPF para encaminhar as informações entre os diversos roteadores da rede interna. Tipo de protocolo de roteamento: como já estudamos anteriormente temos três categorias de protocolos de roteamento (Distance Vector, Link State e Path Vector) e dependendo do protocolo que formos utilizar sabemos pelo tipo de roteamento como ele irá se comportar e se ele vai se adequar aos requisitos do projeto.

1.5 Montando a Tabela de Roteamento e Encaminhando de Pacotes Vamos iniciar lembrando o conceito da distância administrativa (AD – Administrative Distance) e como os protocolos de roteamento tratam as entradas de roteamento recebidas. Quando um roteador aprende a informação sobre o caminho até uma rede (rota) através de mais de uma fonte, ou seja, aprendeu rota para uma mesma rede de destino através de mais de um protocolo de roteamento, a distância administrativa é utilizada como fator de escolha da rota que deve ser utilizada para encaminhamento dos pacotes pelo roteador. Nesse caso, o roteador escolhe a rota aprendida pelo protocolo de roteamento com menor distância administrativa. Cada protocolo possui uma distância administrativa padrão, porém ela pode ser configurada manualmente. Veja a tabela abaixo com as ADs padrões. AD (Distância Administrativa)

Origem da Informação de Roteamento Interface diretamente conectada

0

Rota estática com IP como referência

1

Rota estática com Interface como referência rota sumário EIGRP –

0 5

External Border Gateway Protocol (BGP)

20

EIGRP interno

90

IGRP

100

OSPF

110

Intermediate System-to-Intermediate System (IS-IS)

115

Routing Information Protocol (RIP)

120

Exterior Gateway Protocol (EGP)

140

On Demand Routing (ODR)

160

rota externa EIGRP –

170

BGP interno Desconhecido

200 255

Para construir a tabela de roteamento, além da distância administrativa temos também o conceito da métrica das rotas que é utilizada quando um mesmo protocolo de roteamento aprende mais de uma entrada para o mesmo caminho. Assim como a AD, a menor métrica é a que irá ser inserida na tabela de roteamento. No momento de inserir as rotas na tabela o roteador segue quatro passos para garantir que a ou as melhores entradas sejam escolhidas:


  

 






  




Página 19  



 


1. Verifica para cada rota aprendida se o próximo salto é válido, caso não seja a rota é descartada. 2. Se mais de uma rota é aprendida pelo mesmo protocolo de roteamento o roteador irá inserir a com menor métrica na tabela de roteamento. Se houver balanceamento de carga ativado rotas com mesma métrica podem ser inseridas na tabela de roteamento conforme configuração. 3. As rotas são consideradas idênticas se possuem o mesmo prefixo e máscara, rotas como 10.0.0.0/16 e 10.0.0.0/24 são inseridas separadamente na tabela de roteamento, porém o roteamento dos pacotes é feito pela máscara com o prefixo mais longo, ou UM node prefixo. 4. Se seja, mais mais de umBITS protocolo roteamento anunciar rotas idênticas será inserido na tabela de roteamento a entrada com menor distância administrativa. Toda a análise feita acima é para decidir que rota entra na tabela de roteamento. A partir desse momento vamos analisar que rota um pacote vai utilizar considerando que a tabela de roteamento já está devidamente montada e populada. Uma vez inserida a rota na tabela de roteamento, qual será o caminho que determinado pacote irá seguir? Por qual rota o roteador irá encaminhar seus pacotes? No CCNA R&S a resposta era relativamente simples, aqui no CCNP ROUTE vamos ver que existem várias possibilidades, porém vamos analisar com os conceitos conforme o CCNA nesse momento. O primeiro ponto é que os roteadores encaminham os pacotes analisando o endereço IP de destino dos pacotes e sempre será escolhida a rota com maior prefixo (logest match) para o encaminhamento. Por exemplo, veja a tabela de roteamento abaixo: dltec#sho ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate defau lt, U - per-user static route o - ODR, P - periodic downloaded stati c route, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is 192.168.1.1 to network 0.0.0.0 S* S S S

C C

0.0.0.0/0 [1/0] via 192.168.1.1 10.0.0.0/8 is variably subnetted , 3 subnets, 3 masks 10.0.0.0/8 is directly connected, FastEthernet0/0 10.0.0.0/16 [1/0] via 192.168.1.1 10.0.0.0/24 [1/0] via 192.168.2.2 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

192.168.1.0/24 is directly connected, FastEthernet0/0 192.168.2.0/30 is directly connected, Serial0/0

Se um pacote com endereço de destino 10.0.0.10 for recebido por uma das interfaces do roteador como o roteador fará o encaminhamento? Temos três rotas apontando para a rede 10.0.0.0, a primeira com um prefixo /8, a segunda com um prefixo /16 e a última com um /24. Se compararmos o endereço de entrada com as redes na tabela de roteamento a rota 10.0.0.0/24 é a que tem o prefixo mais longo, pois os três primeiros octetos estão com bit um na máscara de sub-rede, por isso essa será a rota escolhida pelo roteador, ou seja, será enviada para o próximo salto 192.168.2.2 através da serial 0/0.


  

 






  




Página 20  



 


Normalmente em redes de maior porte podemos encontrar roteadores onde mais de um tipo de protocolo de roteamento está configurado, portanto é muito importante entender como o roteador escolhe as rotas para inserir na tabela de roteamento e também uma vez escolhidas as rotas como os pacotes serão encaminhados! 1.6 Revisão Prática de Roteamento IP Se você lembrar do CCNA, basicamente os roteadores podem aprender caminhos em uma rede IP de quatro maneiras (no CCNP ROUTE veremos que existem mais opções!): Via Rota Diretamente Conectada e UP/UP R1(config)#interface fast 0/0 R1(config-if)#ip address 192.168.1.1 255.255.255.0 R1(config-if)#no shut

Quando configuramos o IP em uma interface e ela fica Up/Up uma rota é inserida na tabela de roteamento automaticamente indicando que a rede configurada naquela interface está diretamente conectada a ela. Esta rota é identificada com a letra “C” na frente da rota. Dizemos que esse tipo de rota é uma “Rota Diretamente Conectada”. Via Rota Estática R1(config)#ip route rede mask gateway/interface [Adm-distance]

As rotas estáticas são inseridas e alteradas manualmente por um administrador de rede. Elas consomem pouca memória e processamento do roteador, porém em casos de alteração da topologia da as rede é necessárioem umtodos grande esforço de configuração parte do administrador para alterar configurações os equipamentos, pois tudopor é feito manualmente. Rotas estáticas são recomendadas em redes “stub”, ou seja, com apenas uma saída possível. Elas são identificadas com uma letra “S” na frente da rota. Via Roteamento Dinâmico R1(config)#router rip/igrp AS/ospf process-ID/eigrp AS/bgp AS

Via Gateway padrão R1(config)#ip route 0.0.0.0 0.0.0.0 gateway/interface R1(config)#ip default-network rede (Retirada da revisão atual - CCNP 2.0)

Normalmente uma rota padrão é configurada através de uma rota estática e um asterisco identifica que aquela rota é a rota padrão ou “Gateway of Last Resort”, por exemplo, uma rota padrão configurada com rota estática é identificada com um “S*”. Portando de roteamento, seja ele estático oude dinâmico, tem aIP finalidade de instalar uma “rotao” processo para um determinado “destino ” na “tabela roteamento ” do roteador. Antes de continuarmos a estudar como inserir rotas vamos fazer um estudo do que a tabela de roteamento nos fornece de informações. Veja na figura abaixo a saída do comando “show ip route”.


  

 






  




Página 21  



 


Note que logo após o comando temos uma legenda com o tipo a fonte de aprendizado daquela rota, veja os principais tipos de fontes abaixo:     

C: diretamente conectada (uma rede IP configurada em uma interface que está UP/UP). S: rota inserida manualmente ou estática. R: rota aprendida pelo RIP. D: rota aprendida pelo EIGRP. O: rota aprendida pelo OSPF.

Logo abaixo temos a frase “Gateway of last resort is not set”, a qual significa que não existe roteador padrão (gateway) configurado. Nesse caso se chegar um pacote com um destino que não esteja especificado na tabela, esse pacote será descartado ou “dropado”. Quando temos uma rota padrão configurada nesse campo é mostrado o IP do gateway. Logo abaixo do gateway padrão temos as rotas. Note que na primeira linha temos uma rota para uma rede diretamente conectada, nesse caso o roteador avisa com a frase “is directly connected” e depois da vírgula indica qual interface ela está conectada. Quando vemos esse tipo de rota quer dizer que aquela interface, nesse exemplo a serial1, tem um IP da rede 192.80.209.0 configurado nela e a interface está UP/UP. Para ver o IP que está configurado na interface podemos utilizar o comando “show ip interface brief”. Nas versões 15 do IOS da Cisco ele apresenta também uma rota chamada local (indicada por um L) com o IP da interface com máscara /32 para facilitar o troubleshooting. Agora vamos para a última linha do comando que está em destaque, onde o roteador mostra uma rota aprendida pelo RIP. Note que quando a saída da tabela de roteamento é referente a um protocolo de roteamento dinâmico muitas outras informações são mostradas. Temos os seguintes parâmetros: 200.20.94.0 /24 -> rede de destino. Apostila/E-B     

  

 






  




Página 22  



 




 

[120/1] -> 120 é a distância administrativa e 1 é a métrica (veremos mais tarde o que significam esses parâmetros). Via 192.80.209.13 -> é o IP do próximo salto, ou seja, o IP do vizinho por onde o roteador enviará os pacotes destinados à rede 200.20.94.0/24. 00:00:04 -> tempo em que essa rota foi aprendida, nesse exemplo a quatro segundos. Serial 1 -> a interface local que será utilizada para encaminhar os pacotes à rede 200.20.94.0/24. Com esse parâmetro e o “via 192.80.209.13 sabemos que a interface serial 1 do roteador local, o qual você executou o show ip route, está conectado com um roteador com IP 192.80.209.13.

Além disso, em algumas situações quando temos sub-rede você pode ter rotas primárias e secundárias. As rotas primárias indicam somente que uma rede classe A, B ou C foi “subnetada” (subnetted ou foi quebrada em sub-redes), não sendo utilizada para encaminhar rotas. Somente as rotas com uma letra na frente são utilizada para encaminhamento. Veja o exemplo na figura abaixo, perceba que acima da rota com o R indicando que ela foi aprendida pelo RIP temos a frase “192.168.1.0/30 is subnetted, 3 subnets”, a qual é somente uma indicação que esta rede foi dividida em sub-redes e temos 3 sub-redes, a 192.168.1.0, 192.168.1.4 e 192.168.1.8.

O comando "clear ip route" em modo privilegiado pode ser utilizado para apagar uma todas as entradas da tabela de roteamento (RIB - Router Information Base) e da FIB (Forwarding Information Bases - tabela montada pelo CEF) e fazer com que elas sejam remontadas do zero. 1.7 Qual a Melhor Forma de Migrar o Protocolo de Roteamento de uma Rede em Operação? Quando temos uma rede em operação e precisamos migrar um protocolo de roteamento para outro seja ele qual for temos que tomar cuidado porque cada um tem suas características e parâmetros específicos. Por exemplo, sua rede roda com RIP versão e você precisa trocar o protocolo para o EIGRP. O que ocorre se você começar a subir o EIGRP nos roteadores por padrão? Pense um pouco? A resposta vai estar na próxima página.


  

 






  




Página 23  



 


Se a sua resposta foi que o RIP entre os vizinhos EIGRP que estiverem corretamente configurado vai sair da tabela de roteamento era isso mesmo que deveria ser sua primeira preocupação. Portanto você pode ter problemas sérios ao fazer isso, porque algo pode dar errado e você está fazendo a troca em tempo real. Nesses casos o aconselhável é fazer uma alteração no valor da distância administrativa do EIGRP, colocando maior que 120 que é a do RIP. Assim todos os vizinhos podem aprender as informações do EIGRP e você pode verificar todas as tabelas do EIGRP para garantir que tudo vai estar funcionando corretamente após voltar a distância administrativa do EIGRP para o padrão e remover de vez o RIPv2 da configuração dos roteadores. Vamos aprender a alterar a distância administrativa dos protocolos de roteamento ao decorrer do curso, fique tranquilo... Outra forma de fazer a migração é por etapas, por exemplo, iniciando pelo Core depois indo para distribuição e acesso. Nesse caso vamos ter que fazer o novo protocolo conviver com o antigo através do uso de redistribuição, que também vamos estudar mais a fundo posteriormente. Basicamente a redistribuição permite que rotas aprendidas por um protocolo sejam ensinadas a outro domínio de roteamento, permitindo a coexistência dos dois protocolos e a migração gradual da rede. Por último, a cada capítulo você vai estudar que os protocolos tem parâmetros e configurações específicas que no momento de uma migração precisam ser verificados. Por exemplo, a métrica do RIP é salto e você tem uma interface de menor velocidade seja escolhida entre doisrealizada roteadores porque tem menor saltovocê e é também mais confiável (suposição), caso da migração a ser for para o EIGRP ou OSPF precisará ajustar ounosenão eles escolherão normalmente a rota com maior largura de banda e essa interface não será escolhida como principal. Outros parâmetros como valores de K (métrica) do EIGRP devem ser iguais nos roteadores vizinhos ou então temporizadores de Dead e Hello no OSPF podem fazer com que vizinhanças não sejam estabelecidas, por isso a migração deve ser analisada com cuidado e de preferência feita gradualmente.


  

 






  




Página 24  



 


2 Encaminhando Pacotes - Process Switching, Fast Switching e CEF O processo de roteamento clássico é a ação do roteador receber um pacote, analisar seu endereço IP de destino, verificar em sua tabela de roteamento se existe uma rota, remontar o quadro de camada 2 e encaminhar esse pacote pela interface de saída definida nessa rota. Veja a figura abaixo com um diagrama resumido do processo de roteamento.

Se não houver uma rota explícita definida na tabela de roteamento, o roteador verifica se existe uma rota padrão (Gateway of last resort) e encaminha para a saída definida nessa rota ou então, se não houver a rota padrão configurada, ele simplesmente descarta o pacote e envia uma informação de destino inalcançável (destination unreacheable) através do ICMP para o host de srcem. Este é o processo mais simples de roteamento chamado Process Switching, onde a CPU é envolvida a todo o momento para ler e decidir para que interface encaminhar o pacote IP. Veja o fluxo detalhado do encaminhamento de um pacote utilizando o Process Switching na figura abaixo. No exemplo abaixo um computador conectado à LAN do R3 envia um pacote para o host conectado à LAN do R1.


  

 






  




Página 25  



 


Os passos que o roteador segue para fazer o roteamento por padrão seguem a sequência conforme mostrado na figura. Veja abaixo a explicação de cada passo: 1. O quadro de camada 2 é recebido pela Interfaces Eth 0/0 do roteador e se o FCS (checksum de camada 2) estiver correto ele é processado, caso contrário ele é descartado. Vamos supor que o quadro está com o FCS correto e passa para a próxima etapa. 2. Agora o quadro de camada 2 (Ethernet) é removido e o pacote IP é enviado para a camada de rede do roteador R3. 3. O roteador na R3 tabela verifica IP de destino do pacote IP e procura mais específico deoroteamento para poder encaminhar o pacotepelo para prefixo uma interface de saída, ou seja, verifica a melhor rota para encaminhar o pacote sempre pela máscara de sub-rede ou prefixo mais longo (longest match - quanto mais bits “1” na máscara melhor o caminho). O pacote então é encaminha para a interface de saída. Como o IP de destino é o 172.31.11.201 o roteador verifica que a há uma rota de saída através da sua serial 0 que está diretamente conectada ao IP 172.31.13.1 do seu roteador vizinho. 4. Como foi encontrada uma saída viável para o pacote IP um novo quadro de camada 2 precisa ser remontado conforme o tipo de interface de saída (nesse caso utilizando o encapsulamento conforme protocolo HDLC). Nessa etapa o roteador verifica e prepara as informações de camada 2 para a etapa final de encapsulamento e envio pela camada física. 5. O pacote IP é atualizado com o incremento do campo de TTL e tem seu checksum recalculado, pois o TTL foi alterado. 6. O pacote IP é encapsulado dentro do novo quadro de camada 2 (nesse caso um quadro HDLC) e encaminhado para a camada física através da interface serial 0. Uma vez recebida à informação pelo roteador R1 ele seguirá o mesmo processo para encaminhar o pacote recebido na interface serial para sua LAN, para que assim o host de destino seja alcançado. Outra forma de analisar é utilizando as camadas ou "planes" que são divididas em três unidades funcionais: Control plane: decisões de roteamento e encaminhamento de pacotes, por exemplo, o roteador tem que decidir qual interface utilizar para encaminhar um pacote ou a operação de um protocolo de roteamento são funções realizadas no control plane. Data plane: encaminhamento dos quadros e pacotes, por exemplo, quando um usuário envia um tráfego para um servidor em uma rede remota esses pacotes deverão cruzar o data plane para chegar ao destino. Management plane: utilizado em sessões de gerenciamento, por exemplo, quando acessamos um roteador via Telnet ou SSH através da VTY. 





Podemos então dizer que os pacotes chegam para o Data Plane na interface de entrada (Ingress Interface) e são encaminhadas para o Control Plane, onde a CPU vai tomar a decisão de encaminhamento. Uma vez escolhida a interface de saída (egress Interface) o pacote é encaminhado para essa interface e enviado para seu vizinho conforme decisão de roteamento. O comando "no ip route-cache" ativa o process switching por interface. 2.1 Fast Switching O Fast Switching foi criado para agilizar o processo de verificação do melhor caminho e encaminhamento para a interface de saída quando temos fluxos repetidos de pacotes, pois quando temos pacotes de uma mesma srcem e mesmo destino a consulta feita é igual e repetida.


  

 






  




Página 26  



 


Portanto, o primeiro pacote aciona a criação de uma entrada no Fast-switching cache (router cache) que agiliza o processo de encaminhamento, porém continua utilizando a CPU para essas verificações. Utilizando os Planes podemos dizer que o pacote chega da mesma maneira pelo Data Plane que encaminha a informação para o Control Plane que vai fazer uma operação de process switching apenas no primeiro pacote. Depois disso a informação é gravada no Data Plane uma espécie de "tabela" (router cache) que será utilizada para o encaminhamento na próxima vez que o mesmo tráfego chegar na Interface de Entrada. Isso reduz drasticamente o uso da CPU em comparação com o process-switching. O comando "ip route-cache" ativa o fast-switching por interface. 2.2 CEF - Cisco Express Forwarding Já quando utilizamos o CEF (Cisco Express Forwarding) o roteador cria duas tabelas e as mantém no Data Plane, as tabelas são: Forwarding Information Base (FIB): guarda as informações de camada-3 (L3 ou Layer-3). Adjacency Table: guarda as informações de camada-2 (L2 ou Layer-2). 



Se formos fazer uma comparação bem simplificada é como se o roteador utilizando o Process Switching tivesse que calcular manualmente tudo o que ele precisa para fazer o encaminhamento dos pacotes, isso tudo para cada pacote recebido, ou seja, um a um. Já com o Fast Switching ele utiliza uma memória de cálculo, onde ele faz a conta uma vez quando recebe o primeiro pacote e depois lembra as respostas para os próximos pacotes que vêm na sequência (cache). Por último, quando o roteador utiliza o CEF para encaminhar os pacotes é como se jáeledátivesse uma planilha doacelerando Excel e quando os números sãotodo. inseridos nas células essa planilha o resultado calculado, o processo como um Portanto tanto o CEF quanto o Fast Switching visam economizar tempo e processamento nas etapas 3 e 4 do processo de roteamento, ou seja, na pesquisa da melhor rota na tabela de roteamento e também no levantamento dos dados para montagem do quadro de camada 2. As tabelas FIB e de adjacências são montadas a partir da tabela de roteamento e também do cachê ARP do roteador, evitando consultas à CPU e fazendo um roteamento muito mais eficiente, pois não há necessidade como no fast-switching de processar o primeiro pacote e sim TODO o fluxo é encaminhado diretamente pelo Data Plane. Muitos roteadores e versões de Cisco IOS tem o CEF habilitado por padrão, mas se for necessário o comando "ip cef" ativa o CEF em modo global. Se for necessário ativar o CEF por interface utilize o comando "ip route-cache cef". Veja exemplo abaixo. DlteC#conf t Enter configuration commands, one per line.

End with CNTL/Z.

DlteC(config)#ip cef DlteC(config)#int f0/0 DlteC(config-if)#ip route-cache cef

Com o comando "show ip interface [x/y]" podemos verificar se o CEF está ativo ou não, veja exemplo abaixo: DlteC#show ip interface fastEthernet 0/0 FastEthernet0/0 is up, line protocol is up Internet address is 192.168.10.2/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory


  

 






  




Página 27  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are never sent ICMP unreachables are never sent ICMP mask replies are never sent IP fast switching is enabled IP fast switching on the same interface is disabled IP Flow switching is disabled IP CEF switching is enabled ####Saída Omitida #####

Agora vamos desativar o CEF e ativar o Process-switching na mesma interface utilizada no exemplo anterior e ver o resultado dos comandos: DlteC#conf t Enter configuration commands, one per line. DlteC(config)#int f0/0 DlteC(config-if)#no ip route-cache DlteC(config-if)#do sho ip interface f0/0 FastEthernet0/0 is up, line protocol is up Internet address is 192.168.10.2/24 Broadcast address is 255.255.255.255

End with CNTL/Z.

Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are never sent ICMP unreachables are never sent ICMP mask replies are never sent IP fast switching is disabled IP fast switching on the same interface is disabled IP Flow switching is disabled IP CEF switching is disabled IP Null turbo vector IP multicast fast switching is disabled IP multicast distributed fast switching is disabled

####Saída Omitida ####


  

 






  




Página 28  



 


Outro comando que podemos utilizar com o CEF configurado nas interfaces é o "show ip cef", o qual mostra a FIB do roteador. Com esse comando temos três colunas com os prefixos (Prefix) aprendidos, o próximo salto (Next Hop) e a Interface, veja exemplo do comando abaixo. DlteC#show ip cef Prefix 0.0.0.0/0 0.0.0.0/8 0.0.0.0/32 10.10.10.10/32 127.0.0.0/8 192.168.1.0/24 192.168.1.0/32 192.168.1.1/32 192.168.1.5/32 192.168.1.11/32 192.168.1.12/32 192.168.1.18/32 192.168.1.31/32 192.168.1.45/32 192.168.1.67/32 192.168.1.69/32 192.168.1.70/32 192.168.1.253/32 192.168.1.255/32 192.168.2.0/24 192.168.2.0/32 192.168.2.1/32 192.168.2.20/32 192.168.2.21/32 192.168.2.22/32 192.168.2.255/32 192.168.10.0/24 192.168.10.0/32 192.168.10.1/32 192.168.10.2/32 192.168.10.255/32 224.0.0.0/4 224.0.0.0/24 240.0.0.0/4 255.255.255.255/32 DlteC#

Next Hop 192.168.10.1 drop receive receive drop attached receive receive attached attached attached attached attached attached attached attached attached attached receive attached receive receive attached

Interface FastEthernet0/0

attached attached receive attached receive attached receive receive drop receive drop receive

FastEthernet0/1.30 FastEthernet0/1.30 FastEthernet0/1.30 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0

Loopback1 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.10 FastEthernet0/1.30 FastEthernet0/1.30 FastEthernet0/1.30 FastEthernet0/1.30

Note a primeira linha marcada para a rede 0.0.0.0/0, que é a saída para Internet, o Next Hop (próximo salto) é o endereço IP remoto 192.168.10.1 e sai via interface fast 0/0. Logo a seguir tem uma regra que toda rede 0.0.0.0/8 deve ser "dropada" ou descartada (marcada como "drop"), pois a única opção de uso dessa rede é como saída para Internet. Quando na coluna "next hop" tivermos a informação "attached" significa que é uma rede diretamente conectada ao roteador, por exemplo, a rede 192.168.1.0/24 é uma rede diretamente conectada a sub-interface f0/1.10. Se nessa mesa coluna tivermos a informação "receive" quer dizer que esse endereço IP está configurado em uma das interfaces do roteador local, por exemplo, a rede 192.168.1.1/32 é o endereço IP da interface fast0/1.10.


  

 






  




Página 29  



 


No comando "show adjacency" do Cisco Express Forwarding podemos verificar a "adjacency table" ou "hardware Layer 3-switching adjacency table", em português tabela de adjacências que relaciona os endereços de camada-3 com o MAC. Veja exemplo abaixo. DlteC-FW-GW#show adjacency Protocol Interface IP FastEthernet0/0 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP FastEthernet0/1.10 IP NVI0 IP FastEthernet0/1.30 IP FastEthernet0/1.30 IP FastEthernet0/1.30 DlteC-FW-GW#

Address 192.168.10.1(9) 192.168.1.5(6) 192.168.1.12(6) 192.168.1.20(6) 192.168.1.21(6) 192.168.1.22(6) 192.168.1.31(6) 192.168.1.90(6) 192.168.1.92(6) 192.168.1.253(6) point2point(2) 192.168.2.22(6) 192.168.2.23(6) 192.168.2.24(6)

Podemos encontrar na tabela de adjacência vários tipos de entradas listadas, seguem alguns exemplos abaixo: Null adacency: pacotes endereçados à interface nula (null interface). Drop adjacency: pacotes que serão “dropados” (descartados) pelo switch porque não podem ser encaminhados, por exemplo, por falha no encapsulamento ou o protocolo não foi reconhecido. Podemos ver os pacotes descartados com o comando “show CEF  





drop”. adjacency: pacotes marcados para descarte devido a ACL ou política Discard configurada no switch. Punt adjacency: pacotes que precisam ser enviados para o L3 Engine tratar. Podemos listar essa quantidade por razão de apontamento para a L3 Engine no comando “ show CEF not-switched” ou “show (ip|ipv6) cef switching statistics [feature]” (para IPv4 “show ip CEF switching statistics ”.

Quando uma adjacência está incompleta (marcada como incomplete) pode ser que o roteador não conseguiu utilizar o ARP para descobrir o MAC do vizinho ou então que o comando "clear adjacency" foi digitado e o roteador não conseguiu limpar aquela vizinhança. Em ambos os casos a informação do ARP está incompleta na tabela de adjacências. Outro comando possível de ser utilizado com o CEF é o "show adjacency detail" que mostra com detalhes como alcançar uma determinada adjacência na tabela FIB. Veja no exemplo abaixo que o endereço IP 192.168.10.1 pode ser alcançado via Interface Fast0/0, também note que a informação ARP é colocada no final, pois trata-se de uma interface tipo ethernet. Veja exemplo a seguir. DlteC#show adjacency detail Protocol Interface IP FastEthernet0/0

Address 192.168.10.1(9) 76353388 packets, 18303524109 bytes epoch 0 sourced in sev-epoch 1 Encap length 14 00223F3DD916001E130B1AEE0800 ARP


  

 






  




Página 30  



 


3 Modelos de Design de Rede Atualmente estamos passando pela fase da integração ou convergência das redes em uma única infraestrutura que inclui voz, vídeo, dados, gerenciamento de rede, tráfego de roteamento, diversos tipos de aplicações e aplicativos de usuários, e muito mais. Cada tipo de tráfego exige uma performance diferente quando tratamos de largura de banda, atraso e variação no atraso (bandwidth, delay e jitter), assim como cada um desses tráfegos têm seus próprios requisitos de segurança. Por exemplo, o tráfego de Web é robusto, pouco sensível a atraso ou perda de pacotes, pois ele trabalha com TCP e não exige tráfego em tempo real (real time). Já o tráfego de voz ou vídeo precisa de largura de banda dedicada, assim como são sensíveis ao atraso, à variação do atraso (jitter) e a perda de pacotes. Portanto os designs de rede devem prover um framework para integrar cada diferente tipo de tráfego dentro da mesma rede e, para isso, ao longo dos anos foram desenvolvidos alguns modelos para que fosse possível entender e projetar uma rede e seu fluxo de dados de maneira a facilitar o entendimento em topologias mais complexas. Os modelos que permanecem nessa revisão do CCNP ROUTE são:  

Modelo hierárquico tradicional (três camadas) Enterprise Composite Model (modelo empresarial composto)

3.1 Modelo Hierárquico em Três Camadas Esse é o modelo tradicional e mais utilizado até os dias de hoje em projetos de redes mais complexas, dividindo a rede em três camadas: Acesso, Distribuição e Núcleo (Access, Distribution e Core). Veja a figura abaixo.

Nessa topologia temos um campus com switches de acesso em seus andares, os quais são agregados nos switches de distribuição em cada edificação, normalmente switches layer-3. Esses switches de distribuição dos diversos prédios são agregados em um ou mais switches de núcleo, conforme a necessidade de redundância e porte da rede. Essa mesma topologia, que no exemplo acima usamos em uma LAN, pode ser aplicada a rede WAN onde a Matriz (Headquarter) seria o núcleo, Unidades Regionais (Division Headquarter) seriam a distribuição e o acesso estaria nas Unidades Remotas (Branch Offices). Veja a figura a seguir.


  

 






  




Página 31  



 


Resumindo, as funções de cada camada são:  



Acesso - Access Layer: Fornece conectividade aos grupos de trabalho e estações. Distribuição - Distribution Layer: Faz a conectividade entre as diversas camadas de acesso intermediando os dados entre as diferentes redes baseado em políticas. Núcleo - Core Layer: Fornece chaveamento rápido entre os diversos switches de distribuição.

A vantagem desse modelo é a possibilidade de termos links de backups na camada de acesso, assim como links e equipamentos backups nas camadas de distribuição e núcleo, o que possibilita um modelo altamente redundante, ou seja, com uma alta disponibilidade (tolerante a falhas – fault tolerant). A desvantagem desse modelo é de não definir todos os aspectos de uma rede, tais como onde dispositivos sem fio devem estar posicionados, como o acesso à Internet e a parte de segurança envolvida deve ser provisionada, como o acesso a usuários remotos deve ser fornecido, ou seja, é um modelo de topologia focado em uma estrutura mais convencional. 3.2 Enterprise Composite Model Este é um novo modelo de design proposto pela Cisco, o qual trata dos pontos não endereçados pelo modelo hierárquico, especificando e recomendando como e onde certas funções devem ser implementadas na rede. Este modelo faz parte do modelo de referência chamado Security Architectures for the Enterprise ou SAFE, que traz melhores práticas, recomendações e configurações para o desenho e implementação de redes com segurança. Este modelo divide a rede em módulos (blocos) para facilitar o entendimento e projeto da rede: 

 



Enterprise Campus: switches e dispositivos que compõe a LAN da empresa e fornecem acesso aos dispositivos dos usuários, fornecendo acesso de voz, dados e vídeos corporativos. Enterprise Core: este módulo integra os diversos módulos da topologia de rede. Intranet Data Center: módulo capaz de agregar um grande número de sistemas com a finalidade de prover as diversas aplicações corporativas e armazenar grandes volumes de dados. Enterprise Internet Edge: este módulo, como o nome já diz, provê a conexão da Intranet (privada) com a Internet (pública), atuando como gateway entre a rede interna e o restante do mundo exterior.


  

 






  




Página 32  



 






Enterprise WAN Edge: é a parte da infraestrutura de rede que agrega os links de WAN que conectam filiais geograficamente distantes a um site central, utilizada para conectar as unidades remotas à matriz. Enterprise Branch: fornece conectividade para usuários e dispositivos remotos, os quais normalmente conectam-se ao site central através de uma VPN através da Internet. Management: parte da infraestrutura dedicada ao gerenciamento de redes.

Na realidade, nesse modelo continuamos utilizando o conceito de uma rede hierárquica, aproveitando sua tolerância a falhas, porém adicionando detalhes que não existiam. Por exemplo, note na figura seguinte onde no Enterprise Campus temos as conexões dos switches com referência no modelo hierárquico, porém adicionando nome e funções a cada uma das partes:      

Campus Backbone: o core da rede LAN Building Distribution: camada de distribuição da LAN Building Access: camada de acesso da LAN Management: gerenciamento de rede fora da banda (out-of-band) Server Farm: para conectar servidores corporativos Edge Distribution: camada de distribuição para conectar a serviços de WAN


  

 






  




Página 33  



 


Os serviços de Internet e conexão com outras redes como a de Telefonia convencional (PSTN) podem ser realizados através do Service Provider Edge, uma agregação da Enterprise Internet Edge, Enterprise WAN Edge e Enterprise Branch, conforme mostramos a seguir. Nessa composição temos os blocos WAN, E-commerce (servidores corporativos que serão acessados via Internet por clientes internos e externos), Internet e Remote Access (acesso remoto a unidades e usuários).

Como você pode perceber a complexidade da rede e seus blocos integrantes aumenta de acordo com o porte da empresa e no que tange a escolher os protocolos de roteamento para essa arquitetura vai depender do que estudamos anteriormente. Por exemplo, no bloco da Internet e E-Commerce, se a empresa for um sistema autônomo precisaremos utilizar o BGP-4 para conectar com os outros ASs e ISPs vizinhos com quem vamos trocar tráfego. Já na rede Interna podemos utilizar o OSPF se roteadores de outros fabricantes forem utilizados ou então o EIGRP se a rede for toda Cisco. Podemos agora juntar todas as peças e formar uma topologia complexa, porém projetada e implementada de maneira segura conforme previsto na filosofia SAFE da Cisco, conforme mostrado na figura a seguir, dividindo a rede em Enterprise Campus (a Intranet), Enterprise Edge (a parte que está conectando a rede Interna com o mundo exterior ou unidades remotas através da WAN) e o Service Provider Edge, o qual conecta a rede ao mundo público dos provedores de serviço de WAN, Internet, Telefonia e demais serviços de comunicação. Note que toda a divisão feita tem como base o modelo em três camadas, sendo várias distribuições e acessos conectados a um núcleo (core) único, porém cada um deles ocupndo um espaço distinto no design de rede.


  

 






  




Página 34  



 



  

 






  




Página 35  



 


4 Conceitos Avançados de TCP/IP Lembre-se do CCNA R&S onde o os protocolos que dão o nome a pilha TCP/IP estão respectivamente nas camadas 4 e 3, ou seja, o protocolo IP (Internet Protocol) está na camada de rede (layer 3) e o TCP (Transmission Control Protocol) está na camada de transporte (layer 4), assim como o UDP (User Datagram Protocol) também está na camada de transporte. O CCNA traz bastante informação sobre o assunto, porém nessa versão do CCNP ROUTE vamos estudar alguns conceitos com maior profundidade para que você possa enfrentar os desafios que esse nível de certificação profissional vai exigir na sua vida prática. 4.1 Protocolo IP e seus Desafios O protocolo IP nas suas duas versões atuais (IPv4 e IPv6) é um protocolo roteado responsável pelo endereçamento de camada-3 que possibilita o roteamento tanto localmente como entre redes remotas. Dentro do cabeçalho ou header do protocolo IP são transportadas as informações de controle, endereços de srcem e destino e informações das camadas superiores, como segmentos TCP ou datagramas UDP. Abaixo segue o cabeçalho do protocolo IP versão 4 e logo abaixo a descrição dos campos.

 





  

Versão: Definido como 4. IHL: Comprimento do Cabeçalho da Internet com o número de palavras de 32 bits no cabeçalho IPv4. Tipo de serviço: Definido na RFC 791 e define o tipo de serviço (ToS – Type of Service), agora DiffServ e ECN utilizados para definir marcação de QoS. Tamanho total: Define todo o tamanho do datagrama incluindo cabeçalho e dados. O tamanho mínimo do datagrama ou pacote IP é de vinte bytes e o máximo é 64 Kbytes, porém o MTU mínimo que os hosts precisam suportar é de 576 bytes. Se os pacotes ultrapassarem o MTU precisam ser "fragmentados", ou seja, quebrados em pedaços menores para caberem dentro do tamanho máximo do protocolo do caminho. No IPv4 a fragmentação pode ser feita pelos computadores ou diretamente nos roteadores. Identificador: Usado principalmente para identificar fragmentos do pacote IP srcinal. Flags: Usado para controlar ou identificar fragmentos. Offset do fragmento: permite que um receptor determine o local de um fragmento em particular no datagrama IP srcinal. Apostila/E-B

    

  

 






  




Página 36  



 








 

Tempo de vida: Chamado de TTL (time to live) ajuda a prevenir que os pacotes IP entrem em loop na rede. Utilizado para o teste de traceroute. É decrementado de um a cada salto que passa e o valor inicial é definido pelo sistema operacional que srcinou o pacote IP. Protocolo: Define o protocolo que será transportado no pacote, sendo que os protocolos comuns e os seus valores decimais incluem o ICMP (1) e o TCP (6). Checksum: Campo de verificação de erros para o cabeçalho do datagrama IPv4. Cobre apenas verificação do cabeçalho, não dos dados. Endereço de srcem/destino : Campos que trazem os endereços de srcem (transmissor) e deem destino (receptor) Os endereços seus campos divididos 4 conjuntos de de 8 32 bits,bits oucada seja,um. 4 bytes escritos IP emtem decimal pontuado, por exemplo, 192.168.1.1. Opções: Normalmente não utilizados. Dados: Informações das camadas superiores, por exemplo, segmentos TCP ou datagramas UDP.

O cabeçalho do pacote IPv6 é bem mais simples que o do IPv4, contendo apenas 8 campos principais e caso serviços adicionais sejam necessários existem extensões de cabeçalho que podem ser utilizadas. O cabeçalho (header) básico está na figura abaixo.

A descrição de cada campo segue abaixo:  



 







Version (versão - 4 bits): Contém o valor para versão 6. Priority ou Traffic Class (classe de tráfego - 8 bits): Um valor de DSCP para QoS (qualidade de serviços). Flow Label (identificador de fluxo - 20 bits) : Campo opcional que identifica fluxos individuais. Idealmente esse campo é configurado pelo endereço de destino para separar os fluxos de cada uma das aplicações e os nós intermediários de rede podem utilizá-lo de forma agregada com os endereços de srcem e destino para realização de tratamento específico dos pacotes. Payload Length (tamanho do payload - 16 bits): Tamanho do payload em bytes. Next Header (próximo cabeçalho - 8 bits): Cabeçalho ou protocolo que virá a seguir. É utilizado para identificar que existem cabeçalhos de extensão após o principal. Hop Limit (limite de saltos - 8 bits) : Similar ao tempo de vida de um pacote IPv4 (TTL - time to live) utilizado no teste de traceroute e contagem de saltos. Source Address (endereço IPv6 de srcem - 128 bits) : Endereço IP de quem está enviando os pacotes. Destination Address (endereço IPv6 de destino - 128 bits): Endereço IP do host remoto que deve receber os pacotes. Apostila/E-B

    

  

 






  




Página 37  



 


Aqui vem mais uma diferença do IPv6, pois no IPv4 o cabeçalho base continha todas as informações principais e opcionais (mesmo que não fossem utilizadas). Já o IPv6 trata essas informações adicionais como cabeçalhos opcionais chamados de “cabeçalhos de extensão”. Os cabeçalhos de extensão são inseridos entre o cabeçalho base e o cabeçalho da camada imediatamente acima (payload), não tendo nem quantidade ou tamanho fixo. Caso existam múltiplos cabeçalhos de extensão no mesmo pacote, eles serão encadeados em série formando uma “cadeia de cabeçalhos”. A figura abaixo mostra um exemplo dessa situação.

De uma maneira resumida seguem os cabeçalhos de extensão possíveis e seus identificadores: 



 



Hop-by-hop Options (0): Transporta informações adicionais que devem ser examinadas por todos os roteadores de caminho, por isso o nome hop-by-hop que em português significa salto a salto. Routing (43): Definido para ser utilizado como parte do mecanismo de suporte a mobilidade do IPv6. Fragment (44): Indica se o pacote foi fragmentado na srcem. Encapsulating Security Payload (50) e Authentication Header (51): fazem parte do cabeçalho IPSec, utilizados para criptografia do payload. Destination Options (60): Transporta informações que devem ser processadas apenas pelo computador de destino.

Portanto, o cabeçalho do IPv6 além de ser mais simples que o do IPv4, também trata de questões como QoS e segurança de maneira nativa, ou seja, dentro do próprio cabeçalho sem a necessidade de implementações e recursos adicionais como era necessário para o IPv4. 4.1.1 Os Quatro "casts" - Unicast, Multicast, Broadcast e Anycast

Veja abaixo a descrição resumida de cada um dos quatro "casts": 



Unicast  Comunicação um para um. Presente no IPv4 e IPv6, são endereços de host das classes A, B e C no IPv4 e os que iniciam com 2000::/3 no IPv6 (global unicast address). Broadcast  Um para todos. Somente IPv4, são os endereços 255.255.255.255 e o último IP de cada rede/sub-rede classe A, B e C.


  

 






  




Página 38  



 




Multicast  Um para um grupo. Presente no IPv4 e IPv6, são os endereços Classe D no IPv4 e FF00::/8 no IPv6. Anycast  Um para muitos. Somente IPv6, normalmente o primeiro IPv6 (final zero) de um prefixo, porém é configurável.

Para visualizar a diferença e aplicação do uso do unicast para multicast considere a figura abaixo, onde você tem um dispositivo de vídeo que irá transmitir o sinal para três hosts na rede. Caso de a transmissão seja feita utilizando que ser criadosé três fluxos, Já umnopara cada host destino, ocupando mais banda, unicast pois a terão mesma informação triplicada. caso do uso do multicast o transmissor envia as informações para um único endereço que está configurado em todos os hosts que participam do mesmo “grupo de multicast” que ele, portanto a informação é transmitida utilizando apenas um fluxo até os hosts.

O endereço IP de anycast é um endereço que podemos configurar em mais de um dispositivo, portanto ele será anunciado em diferentes roteadores. Mas para que serve o anycast na prática? Uma das respostas e a mais utilizada é para redundância (apesar de que pode ser utilizado para balanceamento de carga). Por exemplo, você tem três servidores DNS e configura o mesmo IP de anycast nos três, porém cada um está conectado por caminhos diferentes (roteadores distintos ou larguras de bandas diferentes). Quando o computador for realizar uma consulta ao DNS ele enviará o pacote para o IP de anycast (destino) configurado em sua placa de rede, porém quando a rede receber o pacote com o endereço de destino sendo um anycast os roteadores encaminharão esse pacote para o melhor destino em relação à srcem. Ou seja, mesmo tendo três servidores com o mesmo IP de Anycast o que tiver melhor métrica em relação ao protocolo de roteamento utilizado é o que receberá a solicitação. Por exemplo, você está utilizando OSPFv3, o qual utiliza um custo como métrica para encontrar o melhor caminho, se um dos servidores tem custo 25 (Server A), o segundo custo 40 (Server B) e o terceiro custo 20 (Server C) qual dos três irá receber a consulta enviada pelo cliente? Com certeza será o que possui menor custo (menor métrica), portanto o Server C receberá os pacotes referentes à consulta de nomes e deverá responder ao cliente.


  

 






  




Página 39  



 


Duas dicas importantes, o IP de anycast não é utilizado como srcem em um pacote IPv6, somente como destino e precisa estar anunciado entre os roteadores (através do protocolo de roteamento) para que possa ser encaminhado conforme exemplo anterior. Portanto não é só configurar um IP, o uso do anycast exige configurações de roteamento na rede. 4.1.2 Pacotes fora de ordem - Out Of Order Packets

A grande vantagem de uma rede IP é sua flexibilidade e a possibilidade de termos vários links entre duas ou mais localidades como redundância de caminho, assim mesmo que um roteador fique isolado o tráfego continuará chegando ao destino. Devido aos vários caminhos que um pacote pode percorrer ele pode chegar fora de ordem no destino, por exemplo, foram enviados os pacotes 1, 2, 3, e 4 e chegam no destino nessa ordem 2, 1, 4, 3. Se estivermos tratando do TCP ele faz o sequenciamento dos seus segmentos e corrige a ordem antes de enviar para a camada de aplicação. Indo além, o TCP é capaz até de solicitar segmentos faltantes através da retransmissão caso o destino não reconheça o recebimento de todos os segmentos enviados. Basta lembrar do CCNA que o TCP inicia com um handshake de três vias que visa sincronizar a srcem e o destino, assim como definir um valor de sequenciamento para os segmentos através do número de sincronização passado pelo SYN. Se você lembrar do CCNA também podemos ativar o balanceamento de cargas entre os links redundantes tanto no RIP como no OSPF e EIGRP. Esse tipo de recurso pode ser configurado por pacote (per packet) ou por fluxo (per flow) e quando ativamos por pacote ele pode gerar a chegada de pacotes fora de ordem também.


  

 






  




Página 40  



 


4.1.3 Roteamento assimétrico

O roteamento assimétrico ou Asymmetric Routing ocorre quando existe mais de um caminho entre srcem e destino e o tráfego de retorno segue um caminho diferente do tráfego de srcem. Veja o exemplo na figura a seguir.

Na realidade o roteamento assimétrico não é um problema, porém pode gerar problemas se no caso do roteador onde os clientes estão conectados você tiver um NAT configurado, por exemplo. Pois a tabela de tradução está vinculada a interface conectada a WAN 1 e quando o retorno vier pela interface da WAN 2 simplesmente os pacotes podem não chegar ao destino. Para o TCP esse tipo de fluxo acaba gerando problemas e ele não terá seu melhor desempenho, gerando um desempenho "sub-ótimo" (suboptimal). Além disso, ferramentas de monitoração e firewalls podem apresentar problemas com esse tipo de comunicação. Outro caso conhecido de problema com roteamento assimétrico é com redes que utilizam o First-Hop Redundancy Protocol (FHRP, por exemplo, HSRP, VRRP ou GLBP) em switches multicamada na distribuição, principalmente quando temos VLANs de acesso espalhadas em diferentes switches de acesso. Esse problema é conhecido também como flooding de Unicast causado por roteamento assimétrico. Veja a figura a seguir e vamos explicar o que acontece.


  

 






  




Página 41  



 


Note que o PC1 envia um pacote através do switch L3 HSRP ativo, portanto o switch SW-DIST1 conhece o MAC do PC-1. Porém, quando o retorno assimétrico é feito e o switch SW-DIST-2 recebe o pacote de retorno ele não conhece o MAC do PC1 e precisa fazer o flooding em todas as interfaces. Além disso, como os switches de acesso não conhecem o MAC do PC-1 eles podem fazer o flooding também em suas portas e virar um verdadeiro "mar de floodings" nessa rede. Para evitar esse tipo de problema é recomendado não utilizar a mesma VLAN em switches de acesso diferentes, porém se isso for inevitável você pode alterar o temporizador do ARP (aging timer) para ser igual ou menor que o aging time da tabela CAM. Lembre-se que o roteador stand-by recebe o IP do PC1 apenas quando ele faz o ARP Request pedindo pelo IP do seu gateway, depois o PC1 comunica-se apenas com o switch HSRP ativo que é SW-DIST-1, portanto o switch SW-Dist-2 não vai ter mais a entrada para PC1 na tabela CAM porque seu timer é menor que o timer do ARP e o switch acaba apagando o MAC da tabela de endereços de camada-2. Com o temporizador do ARP igual ou menor que o aging timer da CAM nunca vai haver uma entrada na tabela ARP que não esteja também armazenada na CAM table. Portanto, quando a entrada ARP for apagada por "time out" ele utilizará o ARP para aprender o endereço MAC do IP de destino, fazendo assim que a CAM table aprenda a porta de saída. 4.1.4 ICMP Unreachable e Redirects

O ICMP ou “Internet Control Message Protocol” é utilizado para que um roteador ou host destino seja capaz de reportar à estação srcem uma condição de erro no processamento de um pacote ou datagrama. O ICMP apenas informa erros ao host de srcem, não tendo qualquer responsabilidade sobre a correção dos mesmos. O ICMP é transmitido diretamente dentro do campo de dados pacote IP identificado pelo código 0x01 no campo protocolo. Seu cabeçalho possui apenas 4 campos, sendo que no campo Type ou Tipo de Mensagem ICMP (1 byte) você encontra o tipo de mensagem que o ICMP está transmitindo, por exemplo, tipo 0 é um echo reply (resposta do ping), tipo 3 é uma mensagem de destination unreachable (destino inalcançável) e tipo 5 é uma mensagem de redirecionamento ou redirect. Veja a figura do cabeçalho a seguir.

Na sequência do campo Type temos o campo chamado Code ou Código da Mensagem ICMP (1 byte), por exemplo, se a mensagem é do tipo 3 ou um destination unreachable existe 16 códigos diferentes para o motivo dessa mensagem, por exemplo, o código 1 significa que o host está inalcançável. Os outros dois campos finais são um checksum (2 bytes) para garantir a integridade do pacote ICMP e um campo de "Rest of Header" (4 bytes) com informações adicionais específicas de cada mensagem.


  

 






  




Página 42  



 


No CCNP ROUTE você precisa conhecer as mensagens que foram estudadas no CCNA como ping e traceroute, porém o foco maior será nas mensagens de Destination Unreachable e Redirect, as quais vamos estudar na sequência. 4.1.4.1 DESTINATIONUNREACHABLE

O Destination Unreachable ou destino inalcançável é utilizado em situações nas quais a entrega de um datagrama pode falhar principalmente pelos seguintes motivos: Queda de um enlace, roteador desligado ou desconectado para manutenção, razões administrativas (segurança), etc. Se a mensagem é enviada por um roteador intermediário, isso significa que ele considerou o endereço IP destino inatingível. Se a mensagem é enviada pelo host destino, isso significa que o protocolo especificado no campo Protocol do datagrama srcinal é inatingível. 





O destination unreacheble pode ter vários outros motivos representados por 15 códigos conforme abaixo e também mostrado na tabela do item 2 desse documento: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

network unreachable – rede inalcançável host unreachable – host inalcançável protocol unreachable – protocolo inalcançável port unreachable – porta inalcançável fragmentation needed but fg not set – a fragmentação é necessária mais o flag de fragmentação não está habilitado source route failed – rota de srcem com problemas destination network unknown – rede de destino desconhecida destination host unknown – host de destino desconhecido source host isolated (obsolete) – esta mensagem está obsoleta destination network adimistrativly prohibited – rede de destino administrativamente desabilitada destination host administratively prohibited - host de destino administrativamente desabilitado network unreachable for TOS – rede inalcançável para o TOS host unreachable for TOS – idem ao anterior para o Host communication administratively prohibited by filtering – caminho bloqueado por filtragem host precedence violation – violação na precedência do host precedence cut-off in effect – corte ou bloqueio por precedência habilitado

Veja na figura a seguir um exemplo de um servidor que está desconectado e um computador tenta acessá-lo, recebendo a mensagem de host inalcançável.


  

 






  




Página 43  



 


Uma causa muito comum de recebermos esse tipo de mensagem é quando existe um firewall ou lista de controle de acesso que está bloqueando o acesso a determinada rede de destino. 4.1.4.2 ICMP REDIRECT

A mensagem de redirecionamento ou redirect é enviada por um roteador a um host da rede local quando ele detecta a existência de uma rota melhor para a rede destino que o host está tentando alcançar. O roteador envia um ICMP redirect requisitando que o host mude sua tabela de roteamento, trabalhar com roteamento sendo quedinâmico. ao recebê-la, o host muda a tabela caso esteja configurado para Esta mensagem está restrita a um roteador e um host na mesma rede, não sendo enviadas para outros roteadores (não são usadas para propagar informações de roteamento). Veja na próxima figura um exemplo de redirecionamento através do ICMP redirect, onde um computador está tentando enviar pacotes para a rede 192.168.1.0 através do Router A, porém existe um melhor caminho se o computador enviar os pacotes diretamente para o Router B, portanto o Router A envia uma mensagem de redirecionamento para que o host envie os pacotes diretamente para o Router B.


  

 






  




Página 44  



 


O redirecionamento via ICMP em alguns casos pode ser utilizado como um ataque, onde um hacker envia uma mensagem de redirecionamento para um computador para que ele encaminhe seus pacotes para um roteador ou computador que está comprometido para fins de espionagem ou descoberta de usuários e senhas para facilitar ataques mais elaborados. Nas interfaces dos roteadores Cisco o redirecionamento ICMP é permitido, para bloquear essa funcionalidade pode-ser entrar na interface do roteador e digitar o comando “no ip redirects”. 4.1.5 MTU - Maximum Transmission Unit

MTU é o acrônimo a expressão inglesa Maximum Transmission que em português significa Unidade para Máxima de Transmissão , e refere-se ao tamanhoUnit do ,maior datagrama que uma camada de um protocolo de comunicação pode transmitir. Cada tecnologia de camada 2 possui um determinado MTU, por exemplo, o padrão Ethernet tem MTU de 1500 bytes. Em interfaces de baixa velocidade quando maior o MTU maior pode ser o atraso no envio das informações, pois quanto mais bytes para enviar na interface mais tempo leva para que aquele pacote IP saia dela. Ao passo que um MTU baixo pode gerar mais overhead na rede, pois mais cabeçalhos das camadas 2, 3 e 4 terão que ser montados para o envio das informações. O valor do MTU pode ser alterado dentro do modo de interface com o comando "ip mtu", porém você deve tomar cuidado porque isso pode trazer consequências, por exemplo, o OSPF precisa que ambas as interfaces tenham o mesmo MTU para trocar informações de banco de dados, eles até formam vizinhança, chegam até o estado de EXSTART e voltam a cair ficando DOWN assim sucessivamente em loop até que o MTU de ambos os lados sejam corrigidos. 4.1.6 Fragmentação de Pacotes IPv4 e IPv6

Quando oIPpacote IP aé fragmentação muito grande edeultrapassa valor definido da interface o protocolo permite pacotes, opossibilitando quenoumMTU datagrama IP seja dividido em pedaços pequenos o suficiente para poderem ser transmitidos através dessa conexão com o MTU menor que o tamanho datagrama srcinal . Esta fragmentação acontece na camada IP (camada 3 do modelo OSI) e usa o parâmetro MTU da interface de rede que irá enviar o pacote pela conexão. O processo de fragmentação marca os fragmentos do pacote srcinal para que a camada IP do destinatário possa montar os pacotes recebidos, reconstituindo o datagrama srcinal. Indo mais a fundo, os campos Identificador, Flags e Offset do cabeçalho do pacote IP são utilizados quando há fragmentação. No campo Flag temos 3 bits, sendo que o primeiro é sempre zero, o segundo é chamado de DF ou "Don't Fragment" e o terceiro é o MF ou "More Fragments". Quando o DF está setado em 1 significa que o pacote não pode ser fragmentado. Já o MF é utilizado se o DF está como zero (pode fragmentar), aí se há fragmentação ele é setado em 1 para indicar que há mais fragmentos e em zero quando o roteador está enviando o último fragmento e o destino deve remontar o pacote IP. Quando fragmentação campo Identificador uma sequência (se é o primeiro,hásegundo e assimopor diante), depois um indica identificador do pacotedos IP fragmentos para que o destino saiba de quem é aquele fragmento e o tamanho total do pacote IP srcinal antes de ser fragmentado. O campo Offset determina a posição relativa do fragmento em relação ao datagrama srcinal e é sempre utilizado sempre em múltiplos de 8. Veja um exemplo de fragmentação de um pacote com 5140 Bytes que vai ser transportado em uma rede Ethernet que por padrão tem MTU de 1500 bytes. Em uma conta grosseira


  

 






  




Página 45  



 


5140/1500 nos dá que precisamos pelo menos de 4 pacotes de 1500 bytes para transportar essa informação. O primeiro fragmento terá offset igual a 0, pois ele é o primeiro pacote, com um tamanho de fragmento de 1500 já incluindo 20 bytes do novo cabeçalho IP ligeiramente modificado. Ele será marcado com um número de sequência igual a 0. O segundo fragmento terá um offset igual a 185 (185 x 8 = 1480 bytes), o que significa que esse fragmento está 1480 dentro do datagrama IP srcinal. O comprimento do fragmento continua 1500 com os 20 bytes do segundo cabeçalho IP modificado. No terceiro fragmento temos um offset de 370 (370 x 8 = 2960 bytes), que significa que ele inicia 2960 bytes para dentro em relação ao pacote IP srcinal. O tamanho do fragmento é ainda 1500 e mais uma vez inclui o novo cabeçalho do IP modificado para transmissão do fragmento de 20 bytes. No quarto e último fragmento temos um offset de 555 (555 x 8 = 4440 bytes), portanto esse fragmento está 4440 bytes do início do pacote IP srcinal. Agora seu tamanho é de 700 bytes já incluindo o cabeçalho do IP modificado para transporte do fragmento. Somente quando esse último fragmento é recebido que podemos determinar o tamanho do pacote IP srcinal. Nos fragmentos 1, 2 e 3 o flag MF está setado em 1 e no quarto fragmento o bit MF é colocado em zero, pois ele é o último fragmento. Se somarmos o tamanho de todos os fragmentos vamos ver 60 bytes a mais, pois esse é o overhead ou sobrecarga causada pela necessidade de cabeçalhos IPs novos para transmissão dos fragmentos, essa é uma das consequências da fragmentação, a geração de overhead na rede. No datagrama IP srcinal teríamos os seguintes dados nos campos do cabeçalho IP estudados: Sequência Identificador 0 345

Tamanho Total 5140

DF 0

MF 0

Offset 0

Agora veja cada um dos fragmentos como seriam recebidos pelo roteador remoto: Sequência Identificador 0-0 345 0-1 345 0-2 345 0-3 345

Tamanho Total 1500 1500 1500 700

DF 0 0 0 0

MF 1 1 1 0

Offset 0 185 370 555

As consequências negativas da fragmentação são aumento de memória e CPU para processamento dos fragmentos, retenção dos fragmentos em filas ocupando o roteador por mais tempo, a perda de um fragmento gera a necessidade do envio de todos os fragmentos novamente, não existe retransmissão parcial, firewalls que precisam analisar informações de camada 4 ou 7 precisam remontar os fragmentos para analisar o conteúdo ou então escolher simplesmente entre bloquear ou deixar passar os fragmentos, etc. Esses são alguns efeitos negativos da fragmentação. No IPv4 essa fragmentação pode ser feita em qualquer ponto da rede, por exemplo, um pacote com MTU de 1500 ao passar por um link com MTU de 700 bytes pode ser fragmentado somente nesse link, isso tudo sem que a srcem ou destino do tráfego fique sabendo do que ocorreu.


  

 






  




Página 46  



 


Já para o IPv6 a fragmentação não pode ocorrer no meio do percurso, portanto o processo de fragmentação do IPv6 é realizado somente na srcem (no host que está srcinando os dados), o que reduz a sobrecarga dos roteadores intermediários com cálculos dos cabeçalhos. O IPv6 usa o PMTU para descobrir o MTU do caminho e fragmentar os pacotes IP se necessário. Caso haja fragmentação no IPv6 um cabeçalho de extensão deverá ser utilizado, pois as informações de fragmentação não estão mais contidas no cabeçalho principal do IPv6 como no IPv4. As duas maneiras de se evitar fragmentações no IPv4 é através do MSS e do PMTU que vamos estudar na sequência. 4.1.6.1 PATH MTU DISCOVERY- (P)MTU

A norma RFC 1991 descreve o "Path MTU discovery" (PMTU ou PMTUD) para o IPv4, uma técnica para determinar o MTU ideal do caminho entre dois computadores evitando a fragmentação dos pacotes IP quando eles estão transportando segmentos TCP, não sendo suportado pelo UDP ou outros protocolos. Veja na figura a seguir porque a fragmentação ocorre, pois temos um caminho entre dois pontos com três links de MTU diferentes e o MTU mais baixo é o que define o valor máximo que o caminho permite. Se você tentar enviar um pacote de 1500 bytes em um caminho que permite no máximo 800 bytes ele precisará ser fragmentado, ou seja, quebrado em pedaços menores.

Para que haja a fragmentação existe um flag (bit de controle) no protocolo IP chamado DF (don´t fragment) que deve estar desativado, caso este flag esteja habilitado (setado em 1) o roteador não poderá fragmentar o pacote e se ele estiver acima do MTU o roteador irá gerar uma mensagem de erro para o computador de srcem através do ICMP. Portanto, a técnica de descoberta do MTU do caminho (Path MTU Discovery) utiliza um feedback através de mensagem de erro ICMP para o endereço de srcem dos resultados de Fragment) de tentativas ativado. enviar Qualquer datagramas dispositivo de tamanhos que ao progressivamente longo do caminho maiores, necessite comdeo fragmentar bit DF (Don'to pacote irá descartá-lo e enviar uma resposta ICMP de destino inalcançável com o código 4 ou "datagrama demasiado grande" (packet too big) para o endereço de srcem. Através deste teste, o computador de srcem "aprende" qual o valor máximo de MTU que atravessa a rede sem que seja fragmentado. Veja a figura abaixo.


  

 






  




Página 47  



 


A RFC 1981 define o Path MTU Discovery para o protocolo IPv6 e funciona de maneira análoga, porém é realizado apenas na srcem do pacote IP, não sendo possível fragmentar o IP no meio do caminho pelos roteadores. Outra diferença entre o IPv4 e o IPv6 é referente ao envio de pacotes de tamanho elevado, chamados jumbograms. No IPv6 existe uma opção do cabeçalho de extensão hop-by-hop (chamada jumbo payload), que permite o envio de pacotes com cargas úteis (payload) entre 65.536 e 4.294.967.295 bytes de comprimento, o que no IPv4 existia uma limitação de 64Kbytes. 4.1.6.2 TESTANDOMANUALMENTE OMTU DO CAMINHO

COM OPING PARAIPV4

Você pode testar manualmente o MTU do caminho até um determinado destino da Internet a partir do seu computador com o comando ping utilizando as opções “-l” e “-f”.

Com o “-l” você pode definir o tamanho do pacote IP, por exemplo, um “ping 10.0.0.1 –l 1500” define um payload de 1500 bytes para esse pacote do ICMP. Já o “-f” ativa o bit de não fragmentação do pacote (DF), portanto se o pacote for muito grande e precisar de fragmentação com o bit DF ativo você receberá uma mensagem de erro. O teste é simples, faça um ping com tamanho de 1500, o qual é o MTU limite de uma rede do tipo Ethernet e verifique se ele passa, caso haja erro vá diminuindo o valor até chegar ao máximo que você pode enviar para aquele caminho.


  

 






  




Página 48  



 


Veja o teste abaixo feito para o site da Cisco. No exemplo abaixo fizemos um teste iniciando com um pacote de 1500 bytes e fomos diminuindo de 100 em 100 bytes, quando chegamos ao valor de 1200 bytes respondendo ao ping, aí subimos mais 50 bytes e fomos aumentando e diminuindo até chegar ao valor de 1270 bytes de MTU ideal para que não houvesse fragmentação nesse caminho. C:\>ping www.cisco.com -l 1500 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1500 bytes de dados: pacoteprecisa precisa fragmentado, a de sfragmentação está ativa. O pacote serser fragmentado, masmas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), C:\>ping www.cisco.com -l 1400 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1400 bytes de dados: O pacote precisa ser fragmentado, mas a de sfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), C:\>ping www.cisco.com -l 1300 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1300 bytes de dados: O pacote precisa ser fragmentado, mas a de sfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), C:\>ping www.cisco.com -l 1200 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1200 bytes de dados: Resposta de 23.57.128.170: bytes=1200 tempo=31ms TTL=54 Resposta de 23.57.128.170: bytes=1200 tempo=29ms TTL=54 Resposta de 23.57.128.170: bytes=1200 tempo=25ms TTL=54 Resposta de 23.57.128.170: bytes=1200 tempo=29ms TTL=54 Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Aproximar um número redondo de vezes em milissegundos: Mínimo = 25ms, Máximo = 31ms, Média = 28ms


  

 






  




Página 49  



 


C:\>ping www.cisco.com -l 1250 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1250 bytes de dados: Resposta de 23.57.128.170: bytes=1250 tempo=28ms TTL=54 Resposta de 23.57.128.170: bytes=1250 tempo=33ms TTL=54 Resposta de 23.57.128.170: bytes=1250 tempo=26ms TTL=54 Resposta de 23.57.128.170: bytes=1250 tempo=28ms TTL=54 Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Aproximar um número redondo de vezes em milissegundos: Mínimo = 26ms, Máximo = 33ms, Média = 28ms C:\>ping www.cisco.com -l 1280 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1280 bytes de dados: O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. O pacote precisa ser fragmentado, mas a desfragmentação está ativa. Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), C:\>ping www.cisco.com -l 1270 -f Disparando e144.dscb.akamaiedge.net [23.57.128.170] com 1270 bytes de dados: Resposta de 23.57.128.170: bytes=1270 tempo=28ms TTL=54 Resposta de 23.57.128.170: bytes=1270 tempo=26ms TTL=54 Resposta de 23.57.128.170: bytes=1270 tempo=31ms TTL=54 Resposta de 23.57.128.170: bytes=1270 tempo=28ms TTL=54 Estatísticas do Ping para 23.57.128.170: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Aproximar um número redondo de vezes em milissegundos: Mínimo = 26ms, Máximo = 31ms, Média = 28ms C:\> Agora você pode repetir esse teste em seu computador para o site da Cisco ou qualquer outro site que desejar, porém lembre-se que a resposta pode ser diferente, pois o caminho que os pacotes IP irão seguir na Internet dependem da disponibilidade dos roteadores, portanto podem variar dependendo da sua localização na rede, por exemplo, se a sua saída de Internet está em uma operadora diferente da que utilizamos para realizar os testes o resultado pode variar. Além disso, alguns sites bloqueiam o envio de ping para seus domínios, por isso caso você não receba resposta pode significar que seus pacotes foram bloqueados pelos dispositivos de segurança da empresa dona desse domínio. 4.1.7 TTL

O tempo de vida de um pacote é um contador que é decrementado a cada salto ou nó que o pacote IP passa. Cada sistema operacional define um TTL para seus pacotes, em roteadores


  

 






  




Página 50  



 


Cisco o TTL é definido com o valor de 255. Abaixo seguem os valores padrões de TTL para os sistemas operacionais mais comuns:     

UNIX: 255 Linux: 64 Linux + Iptables = 255 Windows: 128 Cisco: 255

Portanto, quando um roteador Cisco srcina um pacote ele coloca o tempo de vida como 255 e a cada roteador que esse pacote passar será decrementado em 1, por exemplo, se o caminho entre o srcinador do pacote e o destino existirem 3 roteadores quando o pacote chegar ao destino ele terá o valor de TTL 252. Veja o exemplo citado anteriormente na figura abaixo.

Analisando a figura acima se um pacote IP trafegar por um número de saltos muito grande ele tem seu tempo de vida expirado o roteador que recebeu o pacote com TTL igual a zero deve enviar uma mensagem à srcem do pacote com uma mensagem ICMP indicando esse problema chamado "time exceeded". Na mensagem de "time exceeded" o roteador onde o TTL chegou a zero informa a quem srcinou o pacote seu endereço IP e com isso o computador consegue saber por onde o problema ocorreu. É o princípio utilizado pelo traceroute para descobrir o caminho de um pacote até um IP de destino, ou seja, enviando pacotes ICMP iniciando com 1 e incrementando de um em um até chegar ao destino.


  

 






  




Página 51  



 


Guarde bem esse conceito porque ele será utilizado quando estudarmos o eBGP Multihop. 4.2 Protocolo TCP O protocolo TCP (Transmission Control Protocol) é normalmente chamado de "confiável" quando comparado ao seu "irmão" de camada de transporte UDP. Veja na figura a seguir os campos do cabeçalho do segmento TCP e logo abaixo a explicação de cada campo.

 





  

Porta de srcem : Número da porta do computador local ou de srcem da conexão TCP. Porta de destino: Número da porta TCP do host remoto, por exemplo, um servidor ou serviço de rede de destino que o host de srcem deseja acessar. Número de sequência: Número utilizado para garantir o sequenciamento correto dos segmentos que estão sendo enviados e recebidos. Especifica a quantidade de informação enviada (byte) em um segmento. O valor inicial é definido no início da sessão pelo 3way handshake com a troca do ISN (Initial Sequence Number) entre origem e destino. O valor pode variar entre 0–4.294.967.295, porém ao fazer troubleshooting e capturar pacotes para analisar a sessão é mostrado um número relativo de sequência como se tudo houvesse iniciado com zero, pois isso facilita a análise. Número de confirmação: Utilizado para solicitar o próximo segmento TCP esperado na sessão. Esse campo é calculado pela soma de uma unidade ao último segmento recebido pelo host de destino. H.Lenght: Comprimento do cabeçalho do segmento em bytes é o offset do TCP. Reservado: Definido como zero. Flags: Funções de controle, como a configuração e término de uma sessão. Utilizado no gerenciamento de sessões e no tratamento de segmentos.


  

 






  




Página 52  



 










Janela: Número de octetos que o remetente está disposto a aceitar. É o valor da janela dinâmica, quantos octetos podem ser enviados antes da espera do reconhecimento. Checksum: Cálculo de verificação feito a partir de campos do cabeçalho e dos dados. Utilizado para verificação de erros no cabeçalho e dados. Urgent Pointer: Indica o final de dados urgentes. Utilizado somente com um sinalizador URG flag. Opção: Informações opcionais. Uma opção atualmente definida é o tamanho máximo do segmento TCP. Dados: Dados de protocolo da camada superior, chamado também de Payload.

Em todas as conexões TCP, o host que serve como um cliente é quem inicia a sessão para o servidor. Os três passos no estabelecimento de uma conexão TCP são conhecidos como handshake de três vias ou triple way handshake (3-way handshake), veja como funciona a seguir: 1. O cliente envia um segmento contendo um valor sequencial inicial (ISN – Initial Sequence Number) com o flag SYN ativo. Esse segmento serve como uma solicitação ao servidor para começar uma sessão. 2. O servidor responde com um segmento contendo um valor de confirmação igual ao valor sequencial recebido mais 1, mais seu próprio valor sequencial de sincronização (flag SYN e ACK ativos). O valor é maior do que o número sequencial porque o ACK é sempre o próximo Byte ou Octeto esperado. 3. O cliente responde com um valor de confirmação igual ao valor sequencial que ele recebeu mais um. Isso completa o processo de estabelecimento da conexão. Veja as figuras abaixo com a ilustração da abertura da conexão com handshake de três vias.


  

 






  




Página 53  



 


4.2.1 MSS - Maximum Segment Size

O Maximum Segment Size (MSS - Tamanho Máximo do Segmento ) do TCP define a quantidade máxima de dados que um host pode aceitar em um único datagrama TCP/IP. O valor do MSS não leva em conta os cabeçalhos das camadas de rede e enlace, ele trata apenas da quantidade de dados do segmento TCP. O valor de MSS é enviado como uma opção do cabeçalho TCP apenas em segmentos TCP SYN, portanto cada lado de uma conexão TCP informa o seu valor de MSS ao outro lado no início do estabelecimento da sessão TCP. Ao contrário do que se pensa, o valor de MSS não é negociado entre hosts. O host de srcem deve limitar o tamanho dos dados de um segmento TCP a um valor igual ou inferior ao de MSS informado pelo host de destino. Portanto, para ajudar a impedir a fragmentação de IP nos hosts finais da conexão TCP a seleção do valor de MSS foi alterada para o tamanho mínimo de buffer e o MTU da interface de saída menos 40 bytes. Os números MSS são 40 bytes menores que MTU porque o MSS que não inclui os cabeçalhos IP e TCP, os quais tem ambos de 20 bytes cada um. Resumindo, o MSS faz com que cada host compare primeiro o MTU da interface de saída com o próprio buffer e escolha o menor valor como o MSS a ser enviado. Em seguida, os hosts comparam o tamanho do MSS recebido com base no MTU de sua própria interface e escolhem novamente o menor dos dois valores como valor de saída. Por exemplo, um host-A de srcem tem MTU de 1500 bytes (conectado a uma rede padrão Ethernet) e MSS de 1460 (MTU-60) em sua interface de saída e o host-B de destino tem MTU de 4462 (conectado a uma rede Token Ring) e MSS de 4422 bytes (4462-60). O host-A de srcem vai enviar seu MSS=1460 ao host-B de destino, o qual enviará seu MSS=4422. Como o MSS de A é menor que de B, o host-B seta seu MSS de saída para 1460, pois a regra é que ele deve ser menor ou igual que ao do host-A.


  

 






  




Página 54  



 


Mas agora vamos analisar o host-A, ele recebe o MSS do host-B igual a 4422 que é maior que seu MSS, portanto se ele montar pacotes IP com esse tamanho vai passar do seu MTU que é 1500 e o protocolo IP teria que fragmentar os pacotes entre A e B, portanto o que o host-A faz para evitar a fragmentação é definir que o MSS de saída dos pacotes que serão enviados para o host-B é igual ao seu MSS, ou seja, 1460. 4.2.2 Janelamento (Windowing)

O TCP transmite seus segmentos utilizando janelas deslizantes ou "Sliding Widows", ou seja, um ou mais segmentos são enviados e devem ser reconhecidos em uma janela com um único (ACK). permite um uso mais da sido largura de banda, pelo pois vários reconhecimento segmentos podem ser Isso transmitidos mesmo anteseficiente de terem reconhecidos receptor. O TCP inicia a transmissão com a janela de um segmento, o qual tem seu tamanho definido pelo MSS que estudamos anteriormente. Se o reconhecimento for recebido com sucesso a janela dobra, portanto são enviados dois segmentos. Se os dois segmentos forem reconhecidos com um único ACK o processo se repete aumentando o tamanho da janela exponencialmente até que o receptor não consiga mais reconhecer todos os segmentos enviados no período de tempo esperado (RTT - round-trip time) ou até que um limite máximo de tamanho de janela seja alcançado (MSS). Veja exemplo na figura abaixo.

No TCP o receptor especifica o tamanho da janela em cada pacote, pois o TCP provê conexão via um fluxo de bytes especificados pelo tamanho da janela, portanto a janela ou window é o número de bytes que pode ser enviado pelo transmissor antes que ele receba uma confirmação. Um tamanho inicial de janela (initial window size) é indicado no início da conexão e como já citado anteriormente varia conforme o fluxo vai sendo trocado entre srcem transmissor e receptor. Um tamanho de janela zero significa que o transmissor não pode enviar mais pacotes com segmentos TCP. O tamanho padrão de uma janela TCP é de 4128 bytes. A recomendação geral da Cisco é não alterar esse valor a não ser que o roteador esteja enviando pacotes grandes e em casos especiais. Nesse caso o comando "ip tcp window-size" pode ser utilizado para alterar o tamanho padrão da janela.


  

 






  




Página 55  



 


Um exemplo onde é necessário habilitar o recurso chamado "Window scaling" é para suportar LFNs (Long Fat Networks) a recomendação da Cisco é utilizar "TCP window size" igual ou maior que 65535 bytes e esse recurso deve ser suportado em ambas as pontas da conexão. O " Window scaling" está na RFC 1323 - TCP Extensions for High Performance. Vamos a um segundo exemplo de operação de uma janela deslizante para deixar mais claro o assunto, por exemplo, numa "TCP sliding-window" onde o transmissor tem que enviar uma sequência de bytes numerados de 1 a 10, porém o receptor tem um "window size" (tamanho de janela) igual a 5. Como o transmissor envia esses bytes? Primeiro o transmissor posiciona a janela nos primeiros 5 bytes e os transmite todos juntos, aguardando pelo reconhecimento (acknowledgment - ACK). Se tudo deu certo no caminho o receptor envia um ACK = 6, indicando que ele recebeu dos bytes de 1 a 5 e espera receber os próximos 5 bytes a partir do byte 6. Além disso, no mesmo pacote com o ACK o receptor indica que sua janela continua igual a 5, por exemplo. Então o receptor move a janela 5 bytes para frente e transmite dos bytes 6 a 10. O receptor recebe todos os bytes e responde com ACK = 11, indicando que espera receber na "próxima leva" de bytes a partir do 11, porém vamos supor que um problema ocorreu e o buffer no receptor ficou cheio, nesse caso ele envia um tamanho de janela igual a 0 indicando ao transmissor que não envie mais bytes, somente quando ele receber novamente um segmento indicando uma janela diferente de zero que ele pode voltar a transmitir. 4.2.3 Outros Recursos do TCP

Como já citado anteriormente foram criadas algumas extensões para o TCP funcionar sobre redes com alta largura de bande e elevado RTT nos links, chamadas de "long fat networks" ou LFNs. Uma delas citamos anteriormente que é o Window Scaling, permitindo a utilização de tamanhos de janelas maiores. Vamos ver mais algumas abaixo: 







TCP timestamps (RFC 1323): esse recurso evita ambiguidades geradas pelo campo de número de sequência e também permite uma estimativa melhor do RTT em casos de perdas de pacotes. Permite aumentar a janela do TCP acima de 64 kB e pode ser utilizado junto com o recurso de window scaling em redes LFN. Para ativar essa opção utilize o comando "ip tcp timestamp". TCP selective acknowledgment options (SACK, RFC 2018): permite que o receptor informe mais precisamente que segmentos TCP foram perdidos, permitindo que o transmissor envie somente os segmentos faltantes ao invés de enviar blocos inteiros de bytes. Esse recurso aumente o desempenho do link uma vez que podemos ter muitas perdas em uma janela sem interferir na transmissão geral, porém isso tem que ser feito dentro de um tamanho de janela específico. O SACK é ativado com o comando "ip tcp selective-ack" em modo de configuração global. Path MTU discovery (RFC 1191): evita a fragmentação de pacotes e reduz a relação de perda de pacotes em um fluxo, conceito já estudado em tópico anterior. Ele é ativado com o comando "ip tcp path-mtu-discovery [age-timer {minutos | infinite}]" em modo de configuração de interface, sendo que o padrão do age-timer são 10 minutos. TCP Explicit Congestion Notification (ECN): permite que um roteador avise os hosts conectados a ele a existência de um congestionamento na rede. O maior benefício dessa feature é a redução no delay e perda de pacotes na transmissão. O comando "ip tcp ecn" ativa o recurso em roteadores Cisco.


  

 






  




Página 56  



 




TCP Connection Attempt Time (SYN): você pode alterar o tempo que uma conexão TCP pode aguardar para estabelecer uma conexão com o comando "ip tcp synwaittime segundos" em modo de configuração global, sendo que o padrão é 30s. Esse temporizador não é do fluxo TCP, sendo apenas do dispositivo que srcinou os segmentos TCP. TCP Keepalive Timer: recurso que permite identificar conexões mortas ou que excederam o tempo de timeout. Utilizado para liberar recursos quando respostas não são recebidas pelo tranmissor dos segmentos enviados ao receptor dentro de uma janela TCP.

Os recursos TCP Time Stamp e TCP Selective Acknowledgment não podem ser utilizados em conjunto com a compressão do cabeçalho do TCP ou "TCP Header Compression". 4.2.4 Slow Start e Global Synchronization

Caso ocorra um congestionamento na rede e um fluxo TCP sofra uma perda de pacotes, ou seja, não tenha recebido o reconhecimento de um segmento enviado, esse fluxo pode sofrer o efeito chamado "Slow Start" ou início lento. Quando o slow start é aplicado a um determinado fluxo ele volta a janela de transmissão para um segmento e vai aumentando exponencialmente até atingir metade do valor da janela onde ocorreu o congestionamento. A partir desse momento o crescimento do tamanho da janela passa a ser linear e não mais exponencial. Outro fenômeno que pode ocorrer é que a fila de saída de uma interface chegar ao máximo de sua capacidade e começar a descartar pacotes de todos os fluxos TCP simultaneamente, o que acaba fazendo com que todos os fluxos TCP entrem em slow start simultaneamente. Esse problema é chamado "Global Synchronization" (sincronização global) ou "TCP Synchronization". A sincronização global gera um desperdício grande de largura de banda porque o tamanho da janela vai ser reduzido e com isso menos tráfego vai ser enviado subutilizando o link. O Cisco IOS suporta um recurso de QoS (Qualidade de Serviço) chamado Weighted Random Early Detection (WRED) que pode pseudo-aleatoriamente descartar pacotes de determinados fluxos com base no número de pacotes que estão na fila e marcações de QoS. Descartando os pacotes antes que a fila fique completamente cheia o problema do "global synchronization" é evitado. 4.2.5 Latência

A latência da rede ou "Network Latency" em uma rede comutada por pacotes é o tempo que o pacote leva pra viajar da sua srcem até o destino. A latência pode ser medida em uma via (one-way), através do tempo que a srcem enviou o pacote até o destino receber, ou então "ida e volta" (RTT ou round-trip time - two way ou duas vias), ou seja, o tempo do pacote ir da srcem ao destino mais o tempo do destino responder a srcem. Ela pode ser causada por váriosetc. motivos, como o atraso ou Delay, pela largura de banda, processamento dos dispositivos, A largura de banda também afeta a latência, pois quanto mais baixa a largura de banda maior o tempo para um pacote chegar da srcem e destino. A latência também pode limitar o throughput total em comunicações TCP, vamos estudar no próximo tópico sobre " bandwidthdelay product".


  

 






  




Página 57  



 


4.2.6 Produto Bandwidth-delay

O produto entre a largura de banda e o atraso ou " Bandwidth-Delay Product" (BDP) diz a quantidade máxima de bits que pode estar em trânsito em uma rede. Ele é a multiplicação da largura de banda (bandwidth em bps) e o delay ou RTT (em segundos). Por exemplo, em um link satelital de 512 kbit/s e 900 ms de RTT temos que Banda×Atraso = 512×10^3 b/s × 900×10^−3 s = 460,800 bits. Dividindo esse valor por oito temos o BDP igual a 57.600 bytes ou 56,26Kbytes (57600/1024). Mas o que isso tudo O buffer da janela TCP determina dos quantos bytes podem ser transfeidos antes quesignifica? o host pare e aguarde pelodoreconhecimento segmentos enviados. Portanto o throughput está intimamente ligado ao BDP, pois se o tamanho da janela de recepção for menor que o produto entre o delay e a largura de banda disponível não vamos utilizar o link até que o cliente envie os reconhecimentos dos segmentos recebidos, ou seja, se a quantidade de bytes enviadas no segmento for baixa em comparação ao BDP vamos subutilizar o link e o TCP não vai atingir seu ponto ótimo de operação. As redes citadas anteriormente chamadas de Long Fat Networks (LFNs) são redes com produto largura de banda x delay alto, normalmente redes MAN ou WAN com largura de banda de 10, 45, 100 Mbps ou mais que muitas vezes tem um desempenho ruim para o TCP. Nesse caso de redes LFN é preciso utilizar recursos como Window Scaling e Selective Acknowledgments ou SACKs para que elas funcionem corretamente e tenham um uso mais efetivo de largura de banda para conexões TCP. 4.3 Protocolo UDP Ao contrário do TCP o protocolo UDP não é orientado a conexão, portanto não possui mecanismos sofisticados de controle de congestionamento e erros como o TCP. As portas do UDP não tem estado, pois elas estão sempre prontas para receber dados. Abaixo segue o cabeçalho do UDP:

   

Porta de srcem : Número da porta chamadora. Porta de destino: Número da porta chamada. Comprimento: Número de bytes que inclui cabeçalho e dados. Checksum: Cálculo de verificação (checksum) feito através de campos do cabeçalho e dados.



Dados: Dados de protocolo de camada superior. Pelo fato do UDP ser mais simples e não ser orientado a conexão ele acaba se tornando mais rápido e preferido para aplicações onde a velocidade é fundamental, como a voz sobre o protocolo IP ou VoIP. O protocolo RTP (Real Time Protocol), por exemplo, utiliza o serviço UDP para transmitir a voz entre aparelhos IP. Outro exemplo de aplicação são as VPN’s ou redes virtuais privadas, elas também normalmente utilizam serviço UDP para transmissão dos seus dados criptografados, pois os pacotes acabam sendo enviados mais rápidos e com menos cabeçalho, pois o UDP tem bem menos bits de controle que o TCP.


  

 






  




Página 58  



 


Quando utilizamos voz ou vídeo através do protocolo RTP é recomendado que a latência seja igual ou menor que 150ms e nesse caso a Cisco recomenda a utilização da tecnologia de enfileiramento chamada Low Latency Queuing (LLQ). Com esse tipo de fila tráfegos como voz e vídeo sobre IP podem ser tratados de maneira especial com alta prioridade (priority queue) que tem uma largura de banda reservada que não é compartilhada com os demais tipos de tráfego. 4.3.1 TCP Starvation e UDP Dominance

Você lembra que já estudamos sobreaoser quedescartados? ocorre quando TCP osofre congestionamento na rede e seus segmentos começam Ele oativa "slowum start" quando ocorre um descarte de pacote no fluxo, reduzindo novamente o tamanho da janela para um segmento e subindo exponencialmente, certo? Mas e o UDP? como ele reage quando acontece um congestionamento e seus datagramas são descartados? Literalmente o UDP não faz nada em relação a isso, pois ele não é orientado a conexão e não tem como saber que houve um descarte de pacote no seu fluxo. O resultado disso pode ser desastroso para o tráfego TCP se ele estiver sendo transportado junto com o UDP na mesma classe, pois ele vai começar a reduzir seu tráfego enquanto o UDP não faz o mesmo, portanto vai chegar um ponto que o TCP fica sem largura de banda ou como o termo em inglês diz em sua forma literal "morre de fome". Esse efeito também é chamado de "TCP starvation" ou "UDP dominance", ou seja, reduz o throughput, aumenta a latência e causa o "starvation" do protocolo TCP. A melhor maneira de evitar esse tipo de problema é separar ao máximo o tráfego de fluxos TCP dos fluxos de UDP e aplicar técnicas de QoS para melhoria do uso dos recursos de rede. 4.3.2 Latência

A latência como já estudamos é o delay fim a fim e diferentemente do TCP o UDP não tem seu throughput afetado por ela, pois ele não é orientado a conexão. A latência é muito importante porque alguns serviços são extremamente sensíveis a ela, por exemplo, o fluxo de voz sobre IP que é realizado pelo protocolo RTP (Real Time Protocol) que utiliza UDP como transporte. A norma G.114, por exemplo, recomenda que a latência em via única (one-way) para VoIP seja de no máximo 150ms. O Jitter (variação no delay) é um dos efeitos da latência que afeta transmissões UDP. É causado por pacotes que chegam com atrasos diferentes no destino, por exemplo, o primeiro pacote chega com 90 ms (mili segundos ou 1 segundo divididos por mil – 0,001s), enquanto o segundo pacote chega com 110 ms, ou seja, uma diferença de 20 ms entre o primeiro e o segundo pacote de voz. Portando dizemos que há 20 ms de variação de delay (jitter) entre os pacotes. Para minimizar o efeito do jitter podem ser utilizados Buffers que armazenam por um curto espaço de tempo a informação compensando a variação no atraso.


  

 






  




Página 59  



 


Capítulo 03 Implementando o EIGRP Nesse capítulo será estudado o protocolo de roteamento desenvolvido pela própria Cisco chamado EIGRP ou “Enhanced Interior Gateway Routing Protocol”.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: As principais características do EIGRP; Funcionamento do EIGRP, seus pacotes, formação de vizinhança e o protocolo DUAL; Como o EIGRP calcula sua métrica e define os melhores caminhos; Como configurar o EIGRP, desde o básico até configurações mais avançadas como a autenticação e criar redes stub. 



O EIGRP é um protocolo proprietário, porém muito rápido e eficiente, sendo a escolha de grandes empresas que utilizam equipamentos Cisco em suas soluções de redes.





Aproveite o capítulo e bons estudos!


  

 






  




Página 60  



 


Sumário do Capítulo

4.9

1

Visão Geral do EIGRP ______________ 62

2

Mensagens do EIGRP ______________ 63

2.1

Formato do Quadro do EIGRP ______ 64

2.2

Tipos de Pacotes do EIGRP _________ 66

Verificando e Mantendo o EIGRP __ 101

2.3 Processo de Descoberta de Vizinhos e Troca de Informações de Roteamento _____ 67 2.4 Alterações na Topologia – Query, Reply e Update ____________________________ 68 3

Escolha do Melhor Caminho ________ 69

3.1 Exemplo de Escolha do Melhor Caminho – Rota Principal _______________________ 71 3.2 Encontrando uma Rota Backup – Feasible Successor _____________________ 73 3.3

Resumo do Funcionamento do DUAL 75

4 Configurando o EIGRP – Planejamento e Implementação______________________ 77

4.1

Configuração Básica ______________ 78

4.2

EIGRP Através da WAN ___________ 80

4.2.1 EIGRP sobre Frame Relay __________ 80 4.2.2 Configurando o Bandwidth em Interfaces Frame-relay ____________________ 84 4.2.3 EIGRP sobre MPLS - Metroethernet _ 86 4.2.4 Vizinhança EIGRP em VPN’s MPLS ___ 87

4.3

Customizações no EIGRP __________ 87

4.3.1 Passive Interface ________________ 88 4.3.2 Unicast Neighbors - Mensagens em Unicast para Vizinhos EIGRP _______________ 88 4.3.3 Sumarização de Rotas ____________ 89 4.3.4 Exemplo de Design de Rede com Sumarização ____________________________ 91

4.4

Balanceamento de Cargas _________ 92

4.4.1 Balanceamento de Carga por Fluxo e por Pacotes 93

4.5

Autenticação no EIGRP ____________ 94

4.6 Melhorando a Escalabilidade do EIGRP – Roteamento Stub _____________________ 96 4.7 Active Process Enhancement e Graceful Shutdown ___________________________ 99 4.8

Anunciando Rotas Default _________ 99

4.8.1

Anunciando a Rota padrão no EIGRP 100


  

 






  




Página 61  



 


1

Visão Geral do EIGRP

O EIGRP é um protocolo de roteamento proprietário da Cisco classificado como vetor de distância avançado (Advanced Distance Vector), classless (suporta CIDR e VLSM) e que utiliza um cálculo complexo para escolha da melhor rota, ou seja, uma métrica composta que por padrão utiliza a largura de banda (bandwidth) e o atraso (delay) como parâmetros de cálculo. As principais características e recursos do EIGRP são:    

   



 

Utiliza o DUAL como algoritmo de determinação das melhores rotas livres de loop. Possui convergência rápida. Suporta VLSM e roteamento Classess. Faz o envio de updates (atualizações) parciais para preservar a largura de banda em caso de alteração na rede. Possui suporte multiprotocolo, tais como IP, AppleTalk e IPX. Roda diretamente sobre o IP com número de protocolo 88. Suporta todos os tipos de conexões em camada 2 e topologias de rede. Permite balanceamento de carga com métricas iguais ou diferentes (Unequal Cost Load Balancing). Utiliza multicast (224.0.0.10) para envio de atualizações de roteamento ao invés de broadcast. Suporta autenticação e sumarização manual em quaisquer interfaces. Suporta rotas backups (feasible successor) que são imediatamente acionadas em caso de uma rota principal (successor) ficar indisponível evitando recálculo por parte do DUAL.


  

 






  




Página 62  



 


Todas essas funcionalidades do EIGRP são controladas basicamente por quatro tecnologias: 1. Descoberta e manutenção de vizinhanças: realizada com o envio periódico de mensagens de Hello. 2. Reliable Transport Protocol (RTP): protocolo utilizado para enviar, solicitar e reconhecer as mensagens do EIGRP. Roda na camada 4 do modelo OSI. 3. Diffusing Update Algorithm (DUAL): responsável por determinar a melhor rota livre de loop, assim como rotas backup. 4. Protocol-independent modules (PDM): os módulos permitem que um roteador trabalhe camadade3 como um “plug-in” deles, com issocom o diversos roteadorprotocolos EIGRP éde capaz trabalhar com IP,para IPXcada e um Appletalk simultaneamente em um mesmo processo de roteamento. O EIGRP inicia seu processo com a descoberta de vizinhos através do protocolo de Hello, o qual é muito mais simples em relação ao Hello do OSPF. Quando ele encontra um vizinho que atende os requistos para que seja possível a troca de tabela de roteamento (estar no mesmo AS, utilizar os mesmos parâmetros para cálculo da métrica e pertencer à mesma sub-rede IP) é realizada a troca de informações de roteamento para que o DUAL possa ser executado e as melhores rotas sejam determinadas e inseridas na tabela de roteamento. No final de todo o processo o EIGRP monta três tabelas de controle: 1. Tabela de vizinhanças: construída a partir da troca de Hellos e utilizada para controlar o envio de mensagens entre os vizinhos. Pode ser visualizada com o comando “show ip eigrp neighbors”. Chamada de “neighbor table”. 2. Tabela de Topologia: a tabela de topologia ou “topology table” contém informações de todas as melhores rotas (successor, rota sucessora ou rota principal) e as possíveis rotas backups (feasible successor, sucessora viável ou rota backup) livres de loop. Pode visualizada com o comando “show ip eigrp topology ”. 3. ser Tabela de Roteamento : contém as melhores rotas aprendidas pelo EIGRP e demais protocolos de roteamento configurados no roteador. Pode ser visualizada com o comando “show ip route” ou “show ip route eigrp”. Chamada de “routing table”. 2 Mensagens do EIGRP Conforme estudamos no tópico anterior o EIGRP utiliza o protocolo RTP (Reliable Transport Protocol) para enviar suas informações, com o objetivo de estabelecer relacionamento entre vizinhos e também manter as informações precisas na tabela de roteamento. Essa troca de mensagens foi projetada para economizar ao máximo a largura de banda entre os vizinhos, enviando mensagens somente quando necessário e para aqueles vizinhos específicos que solicitaram as informações. Lembre-se do CCNA que os protocolos baseados em vetores de distância não trabalham assim, eles continuam enviando suas tabelas de roteamento aos vizinhos mesmo que apenas uma rota sofra alteração, por isso o EIGRP é um vetor de distância avançado.


  

 






  




Página 63  



 


2.1 Formato do Quadro do EIGRP As mensagens do EIGRP são transportadas pelo protocolo RTP diretamente sobre o IP com número de protocolo 88, veja na figura abaixo a ilustração de um quadro transportando um pacote do EIGRP dentro de um pacote IP.

Como podemos observar, quando o EIGRP envia um pacote ele utiliza como IP de destino o endereço de multicast 224.0.0.10, o qual possui o endereço MAC 01-00-5E-00-00-0A. As informações do EIGRP são divididas em dois blocos: cabeçalho e mensagens. Veja na figura seguinte o formato do cabeçalho do EIGRP.

Dentro do campo Opcode do cabeçalho do EIGRP está descrito o tipo da mensagem que está sendo enviada, se um Hello, Update, Query ou Reply. O reconhecimento das mensagens enviadas em modo seguro (com confirmação) está no campo ACK. Acompanhe na próxima figura o detalhe do campo Opcode.


  

 






  




Página 64  



 


Já na figura seguinte temos o detalhamento do formado da mensagem do EIGRP, a qual é dividida em tipo, tamanho e valor (Type/Length/Value - TLV). Como podemos verificar, existem três tipos de mensagens que podem ser trocadas: informações dos parâmetros do EIGRP (0x0001), sobre rotas internas (0x0002) e sobre rotas externas (0x0003).

Por exemplo, o EIGRP poderia enviar um update, identificado no cabeçalho do EIGRP com opcode 1, e dentro do update trazer uma informação sobre uma rota interna ao AS identificando com o TVL 0x0002, sendo que as informações sobre a rota estariam descritas no campo de “parameter specifics” da mensagem do EIGRP. A seguir vamos estudar melhor cada um dos tipos de pacotes do EIGRP.


  

 






  




Página 65  



 


2.2 Tipos de Pacotes do EIGRP O EIGRP possui cinco tipos de pacotes para trocar suas mensagens: 



Hello: Usados para descobrir vizinhos e manter a tabela de vizinhança. É enviado por multicast no IP 224.0.0.10 de 5 em 5 segundos em links maiores que 1.544Mbps (T1) ou de 60 em 60 segundos para links de menor banda que o T1. Similar a um mecanismo de Keepalive. Update: Utilizados para troca confiável (RTP) de informações de roteamento.







Query : Pacotes enviados de forma confiável via caminho, RTP e utilizados para verificar se existe um roteador de também backup para um determinado ou seja, para obter informações sobre rotas específicas que ficaram indisponíveis. Reply: Pacotes de resposta a uma Query que requerem confirmação (confiável RTP), enviado por Unicast somente a quem perguntou. Acknowledgment (ACK): Pacotes de confirmação ou reconhecimento enviados por Unicast para quem solicitou a informação. Pacotes como update, query e reply precisam de confirmação.

Apesar do protocolo EIGRP ser confiável, os pacotes de Hello e ACK não precisam ter seu recebimento confirmados, apenas updates, query e reply precisam ser reconhecidos com um ACK. Os pacotes enviados como confiáveis (update, query e reply) devem ser reconhecidos, porém caso algum problema ocorra e o roteador não receba o reconhecimento, esse roteador envia periodicamente pacotes em Unicast para o vizinho que não está respondendo com uma janela de transmissão igual a um. Isso é feito dessa forma para que nenhum outro tráfego seja enviado até que o vizinho responda. Após o envio de 16 transmissões confiáveis não reconhecidas o roteador vizinho é removido da tabela de vizinhança. Na sequência veremos alguns processos mais específicos do EIGRP para descoberta de vizinhos e solicitação de informações sobre rotas. Basicamente, no processo inicial, são utilizados pacotes de Hello para realizar a vizinhança, depois pacotes de update e ACK para troca de informações de roteamento e convergência da rede, veja a figura abaixo.

Após a rede convergir são trocados Hellos periodicamente e em caso de queda ou indisponibilidade de determinadas redes os roteadores utilizam pacotes de query, reply e ACK para trocar informações específicas, acompanhe na figura abaixo. Updates também podem ser utilizados quando os roteadores detectam alterações na topologia (adição de novas redes ou interfaces).


  

 






  




Página 66  



 


2.3 Processo de Descoberta de Vizinhos e Troca de Informações de Roteamento Uma vez configurado o EIGRP, o primeiro processo a ser realizado é a descoberta de vizinhos através do envio de mensagens de Hello e construção da tabela de vizinhos (neighbor table). As condições para formação da vizinhança são:  



Os roteadores devem pertencer ao mesmo AS (mesmo número de sistema autônomo); Utilizar os mesmos parâmetros para cálculo da métrica (valore s de “k” da fórmula da métrica iguais); As interfaces diretamente conectadas devem pertencer à mesma sub-rede IP.

Dica importante: Diferente OSPF,em no ambos EIGRP os timers apenas de os parâmetros acima devem serdoiguais vizinhospodem para ser que diferentes, haja a formação vizinhança. Se os valores estão batendo o processo de descoberta de vizinhança e troca de informação de roteamento entre os vizinhos segue os seguintes passos (acompanhe na figura abaixo): 1. 2. 3. 4. 5.

Roteador R1 envia um hello em multicast para o roteador R2 Roteador R2 envia um hello e um update contendo suas informações de roteamento Roteador R1 reconhece com um ACK o update de R2 Roteador R1 envia seu update com suas informações de roteamento Roteador R2 envia um ACK reconhecendo o recebimento do update de R1


  

 






  




Página 67  



 


Note que juntamente com o processo de descoberta de vizinho o roteador já faz também a troca de informações de roteamento através do envio de mensagens de update em modo confiável, ou seja, é necessária a confirmação (ACK) do recebimento da mensagem de update pelo vizinho. Uma vez realizado o processo de descoberta de vizinhos, ou seja, os roteadores trocaram informações de roteamento e a rede convergiu, os Hellos continuam sendo trocados periodicamente de 5 em 5s em links maiores que 1.544Mbps (T1) ou de 60 em 60s para links de menor banda que o T1. Esse processo é similar a um mecanismo de Keepalive e garante que os vizinhos continuam funcionando perfeitamente. Caso um vizinho não envie pacotes de Hello existe um temporizador chamado “Hold Timer” que por padrão é três vezes o valor do hello e quando expirado o vizinho é removido da tabela de vizinhos. Portanto o valor padrão de Hello e Hold timers são: 



Hellos trocados de 5 em 5s em links maiores que 1.544Mbps (T1), com um Hold Timer de 15s. Hellos trocados de 60 em 60s para links iguais ou menores que a banda do T1, com um Hold Timer de 180s.

Essas informações são visualizadas com o comando “show ip eigrp neighbor”. Via debug podem ser utilizados os comandos “debug ip eigrp” ou “debug ip eigrp packets”. 2.4 Alterações na Topologia – Query, Reply e Update O processo eque vimos no tópico anterior o início,normal. ou seja, vocênesse subiutópico, o protocolo de roteamento a rede convergiu entrando em éoperação Agora, vamos ver as mensagens que são utilizadas quando ocorrem problemas ou alterações de topologia. Lembre-se que se nada ocorrer com uma rede EIGRP somente Hellos são trocados após a convergência. As mensagens de Query e Reply são enviadas quando um roteador não possui uma rota backup instalada em sua tabela de topologia. Lembre-se que uma das vantagens do EIGRP é a capacidade de manter uma ou várias rotas backup, chamadas de “ feasible successor”, em sua tabela de topologia e em caso da queda da rota principal (successor ou sucessora) essa rota backup é imediatamente acionada sem a necessidade de recálculo por parte do DUAL. Portanto, quando não existe uma rota backup na tabela de topologia o roteador envia uma mensagem de query para todos os seus vizinhos diretamente conectados perguntando sobre aquela rota específica que caiu. Caso exista no vizinho uma rota backup ou feasible successor o vizinho instrui ao solicitante a utilizar aquele caminho, evitando o recálculo da melhor rota pelo DUAL e economizando tempo. No entato, se nenhum roteador conhecer um melhor caminho, por exemplo, a rota que caiu existia somente naquele roteador, o roteador que srcinou a query terá que recalcular o caminho utilizando o DUAL e enviar as informações para os vizinhos através de um update que aquela rota não existe mais, veja na figura abaixo.


  

 






  




Página 68  



 


Tanto a query como reply são enviados de maneira confiável (reliable) e precisam de uma resposta de reconhecimento (ACK - não confiável ou unreliable). As mensagens de update também são enviadas de forma confiável e são utilizadas mesmo após a fase inicial da troca de informações para que o roteador informe aos seus vizinhos sobre mudanças na topologia, por exemplo, quando uma nova rede foi inserida ou ficou indisponível. Essas mensagens são parciais, ou seja, específicas sobre a ou as redes alteradas. 3 Escolha do Melhor Caminho O que acontece na prática é que o EIGRP quer descobrir quais as melhores rotas para instalar na tabela de roteamento e também se existem possíveis rotas backup para serem utilizadas em caso da rota sucessora (principal) ficar indisponível. Veja a figura abaixo.

Vamos ver agora como o roteador calcula e decide essas informações. A escolha do melhor caminho no EIGRP é realizada como em qualquer outro protocolo de roteamento através da métrica calculada para cada rota. A melhor métrica calculada pelo roteador é chamada de distância viável ou “feasible distance” (FD) e é a menor métrica dentre todas as calculadas para uma determinada rede de destino. O cálculo da FD no EIGRP por padrão leva em conta a largura de banda da interface (configurada no comando bandwidth nas interfaces seriais) e o atraso (delay). A fórmula completa leva em conta mais parâmetros que os dois citados anteriormente, na realidade ela é baseada nas constantes K1, K2, K3, K4 e K5, as quais podem ser zero ou um na fórmula conforme figura a seguir.


  

 






  




Página 69  



 


Portanto, a métrica do EIGRP pode ser composta pelos seguintes parâmetros das interfaces:  

 

BW : menor larguradodeatraso bandadas ou bandwidth de um caminho. Delay : somatório interfaces do caminho em décimos de microssegundos (divide o que estiver mostrando no show interfaces por 10 antes de somar!). Load: carga da interface (quanto ela está sendo ocupada). Reliability: confiabilidade da interface.

Todos os parâmetros acima podem ser encontrados com o comando “show interfaces”. Por padrão os valores de k são: k1=1, k2=0, k3=1, k4=0 e k5=0, o que resulta na simplificação da fórmula ficando somente o que temos na figura abaixo.

Normalmente o valor da largura de banda é mais significativo na escolha do melhor caminho, já o delay tem o papel de decisão em caminhos com largura de banda semelhantes, porém com menos saltos, ou seja, para escolha de caminhos mais diretos até o destino. Tanto o delay como a largura de banda podem ser alterados para influenciar na escolha do melhor caminho, lembrando que nas interfaces seriais se o parâmetro bandwidth não for configurado o EIGRP assume que a interface tem a largura de banda de um T1 ou 1,5Mbps. Sobre os parâmetros de load (carga) e reliability (confiabilidade) o EIGRP não calcula e sim usa os valores dos contadores de interface, conforme calculado pelo código da própria interface. Geralmente, a carga é baseada na quantidade de largura de banda disponível (com base na largura de banda configurada), convertida para um número entre 0 e 255 (255 o router está usando uma carga ou largura de banda de 100%, enquanto que 0 é 0% de carga). A confiabilidade é geralmente baseada em pacotes perdidos ou erros, dependendo do tipo de interface, e é também ajustada para estar compreendida entre 0 e 255. Embora na prática esses números sejam dinâmicos, o EIGRP não fica constantemente lendo a partir da interface dinamicamente e os atualizando. Em outras palavras, se você utilizar o K2, k4 e/ou k5 diferentes de zero, quando o EIGRP formar a vizinhança a confiabilidade e a carga serão lidas na interface e depois disso ficarão constantes até que o relacionamento com esse vizinho seja desfeito. Portanto, com as informações de suas redes diretamente conectadas e também recebidas pelos seus vizinhos o roteador calcula a métrica e instala os menores valores na tabela de roteamento. O próximo passo é determinar se existem rotas backup ou feasible successors.


  

 






  




Página 70  



 


O valor da melhor métrica calculada em um roteador é também anunciado aos seus vizinhos como distância anunciada ou reportada (Reported Distance – RD - ou Advertised Distance - AD), ambos os termos são sinônimos e podem ser encontrados em algumas documentações sobre o assunto. Esse valor é utilizado para definir se as demais rotas que estão na tabela de topologia podem ser consideradas como backup ou “feasible successor”. A condição para que uma rota seja considerada backup é que sua distância anunciada (AD) deve ser menor que a distância viável (FD) da rota principal, portando a condição de viabilidade de uma rota backup (feasible condition) é “AD ou RD < FD”. Lembrem-senaque as rotas backup Essas não são inseridas na tabela de roteamento, mas ficam disponíveis tabela de topologia. rotas não recebem nenhuma marcação especial na tabela e um dos objetivos do exame do CCNP ROUTE é reconhecer se uma rota é ou não backup analisando a tabela de topologia com o comando “show ip eigrp topology”, o qual estudaremos posteriormente quando iniciarmos as configurações. 3.1 Exemplo de Escolha do Melhor C aminho – Rota Principal A escolha do melhor caminho pelo EIGRP é realizada com o cálculo da métrica dos possíveis caminhos para uma determinada rede e como já comentado a menor métrica será a escolhida para o encaminhamento de pacotes, ou seja, será inserida na tabela de roteamento. Por padrão essa métrica depende da menor banda do caminho, a qual foi configurada nas interfaces seriais pelo comando bandwidth, e o somatório dos atrasos das interfaces do caminho. Vamos verificar a escolha do melhor caminho de R4 para chegar à rede 10.0.2.0/24 que está conectada entre R3 e R5 utilizando a topologia mostrada abaixo. Note que R4 tem duas saídas para a mesma seja, dois possíveis caminhos: através da interface s0/0 ou pela s0/1, para saber qualrede, ele iráouutilizar precisamos calcular a métrica de cada caminho.


  

 






  




Página 71  



 


Para verificar o delay e a largura de banda configurada nas interfaces utilize o comando “show interfaces” e você encontrará os valores da largura de banda (BW) e delay (DLY), veja exemplo da saída dos comandos e a topologia com os dados para cálculo. R2#show int f0/0 FastEthernet0/0 is up, line protocol is up Hardware is Gt96k FE, address is c202.216c.0000 (bia c202.216c.0000) Internet address is 10.0.0.1/24 MTU 1500 bytes, BW 100000 Kbit , DLY 100 usec , reliability 255/255, txload 1/255, rxload 1/255 R4#show int s0/0 Serial0/0 is up, line protocol is up Hardware is GT96K Serial Internet address is 192.168.0.2/30 MTU 1500 bytes, BW 512 Kbit, DLY 20000 usec , reliability 255/255, txload 1/255, rxload 1/255

Portanto a largura de banda na fórmula para os dois caminhos será de 64kbps e o delay será o fator de decisão. Para o caminho através da serial 0/0 de R4 temos o link entre R4 e R2, depois R2 e R3 e chegamos na serial entre R3 e R5 que possui a rede 10.0.2.0/24, portanto a fórmula ficará: Métrica = [10^7/64 + (20000+100+20000)/10]*256= 41026560 Para o segundo caminho através da serial 0/1 de R4 teremos a fórmula: Métrica = [10^7/64 + (20000+20000)/10]*256= 41024000 Portanto, apesar do caminho através da serial 0/0 ter um link de 512kbps, o EIGRP escolherá como rota principal o caminho através do link da serial 0/1 com 128kbps, pois a métrica composta é melhor. Esse exemplo foi dado de propósito, pois a primeira vista escolheríamos o caminho com o link de 512kbps!


  

 






  




Página 72  



 


Esse melhor caminho é a rota sucessora ou Successor Route. Com o comando “show ip eigrp topology” ou “show ip eigrp topology 10.0.2.0/24” podemos analisar a tabela de topologia do EIGRP, sendo que o segundo comando nos dá detalhes sobre os parâmetros utilizados no cálculo da métrica. R4#sho ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(192.168.0.6) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.2.0/24, 1 successors, FD is 41024000 via 192.168.0.5 (41024000/40512000), Serial0/1 via 192.168.0.1 (41026560/40514560), Serial0/0 ###Saída Omitida ###

R4#show ip eigrp topology 10.0.2.0/24 IP-EIGRP (AS 100): Topology entry for 10.0.2.0/24 State is Passive, Query srcin flag is 1, 1 Successor(s), FD is 41024000 Routing Descriptor Blocks: 192.168.0.5 (Serial0/1),from 192.168.0.5, Send flag is 0x0 Composite metric is (41024000/40512000), Route is Internal Vector metric: Minimum bandwidth is 64 Kbit Total delay is 40000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 192.168.0.1 (Serial0/0), from 192.168.0.1, Send flag is 0x0 Composite metric is (41026560/40514560), Route is Internal Vector metric: Minimum bandwidth is 64 Kbit Total delay is 40100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 R4#

3.2 Encontrando uma Rota Backup

–

Feasible Successor

Lembre-se que o DUAL sempre vai procurar uma rota sucessora e uma sucessora viável, ou seja, uma rota backup para uso imediato em caso da rota principal ficar indisponível. Se lembrarmos da topologia anterior veremos que temos um link de 512kbps que pode ou não ser considerado um caminho redundante ou feasible successor. Para que esse caminho seja considerado um sucessor viável o roteador R4 fará a comparação entre a Feasible Distance (FD ou métrica da melhor rota) e a distância anunciada (AD – Advertised Distance ou distância anunciada pelo vizinho), a qual é a métrica para a mesma rota que seu vizinho anunciou.


  

 






  




Página 73  



 


Veja no comando abaixo que na rota via serial 0/0 o EIGRP tem em sua tabela de topologia a métrica de 41026560 e uma AD (Advertised Distance) de 40514560. Se comprarmos a FD (distância viável ou feasible distance) da rota sucessora que é 41024000 vamos notar que ela é maior que o valor do AD da rota que restou, por isso atende a condição de viabilidade ou Feasible Condition, podendo ser considerada uma rota backup ou feasible successor do caminho principal. Veja a figura abaixo. R4#sho ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(192.168.0.6) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 10.0.2.0/24, 1 successors, FD is 41024000 via 192.168.0.5 (41024000/40512000), Serial0/1 via 192.168.0.1 (41026560/40514560), Serial0/0

A distância anunciada ou AD é a métrica calculada no roteador vizinho, é o valor que aparecerá no comando show ip route como métrica, veja o exemplo do roteador R2 abaixo: R2#show ip route 10.0.2.0 Routing entry for 10.0.2.0/24 Known via "eigrp 100", distance 90, metric 40514560, type internal Redistributing via eigrp 100 Last update from 10.0.0.2 on FastEthernet0/0, 01:29:15 ago Routing Descriptor Blocks: * 10.0.0.2, from 10.0.0.2, 01:29:15 ago, via FastEthernet0/0 Route metric is 40514560 , traffic share count is 1 Total delay is 20100 microseconds, minimum bandwidth is 64 Kbit Reliability 255/255, Loading 1/255, Hops 1minimum MTU 1500 bytes

O conceito por trás da feasible condition é circular, ou seja, se a distância anunciada pelo vizinho for menor que a distância viável local significa que por aquele caminho não há loops de roteamento, pois se a distância anunciada fosse menor que a distância viável do roteador local no caso da queda do link principal o roteador local olharia aquele caminho e ele seria melhor que o anterior, devolvendo os pacotes para esse roteador e podendo causar um loop. Por exemplo, se configurarmos a largura de banda entre R2 e R3 como 32kbps teremos uma alteração nos valores das métricas e ficará conforme a figura abaixo.


  

 






  




Página 74  



 


Note que com esse valor novo de banda a AD enviada por R2 acaba ficando maior que a FD da rota principal de R4, que permanece a mesma, porém a métrica do caminho de volta com esse novo valor de banda entre R2 e R3 ficou muito alta, o que é interpretado pelo DUAL como uma possibilidade de loop, pois significa que o caminho de volta de R2 para a rede 10.0.2.0/24 é maior que a métrica do caminho entre R4 e a rede 10.0.2.0/24. Na prática o que aconteceria é que se o roteador R4 passasse a enviar quadros para a rede 10.0.2.0/24 através da serial 0/0, o roteador R2 devolveria para R4, pois a métrica por R4 é melhor que por R3, causando um loop de roteamento! 3.3 Resumo do Funcionamento do DUAL O algoritmo DUAL é utilizado pelo EIGRP para realizar a escolha dos melhores caminhos através da análise dos parâmetros AD e FD, conforme estudamos anteriormente. Lembre-se que o caminho com métricacom é chamado successor disso,detambém estudamos quemenor os caminhos AD menordeque o FD da ou rotasucessor. sucessoraAlém são livres loop e chamados de feasible successors, o que significa que ao perder a rota principal, o roteador pode utilizar um caminho definido como feasible successor imediatamente como redundância do link principal sem correr o risco de haver loops de roteamento na rede. Portanto, se há um sucessor viável ou feasible successor o roteador não precisará recalcular a melhor rota, economizando processamento e reduzindo o tempo de indisponibilidade para os usuários da rede, pois esse chaveamento do envio dos pacotes pela rota redundante é realizado em frações de micro segundos, o que garante uma perda mínima de pacotes. Além disso, o DUAL deve ter controle do estado das suas rotas, o que é informado através do comando “show ip eigrp topology” através de uma terminologia padrão conforme saída abaixo. R4#sho ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(192.168.0.6) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

Após o roteador escolher o melhor caminho para uma determinada rede de destino, essa rota é marcada como Passive (P - passiva). Se um caminho principal (successor) fica indisponível e nenhum feasible successor está presente na tabela de topologia o roteador envia queries em todas as suas interfaces procurando identificar em seus vizinhos um caminho alternativo, nesse caso a rota é marcada como Active (A – ativa). Além disso, nenhuma rota sucessora (successor) pode ser escolhida sem que o roteador receba resposta de todas as queries.


  

 






  




Página 75  



 


Caso essa resposta (reply) não seja enviada em até 3 minutos o roteador passa para o estado de stuck in active (SIA - s). Nesse caso, o roteador que enviou a query irá reinicializar o processo de estabelecimento de vizinhança com o roteador que não respondeu sua query. As causas mais comuns para que roteadores entrem no estado de SIA são: 





O uso de CPU ou memória está muito alto e o vizinho não consegue processar a query ou responde-la. O link entre os roteadores está descartando pacotes, nesses casos normalmente a vizinhança é mantida, mas a perda pacotes impede Links unidirecionais impedindo quede o roteador receba aosresposta pacotesdas do queries. vizinho, isso pode ser causado por ACLs mal configuradas, por exemplo.

Perceba que esse processo de envio de query para descobrir rotas alternativas em caso de queda de uma sucessora e não haver sucessora viável pode ser altamente complexo em redes com muitos links redundantes, por exemplo, em redes full-meshed. Nesse caso o uso de técnicas para melhorar o desempenho e envio de anúncios devem ser utilizados, como por exemplo, a sumarização manual de rotas, a qual no EIGRP pode ser feita por interface. Veja a figura abaixo, onde o roteador HQ1 perde conexão com sua fast2/0 e envia query pelas interfaces s1/0, s1/1 e fast 0/0. Note que as queries recebidas são retransmitidas pelos roteadores para seus vizinhos fazendo com que o processo consuma banda da rede com as consultas.


  

 






  




Página 76  



 


4 Configurando o EIGRP – Planejamento e Implementação Vamos seguir nesse capítulo e nos próximos que tratarem da configuração com a nova perspectiva proposta pelo conteúdo do CCNP ROUTE, a qual traz além dos comandos em si também uma fase de “planejamento”. Vamos simplificar ao máximo e utilizar um conceito sem nos ater a padrões como ITIL, aqui você como CCNP recebeu a missão de ativar o EIGRP em uma rede nova ou então migrar uma rede que está com RIP, por exemplo, para o EIGRP. Aí vem uma pergunta inicial: “O que preciso saber para planejar essa implantação?”. Quando planejamos uma implantação de protocolo de roteamento como o EIGRP você precisa conhecer a rede, portanto a primeira fase é coletar as informações para identificar as condições atuais da rede e já definir os requisitos para o futuro, tais como: 

 



Topologia da rede detalhada, incluindo tipos de links utilizados e utilização atual desses links. Redes IP utilizadas (redes e endereços IP das interfaces dos roteadores ou VLANs). Modelos de roteadores e versões de IOS para verificar a compatibilidade entre eles e se há suporte a todas as facilidades que serão utilizadas. Normalmente, esse ponto não interfere na implantação do EIGRP, porém dependendo do recurso ou feature necessária um upgrade de IOS pode ser necessário antes de iniciar a implantação. Necessidades de futuras ampliações ou previsão de crescimento da rede nos próximos cinco anos (esse prazo pode variar dependendo de cada projeto).

Um bom projeto de endereçamento IP permite a sumarização de rotas, o que pode economizar banda e melhorar a performance do protocolo de roteamento. Apesar do EIGRP não exigir um projeto hierárquico de rede ele pode ser bem mais eficiente se esse ponto for considerado nessa etapa antes de realizar a configuração dos roteadores. Uma vez coletadas as informações sobre a condição atual da rede e suas necessidades futuras é hora de planejar como vamos implantar o EIGRP na rede de uma maneira macro, incluindo:   

Detalhes sobre sumarização e uso de áreas stub. Possíveis alterações na métrica das interfaces para melhorar o uso da largura de banda. Definição de parâmetros gerais como o AS a ser utilizado, etc.

Para finalizar o plano de implantação devemos incluir os detalhes para a atividade de campo e também definir os testes de validação do ambiente após a implantação do EIGRP. Abaixo seguem alguns detalhes a serem elaborados: 





Topologia final exata a ser implementada, contendo redes IP, endereços das interfaces dos roteadores, número de AS do EIGRP, lista dos roteadores que terão EIGRP implementado, quaisquer parâmetros que não sejam padrão e precisem ser alterados via comando, ou seja, o máximo de informações de uma maneira visual e o mais simples Lista de possível. atividades (tasks ou checklist) de implantação para cada roteador que estiver envolvido nas mudanças. Nessa lista temos que cuidar com o que inserir, normalmente é feita com atividades macro e relevantes, porém dependendo do padrão de cada empresa pode ser exigido um documento detalhado da implantação e incluir um fallback, ou seja, um procedimento de como voltar ao estado anterior em caso da atividade não ser bem sucedida. Por último deve-se elaborar um documento contendo os testes de validação do ambiente após a implantação para garantir que o objetivo final foi alcançado e tudo está funcionando conforme planejado. Por exemplo, pode ser elaborado um caderno de testes para ser executado em cada roteador verificando os vizinhos, tabelas de


  

 






  




Página 77  



 


roteamento, tabela de topologia do EIGRP, testes de ping e trace para conectividade, testes de acesso à serviços de rede para garantir comunicação até a camada 7, etc. Em alguns casos o plano de testes pode até conter testes de redundância, por exemplo, a rede tem dois links WAN e deseja-se garantir após a implementação do EIGRP que se o principal falhar o backup assumirá, portanto faz-se um teste de desligamento e continuidade de comunicação após a falha do link principal. Portanto, os testes a serem realizados dependem da complexidade do ambiente e da exigência do contratante! 4.1 Configuração Básica A ativação do EIGRP é realizada em modo de configuração global através do comando “router eigrp AS-Number”, onde o AS-Number é o número de sistema autônomo que deve ser o mesmo em todos os routers que devem trocar informações. Além disso, no CCNA aprendemos a configurar o EIGRP principalmente fazendo o anúncio das redes classfull diretamente conectadas com o comando “network” e também o comando “no auto-summary” para que as sub-redes fossem anunciadas, lembra-se disso? Portanto, o EIGRP é ativado entrando em modo de configuração global, depois entraremos em modo de configuração do roteador e teremos que identificar as redes que farão parte do AS. Lembre-se que os números de AS (Autonomous system numbers) devem ser iguais para que dois roteadores EIGRP formem uma vizinhança e sejam capazes de trocar informações de roteamento. Veja um exemplo abaixo: Router(config)#router eigrp 100 Router(config-router)#network 192.168.10.0

Você pode utilizar também uma máscara curinga para identificar de forma precisa qual interface fará parte do EIGRP no comando network, por exemplo, se um roteador tem duas interfaces — fa0/0 (192.168.10.1/27) e fa0/1 (192.168.10.33/27) — e precisa que o EIGRP rode apenas na interface fa0/0, podemos utilizar o seguinte comando: Router(config-router)#network 192.168.10.0 0.0.0.1

Com a máscara curinga 0.0.0.1 temos correspondência apenas com os IPs 192.168.10.0 e 192.168.10.1, portanto somente a interface fa0/0 será incluída nos anúncios do EIGRP. Outra maneira de fazer isso seria com a máscara 0.0.0.0 configurando o comando da seguinte maneira:”Router(config-router)#network 192.168.10.1 0.0.0.0” , assim o roteador pega apenas a rede da interface fast 0/0. A regra é bem simples, veja abaixo: 1. Os vizinhos devem ter configurado o mesmo número de AS. 2. O roteador irá habilitar o EIGRP nas interfaces que correspondam com o que foi configurado no comando “network” enviando hello nessas interfaces e anunciando aos vizinhos a sub-rede configurada nelas. 3. Se você não for utilizar a máscara curinga (widlcard mask) então anuncie usando as redes classfull A, B ou C. Nesse caso o roteador habilita o EIGRP em TODAS as interfaces que estejam configuradas em sub-redes da classe definida no comando network.


  

 






  




Página 78  



 


4. Se a máscara curinga foi utilizada o roteador fará um processo de correspondência (match), similar a uma ACL, e vai ativar o EIGRP somente nas interfaces que estiverem dentro da faixa definida pelo IP e máscara curinga. Você pode estar se perguntando: “e como eu devo fazer na prova? Anuncio a rede classfull ou uso máscara curinga?”. A resposta é simples: “Depende do que foi solicitado!”. Se o exercício pedir para anunciar somente as interfaces ou as interfaces exatas que irão participar do EIGRP utilize máscara curinga. Como o CCNP é um nível mais avançado pode ser cobrada a interpretação da solução nas questões. Não se esqueça que a métrica padrão do EIGRP depende da largura de banda configurada no comando bandwidth em interfaces seriais, portanto a não configuração desse parâmetro pode afetar o cálculo da métrica! A configuração da largura de banda se dá com o comando abaixo: R1(config)#interface s0/0 R1(config-if)#bandwidth kbps

Para as interfaces LAN (eth, fast ou giga) o roteador consegue sozinho determinar a largura de banda. Além disso, o atraso ou delay pode também ser configurado em modo de configuração de interface com o comando abaixo: R4(config)#int s0/1 R4(config-if)#del R4(config-if)#delay ? <1-16777215>

Throughput delay (tens of microseconds)

Note que o valor é em décimos de micro segundos e pode ser utilizado para alterar a métrica sem necessidade de alteração da velocidade. Com os comandos abaixo você pode verificar após a configuração as três tabelas do EIGRP: 







Show ip eigrp neighbors: visualizar a tabela de vizinhança, ou seja, os routers que trocaram hello com o roteador local e formaram vizinhança. Show ip eigrp topology: verificar a tabela de topologia, ou seja, as rotas sucessoras e sucessoras viáveis (backup) que o roteador aprendeu via EIGRP. Show ip route: verificar a tabela de roteamento com as melhores rotas aprendidas via EIGRP. Show ip protocols: verificar as configurações gerais do EIGRP, tais como balanceamento de carga, rotas anunciadas, etc.


  

 






  




Página 79  



 


4.2 EIGRP Através da WAN O EIGRP pode ser utilizado em diversos tipos de rede WAN, desde redes ponto a ponto até redes MPLS (Multiprotocol Labeling Switching), porém em redes MPLS e Frame-relay temos algumas características próprias que devem ser analisadas com mais cuidado, sendo esse o objetivo desse tópico. 4.2.1 EIGRP sobre Frame Relay

O frame-relay, diferente de circuitos ponto a ponto, cria “caminhos virtuais” ou VCs (Virtual Circuits) entre dispositivos finais (CPE – Customerchamado PremiseDLCI Equipment), os Connection quais são identificados peloosendereço de camada 2 do frame-relay – Data Link Identifier. Cada DLCI deve ser mapeado ao endereço de camada 3 de seu vizinho, processo que pode ser realizado manualmente ou dinamicamente utilizando-se o Inverse ARP. Portanto, em uma rede frame-relay cada conexão será identificada com um DLCI, o qual deve ter mapeado o endereço IP do dispositivo remoto para que os pacotes possam ser enviados até ele através de uma nuvem frame-relay através de um DLCI local. Por isso o nome ARP Inverso ou Inverse ARP, pois no ARP mapeamos um endereço IP remoto ao MAC remoto e aqui mapeamos um endereço de camada 2 local (DLCI local) ao endereço de camada 3 remoto. A comunicação entre os dispositivos finais ou CPEs e a nuvem frame-relay se dá através de um protocolo local que roda entre o CPE e seu switch frame-relay chamado LMI, lembrando que normalmente esse parâmetro não precisa ser configurado para IOSs superiores à versão 11.3. O frame-relay pode sercompleta). conectado em dois tiposentre de topologia: “partial mesh” (malha parcial) ou “full-meshed” (malha A diferença uma rede full-meshed para uma partial meshed é que na primeira todos os PVCs possíveis devem ser criados entre os CPEs. Uma malha parcial muito utilizada na prática é a Hub and Spoke, representada na figura abaixo. Nessa rede temos um roteador central chamado de Hub e vários routers remotos chamados Spokes.


  

 






  




Página 80  



 


Portanto, quando o roteador Hub quiser enviar pacotes para o Spoke_A, por exemplo, ele enviará os quadros via o circuito virtual do frame-relay identificado com o DLCI 102. Esses quadros serão encaminhados ao switch local onde o Hub está conectado e direcionado para o Spoke_A que receberá as informações no DLCI 201, portanto quando ele for responder ao Hub ele enviará as informações para o DLCI 201 e o Hub as receberá no DLCI 102. Se dois spokes quiserem trocar mensagens eles deverão encaminhar ao Hub para que ele sirva de intermediário nessa topologia. Em termos de vizinhança nessa topologia ela será estabelecida apenas entre o roteador Hub e cada um dos spokes, sendo que os spokes não estabelecerão vizinhanças entre si, pois para que haja esse estabelecimento seriam necessários PVCs criados entre eles. Portanto, em um “show ip eigrp neighbors” (tabela de vizinhança) o Hub terá como vizinho os spokes A, B, C e D, porém cada Spoke terá apenas o Hub em sua tabela. As topologias em malha completa não têm restrições com relação ao funcionamento ou estabelecimento de vizinhanças no EIGRP, pois haverão PVCs criados entre todos os CPEs. É importante lembrar que para as topologias em malha parcial, especialmente Hub and Spoke, quando conectadas com interfaces ou subinterfaces multiponto essas ficam sujeitas ao Split Horizon. Na prática ocorre que o Hub irá conhecer as redes dos spokes, porém os spokes conhecerão apenas as redes do Hub, pois a rede dos vizinhos spokes será bloqueada pelo split horizon. Por exemplo, quando o spoke A anuncia suas redes ao Hub ele não poderá retransmitir esse mesmo anúncio para os DLCIs 103, 104 e 105, pois em uma rede NBMA todos os DLCIs estariam na mesma interface, subinterface e consequentemente na mesma rede ou sub-rede IP, portanto o split horizon não permitirá o encaminhamento do anúncio na mesma interface. Para resolver esse problema podemos utilizar subinterfaces ponto a ponto ou então desativar o split horizon no roteador Hub. Analise a topologia da figura abaixo onde as interfaces estão configuradas com o frame-relay padrão nas interfaces físicas e R1 é o roteador HUB com DLCIs apontando para R2 e R3 conforme tabela de encaminhamento do switch frame-relay FR1.


  

 






  




Página 81  



 


Se nenhuma configuração extra for realizada os roteadores R2 e R3 apenas visualizarão suas próprias redes e a rede de R1 e não conseguirão visualizar em suas tabelas de roteamento as redes um do outro. Veja exemplo do show ip route no roteador R2 abaixo e note que a rota para R3 está faltando: R2#sho ip rou ###Saída Omitida### 10.0.0.0/24 is subnetted, 2 subnets D

10.0.0.0 [90/2195456] via 192.168.1.1, 00:00:32, Serial0/0

C

10.0.1.0 is directly connected, FastEthernet0/0 192.168.1.0/29 is subnetted, 1 subnets

C

192.168.1.0 is directly connected, Serial0/0

R2#

Agora vamos desativar o split horizon em R1 para que as rotas possam ser aprendidas por R2 e R3 com o comando dentro da interface serial 0/0 “no ip split-horizon eigrp 100”: R1#conf t Enter configuration commands, one per line.

End with CNTL/Z.

R1(config)#int s0/0 R1(config-if)#no ip split-horizon eigrp 100

R1(config-if)# *Mar

1 01:45:01.471: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.3 (Serial0/0) is resync: split horizon changed

*Mar

1 01:45:01.475: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.2 (Serial0/0) is resync: split horizon changed

R1(config-if)#

Note que após o comando imediatamente o EIGRP faz uma resincronização (resync) passando as redes para os vizinhos R2 (192.168.1.2) e R3 (192.168.1.3). Após esse comando veja o que acontece em R2. Primeiro o EIGRP avisa um resincronismo e um “gracefull restart”, ou seja, a vizinhança está sendo reinicializada. Após isso com o show ip route já conseguiremos visualizar a rede de R3 10.0.2.0 na tabela de roteamento. R2# *Mar

1 01:45:10.179: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.1 (Serial0/0) is resync: peer graceful-restart

R2# R2#sho ip rou ###Saída Omitida### 10.0.0.0/24 is subnetted, 3 subnets D

10.0.2.0 [90/2707456] via 192.168.1.1, 00:02:23, Serial0/0

D

10.0.0.0 [90/2195456] via 192.168.1.1, 00:05:22, Serial0/0

C

10.0.1.0 is directly connected, FastEthernet0/0 192.168.1.0/29 is subnetted, 1 subnets

C

192.168.1.0 is directly connected, Serial0/0


  

 






  




Página 82  



 


Lembre-se que a configuração padrão do frame-relay nas interfaces Cisco faz com que todas as interfaces estejam na mesma sub-rede, chamada de rede NBMA ou Non-broadcast Multiple Access Network. Aqui nesse detalhe é onde na prática devemos tomar cuidado na escolha de que opção devemos utilizar para a configuração das interfaces frame-relay, pois ela pode ser: 







Sem subinterface: todas as interfaces ficam na mesma rede IP e são NBMA, portanto estão sujeitas ao split-horizon. Com subinterfaces ponto multiponto (point-to-multipoint): as interfaces físicas deixam de ser utilizadas, mas mesmo assim as subinterfaces estão sujeitas ao splithorizon e são NBMA. Com subinterfaces ponto a ponto (point-to-point): as interfaces são divididas em subinterfaces que emulam circuitos ponto a ponto, portanto para cada conexão entre dois pontos será necessária uma rede IP /30 no mínimo. Configuração mista com interfaces ponto a ponto e ponto multiponto: utilizada quando quer se ter partes da rede como NBMA e partes frame-relay ponto a ponto. Nessa topologia mista é importante lembrar do efeito do split-horizon na parte pontomultiponto da rede.

Essas configurações fazem parte do CCNA, em caso de dúvidas faça uma revisão prévia. Dica prática: com a topologia da figura anterior configurada com interfaces multiponto (com ou sem subinterface) para que as interfaces dos roteadores R2 e R3 se comuniquem será necessário o mapeamento estático do IP remoto com o DLCI, conforme mostrado no exemplo abaixo com a configuração das interfaces em cada roteador: R2#show run int s0/0 Building configuration... Current configuration : 165 bytes ! interface Serial0/0 ip address 192.168.1.2 255.255.255.248 encapsulation frame-relay IETF clock rate 2000000 frame-relay map ip 192.168.1.3 201 broadcast end R3#sho run in s0/0 Building configuration... Current configuration : 165 bytes ! interface Serial0/0 ip address 192.168.1.3 255.255.255.248 encapsulation frame-relay IETF clock rate 2000000 frame-relay map ip 192.168.1.2 202 broadcast end

Sem esse mapeamento os roteadores R2 e R3 não conseguirão pingar suas interfaces seriais, pois não existe mapeamento entre o DLCI e o IP remoto devido a eles não terem um PVC configurado diretamente entre eles. Apostila/E-B     

  

 






  




Página 83  



 


4.2.2 Configurando o Bandwidth em Interfaces Frame-relay

O padrão do EIGRP é limitar o envio de suas informações a 50% da velocidade do link, ou seja, em um link serial com a configuração padrão (bandwidth 1544kbps ou T1) o EIGRP poderia consumir até 778kbps com envio dos seus pacotes. Mas onde isso pode influenciar um link WAN? Simples, se o circuito for na realidade um link de 256kbps e você esqueceu de configurar o comando bandwidth o EIGRP poderia utilizar toda a largura de banda disponível com suas informações! Por isso a recomendação de configurar o comando bandwidth ou fazer a sua verificação antes de ativar o EIGRP. Essa porcentagem máxima do link ocupada pelo EIGRP pode ser configurada com o comando “ip bandwidth-percent” dentro da configuração de interface, conforme exemplo abaixo onde vamos limitar o tráfego do EIGRP em 25% da banda da interface: Router(config)#int s0/0 Router(config-if)#ip bandwidth-percent eigrp 100 25

Falando mais especificamente de uma rede frame-relay, lembre-se que uma mesma interface pode ter vários circuitos virtuais e cada PVC pode ter uma largura de banda física e uma taxa garantida menor (CIR). Veja o exemplo da figura abaixo onde R1 tem um link de 256 kbps com a nuvem Frame Relay e dois “permanent virtual circuits” (PVCs) com “committed information rates” (CIR) de 128 Kpbs e 64 Kbps.

Por padrão o EIGRP irá dividir a largura de banda de maneira equivalente entre o número de vizinhos que estiverem estabelecidos por aquela interface, porém analisando a topologia mostrada essa não é uma solução ideal, pois um dos vizinhos não suporta a velocidade de 128kbps (metade dos 256kbps). Ou seja, com um bandwidth de 256 teríamos reservado para o EIGRP da banda (50% de PVC, 256kbps = 128kbps), comoo temos banda máxima50% de 64kbps para cada o que poderia afetar uso dodois linkPVCs entreficaria R1 e uma R3, pois a banda máxima do EIGRP seria igual a CIR configurada para esse circuito. Uma das soluções para resolver esse problema é manter a interface como está e utilizar a menor CIR através de um ajuste com o comando “ip bandwidth-percent”. Portanto nesse caso utilizamos o valor real do bandwidth e com o comando bandwidth-percent configurado para 25%, ou seja, uma largura de banda máxima do EIGRP para 32kbps que é metade do menor CIR configurado.


  

 






  




Página 84  



 


R1(config)#int serial 0/0/0 R1 (config-if)#bandwidth 256 R1 (config-if)#ip bandwidth-percent eigrp 100 25

Lembre-se que temos 2 PVCs portanto são 25% de 256k divididos por dois, que dá 64kbps divididos por dois, ou seja, para cada PVC o EIGRP ocupará no máximo 32kbps. Outra solução em é utilizar subinterfaces point-to-point configurar o comando bandwidth separadamente cada uma das subinterfaces. Veja noeexemplo abaixo onde a serial s0/0.1 pode chegar a 64kbps (50% do total para o EIGRP, ou seja, 128k divididos por 2) e a s0/0.2 até 32k, utilizando o valor padrão do EIGRP que é 50% do que foi configurado no comando bandwidth. R1(config)#int serial 0/0.1 point-to-point R1(config-if)#bandwidth 128 R1(config-if)#frame-relay interface-dlci 100 ! R1(config)#int serial 0/0.2 point-to-point R1(config-if)#bandwidth 64 R1(config-if)#frame-relay interface-dlci 101

No caso da interface do Hub ter a velocidade menor que a soma de todos os CIR (oversubscribed - subdimensionada) normalmente multiplica-se a velocidade da menor CIR pelo número de interfaces para dar o total alocado no comando bandwidth que será utilizado na interface física do Hub, pois assim vamos garantir que a interface com menor velocidade nunca será sobrecarregada.


  

 






  




Página 85  



 


4.2.3 EIGRP sobre MPLS - Metroethernet

O MPLS (Multi Protocol Label Switching) pode fornecer conexões baseadas na camada 2 ou 3 do modelo OSI (Layer 2 ou Layer 3), sendo que em sua nomenclatura padrão os roteadores que estão nas pontas da WAN (edge routers) são chamados de CE (Customer Edge Routers), já no provedor de serviços (ISP) os roteadores WAN são chamados de PE (Provider Edge Routers). Dentro da rede dos ISP’s temos os roteadores chamados de P (Provider Routers), os quais não são visíveis para os CE’s. Veja na figura seguinte a topologia padrão do MPLS.

Com o Ethernet over MPLS (EoMPLS) podemos ter o “Any Transport over MPLS” (AToM) para fornecer conexões Layer 2, como por exemplo no Metro Ethernet. Quando utilizamos o EoMPLS, os roteadores CE enxergam a rede como se tivessem conexões ponto a ponto via Ethernet através da WAN, porém na realidade os CE’s conectam-se via Ethernet com um roteador PE local o qual acaba sendo transparente para os CE’s, assim como o restante da nuvem MPLS. Acompanhe na figura abaixo.


  

 






  




Página 86  



 


Portanto o PE1 recebe os quadros Ethernet do CE1, encapsula os quadros dentro de pacotes MPLS e os envia através da WAN (nuvem MPLS) para o PE2. O PE2 desencapsula os pacotes, remonta os quadros Ethernet e envia para o CE2, fazendo com que a vizinhança entre o CE1 e CE2 em relação ao EIGRP seja direta, não envolvendo os roteadores do ISP no processo de roteamento. Além disso, os roteadores PE não aprendem nenhum endereço MAC nem participam do processo de spanning tree relacionado aos CE’s. 4.2.4

Vizinhança EIGRP em VPN’s MPLS

Quando temos o MPLS em layer 3 os roteadores PE são envolvidos no processo de roteamento quando utilizamos o EIGRP. Essa tecnologia é chamada de Layer 3 MPLS VPN’s ou VPN’s MPLS em camada 3. Nas VPN’s MPLS a conexão entre o CE e PE é realizada em Layer 3, fazendo com que cada P E e CE conectados sejam vizinhos para o EIGRP, porém tanto o PE como CE não enxergam os roteadores P do provedor de serviço que formam a nuvem MPLS. Portanto, nesse caso, o CE1 cria uma relação de vizinhança EIGRP com o roteador PE1, ou seja, quando o CE1 envia updates do EIGRP sobre suas redes ao router PE1, ele deve instalar as rotas na devida tabela de “Virtual Routing and Forwarding” (VRF) e retransmitir via WAN através de pacotes MPLS essas informações ao PE2. Por sua vez, o PE2 é um vizinho do EIGRP em relação ao CE2, logo ele deve enviar através do EIGRP os updates de roteamento normalmente ao CE2.

Quando utilizamos EIGRP sobre MPLS devemos garantir que tanto os clientes como o provedor de serviços utilizem a mesma configuração básica do EIGRP, tais como número de AS e autenticação. 4.3 Customizações no EIGRP O EIGRP permite diversas customizações para melhoria de seu desempenho, sendo que nesse tópico estudaremos o comando passive-interface, como configurar troca de mensagens em unicast com os vizinhos (comando neighbor) e a sumarização de rotas.


  

 






  




Página 87  



 


4.3.1 Passive Interface

O comando “passive-interface” é utilizado dentro do modo de configuração do EIGRP e tem a função de desabilitar o envio de updates de roteamento e mensagens de hello através da saída da interface. No caso do RIP ele não envia anúncios quando o passive-interface é ativado, porém no EIGRP e OSPF os pacotes de hello também não são enviados, portanto evitando que vizinhos sejam descobertos através dessas interfaces. Existem duas maneiras de se utilizar o comando, sendo que a primeira é desabilitar o protocol interface por interface (uma a uma) utilizando o comando “passive -interface” dentro do modo de configuração do protocolo de roteamento. A segunda maneira é usar o processo inverso, ou seja, desabilitar o envio de updates em todas as interfaces e ativar apenas aquelas interfaces que realmente necessitam participar do processo de roteamento. Para desabilitar o envio de updates em todas as interfaces utilizamos o comando “passive-interface default”, depois para habilitar as interfaces corretas utilizamos o comando “no passive-interface” para cada uma das interfaces. Veja o exemplo abaixo onde no roteador R1 somente a interface serial 0/0 deve enviar e receber anúncios do EIGRP. R1(config)#router eigrp 100 R1(config-router)#passive-interface default R1(config-router)#no passive-interface s0/0

desabilitar envio de anúncios por será uma anunciada interface, se vocêosanunciar aApesar rede do quepassive-interface essa interface pertence noocomando network ela para demais vizinhos normalmente. 4.3.2 Unicast Neighbors - Mensagens em Unicast para Vizinhos EIGRP

Como já estudamos no CCNA e aqui no CCNP Route, o EIGRP por padrão utiliza o endereço de multicast 224.0.0.10 para troca de mensagens entre seus vizinhos. Você pode configurar o roteador para utilizar endereços de unicast ao invés de multicast através do comando “neighbor” e definindo o endereço IP do vizinho, porém esse IP deve estar na mesma sub-rede em que as interfaces ou subinterfaces dos vizinhos irão se comunicar e não podem ser IPs secundários. Veja um exemplo abaixo onde o roteador R1 possui dois vizinhos com IP 192.168.1.2 e 192.168.1.3. R1(config-router)#neighbor 192.168.1.2 serial 0/0 R1(config-router)#neighbor 192.168.1.3 serial 0/0

Se na configuração forem utilizadas subinterfaces e o IP estiver configurado nela deve-se referenciar corretamente à subinterface, pois colocamos o IP e a interface ou subinterface onde o IP está configurado. Uma vez utilizado esse comando deveremos utilizá-lo em todos os vizinhos, pois ele desabilita o envio e recebimento de multicasts para descoberta de vizinhança pelo EIGRP. Portanto se inserirmos o comando em R1, o qual é vizinho de R2 e R3, automaticamente as vizinhanças irão cair até que o comando seja configurado também em R2 e R3.


  

 






  




Página 88  



 


Com o comando “show ip eigrp neighbors detail” você verá o termo “Static neighbor” identificando que foi configurada uma vizinhança estática naquele roteador através do comando neighbor. R1#show ip eigrp neighbors detail IP-EIGRP neighbors for process 100 H 0

Address

Interface

192.168.1.2

Se0/0

Hold Uptime

SRTT

(sec)

(ms)

133 00:07:13

RTO

Q

Seq

Cnt Num

37

222

0

13

38

228

0

10

Static neighbor

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1 1

192.168.1.3

Se0/0

130 00:09:52

Static neighbor

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1 R1#

Portanto, esse comando é utilizado para economia de banda com envio de multicasts através da rede. Nesse ponto também é interessante analisar um detalhe sobre o EIGRP sobre “como ele insere rotas tabela de roteamento”. Normalmente estamos acostumados a pensar no comando “network”, ou seja, as redes configuradas nesse comando que serão anunciadas e irão popular a tabela de roteamento, porém as redes contidas no comando neighbor e rotas redistribuídas também serão utilizadas para esse fim. 4.3.3 Sumarização de Rotas

Você deve lembrar que o EIGRP, assim como o RIP, por padrão faz a sumarização automática utilizando redes classful (classes A, B ou C cheias) em suas interfaces de borda, porém recomenda-se desabilitar essa sumarização automática através do comando “no autosummary”, dado dentro do modo de configuração de roteamento. Com a sumarização automática temos o problema quando na rede existem descontinuidades de IP ou “discontiguous network”, em inglês. Quando se está usando, por exemplo, redes classe A todas com máscara /24 e entre WANs utilizamos uma /30 estamos causando uma descontinuidade no endereçamento e com o “auto-summary” as redes /30 podem não ser anunciadas. Por isso, para garantir que todos os roteadores tenham a mesma informação de roteamento recomenda-se desativar a sumarização automática e para minimizar o número de rotas trocadas utilizar a sumarização manual. No EIGRP é possível também a configuração de rotas sumarizadas manualmente por interface. Quando ativamos uma rota sumário outra rota apontando para a interface null0 é criada automaticamente para evitar loops de roteamento. Essa configuração além de diminuir a quantidade de rotas que deverão ser anunciadas entre ser os vizinhos, reduz ono número de queries, updates e ACKs que eventualmente devem trocados também entre vizinhos caso da perda de rotas que não possuem um feasible successor disponível, pois o número de rotas anunciadas torna-se naturalmente menor. A configuração da rota sumarizada deve ser realizada dentro da interface com o comando “ip summary-address”. Veja um exemplo abaixo onde a rota padrão será anunciada via FastEthernet0/0 e uma rota sumarizada 172.16.8.0/22 será anunciada através da Serial0/0 para o EIGRP com número de AS 100.


  

 






  




Página 89  



 


R1(config)#int fa0/0 R1(config-if)#ip summary-address eigrp 100 0.0.0.0 0.0.0.0 R1(config)#int s0/0 R1(config-if)#ip summary-address eigrp 100 172.16.8.0 255.255.252.0

Veja as rotas apontando para a Null0 configuradas automaticamente em R1 abaixo. R1#sho ip route eigrp 100 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks D

172.16.8.0/22 is a summary, 00:01:34, Null0

10.0.0.0/24 is subnetted, 3 subnets D

10.0.2.0 [90/2195456] via 192.168.1.3, 00:35:50, Serial0/0

D

10.0.1.0 [90/2195456] via 192.168.1.2, 00:33:11, Serial0/0

D*

0.0.0.0/0 is a summary, 00:01:34, Null0

R1#

Portanto, as vantagens do uso da sumarização de rotas são: 







Redução no tamanho da tabela de roteamento. O EIGRP suporta sumarização em quaisquer pontos da rede, diferente do OSPF que suporta apenas em routers ABR e ASBR (roteadores de borda). A rota sumarizada tem métrica da melhor sub-rede que está dentro do conjunto de rotas que estão sendo sumarizadas. Redução no escopo das queries, pois o roteador que recebe uma query sobre uma subrede que faz parte de uma rota sumarizada não faz sua propagação, a não ser que receba uma query sobre aquela rota sumarizada específica.

As desvantagens do uso da sumarização são que pacotes para sub-redes que fazem parte da rota sumarizada e que estejam eventualmente indisponíveis serão encaminhadas até o destino antes de serem descartados, pois o roteador que recebe uma rota sumarizada não sabe se as sub-redes específicas que fazem parte desse sumário estão Up ou Down. Outra desvantagem é que nem sempre a melhor rota vai ser a escolhida pelo mesmo fato dos roteadores não conhecerem o estado das sub-redes que fazem parte dessa rota sumarizada. Por exemplo, veja na figura abaixo onde o roteador Core 1 tem que enviar um pacote para um Host que está na rede LAN 10.11.1.0/24 pertencente ao roteador B1. Suponha que o link ótimo (que seria entre WAN1 e B1) tenha caído, como Core1 tem uma rota sumarizada 10.11.0.0/16 e não tem como saber que a rota entre WAN1 e B1 existe ou seu estado ele envia o pacote para WAN1 tomando um caminho maior para entregar o pacote (caminho com as setas pretas). Se ele (destacado conhecesseem todas rotas provavelmente teria escolhido o problema caminho diretamente por WAN2 azul)aspara entregar os pacotes. O nome desse é o “Suboptimal Forwarding”, pois como o roteador que recebe uma rota sumarizada não conhece a topologia como um todo nem sempre a melhor rota será escolhida.


  

 






  




Página 90  



 


4.3.4 Exemplo de Design de Rede com Sumarização

Algumas questões sobre como montar a rede, que blocos de IP utilizar em cada ambiente de rede, como calcular as rotas sumarizadas, onde realizar a sumarização e que arquitetura podemos utilizar devem ser pensadas na fase de projeto ou design da rede. O cálculo da rota sumarizada ou sumário é o mesmo utilizado no CCNA, porém vamos passar uma dica prática para verificar se as redes estão realmente na faixa escolhida para sumarização. Para isso vamos utilizar o princípio da máscara curinga que é o inverso da máscara de sub-rede, por exemplo, você tem uma rota sumarizada 172.16.16.0/20 e quer saber a faixa de IP’s que está nesse sumário. Uma /20 é a mesma coisa que 255.255.240.0, invertendo essa máscara temos 0.0.15.255 (255.255.255.255 - 255.255.240.0), portanto o range de IP’s vai de 172.16.16.0 até a soma desse IP mais a máscara inversa: 172.16.31.255, ou seja, as redes sumarizadas estão entre 172.16.16.0 até 172.16.31.255. Sobre a alocação das faixas de IP veja um exemplo na figura abaixo, onde temos dois equipamentos no Core (Core1 e Core2), dois roteadores concentradores dos links WAN (WAN1 e WAN2) e vários roteadores remotos nomeados como “Bx” (B1 até Bx).


  

 






  




Página 91  



 


Note que conectados aos roteadores de Core temos um ambiente de produção da empresa e o Data Center, os quais foram alocados com faixas de IP /19 e /16 respectivamente. Dentro de cada ambiente existirão várias VLANs e cada uma com uma sub-rede dentro dessas faixas. Para os links LAN-to-LAN entre os switches de Core e os roteadores WAN1 e WAN2 foi escolhida a faixa de IPs 10.9.1.0/24, a qual será dividida em diversas /30 para a conexão ponto a ponto entre os dispositivos. Depois entre os roteadores WAN 1 e WAN2 e os roteadores remotos (branch routers) foi alocada a faixa concentradores 10.1.0.0/16 para acomodar os diversos PVCs que interligarão as unidades remotas ao Data Center passando por WAN1 e WAN2. Para as redes LAN das unidades remotas foram destinadas duas faixas de IP: 10.11.0.0/16 e 10.12.0.0/16, possibilitando um design de rede redundante e com o balanceamento das conexões dos roteadores remotos com WAN1 e WAN2. Note na figura que parte dos roteadores remotos serão alocados com a faixa dentro do bloco 10.11.0.0/16 e parte com 10.12.0.0/16, porém cada roteador terá dois PVCs, um apontando para WAN1 e outro apontando para WAN2. Nos routers alocados com a faixa 10.11.0.0/16 o PVC que aponta para WAN1 terá uma melhor métrica, por exemplo, o bandwidth configurado como “1000”, e para o segundo PVC que aponta para WAN2 o PVC terá largura de banda 500, assim o router alocado na faixa do 10.11 terá a saída por WAN1 e caso o PVC caia ele redireciona os pacotes para WAN2. Quando essas redes sumarizadas forem anunciadas de WAN1 e WAN2 em direção ao Data Center, a rota para 10.11 será preferencialmente escolhida pelos switches Core apontando para WAN1, pois a métrica da rota sumarizada será melhor que a anunciada por WAN2, já para a rede 10.12 será ao contrário, os switches Core apontarão para o roteador WAN2. Além disso, os switches de Core também anunciarão as redes do Data Center e da produção em direção aos roteadores remotos como rotas sumarizadas. 4.4 Balanceamento de Cargas O EIGRP, assim como o RIP e OSPF, automaticamente faz o balanceamento de cargas entre quatro rotas de métricas iguais (Equal Cost Load Balancing), podendo chegar até 16 ou 32 rotas dependendo da versão do IOS que estiver rodando no roteador. O que torna o EIGRP único é a capacidade de balancear carga proporcionalmente entre rotas de métricas diferentes (Unequal Cost Load Sharing). Esse recurso pode ser ativado através do comando “variance”, o qual pode ir de 1 a 128, sendo que o valor 1 torna o balanceamento de carga somente entre rotas de mesma métrica e acima de 1 funciona como um multiplicador, ou seja, a carga é balanceada entre rotas que tem métrica igual até a melhor métrica vezes o variance. Por exemplo, se temos uma rota sucessora com métrica 1000 e utilizamos o variance 10, balanceamento carga irá entre rotas àcom métrica 1000 (RD

  

 






  




Página 92  



 


Veja o exemplo abaixo onde vamos configurar o variance como 2, pois o roteador R1 tem uma rota principal ou successor com métrica 12.345 e uma sucessora viável com métrica 20.182 que não está na tabela de roteamento, porém está presente na tabela de topologia. Com o variance 2 o balanceamento irá entre rotas que estão com métrica de 12.345 até 24.708, portanto a rota com métrica 20.182 irá entrar na tabela de roteamento e será acionado o balanceamento de cargas entre elas. R1(config)#router eigrp 100 R1(config-router)#variance 2

Lembre-se que, por padrão, o balanceamento de carga é realizado entre rotas de mesmo custo ou não vem com quatro rotas no máximo para executar o processo, caso seja necessário alterar o comando utilizado é o maximum-paths dentro do modo de configuração do EIGRP, veja exemplo abaixo. R1(config)#router eigrp 100 R1(config-router)#maximum-paths 5

Caso seja necessário desabilitar o balanceamento de cargas basta configurar o maximum-paths para o valor “1”. 4.4.1 Balanceamento de Carga por Fluxo e por Pacotes

Como já estudamos, o balanceamento de carga é uma propriedade tanto do RIP, OSPF e EIGRP utilizar um segundo link backup para compartilhar o envio de dados. Veja a figura a seguir com um exemplo de balanceamento de carga de custos iguais por pacotes.

Quando o protocolo de roteamento ativa o balanceamento de carga em dois ou mais links se um host envia pacotes para umadestino) rede de entre destino roteador divide os pacotes (per packet ) ou fluxos (per destination – por asointerfaces balanceando , dividindo o envio dos pacotes (carga) entre esses caminhos.


  

 






  




Página 93  



 


No balanceamento de carga por pacotes os roteadores enviam um pacote para cada interface que participa do processo. Já por fluxo (ou destino) o balanceamento de carga é realizado por conexão TCP ou UDP aberta, ou seja, se um usuário solicitou uma página de internet aquele fluxo vai seguir até o final por um link, quando um segundo usuário abrir outra sessão na sequência o fluxo dele será encaminhado ao segundo link. O tipo de balanceamento de carga depende do tipo do encaminhamento de pacotes que está configurado nas interfaces do roteador. No process switching você terá balanceamento de carga padrão por pacotes, já para o fast switching e CEF o padrão é balanceamento de carga por fluxo (destino). O comando o process switching “no “ip ip route-cache para habilitar o fast switching é opara “ip habilitar route-cache ” e para habilitaré o CEF route-cache”,cef ”. Esses comando são inseridos em modo de configuração de interface, veja exemplo abaixo onde deixamos a interface fast0/0 com process switching, a fast0/1 com fast switching e a fast 1/0 como CEF: Router#config t Router(config)#interface fast 0/0 Router(config-if)# no ip route-cache Router(config)#interface fast 0/1 Router(config-if)# ip route-cache Router(config-if)# Router(config)#interface fast 1/0 Router(config-if)# ip route-cache cef

Para configurar o modo de operação do balanceamento de carga por pacote ou por destino utilize o comando “ip load-sharing” também em modo de configuração de interface, veja um exemplo abaixo: R3(config-if)#ip load-sharing ? per-destination Deterministic distribution per-packet Random distribution R3(config-if)# ip load-sharing per-packet R3(config-if)#

4.5 Autenticação no EIGRP Por padrão a autenticação não é um recurso habilitado nos protocolos de roteamento, porém protocolos como RIPv2, IS-IS e OSPF suportam autenticação simples entre os roteadores vizinhos, através de “clear-text password” ou senha com texto em modo claro, sem criptografia. Já o EIGRP não suporta autenticação simples, ao invés disso pode utilizar autenticação para cada pacote trocado utilizando um Hash MD5 para proteger a informação através de chave uma pré-compartilhada (pre-shared key). Este processo acaba sendo muito mais seguro, pois ao invés de trocar a senha através da rede o que é enviado é uma “message digest”, ou seja, o produto de uma conta feitacaso coméachamada chave pré-compartilhada segurança. A senha nesse de chave ou key.utilizando o MD5 como protocolo de Quando habilitada a autenticação, o EIGRP autentica cada pacote recebido verificando a srcem de cada pacote no seu Hash MD5, caso o valor calculado localmente seja diferente do recebido no pacote ele é descartado automaticamente pelo EIGRP, sem envio de aviso do descarte (descarte silencioso ou “silent drop”).


  

 






  




Página 94  



 


Um possível plano de implementação para configurar a autenticação em protocolos de roteamento seria: 1. Analisar as configurações atuais dos roteadores. Para o EIGRP devemos determinar o número do AS e as interfaces que serão configuradas. 2. Decidir o tipo de autenticação, sendo que o EIGRP deve ser com Hash MD5. 3. Definir as “key strings” (chaves ou senhas) e quantas chaves serão utilizadas. 4. Opcionalmente, definir o tempo de vida das chaves (key lifetimes). Antes de iniciarmos a tratar mais especificamente das configurações, a autenticação usa o conceito de molho de chaves ou “key-chain”, ou seja, você tem um molho de chaves e para abrir uma porta deve escolher a chave certa. Na configuração do EIGRP temos o mesmo conceito e podemos criar várias chaves, inclusive algumas com tempo de vida (lifetime) curto para implantações temporárias, por exemplo. Para configurar a autenticação no EIGRP devemos seguir os seguintes passos: Passo 1: Configurar o “key chain” para configuração do grupo de chaves. Passo 2: Configurar uma ou mais chaves dentro do “key chain”, sendo que o roteador irá verificar todos os pacotes de entrada utilizando essa lista de chaves e utilizará a primeira válida que for encontrada. Passo 3: Configurar a senha ou “authentication string” para a chave específica, podendo repetir os passos 2 e 3 para adicionar mais chaves caso necessário. Passo 4: Esta etapa é opcional permitindo que seja configurado um tempo de vida (lifetime) para chaves dentro do molho de chaves (key chain). Se for utilizada essa opção o mesmo tempo de vida deve estar sincronizado entre os roteadores vizinhos, pois senão um pode utilizar uma chave e na outra ponta estar sendo esperada outra diferente. Passo 5: Habilitar a autenticação e definir a “key chain” dentro das interfaces corretas. Passo 6: Configurar o MD5 como tipo de autenticação. No exemplo abaixo o EIGRP será configurado para aceitar autenticação. O lifetime dos pacotes foi configurado na chave “key 1” iniciando às 10:15 com duração de 300 segundos, além disso, foi configurado para receber pacotes que utilizam a chave “key 1” iniciando às 10:00 até às 10:05. Também vamos configurar uma chave “key 2” sem as opções de lifetime, ou seja, ela será válida sempre. Para isso os relógios dos roteadores devem estar sincronizados de preferência utilizando um servidor NTP. R1(config)#key chain R1_Auth R1(config-keychain)#key 1 R1(config-keychain-key)#key-string dltec123 R1(config-keychain-key)#send-lifetime 10:15:00 22 jan 2013 duration 300 R1(config-keychain-key)#accept-lifetime 10:00:00 22 jan 2013 10:05:00 22 jan 2013 R1(config-keychain-key)#key 2 R1(config-keychain-key)#key-string dltec1234 R1(config-keychain-key)#exit R1(config)#interface s0/0 R1(config-if)#ip authentication mode eigrp 100 md5 R1(config-if)#ip authentication key-chain eigrp 100 R1_Auth


  

 






  




Página 95  



 


Para verificar as chaves criadas utilize o comando “show key chain”, além disso com o “show ip eigrp neighbors” você pode verificar se as vizinhanças após a configuração das chaves continuam estabelecidas ou utilizar o comando debug eigrp packets para verificar as mensagens em tempo real e verificar os problemas de autenticação caso as vizinhanças não subam. Lembre-se que a autenticação deve ser configurada em ambas as pontas para que o EIGRP suba. Veja abaixo a saída do comando “show key chain”, note que para a Key 2 temos a frase “always valid” que significa “sempre válidas”. R1#sho key chain Key-chain R1_Auth: key 1 -- text "dltec123" accept lifetime (10:00:00 UTC Jan 22 2013) - (10:05:00 UTC Jan 22 2013) send lifetime (10:00:00 UTC Jan 22 2013) - (300 seconds) key 2 -- text "dltec1234" accept lifetime (always valid) - (always valid) [valid now] send lifetime (always valid) - (always valid) [valid now]

4.6 Melhorando a Escalabilidade do EIGRP – Roteamento Stub Escalabilidade é um termo muito utilizado em redes, principalmente pela Cisco, para designar o crescimento da rede de forma simples e sustentável. Por exemplo, imagine que você tenha uma rede em operação e agora é necessário adicionar mais 100 usuário. O conceito de escalabilidade torna essa tarefa possível sem a necessidade de reprojetar todo o ambiente, bastando apenas seguir os padrões de inserir os switches, VLANs, roteadores, etc como um “jogo de lego”, ou seja, apenas encaixando mais peças quando queremos aumentar a estrutura inicial. Os fatores que afetam a escalabilidade do EIGRP são principalmente: 







O número de rotas a serem trocadas entre os vizinhos (isso pode ser minimizado com a sumarização). O número de roteadores que devem ser informados sobre mudanças na topologia, pois quanto maior o número mais query/ACK ou updates serão trocados nas mudanças de topologia. O número de rotas alternativas na rede. O número de saltos de uma ponta à outra da rede, chamada de profundidade da topologia (topology depth).

Para minimizar esses efeitos podemos utilizar a sumarização de rotas, conforme já mencionado, tentar manter a profundidade da rede menor ou igual a sete e limitar o escopo das solicitações (queries) do EIGRP. A sumarização já foi estudada anteriormente e a profundidade da rede é uma questão do projeto físico e lógico, porém vamos estudar nesse tópico como limitar o escopo das queries do EIGRP através do roteamento Stub. Portanto o “stub routing” ou “roteamento stub” é uma maneira de limitar a propagação de queries quando um roteador precisa de informações sobre rotas alternativas. Para um roteador ser considerado stub ele deve ter uma ou no máximo duas conexões, ou seja, um ou dois vizinhos e não pode ser um roteador de trânsito de informações (transit router). Por exemplo, pode ser um roteador que liga uma unidade remota e possui uma conexão principal e uma reserva, sem possuir mais vizinhos conectados a ele.


  

 






  




Página 96  



 


Esse recurso é muito utilizado na topologia hub-and-spoke para prover redundância, onde temos dois HUBs e cada Spoke tem duas conexões, ou seja, uma para cada HUB por questões de backup. Veja a figura na topologia abaixo.

O segredo dessa configuração é que quando um roteador é configurado como “EIGRP stub” ele notifica aos seus vizinhos e, em caso da perda de uma rota principal, os seus vizinhos não irão enviar query a esse roteador procurando por rotas alternativas. Por padrão um “EIGRP stub router” recebe os anúncios de rotas normalmente de seus vizinhos para que ele possa construir sua tabela de roteamento. O comando para configurar a opção stub fica dentro do modo de configuração do roteamento EIGRP e tem a seguinte sintaxe: eigrp stub [receive-only|connected|static|summary|redistributed]

O comando “eigrp stub” faz com que o roteador compartilhe as rotas diretamente conectadas e sumarizadas com todos os seus vizinhos por padrão, com as opções abaixo podemos alterar algumas características do funcionamento conforme explicação: 









eigrp stub receive-only: Essa opção deve ser utilizada sozinha e faz com que o roteador receba as rotas dos vizinhos, porém não permitirá que o roteador anuncie rotas, nem mesmo as suas rotas, aos demais vizinhos. eigrp : Ativa ocom anúncio das rotasnetwork diretamente conectadas (connected routes)stub que connected foram anunciadas o comando ou redistribuídas dentro do EIGRP. Vem habilitado por padrão. eigrp stub static: Ativa o anúncio de rotas estáticas que foram redistribuídas dentro do EIGRP. eigrp stub summary: Ativa o anúncio das rotas sumarizadas criadas manualmente ou automaticamente e vem habilitado por padrão. eigrp stub redistributed: Permite que o roteador anuncie rotas redistribuídas de outro protocolo ou AS dentro do EIGRP sejam anunciadas.


  

 






  




Página 97  



 


Para visualizar o efeito das configurações e fazer o troubleshooting podemos utilizar os comandos “show ip eigrp neighbors detail”. Nos roteadores stub você verá que o envio de queries estará suprimido (suppressing queries) e, dependo das opções utilizadas, o comando “show ip route” e “show ip eigrp topology” podem confirmar as rotas anunciadas. Veja exemplo do comando abaixo onde o vizinho 10.0.2.2 está configurado como stub. R3#show ip eigrp neighbors detail IP-EIGRP neighbors for process 100 H 1

Address

Interface

10.0.2.2

Hold Uptime

SRTT

RTO

(sec) (ms) 10 00:00:50 42

Se0/1

Q

Seq

Cnt Num 3420 0 8

Version 12.4/1.2, Retrans: 1, Retries: 0

Stub Peer Advertising ( CONNECTED SUMMARY ) Routes Suppressing queries

2

192.168.0.6

Se0/0

12 00:01:26

47

1140

0

8

825

4950

0

10

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 11 0

10.0.0.1

Fa0/0

10 00:02:13

Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 10

Portanto, o padrão quando digitamos “eigrp stub” é igual a digitar “eigrp stub connected summary”. Se quisermos que o roteador anuncie todos os tipos de rotas possíveis devemos utilizar o comando “eigrp stub connected static summary redistributed”. Em versões de IOS mais novas existe também a opção “leak-map”, a qual permite prefixos dinâmicos baseados em “leak-map” serem anunciados pelo roteador stub. Portanto, a opção “eigrp stub” é capaz de melhorar a escalabilidade do EIGRP evitando que a propagação de queries (consultas por rotas backup) “inunde” a rede e consum am banda de forma desnecessária. Além disso, em conjunto com a sumarização de rotas o roteamento stub limita o escopo das queries, melhorando o desempenho do EIGRP. Dica para a prova: falando mais especificamente sobre a topologia Hub-and-Spoke com dois roteadores na unidade central (Headquarter) com cada spoke nas unidades remotas (branches) conectados com um link ou PVC apontando para cada roteador central temos algumas considerações a fazer: 







Para uma implantação de projetos grandes nessa topologia na fase de planejamento é importante ter claro as velocidades de todos os PVCs, política de roteamento e versão de IOS dos roteadores. A velocidade dos PVCs permitirá a configuração correta do bandwidth e da divisão dos links utilizando faixas de IPs para dividir os roteadores remotos entre os dois ou mais roteadores centrais. A política de roteamento permite definir como o tráfego irá ser propagado, por exemplo, caso o link entre o HUB1 e o HUB2 da figura (mostrada no início desse tópico) caia é permitido que as informações sejam trafegadas por entre os spokes? Normalmente não se faz isso, por isso mesmo os spokes são configurados como EIGRP Stub. O que ocorre se não configurarmos os spokes como EIGRP Stub? Simplesmente pode haver uma sobrecarga de queries trocadas entre os equipamentos, aumentando o uso da CPU dos roteadores centrais HUB1 e HUB2 e também o tempo de convergência do EIGRP. Imagine uma rede com mais de 100 roteadores spokes trocando query com os HUBs? Fácil perceber o problema. Apostila/E-B

    

  

 






  




Página 98  



 


Em implantações onde já existem roteadores e vamos mudar a tecnologia é preciso verificar também a versão de IOS de todos os equipamentos e a compatibilidade com o recurso que será configurado antes da implantação, pois isso evita surpresas em campo. Muitas vezes será necessária a homogeneização da versão do IOS e upgrade em alguns dispositivos.

4.7 Active Process Enhancement e Graceful Shutdown A melhoria do processo do tratamento de rotas que entram no estado ativo ou “Active Process Enhancement” permite que os roteadores utilizem mensagens de SIA-Queries e SIA-Replies para evitar a perda da vizinhança desnecessária em caso de condições de SIA (Stuck in Active). Este processo foi introduzido nos IOSs acima da versão 12.2. Isso é feito pelo roteador de srcem enviando uma mensagem de SIA-Query ao seu vizinho quando ele não responde a uma query normal. Se o vizinho responder com um SIA-Reply o roteador de srcem não termina a vizinhança depois dos três minutos, conforme padrão do processo de SIA, pois ele sabe que esse vizinho está respondendo. O “Graceful Shutdown” é um recurso que permite acelerar a convergência da rede em caso de um reload, por exemplo. Antes de finalizar o EIGRP o roteador envia uma mensagem de “adeus” ou “goodbye” para seus vizinhos. Essa mensagem é enviada através de um pacote de “hello” e permite que os vizinhos recalculem imediatamente quaisquer caminhos que serão afetados pela queda desse roteador, evitando que os temporizadores necessitem expirar para depois o vizinho procurar por rotas alternativas. 4.8 Anunciando Rotas Default Existem três maneiras diferentes de se anunciar a rota padrão através do EIGRP: 1. Com o comando “default-network” (retirado da revisão atual do CCNP ROUTE). 2. Configurando uma rota padrão via rota estática e anunciando a rede 0.0.0.0 com o comando network no EIGRP, ou seja, anunciando a rota padrão dentro do EIGRP. 3. Configurando a rota estática padrão e fazendo uma redistribuição (o comando redistribute será visto posteriormente). Vamos usar a topologia da figura abaixo como base para exemplificar as configurações dos itens 2 e 3 citados acima.


  

 






  




Página 99  



 


4.8.1 Anunciando a Rota padrão no EIGRP

Na segunda opção de anúncio da rota padrão através do EIGRP vamos criar uma rota estática padrão e depois anunciar a rede 0.0.0.0 dentro do modo de configuração do EIGRP. Para que a configuração seja possível via o comando network, a rota estática deve apontar para uma interface, pois se apontar para um IP de próximo salto não é considerada como diretamente conectada e o comando network não irá funcionar. No caso da rota estática apontar para um IP remoto utilize o comando “redistribute static” para que ela seja redistribuída dentro do AS do EIGRP. Note na topologia anterior (repetida abaixo) que o IP do gateway é 192.168.1.1. Veja a configuração abaixo para a rota estática apontando para uma interface. R4(config)#ip route 0.0.0.0 0.0.0.0 fast 0/1 R4(config)#router eigrp 100 R4(config-router)#network 0.0.0.0

Agora com a redistribuição e a rota estática padrão apontando para um IP remoto. R4(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.1 R4(config)#router eigrp 100 R4(config-router)#redistribute static


  

 






  




Página 100  



 


4.9 Verificando e Mantendo o EIGRP Para verificar se o EIGRP subiu conforme planejado primeiro é importante ter seguido a fase de planejamento da implantação e realizar tudo conforme esse plano. Partindo desse pressuposto, para verificar o funcionamento do EIGRP temos os principais comandos show abaixo: 













Show interfaces [serial|fast x/y/z]: no início do comando são mostrados os valores que serão utilizados no cálculo da métrica, tais como largura de banda e delay. Show ip protocols: nele você pode verificar os números de AS utilizados, valores das constantes K ativas no cálculo da métrica, quantas rotas estão configuradas para balancear carga e se o variance está ativado para possibilitar Unequal Cost Path, redes anunciadas pelo comando network, se existem interfaces passivas (passive-interface), ect. Show ip eigrp neighbors: permite visualizar a tabela de vizinhança. Lembre-se que antes de trocar rotas os roteadores precisam formar uma vizinhança no EIGRP, se o vizinho não aparece nessa tabela existe um problema de conexão (camadas 1 e/ou 2), as interfaces estão em IPs diferentes ou o número de AS não bate. Verifique a configuração com o “show running-config” e as interfaces com “show ip interface brief”. Show ip eigrp neighbors detail: similar ao comando anterior, porém trás mais detalhes do vizinho, permitindo verificar se o vizinho é stub, por exemplo. Show ip eigrp topology: após formar as vizinhanças os roteadores trocam informações de roteamento, as quais ficam armazenadas na tabela de topologia. Com esse comando será possível visualizar as rotas principais (successor) e backup (feasible successor), além disso, os valores da feasible distance, reported distance e sobre o estado da rota (active, passive, etc.). Esse comando possui várias opções para visualização mais específica da tabela de topologia, as duas principais são: o Show ip eigrp topology all-links : permite visualizar todas as entradas na tabela de topologia, inclusive rotas que não são successors ou feasible successors. o Show ip eigrp topology rede/prefixo: mostra detalhes sobre aquela rota como a largura de banda e delay utilizados no cálculo da métrica. Show ip route: após formada a vizinhança e trocadas as informações de roteamento, as melhores rotas são inseridas na tabela de roteamento e com o show ip route podemos verificar a tabela de roteamento completa do roteador. Para visualização mais específica podemos utilizar alguns parâmetros conforme abaixo para melhorar a pesquisa: o Show ip route eigrp [AS]: mostra as entradas aprendidas somente pelo EIGRP. Opcionalmente se você tiver mais de um AS configurado pode inserir após o comando o número do AS, por exemplo, “show ip route eigrp 100” mostraria as rotas somente do AS com número 100. o Show ip route rede [máscara-decimal]: com esse comando você pode visualizar as informações específicas de uma rede, por exemplo, qual a fonte de aprendizado, métrica, largura de banda e delay utilizados no cálculo da métrica, etc. o Show ip route rede [ máscara-decimal] longer-prefix: mostra todas as subredes que estão dentro do prefixo passado ou maiores, por exemplo, o comando “show ip route 172.16.0.0 255.254.0.0 longer-prefixes” mostra todas as subredes na tabela de roteamento que estão dentro do range do prefixo 172.16.0.0/15 especificado no comando. Show ip eigrp traffic: mostra estatísticas do EIGRP como hello, updates, queries, replies e acknowledgments.


  

 






  




Página 101  



 


Além dos comandos show, para auxiliar na manutenção e resolução de problemas (trobleshooting) temos os comandos “debug”, os quais mostram informações em tempo real de ações e eventos do roteador, para o EIGRP temos os principais comandos abaixo: 









Debug eigrp packet: pode ser utilizado para verificar os pacotes trocados pelo EIGRP, por exemplo, resolver problemas de autenticação e visualizar mensagens de prefixos suprimidos devido ao split horizon. Além disso, pode ser utilizado para verificar se a vizinhança não sobe por configurações diferentes nos valores de k (métricas) ou número de AS, chamados de “mismatch” quando um dos lados tem o valor configurado diferentemente. Debug eigrp fsm: mostra informações em tempo real relacionadas às rotas sucessoras e feasible successor. Debug eigrp neighbor: mostra informações sobre a troca de hellos e formação de vizinhança. Debug ip eigrp: mostra informações de trocas de mensagens do protocolo EIGRP mais especificamente para o IP. Debug ip eigrp notifications: mostra updates enviados e recebidos pelo EIGRP.

Agora assista aos vídeos com o resumo da teoria e sobre a prática relacionada ao EIGRP, na sequência faça os labs sugeridos na área do aluno e o questionário. Em caso de dúvidas utilize o fórum do capítulo para esclarecimento.


  

 






  




Página 102  



 


Capítulo 4 - Implementando o OSPF Multiarea Nesse capítulo estudaremos o OSPF ou Open Shortest Path First, o qual é um protocolo de roteamento classificado como Link State, Classless e aberto, ou seja, pode ser configurado para interligar roteadores Cisco a roteadores de outros fabricantes.

Objetivos do Capítulo Ao final desse capítulo você deverá ter estudado e compreendido os seguintes tópicos: A estrutura do OSPF assim como seu funcionamento, mensagens e métrica; Operação do protocolo OSPF e o relacionamento com seus vizinhos; Configurações básicas e avançadas do OSPF; Configuração da autenticação; Como manter e resolver problemas em redes com OSPF (troubleshooting). 





O foco do CCNA foi o estudo do OSPF single-area, ou seja, todos os roteadores conectados ao backbone via área zero, porém agora no CCNP você estudará detalhes do funcionamento do OSPF e também a configuração do OSPF Multiarea.

 

Divirtam-se e bons estudos!


  

 






  




Página 103  



 



Visão Geral do OSPF _____________ 105

1.1

Topologia de uma Rede OSPF _____ 105

1.2 Nomenclatura do OSPF – Tipos de Redes, Áreas e Roteadores _____________ 107 1.3 2

2.1 3

Métrica do OSPF ________________ 108

Anúncios do OSPF – LSA’s _________ 110

Tipos de LSA ___________________ 111

Operação do OSPF _______________ 112

3.1

Formando Vizinhanças ou Adjacências 112

3.2 Processo de Estabelecimento de Adjacências e Troca de Informações de Roteamento _________________________ 113 4 5

Planejando a implantação do OSPF _ 114 Configuração Básica do OSPF ______ 115

5.1 6

RID – Router I D _________________ 115

Tipos de Redes OSPF _____________ 116

6.1 OSPF em Redes Broadcast – Eleição de DR e BDR ___________________________ 118 6.2 Considerações sobre OSPF em Redes NBMA (Frame-relay e ATM) ____________ 119 6.3 Considerações sobre o OSPF em Redes MPLS 120 7

Configurações Avançadas do OSPF __ 121

7.1

Comando Passive-interface _______ 121

7.2

Sumarização de Rotas ___________ 121

7.3

Anunciando Rotas Default ________ 123

7.4 Escalabilidade no OSPF - Áreas Stub e Not-So-Stubby _______________________ 124 7.5

Links Virtuais___________________ 127

7.6

Configurando a Autenticação no OSPF 128

8 Mantendo e Resolvendo Problemas com OSPF _____________________________ 129


  

 






  




Página 104  



 


1

Visão Geral do OSPF

O OSPF ou Open Shortest Path First (“Use Caminho mais Curto Primeiro”) é um protocolo de roteamento que utiliza padrão aberto, classless, com convergência rápida e usa o custo como uma métrica, sendo que o IOS da Cisco automaticamente associa o custo com a largura de banda (bandwidth) da interface. O OSPF é um protocolo de roteamento link-state (estado de enlace) que usa o algoritmo Shortest Path First (SPF ou algoritmo de Dijkstra, o criador do algoritmo SPF) para determinar a sua melhor caminho para cada rede. A primeira responsabilidade de um roteador link-state é criar um banco de dados que reflita a estrutura da rede, ou seja, criar um banco de dados da topologia exata da rede, diferente do que estudamos para o EIGRP. Os protocolos de roteamento link-state sabem mais informações sobre a estrutura da rede do que outros protocolos de roteamento e, portanto, podem tomar decisões de roteamento mais precisas. Os roteadores OSPF trocam mensagens de hello com seus vizinhos, aprendendo o Router ID (RID) e custo de cada um deles. Essas informações de vizinhança são mantidas na base de dados de adjacência (adjacency database) ou tabela de vizinhança. O roteador então constrói os anúncios chamados de Link State Advertisements (LSA – anúncios de estado de enlace) que incluem informações como RID e custo para cada vizinho. Cada roteador irá trocar seus LSAs com todos os outros demais roteadores, possibilitando que cada um dos dispositivos tenha um conjunto completo de LSAs em um banco de dados de Estado de Enlace (LSDB – Link State Database). Com essas informações cada roteador executa o algoritmo SPF para calcular os melhores caminhos, sendo que as melhores rotas serão inseridas tabela de roteamento ou de encaminhamento. Portanto, nenhuma grande novidade do que deve ter sido estudado sobre o OSPF no CCNA até o momento, porém aqui nesse curso iremos estudar um pouco mais do que é trocado e os tipos de LSA que existem. 1.1 Topologia de uma Rede OSPF Os domínios de roteamento do OSPF são divididos em áreas e uma rede OSPF DEVE conter uma área zero, podendo conter outras áreas, as quais devem ser conectadas à área zero. A área zero é também conhecida como área de backbone ou de trânsito, pois é através dela que as diversas áreas devem se comunicar entre si ou com o mundo exterior. Portanto, nessa topologia o algoritmo SPF é executado dentro de uma área e rotas inter-areas são passadas entre as áreas através do backbone para que elas possam se comunicar. No OSPF temos uma hierarquia de dois níveis, sendo que a área foi concebida como uma área de trânsito e, conforme já citado, as outras áreas devem ser conectadas diretamente à área 0 e somente à área 0. O banco de dados de estado de link deve ser idêntico para cada roteador em uma mesma área.


  

 






  




Página 105  



 


Em termos de design de rede, as áreas OSPF normalmente devem ser compostas entre 50 a no máximo 100 roteadores, dependendo da estabilidade de rede. Quanto mais instável as conexões menos roteadores são aconselháveis a serem compartilhados nessa determinada área. A instabilidade nesse caso são interfaces que ficam subindo e descendo (UP/DOWN) várias vezes, chamado de “flapping” em inglês. Veja a topologia de rede abaixo onde temos um backbone com algumas áreas dividindo as redes remotas.

Portanto, dividir uma rede OSPF em áreas traz os seguintes benefícios:    

Minimizaraoinundação número dedeentradas da tabela roteamento Reprimir LSA’s a uma área de razoável (flooding) Minimizar o impacto de mudanças na topologia (quedas de link, flapping, etc) Reforçar o conceito de um projeto de rede hierárquico

Lembre-se que o OSPF precisa de um projeto de rede hierárquico, pois diferente do EIGRP ele faz a sumarização de rotas apenas nos roteadores de borda (aqueles que estão posicionados entre as áreas), como por exemplo, os roteadores que ligam a área zero a área 1 e área zero à área 2 na figura anterior. Assim como o EIGRP o OSPF utiliza três bancos de dados/tabelas para administração do protocolo de roteamento: 





Vizinhança ou adjacência -> Adjacency Database -> Neighbor Table: guarda as informações das vizinhanças descobertas pelo OSPF através do protocolo de hello, o qual é bem mais complexo do que o utilizado pelo EIGRP. LSDB -> Link-state Database -> Topology Table: guarda a base de dados topológica do OSPF, ou seja, as LSA’s que foram recebidas pelo roteador e serão utilizadas algoritmo SPF para descobrir as melhores rotas. Table: as melhores Tabela depelo roteamento -> Forwarding Database -> Routing rotas são inseridas na tabela de roteamento.

Lembre-se que um projeto de rede OSPF depende do tipo de áreas que serão implementadas (nbackbone, normais, stub, totally stub, NSSA ou totally NSSA – serão estudadas posteriormente), do número de LSAs externos na rede e como a rede foi projetada para suportar a sumarização, pois quanto mais rotas maior a base de dados do OSPF.


  

 






  




Página 106  



 


1.2 Nomenclatura do OSPF – Tipos de Redes, Áreas e Roteadores Vamos agora ver algumas nomenclaturas e termos utilizados para dividir as redes, roteadores e áreas no OSPF. Vamos iniciar estudando os tipos de áreas, conforme abaixo:  







Área de backbone: esta é a área zero, a qual interliga todas as outras áreas. Área normal: são as demais áreas ou “Non-backbone areas”. No seu banco de dados existem rotas internas e externas. Área Stub: um tipo de área que em seu banco de dados estão descritas apenas as rotas internas e umaStubby rota padrão. Área Totally : esta é uma classificação proprietária da Cisco, sendo que nesse tipo de área o banco de dados tem apenas as rotas para sua própria área e uma rota padrão. Área Not-so-stubby ou NSSA: no banco de dados de uma área NSSA existem apenas as rotas internas, rotas redistribuídas a partir de um processo de roteamento diretamente conectado e opcionalmente uma rota padrão. Totally NSSA: também uma designação proprietária da Cisco onde o banco de dados contém apenas as rotas para sua própria área, rotas redistribuídas a partir de um processo de roteamento diretamente conectado e uma rota padrão. Obs: esse tópico foi retirado da revisão 300-101 não precisa estudar para a certificação.

Mais tarde você aprenderá a configurar cada uma dessas diferentes áreas. Outro conjunto de termos do OSPF definem as funções dos roteadores na rede, sendo que cada dispositivo pode ter várias funções conforme descrito abaixo (acompanhe também na próxima figura): 







Internal Router:mantêm um roteador interno as interfaces esses roteadores um banco de tem dadostodas de estado de link em parauma sua única própriaárea áreae apenas. Backbone Router: esse tipo de roteador tem pelo menos uma interface atribuída a área zero, por isso são roteadores de backbone. Roteador de borda de área (ABR - Area Border Router): esse tipo de roteador tem interfaces em duas ou mais áreas. Os ABRs separam o flooding de LSA entre as áreas, fazem a sumarização de rotas e também anunciam rotas padrão. Eles mantêm uma base de dados de link-state para cada área à qual estão conectados. Roteador de limite de Sistema Autônomo (ASBR - Autonomous System Boundary Router): esses roteadores têm interfaces dentro e fora do domínio de roteamento OSPF, podendo estar conectado com uma rede EIGRP e configurado para redistribuição de rotas, fazendo com que diferentes domínios de roteamento troquem informações entre si.


  

 






  




Página 107  



 


Além da diversidade de tipos de roteadores no OSPF Multiarea temos também diferentes tipos de rotas quando usamos esse tipo de topologia, abaixo segue a descrição dos principais tipos:  



Interna ou Intra-área (Intra-area route): rotas que pertencem à mesma área OSPF. Inter Área (Inter-area route): rotas que pertencem ao mesmo processo OSPF, porém a áreas diferentes da que o roteador está configurado. Externa (External route): rotas aprendidas por fontes externas ao OSPF, por exemplo, uma rota padrão aprendida pelo comando “default-information srcinate” ou por redistribuição.

1.3 Métrica do OSPF Veja a figura abaixo onde para a rede 10.0.0.0 /24 (conectada ao roteador R1) alcançar a rede 10.0.1.0 /24 (conectada ao R4) temos duas opções: via R2 através de dois links de 10Mbps ou via R3 através de dois links de 100Mbps. Tanto o OSPF como o EIGRP, por padrão, escolherão sempre a rota com maior largura de banda total pelo caminho. Já o RIP iria fazer o balanceamento de carga nesse exemplo, pois para ele as duas rotas tem a mesma métrica de dois saltos.


  

 






  




Página 108  



 


Esta métrica, chamada custo no OSPF, é a soma da divisão do valor de 100.000.000 (100 milhões) pela largura de banda da interface em bps (10^8 / bandwidth-em-bps). Por exemplo, em um link Ethernet (10Mbps ou 10.000.000bps) temos o custo de “100.000.000/10.000.000”, o que nos dá um custo igual a 10. Em um link de 64kbps teremos um custo de “100.000.000/64000”, o que nos dá um custo igual a 1.562. Os valores da métrica são números inteiros, por isso desconsideramos o resto da divisão. Portanto, entre um link de 64k e um Ethernet o OSPF prefere o Ethernet, pois a métrica dele é menor. Se o caminho passa por vários links a métrica é a soma desses links, por exemplo, se temos dois roteadores comainterfaces fastethernet conectados por um link serial de 64kbps o custo desse caminho será soma de (100.000.000/64.000)+(100.000.000/100.000.000)] = 1562 + 1 = 1563. Você pode configurar manualmente o custo de uma interface com o comando “ip ospf cost” (em modo de configuração de interface). Por exemplo, para configurar o custo de uma interface para 65 basta entrar na interface e digitar “ip ospf cost 65”. Isso faz com que o roteador igno re o comando bandwidth e não seja mais necessário pelo protocolo de roteamento o cálculo do custo, pois você já inseriu o comando de maneira manual. Por padrão, o custo das interfaces OSPF está referenciado a um custo onde a maior velocidade é de 100 Mbps, portanto para uma interface de 1Gbps o custo seria 1, o mesmo de uma interface de 100Mbps. Sendo assim, em roteadores mais novos com interfaces LAN a gigabit será necessário ajustar esse valor no protocolo de roteamento através do comando “auto-cost” em modo de configuração de roteamento. Acompanhe o exemplo abaixo onde vamos ajustar para a base ser um link de 1 Gbps: R1(config)#router ospf 1 R1(config-router)#auto-cost reference-bandwidth 1000

Com esse ajuste uma interface de 1Gbps terá custo 1 (1.000Mbps/1Gbps=1) e uma interface de 100Mbps terá custo 10 (1000Mbps/100Mbps=10). Um cuidado com esse comando é de não utilizar valores muito grandes, pois links de baixa velocidade, por exemplo, 64kbps, podem acabar ficando com uma métrica tão alta que acabam sendo considerados com custo infinito e não anunciados pelo OSPF! Lembre-se também que, assim como para o EIGRP, o OSPF também retira a informação da largura de banda para as interfaces seriais do comando “bandwith” que se não for configurado terá por padrão a banda de um T1!


  

 






  




Página 109  



 


2 Anúncios do OSPF – LSA’s Cada roteador mantém um banco de dados chamado de banco de dados link-state (LSDB), o qual armazena os últimos LSA’s recebidos. Além disso, um LSDB único é mantido para cada área conectada ao roteador, por exemplo, um roteador de borda que possui a área zero e a área um terá um banco de dados separado cada uma dessas áreas. Cada LSA é numerado com um número de sequência e um temporizador é ativado para que LSA’s antigos possam ser apagados ou atualizados, esse timer padrão é de 30 minutos. Quando é recebido um LSA, ele é comparado com o LSDB e as seguintes ações podem ser tomadas:  



Se o LSA é novo, ele é adicionado ao banco de dados e o algoritmo SPF é executado. Se for de um Router ID que já está na base de dados então o número de sequência é comparado, se for um novo LSA, ele é inserido na base de dados e o algoritmo SPF é executado. Se for um LSA mais antigo, o LSA mais recente na memória é enviado de volta para quem enviou o antigo. Quando um novo LSA é encontrado ele é inundado para todos os vizinhos, menos para quem o enviou.

A sequência de números OSPF é de 32 bits, sendo que o primeiro número da sequência é 0x80000001. Os números maiores são os mais recentes. O número de sequência muda apenas sob duas condições:  

As mudanças LSA porque uma rota foi adicionada ou excluída. O LSA expirou (as atualizações de LSA são inundadas dentro de uma área a cada meia hora, mesmo se nada mudar).

O comando "show ip ospf database" mostra a idade (em segundos) e número de sequência para cada roteador. Como cada roteador envia um LSA para cada link, roteadores em grandes redes podem receber e ter que processar um grande número de LSA’s. Isso pode aumentar demais o processamento na CPU e uso da memória RAM, prejudicando outras funções ou até mesmo travando o roteador. Existe uma maneira de proteger a sobrecarga de recebimento de LSA configurando o roteador para monitorar o número de LSAs recebidos e inseridos na base de dados LSDB. Se o limite especificado for excedido por um minuto o roteador entra no estado de "ignorar" (ignore), descartando todas as adjacências e limpando o banco de dados OSPF. O roteador retoma as operações normais após o OSPF normalizar para um período configurado. Deve-se ter cuidado porque esse recurso interrompe o roteamento quando acionado, por isso pode ao mesmo tempo que protege o roteador também causar interrupções no roteamento de pacotes entre algumas ou todas as redes. Para configurar a proteção de sobrecarga de LSA devemos utilizar o comando abaixo dentro do modo de configuração do OSPF: max-lsa maximum-number [threshold-percentage] [warning-only] minutos] [ignore-count número] [reset-time minutos]


  

 






  




[ignore-time

Página 110  



 


2.1 Tipos de LSA O OSPF utiliza diferentes tipos de LSAs para anunciar diferentes tipos de rotas. Muitas destas rotas estão representadas na tabela de roteamento por um prefixo especial (letra que designa o tipo de rota na frente dela). Veja abaixo uma descrição dos 11 tipos de LSA: 

















LSA Tipo-1 (Router LSA): Anuncia rotas intra-área. São geradas por roteador OSPF e inundadas apenas dentro da área. Recebem a letra "O" na tabela de roteamento. LSA Tipo-2 (Network LSA): Anuncia roteadores em um link de acesso múltiplo (rede broadcast ethernet), ou seja, são geradas por um"O" roteador DR.de São inundadas apenas dentro da área e recebem também a designação na tabela roteamento. LSA Tipo-3 (Summary LSA): Anuncia rotas inter-area e são geradas por um ABR. São inundadas em áreas adjacentes (vizinhas) e recebem a designação "O IA" na tabela de rotas. LSA Tipo-4 (Summary LSA): Gerada por um ABR para anunciar a rota para um ASBR para as demais dentro do OSPF. Inundada para áreas adjacentes. Recebem a designação "O IA" na tabela de roteamento. LSA Tipo-5 (External LSA): Anuncia rotas em domínio de roteamento gerado por um ASBR. Essa mensagem de LSA é inundada para áreas adjacentes e recebe a designação "O" na tabela de roteamento com um dos dois sufixos (O E1 ou O E2): o E1– a métrica é aumentada a cada roteador que passa pela rede. o E2– a métrica fica fixa e não aumenta ao passar por outros roteadores na rede (default). LSA Tipo-6 (Multicast LSA) : Utilizado em operações que envolvem o multicast no OSPF. LSA Tipo-7 (Not-so-stubby area LSA): Anuncia rotas em domínio de roteamento e é gerado por um ASBR em uma área not-so-stubby, recebendo a designação "O" na tabela de roteamento com um dos sufixos aabaixo (O N1 ouque O N2): o N1– a métrica é aumentada cada roteador passa pela rede. o N2– a métrica fica fixa e não aumenta ao passar por outros roteadores na rede (default). LSA Tipo-8 (External attributes LSA): Utilizada na operação entre o OSPF e BGP para anunciar rotas externas. LSA Tipo-9,10 e 11 (Opaque LSAs): Utilizado para aplicações específicas, por exemplo, na integração do OSPF e MPLS.

Os tipos de LSA que estão presentes no banco de dados de um roteador podem ser visualizados com o comando “show ip ospf database” e são identificados com o nome e não o número. Através desse comando e dos tipos de LSA que os roteadores têm presentes em sua tabela de topologia que sabemos em que modo o roteador está operando, por exemplo, um roteador interno deve ter apenas LSAs da sua própria área, já um ABR terá LSAs de diversas áreas simultaneamente. Um roteador ASBR terá LSAs do tipo 5 srcinadas a partir de suas interfaces diretamente conectadas, pois eles estão conectados diretamente às redes externas.


  

 






  




Página 111  



 


3 Operação do OSPF O OSPF utiliza vários tipos de mensagens diferentes para estabelecer e manter relacionamentos com seus vizinhos, assim como para manter as informações de roteamento corretas. Portanto, no CCNP ROUTE é importante entender cada tipo de pacote OSPF e o processo para estabelecimento de vizinhanças, pois serão conceitos cobrados durante o exame! OSPF usa cinco tipos de pacotes, porém eles não são transportados pelo UDP ou TCP, ao invés vez disso, ele é executado diretamente sobre IP (protocolo IP 89) usando um cabeçalho exclusivo do OSPF. Um campo neste cabeçalho identifica o tipo de pacote a ser transportado, sendo que os cinco tipos de pacotes OSPF são: 1. Hello: Identificam vizinhos e servem como um keepalive. 2. Link State Request (LSR): O pedido de Link State Update (LSU) contém o tipo de LSU solicitado e o ID do roteador solicitante. 3. Database Description (DBD): Trata-se de um resumo do LSDB (banco de dados linkstate), incluindo RID e o número de sequência de cada LSA no LSDB. 4. Link State Update (LSU): Contém uma entrada LSA completa, incluindo informações de topologia, por exemplo, o RID do roteador local e o RID e custo de cada vizinho. Uma LSU pode conter múltiplos LSA’s. 5. Link State Acknowledgment (LSAck): Utilizado para reconhecer o recebimento de todos os outros pacotes OSPF exceto pacotes de hellos, os quais não precisam de reconhecimento. Outro ponto importante é que o tráfego do OSPF é enviado por multicast a um dos dois endereços:  

224.0.0.5 para todos os roteadores OSPF ou 224.0.0.6 para todos os roteadores DR no OSPF

3.1 Formando Vizinhanças ou Adjacências Os roteadores OSPF enviam periodicamente pacotes em multicast para se apresentar para outros roteadores em um link, tornando-se vizinhos quando enxergam seu ID de roteador (RID) incluído no campo da mensagem de hello do outro roteador. Portanto, quando roteador vê seu RID na mensagem de hello recebida significa que ele tem comunicação bidirecional com seu vizinho. Além disso, dois roteadores devem estar na mesma sub-rede para que seja formada uma adjacência (links virtuais são uma exceção a esta regra). Para que dois roteadores tornem-se vizinhos eles precisam, além de estar na mesma sub-rede ou compartilharem um link virtual, que os seguintes parâmetros sejam iguais:   

Temporizadores de Hello e Dead ID da área Tipo de autenticação e senha



Flag de área Stub Os roteadores OSPF podem ser vizinhos sem ser uma adjacência. Somente vizinhos adjacentes trocam atualizações de roteamento e sincronizam suas bases de dados. Em um link ponto-aponto, por exemplo, uma adjacência é estabelecida diretamente entre os dois roteadores vizinhos. Em um link de acesso múltiplo (Redes Ethernet ou NBMA), cada roteador estabelece uma adjacência apenas com o DR (Designate Router) e o DR backup (BDR – Backup Designate Router).


  

 






  




Página 112  



 


Os Hellos também servem como keepalives, sendo que um vizinho é considerado perdido (Dead ou Morto) se não for recebido nenhum Hello dentro de quatro períodos de Hello (o chamado de Dead Timer). Os valores padrão para o Hello e Dead são os seguintes:  

10 segundos e 40 segundos para interfaces LAN e ponto-a-ponto 30 segundos e 120 segundos para interfaces multi-acesso sem broadcast (NBMA – por exemplo, Frame Relay)

No próximo tópico vamos analisar os passos para que dois roteadores tornem-se vizinhos adjacentes, ou seja, capazes de trocar informações de roteamento! 3.2 Processo de Estabelecimento de Adjacências e Troca de Informações de Roteamento O processo de estabelecimento de adjacência e troca de rota entre dois roteadores OSPF segue os passos abaixo (acompanhe os passos com a figura seguinte): Passo 1 – Down State: o processo do OSPF ainda não começou e os Hellos ainda não foram enviados. Passo 2 - Init State: o router envia pacotes de Hello para todas as interfaces OSPF configuradas no comando "network". Passo 3 - Two-way State: o roteador recebeu um Hello do outro roteador contendo seu próprio ID de roteador na lista de vizinhos. situação todos os requisitos paraNessa vizinhança foram cumpridos e os roteadores podem se tornar vizinhos. Passo 4 - Exstart State : Se os roteadores se tornarem adjacentes (fazer troca de rotas), nesse passo eles determinam quem começa o processo de troca de informações. Passo 5 - Exchange State : as bases de dados dos roteadores são trocadas listando os LSAs em seu LSDB pelo RID e número de sequência. Passo 6 - Loading State: cada roteador compara a base de dados recebida com o conteúdo de seu banco de dados local. Em seguida, envia um LSR para LSAs faltantes ou desatualizadas. Cada roteador responde a LSR do seu vizinho com uma atualização do estado do enlace. Cada LSU é reconhecido com um LSAck. Passo 7 - Full State: A LSDB foi sincronizada com o vizinho e foi finalizado o processo de inicialização do OSPF.


  

 






  




Página 113  



 


Quando o roteador completa o processo e chega ao estado de Full uma mensagem é enviada para cada adjacência formada, veja a saída abaixo: 

00:00:20: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.2 on Serial0/0/1 from LOADING to FULL, Loading Done

4 Planejando a implantação do OSPF Planejar uma implementação de OSPF exige mais planejamento em comparação ao EIGRP, pois o OSPF tem requisitos mais específicos de rede. As informações mais importantes a serem coletadas e planejadas para essa implantação são: 







Mapear a configuração de rede atual e as futuras exigências: Documentar o endereçamento IP utilizado e a topologia da rede, incluindo os tipos de links utilizados na LAN e WAN, largura de banda e dados sobre utilização (baseline de tráfego). Documentar a utilização atual do roteador em termos de processamento e memória, pois o OSPF normalmente exige mais do roteador na inicialização. Criar um projeto de endereçamento IP hierárquico que permita a sumarização nos routers ABR: O projeto de rede OSPF requer um projeto de rede hierárquico, ou seja, planejar um endereçamento que seja possível fazer a sumarização nos roteadores de borda de área. Criar uma área de backbone (área 0) e áreas normais: A área 0 deve ser contígua e as demais zonas devem ser conectadas à área 0, seja diretamente ou através de uma ligação virtual. Além disso, deve ser decidido onde os limites de área serão posicionados (posição dos roteadores ABR e ASBR). Certifique-se também que as áreas normais possuem conectividade com a área 0 e que todos os roteadores ABRs têm os recursos (CPU e memória RAM) para suportar o tráfego OSPF junto com o tráfego normal de redes. Melhorar a escalabilidade do OSPF: Este passo inclui a sumarização de rotas e uso de áreas stub.

Seu plano de implementação final precisa incluir parâmetros detalhados como: 

 



A topologia exata, redes IP a serem anunciadas no comando network, número do processo OSPF, listas de roteadores que serão configurados OSPF e as alterações necessárias para ajustar a métrica das interfaces. Definir uma lista de execução de tarefas para cada roteador na rede. Elaborar um plano de verificação (validação do ambiente) para cada roteador local, assim como para os vizinhos, por exemplo, verificar as tabelas de roteamento IP, tabelas de topologia OSPF e conectividade de rede. Documentar as novas configurações de rede.

Assim como foi recomendado para o EIGRP, quando implementamos novos recursos em roteadores existentes é necessário verificar se o IOS da Cisco rodando nos roteadores suporta toda a lista de facilidades que desejamos utilizar.


  

 






  




Página 114  



 


5 Configuração Básica do OSPF Uma vez feito o planejamento chegou a hora de configurar os roteadores e depois testar com comandos show e debug se tudo está conforme o planejado. Para configurar o OSPF precisamos entrar no modo de configuração do roteador, definindo uma identificação de processo (process ID). Esse número de processo não precisa ser o mesmo nos dispositivos OSPF para que eles troquem informações, diferente do EIGRP que precisa todos os routers com o mesmo AS. Depois devemos identificar as interfaces e redes onde o OSPF deve ser executado, juntamente com as áreas que essas interfaces pertencem. A declaração das redes é feita com o comando “network” e utiliza uma máscara curinga para identificar um intervalo de endereços que farão parte do processo do OSPF. Ao contrário do EIGRP, no OSPF a máscara curinga não é opcional. O exemplo a seguir mostra um roteador configurado como um ABR, onde a interface que conecta o roteador com o backbone via rede WAN está com a rede 192.168.10.0/30 e colocada na área de backbone, já a interface LAN com a rede 172.16.10.0/24 será colocada na área 1 e será utilizada para conexão dos demais roteadores remotos. Nesse exemplo estamos supondo que todas as configurações gerais e de interfaces foram realizadas corretamente. R1(config)#router ospf 1 R1(config-router)#network 192.168.10.0 0.0.0.3 area 0 R1(config-router)#network 172.16.10.0 0.0.0.255 area 1

Outra maneira de ativar o OSPF é utilizando uma declaração de rede diretamente em modo de configuração da interface. Isso é especialmente útil em interfaces de unnumbered e permite um controle mais preciso sobre quais interfaces irão executar OSPF, veja exemplo abaixo: R1(config) #int s 0/0 R1(config-if) #ip ospf area 1

O comando “ip ospf area” tem precedência sobre o comando “network”. 5.1 RID – Router ID Não devemos confundir o número do processo do OSPF com o router ID (identificação do roteador OSPF ou RID). O algoritmo SPF mapeia o caminho mais curto entre uma série de nós utilizando um endereço IP, porém isso traz um problema devido a um roteador IP poder possuir vários endereços IPs configurados. Por esta razão, um único endereço IP é designado como o "nome" do roteador: o Router ID (RID). Por padrão o RID é o maior endereço IP em uma interface ativa quando o processo do OSPF é iniciado. O RID é selecionado quando OSPF começa e por razões de estabilidade não é alterado até que se reinicie o OSPF. O processo OSPF pode ser reiniciado por “reload” (via comando ou físico, desligando e ligando o roteador) ou usando o comando “clear ip ospf process”. Ambos os comandos irão parar o roteamento por um tempo, por isso cuidado ao utilizá-los.


  

 






  




Página 115  



 


Por questões de estabilidade, antes de iniciar a configuração do OSPF, recomenda-se a criação de uma interface de loopback, a qual é uma interface virtual e mais estável do que uma interface física, para a utilização como RID. Tenha em mente que se utilizamos o RID em uma interface física, quando ela ficar down o OSPF terá que escolher um novo RID e fazer o recálculo do algoritmo novamente. O endereço de loopback é configurado através da criação de uma interface e configuração de um endereço IP, normalmente um endereço com a máscara /32 para identificar que é um endereço de host único, veja exemplo abaixo. R1(config)#interface Loopback0 R1(config-if)#ip address 10.0.0.1 255.255.255.255

O endereço de loopback não precisa ser incluído no processo de roteamento OSPF, mas pode ser anunciado para auxiliar na solução de problemas e possibilitar o ping e trace para esse IP. Uma terceira opção para configuração do RID é através do comando “router-id” diretamente no modo de configuração do roteador OSPF. O comando router-id define estaticamente o RID do roteador e evita que o processo seja reinicializado pela queda de uma interface, seja ela física ou virtual. Veja um exemplo de configuração abaixo. R1(config)#router ospf 1 R1(config-router)#router-id 10.0.0.1

Caso o roteador não tenha nenhuma interface ativa com o IP configurado não será possível ativar o protocolo OSPF e uma mensagem de erro será exibida “OSPF process 1 cannot start.”. Uma recomendação na configuração do OSPF é a utilização de um RID que seja previsível, evitando deixar que as interfaces físicas ou lógicas sejam utilizadas, pois um RID duplicado pode gerar uso de CPU recálculos algoritmoosSPF consequências imprevisíveis peloexcessivo OSPF utilizar essepor parâmetro paradoidentificar LSAsounaoutras sua base de dados. 6 Tipos de Redes OSPF O algoritmo SPF constrói um mapa com todos os caminhos formados de uma série de pontos conectados por links diretos, como uma árvore onde o próprio roteador está como raiz. Uma das consequências desta abordagem é que o algoritmo não tem maneira de lidar com uma rede de múltiplo acesso com muitos roteadores, tal como redes Ethernet, pois a formação de vizinhanças seria tão grande em situações extremas que não haveria memória e processador que aguentasse o volume de informações, além do tráfego de rede exigido. No caso de redes Broadcast ou Não-Boradcast Multiacesso a solução utilizada pelo OSPF é eleger um roteador chamado de Designated Router (DR), o qual servirá como ponto focal de todo segmento para o recebimento e envio das informações do OSPF. Além do roteador DR pode existir um segundo roteador backup (chamado BDR), o qual possui uma cópia da base de dados do DR e entra em ação caso o DR fique indisponível. O processo de eleição será visto posteriormente. Dessa forma, não importa quantos roteadores existam na rede, pois eles terão apenas um vizinho (ou no máximo dois), com exceção do próprio DR que terá mais vizinhanças. Em circuitos ponto-a-ponto o SPF não precisa de nenhum método especial para troca de mensagens, ou seja, não há uso ou eleição de DR ou BDR e todo o tráfego é enviado via multicast para o endereço 224.0.0.5.


  

 






  




Página 116  



 


O OSPF, por padrão, suporta três tipos de redes: 





Ponto a ponto: Padrão para interfaces seriais ponto a ponto, tais como T1, E1, ISDN BRI/PRI, PPP e HDLC. Não faz eleição de DR/BDR. Broadcast Multiacesso: Modo padrão para redes locais (redes Ethernet ou Token Ring), utilizando DRs/BDRs e descoberta automática de vizinho. Não-Broadcast Multiacesso (NBMA): Utilizada em redes WAN do tipo frame-relay, ATM ou X.25. Nas interfaces Cisco pode ser configurada com cinco modos de operação diferentes!

Em roteadores Cisco o OSPF suporta cinco tipos de redes que são definidas nas interfaces e podem ser utilizadas inclusive em interfaces WAN: 









NBMA: Padrão para interfaces serial multiponto, por exemplo, interfaces Frame-relay. Compatível com RFC que utiliza DR/BDR e requer configuração manual de vizinhos com o comando “neighbor”. Comando “ip ospf network non-broadcast” em modo de interface. Padrão para redes frame-relay configuradas como NBMA (diretamente na interface ou subinterfaces multiponto) em uma única sub-rede. Além disso, DR/BDR precisam ter conexão completa com os Spokes, por isso o HUB deve ser escolhido como DR em topologias hub-and-spoke. Ponto-a-multiponto (P2MP): Não usa DRs aumentando logaritmicamente a criação de vizinhanças entre os roteadores. Esse modo é compatível com RFC resiliente que utiliza a descoberta automática de vizinhos. Comando “ip ospf network point-to-multipoint” em modo de interface e as interfaces precisam também estar em uma mesma sub-rede. Ponto-a-multiponto sem broadcast (P2MNB): Modo proprietário da Cisco que é utilizado em instalações de camada-2 onde a descoberta dinâmica de vizinho não é suportada. Requer configuração manual dos vizinhos. Comando “ip ospf network pointto-multipoint non-broadcast” emredes modolocais de interface. Broadcast: Modo padrão para (redes Ethernet ou Token Ring), utilizando DRs/BDRs e descoberta automática de vizinho. Proprietário Cisco quando utilizado na interface WAN, isso mesmo, podemos configurar esse modo em uma WAN NBMA. Comando “ip ospf network broadcast” em modo de interface. Ponto-a-ponto (P2P): Modo proprietário Cisco que descobre vizinhos e não requer eleição de DR/BDR. Comando “ip ospf network point-to-point” em modo de interface.

Se o tipo de interface padrão não atende os requisitos do projeto é possível configurar estaticamente com o comando “ip ospf network” em modo de configuração de interface conforme exemplo abaixo: R1(config-if)#ip ospf network ? broadcast Specify OSPF broadcast multi-access network non-broadcast Specify OSPF NBMA network point-to-multipoint Specify OSPF point-to-multipoint network point-to-point Specify OSPF point-to-point network R1(config-if)#ip ospf network point-to-multipoint

Ao usar o NBMA ou P2MP (modos sem broadcast) os vizinhos devem ser configurados manualmente em modo de configuração do roteador OSPF: R1(config)#router ospf 1 R1(config-router)#neighbor 172.16.0.1

O comando “show ip interface ospf” exibe o tipo de rede configurado ou estabelecido automaticamente para cada link.


  

 






  




Página 117  



 


6.1 OSPF em Redes Broadcast – Eleição de DR e BDR Em um link de multiacesso um dos roteadores é eleito como DR e outro como um DR backup (BDR). Todos os outros routers formam adjacências apenas com o DR e BDR, não uns com os outros (eles param no estado Two-way). O DR é responsável pela criação e distribuição (inundação ou flooding) dos LSAs (tipo 2) na rede anunciando o link multiacesso. Já os roteadores que não são DR (NonDR ou DROTHER) comunicam-se com os DRs usando o endereço IP de multicast 224.0.0.6. O DR utiliza o endereço IP como de multicast 224.0.0.5 para enviar as informações para os outros roteadores classificados DROTHER.

O DR e BDR são eleitos como segue: 1. Um roteador inicia o processo de escuta de Hellos, se nenhum pacote for recebido dentro do tempo do temporizador Dead, ele mesmo se elege como DR. 2. Se Hellos de quaisquer outros roteadores são recebidos, o roteador com a maior prioridade OSPF é eleito DR e o processo de eleição se inicia novamente para determinação do BDR. A prioridade zero remove um roteador da eleição. 3. Se dois ou mais roteadores têm a mesma prioridade OSPF, o roteador com o maior RID é eleito DR e o processo de eleição é reiniciado para determinação do BDR. Lembre-se que o RID pode ser configurado estaticamente, se não existir o comando “router -id” então o IP da interface de loopback é utilizado como RID e se não houver loopback o maior IP configurado em uma interface ativa é utilizado como RID. Depois que um DR e BDR são eleitos, só acontecerá eleição novamente se o DR ou BDR forem perdidos. Devido a esse fato, o DR é normalmente o primeiro dispositivo ativado com uma prioridade diferente de zero. A melhor maneira de controlar a eleição do DR e BDR é definindo uma prioridade manualmente para os roteadores que devem ser eleitos como DR e BDR. A prioridade padrão é 1 e a prioridade 0 significa que o roteador não poderá ser eleito DR ou BDR, ou seja, poderá ser apenas DROTHER. O roteador com maior prioridade na rede será o DR e o segundo maior o BDR.


  

 






  




Página 118  



 


Para configurar a prioridade utilizamos o comando "ip ospf priority" no modo de configuração de interface, conforme exemplo abaixo: R1(config)#int fa 0/1 R1(config-if)#ip ospf priority 2

No exemplo acima, como a prioridade padrão é 1 esse roteador será o DR para a rede da interface fast 0/1, pois ele tem a prioridade 2. Com o comando “show ip ospf interface” é possível verificar se o roteador é DR, BDR ou DROTHER, assim como a prioridade de cada interface. 6.2 Considerações sobre OSPF em Redes NBMA (Frame-relay e ATM) Os protocolos de roteamento multi-acesso assumem que os links suportam broadcast e tem conectividade full-mesh (malha completa) entre os roteadores. Para o OSPF isso significa o seguinte: 







Todos os mapeamentos estáticos do Frame-Relay (comando frame-relay map) ou ATM devem incluir o atributo “broadcast” no final do comando de configuração. O DR e BDR devem ter conectividade completa com todos os outros dispositivos, ou seja, PVCs entre todos os dispositivos formando uma topologia em malha completa. Ambientes hub-and-spoke devem ter o DR como o hub ou utilizar subinterfaces ponto-aponto, as quais não necessitam de DR. Acompanhe na figura abaixo.

Em ambientes em malha parcial (partial-mesh) é preferencial que seja utilizada configuração através de subinterfaces ponto-a-ponto, principalmente quando existir dispositivos que não tenham conectividade total com os demais roteadores. Se houver um subconjunto da topologia com conectividade completa (full-mesh), pode ser utilizada a configuração com subinterface multiponto nesse segmento. Veja a figura abaixo.


  

 






  




Página 119  



 






As topologias full-mesh podem ser configuradas utilizando a interface física, mas muitas vezes as interfaces lógicas são preferíveis para tirar vantagem dos outros benefícios das configurações com subinterfaces. Em algumas topologias pode ser necessário identificar os endereços IP dos vizinhos estaticamente com o comando “neighbor”.

6.3 Considerações sobre o OSPF em Redes MPLS As soluções MPLS em Camada 2 e Camada 3 foram descritas no Capítulo 3, onde estudamos o EIGRP e os conceitos são os mesmos para o OSPF. Conexões baseadas em camada 2 utilizam o EoMPLS e o OSPF funciona exatamente como faria em qualquer outra rede Ethernet, ou seja, eles formam relacionamento com o roteador CE vizinho através da WAN e eles elegem um DR e BDR, utilizando o mesmo processo de uma rede do tipo Broadcast Multiacesso. Quando o MPLS utiliza VPN Layer 3, ele exige que os roteadores CE formem relacionamento com o roteador PE diretamente conectado a ele. O roteador PE aparece para a empresa como outro roteador dentro de sua rede e o tipo de rede OSPF é determinado pelo tipo de ligação entre os roteadores CE e PE. Esse tipo de WAN exige mais cuidados no planejamento e configuração, pois exige que o provedor de serviços tenha o OSPF configurado e compartilhando informações com o cliente.


  

 






  




Página 120  



 


7 Configurações Avançadas do OSPF O OSPF oferece diferentes configurações para aperfeiçoar sua operação e atender às necessidades da rede. Vamos nesse tópico estudar os seguintes itens:     

Sumarização de rotas Interfaces passivas Rotas padrão Áreas stub Links virtuais

7.1 Comando Passive-interface O comando “passive-interface” no OSPF impede que o roteador envie mensagens d e Hello naquela interface. Assim, um roteador OSPF com esse comando na interface não consegue descobrir vizinhos ou formar uma adjacência nessa interface. Para desligar o protocolo em todas as interfaces, utilize o comando “passive-interface default”. Depois você pode então, para as interfaces que devem executar o protocolo, utilizar o comando “no passive-interface interface”. R1(config)#router ospf 1 R1(config-router)#passive-interface default R1(config-router)#no passive-interface s0/0

7.2 Sumarização de Rotas A sumarização ajuda a todos os protocolos de roteamento suportarem redes de grande porte resumindo várias redes em um único anúncio. Especialmente para o OSPF os benefícios vão além da escalabilidade, pois ajuda a economizar recursos de memória e CPU dos roteadores. O algoritmo SPF consome bastante recurso da CPU quando ele é executado, sendo que a sumarização impede que mudanças na topologia sejam passadas para fora de uma área, poupando os demais roteadores em áreas diferentes de terem que executar o algoritmo SPF a cada queda de uma rede interna em determinada área. Quando temos múltiplos bancos de dados OSPF, quanto maior o tamanho desses bancos mais memória eles irão utilizar. A sumarização melhora esse processo, pois ela diminui o número de rotas trocadas e o tamanho das bases de dados, fazendo com que o impacto da mudança da topologia fique restrito dentro da própria área. O OSPF pode produzir resumos dentro de uma rede classful (VLSM) ou resumos de blocos de redes classful (CIDR). Existem dois tipos de sumarização:  

Sumarização inter-área (LSA tipo 3) Sumarização de rotas externa (LSA tipo 5)

Na sumarização inter-área (LSA tipo 3) as rotas são criadas no ABR, dentro do modo de configuração do roteamento OSPF, usando o comando “area range”. A rota sumário será anunciada desde que pelo menos uma sub-rede dentro do resumo esteja configurada na área em questão. Já a métrica da rota sumarizada é igual a rota de menor custo dentre as rotas pertencentes a faixa da sumarização. Assim como no EIGRP, o roteador OSPF cria automaticamente uma rota estática para o sumário apontando para a Null0.


  

 






  




Página 121  



 


Abaixo segue exemplo de criação de uma rota sumarizada 172.16.0.0 com o prefixo /12 dentro da área 1: R1(config-router)#area 1 range 172.16.0.0 255.240.0.0

Portanto essa rota será passada pelos roteadores de borda de área ao backbone, o qual irá anunciar essas rotas aos demais roteadores de borda das demais áreas. Ao invés dos roteadores internos das demais áreas aprenderem todas as redes da área 1, eles aprenderão apenas a rota 172.16.0.0/12. Veja outro exemplo na figura abaixo onde os roteadores ABR R1 e R2 sumarizam suas rotas internas (comando area 1 range e area 2 range) e também sumarizam a rota do backbone (area 0 range) para dentro das áreas internas.

A sumarização de rotas externas (LSA tipo 5) é feita em um roteador ASBR usando o comando “summary-address” dentro do modo de configuração do roteamento OSPF. Ele também pode ser feito em um roteador ABR com rotas NSSA do tipo 7 antes de serem anunciadas como rotas do tipo 5. O roteador cria automaticamente uma rota estática para o sumário apontando para a Null0.


  

 






  




Página 122  



 


O exemplo a seguir cria um sumário de rotas externas com a rede 192.168.0.0 e o prefixo /16, injetando uma única rota do tipo 5 dentro do OSPF. R1(config-router)#summary-address 192.168.0.0 255.255.0.0

Portanto, nessa segunda configuração estamos em um roteador que está, por exemplo, fazendo redistribuição com o EIGRP ou BGP e vamos sumarizar as rotas aprendidas desse domínio de roteamento externo para dentro do OSPF. Veja exemplo na figura seguinte onde os roteadores ABR R1 e R2 sumarizam suas rotas internas (comando area 1 range e area 2 range) e também sumarizam a rota do backbone (area 0 range) para dentro das áreas internas.

Você deve ter notado aqui uma diferença entre o que estudamos no capítulo anterior para o EIGRP e o que vimos para o OSPF, pois se lembre de que para o EIGRP fazemos a sumarização em quaisquer interfaces, já no OSPF apenas em roteadores de borda e a configuração é dentro do protocolo de roteamento e não na interface, como é feito no EIGRP. 7.3 Anunciando Rotas Default A rota padrão ou default é um tipo especial de rota resumo ou rota sumarizada, pois ela resume todas as redes em um único anúncio de rota, o que acaba reduzindo as informações de roteamento para apenas uma rota. Os benefícios do uso de uma rota padrão são:   

Redução na tabela de roteamento. Menor uso de recursos do roteador. Os roteadores não precisam manter informações sobre rotas externas.

As rotas padrão são injetadas no OSPF como uma rota do tipo 5 (O E2). Existem várias maneiras de injetar uma rota padrão no OSPF, porém a forma mais conhecida é utilizando o comando "default-information srcinate" dentro do modo de configuração do roteamento OSPF. Veja o comando completo abaixo. R1(config-router)#default-information srcinate [always] [metric métrica]


  

 






  




Página 123  



 


Podemos utilizar ainda as opções “always” e “metric” juntamente com o comando “defaul information”. Sem a opção “always” o OSPF anuncia uma rota padrão aprendida de outra fonte, por exemplo, através de uma rota estática (“ip route 0.0.0.0 0.0.0.0”). Se a opção “always” está presente, o OSPF anuncia uma rota padrão mesmo que esse caminho não exista na tabela de roteamento. A opção “metric” define a métrica inicial para a rota padrão. Outra opção que pode ser utilizada com o comando “default-information” é o “metric-type”, utilizado para definir se a rota padrão anunciada é do tipo 1 ou tipo 2. Lembrando que em uma rota externa tipo 2 (O E2) a métrica sempre será a definida inicialmente, já se for configurada como tipo 1 a métrica é adicionada com o valor calculado a cada roteador onde passar a rota. Em ambientes onde existem duas saídas para a Internet as opções “metric” e “metric-type” podem ser utilizadas para definir uma rota principal e outra backup. Por exemplo, R1 e R2 possuem saída para Internet, no roteador R2 você pode definir uma métrica de 25 e deixar o padrão em R1, assim R1 será a saída principal e R2 a backup. Para garantir que não haja influência dos outros roteadores na métrica aconselha-se configurar o “metric-type 2”, assim a métrica de R1 sempre será melhor, pois o valor padrão é 1. Outra maneira de fazer o anúncio de rotas padrão no OSPF é através da criação de uma rota sumarizada padrão utilizando o comando “summary-address” ou o comando “area range”, os quais já estudamos no tópico anterior. Estes comandos podem fazer com que o roteador anuncie uma rota padrão apontando para si mesmo. A redução de informações de roteamento em áreas que não são backbone é um requisito comum em projetos de redes de grande porte que utilizam OSPF, pois os roteadores das unidades são tipicamente de menor porte (com menor poder de processamento e memória) e os links que os conectam normalmente têm a menor largura de banda, por isso quanto mais econômica de roteamento em um termos melhor seráaosolução desempenho da rede como todo.de uso dos recursos dos roteadores remotos Uma preocupação específica é que uma área pode ser sobrecarregada com informações de roteamento vindas de rotas externas, por isso a utilização da sumarização ou de rotas padrões é tão importante. 7.4 Escalabilidade no OSPF - Áreas Stub e Not-So-Stubby Outra forma de reduzir as informações de roteamento no OSPF e aumentar sua escalabilidade é configurar áreas como stub. Configurando uma área como stub você força que o ABR remova todas as rotas externas (tipo 5) e substitua por uma rota padrão. Veja exemplo ao lado onde a área 1 é configurada como stub em R1 e R2 (ABR): R1(config-router)#area 1 stub R2(config-router)#area 1 stub


  

 






  




Página 124  



 


Para limitar ainda mais as informações de roteamento, a área pode ser configurada como totalmente stubby (totally stubby area) usando no ABR a opção “no -summary”. Com essa configuração todas as rotas inter-area e rotas externas são omitidas pelo ABR e substituídas por uma rota padrãEm ambos os casos a rota padrão começa com um custo de 1 e para alterar podemos utilizar o comando “area x default-cost”. Acompanhe na figura abaixo.

O exemplo abaixo mostra a configuração da área 1 como totalmente stubby e custo 100 em R2 (ABR) e em R1: R2(config-router)#area 1 stub no-summary R2(config-router)#area 1 default-cost 100 R1(config-router)#area 1 stub

As redes stub economizam processamento e memória nos roteadores remotos, porém possuem algumas limitações, tais como:    

As áreas stub não podem conter links virtuais. Não podem ter roteadores ASBR incluídos nelas. Deve ser configurada em todos os roteadores daquela área. A área de backbone (área zero) não pode ser uma área de stub.

Outro tipo de área stub é uma área not-so-stubby ou NSSA, a qual é como uma área stub ou totalmente stub, mas permite um ASBR dentro da área, assim as rotas externas são anunciados como rotas do tipo 7 pelo ASBR. Porém, um roteador ABR deve converter essas rotas externas tipo 7 para rotas do tipo 5 para anunciá-las em áreas vizinhas. Veja a figura ao abaixo.


  

 






  




Página 125  



 


Uma área NSSA é configurada com o comando “area x nssa” dentro do modo de configuração do roteamento OSPF nos ABRs e roteadores internos. A opção “no-summary” no ABR configura a área como totalmente NSSA (totally NSSA), a qual é um tipo de área proprietária da CiscPor padrão, um ABR não injeta rota padrão em uma área NSSA e ao utilizarmos a opção “default information-srcinate” no ABR ou ASBR podemos forçar o roteador a fazer a divulgação da rota padrão dentro da área NSSA ou tottaly NSSA. Veja o comando completo abaixo e a figura a seguir com um exemplo de rede totally NSSA em R1 e R2 (ABR). R1(config-router)#area 10 nssa R2(config-router)#area 10 nssa no-summary

Por que tudo isso é importante? Lembre-se que a regra geral de design do OSPF é de separar a rede conforme sua complexidade, por exemplo, você deve separar um grande hub-and-spoke do restante da rede, pois assim você iria colocar a topologia hub-and-spoke em uma área ou domínio separado o flooding da roteadores informação não sobre esse conjunto de oroteadores dentro das demais áreas. evitando Uma falha de um dos terá impacto sobre restante da rede que estão em áreas diferentes. Ocultar ou limitar as informações da topologia torna a rede mais estável, ajuda a proporcionar convergência mais rápida e permite a escalabilidade do projeto utilizando o roteamento OSPF. O conceito das redes stub ajuda a reduzir o flooding de pacotes do OSPF na rede e também a redução do domínio de flooding na rede, o que melhora a estabilidade da topologia como um todo.


  

 






  




Página 126  



 


Na tabela abaixo temos um resumo dos tipos de LSA que podem ser encontradas em cada tipo de área. Os LSAs acabam determinando as fronteiras entre as áreas e dependendo do tipo de área não serão encontrados alguns tipos de LSA.

7.5 Links Virtuais O OSPF tem um requisito básico de que todas as áreas devem estar conectadas ao backbone (área 0), além disso a área zero deve ser contígua (sem descontinuidades). Quando isso não é possível, você pode usar um link virtual para fazer a conexão com o backbone através de uma área intermediária. Portanto um link virtual tem a função de conectar uma área que não possui ligação física com a área 0. Além disso, um link virtual pode conectar uma área descontínua 0, por exemplo, na fusão de duas redes de empresas onde as áreas zero não estão fisicamente conectadas. Em ambos os casos recomenda-se que esta seja uma solução temporária. Veja a figura abaixo onde faremos um exemplo de configuração. Nessa topologia a área 1 será a área de trânsito para a ligação virtual entre roteadores de um backbone descontíguo. O link virtual deve ser configurado nos roteadores ABRs da área de trânsito com o comando "area area-number virtual-link router-id", onde cada extremidade da ligação é identificada pelo seu RID. A área indicada no comando é a área de trânsito e não a área a ser conectada pelo link. Seguem as configurações de R1 e R2 abaixo: R1(config)#router ospf 1 R1(config-router)#area 1 virtual-link 10.2.2.2 R2(config)#router ospf 1 R2(config-router)#area 1 virtual-link 10.1.1.1

Para verificar o link virtual utilize o comandi “show ip ospf virtual-links”. Além disso, interfaces virtuais são tratadas como interfaces reais pelo processo OSPF, para verificar seu status pode ser utilizado o comando "show ip ospf interface interface-id".


  

 






  




Página 127  



 


7.6 Configurando a Autenticação no OSPF Para reforçar a segurança podemos configurar o OSPF para que ele autentique todos os pacotes de atualizações de roteamento OSPF, assim como sua srcem. Por padrão o OSPF não utiliza autenticação, porém ele suporta dois tipos de autenticação:  

Autenticação simples: enviada em texto claro (plain text), sem criptografia. Autenticação MD5: utiliza o hash MD5 para criptografar os pacotes enviados na rede, evitando que eles sejam lidos quando eventualmente capturados por um usuário mal

intencionado. O exemplo a seguir mostra um roteador configurado para autenticação de senha simples na área 1 utilizando a senha (chave ou key) "dltec". As configurações são realizadas em modo de configuração do roteamento OSPF e também em modo de configuração de interface. Uma vez configurada a autenticação todos os vizinhos devem usar autenticação e senha, porém é possível usar senhas diferentes por par de interfaces. R1(config)#int fast0/0 R1(config-if)#ip ospf authentication-key dltec R1(config-if)#ip ospf authentication R1(config-if)#router ospf 1 R1(config-router)#area 1 authentication

Agora vamos configurar OSPF com autenticação MD5 para a área 0 utilizando a senha "dltec123". Note que os comandos são ligeiramente diferentes, pois a opção “message-digest” é nos comandos para ativar a criptografia com MD5, além disso, um número de chave deve ser especificado no comando que define a senha dentro da interface fast 0/1. Assim como no exemplo anterior, os vizinhos que estão trocando pacotes OSPF com R1 na interface fast 0/1 devem estar configurados com suporte ao MD5 e a mesma chave. R1(config)#int fast0/1 R1(config-if)#ip ospf message-digest-key 2 md5 dltec123 R1(config-if)#ip ospf authentication message-digest R1(config-if)#router ospf 1 R1(config-router)#area 0 authentication message-digest

Para verificar e solucionar problemas de autenticação OSPF podemos utilizar os comandos abaixo: 





debug ip ospf adj: Com esse comando podemos analisar em tempo real a mensagem de erro se não houver correspondência na chave configurada. show ip ospf neighbor: Se a vizinhança foi estabelecida e está como full podemos assumir a autenticação funcionou corretamente. show ip route: Utilize para verificar se as rota estão sendo trocadas entre os dois roteadores com autenticação configurada.


  

 






  




Página 128  



 


8 Mantendo e Resolvendo Problemas com OSPF Para resolver problemas com o OSPF é importante lembrar o processo de inicialização que começa com a troca de hellos, formação de vizinhança e adjacência. É importante lembrar que ao final do processo, quando tudo funcionou, os roteador informam que eles passaram ao estado de full, porém em ambientes multiacesso apenas o DR e o BDR ficarão como full, os demais roteadores chamados de “DROTHER” ficam no estado “two-way”. O processo de inicialização do OSPF pode ser analisado com o comando "debug ip ospf adjacencies". Esse comando pode ser utilizado para verificar o processo de autenticação em tempo real. Já a tabela de vizinhanças pode ser vista com o comando "show ip ospf neighbors", o qual mostra o estado da adjacência e também se os vizinhos são DRs e BDRs, e também com o comando “show ip ospf interface”. Com o comando "debug ip ospf packet” podemos visualizar a troca de todos os pacotes OSPF em tempo real. Com o “debug ip ospf events” você pode monitorar os eventos do OSPF em tempo real e observar problemas como temporizadores de Hello e Dead configurados de maneira diferentes nos vizinhos e impedindo o estabelecimento da vizinhança. Normalmente notamos os problemas com o OSPF analisando a tabela de roteamento com o comando "show ip route", porém você pode filtrar apenas as informações do OSPF com o comando "show ip route ospf". Com o comando "show ip protocols" podemos analisar as informações gerais do OSPF, com ele podemos encontrar informações como parâmetros, temporizadores, identificar as redes anunciadas pelo OSPF, vizinhos diretamente conectados (routing information sources – srcem das informações de roteamento) e também o número de rotas que estão configuradas para balanceamento de carga com o comando “maximum-paths”. Lembre-se que o OSPF suporta apenas balanceamento de cargas entre rotas de mesma métrica e por padrão vem configurado para quatro rotas. O comando "show ip ospf" é útil para verificar o RID do OSPF, temporizadores e contadores, por exemplo, quantas vezes o algoritmo SPF foi executado. Um problema que pode ocorrer é o uso errado das máscaras curinga no comando “network”, fazendo com que as interfaces sejam agrupadas de maneira errada nas áreas. Para verificar esse tipo de informação podemos utilizar o comando “show ip ospf interface”. Esse comando mostra as interfaces que estão rodando OSPF, a área onde elas estão alocadas, o tipo de rede configurada nelas, temporizadores de Hello/Dead, prioridade configurada nos roteadores e também informações sobre DR/BDR. O LSDB ou banco de dados Link State pode ser verificado com o comando “show ip ospf database”, o qual pode ser utilizado com algumas opções como “external” (show ip ospf database external) para verificar somente entradas de LSA’s externas do tipo 5, por exemplo. Além disso, é importante verificar no comando “show interfaces” e “show largura de banda configurada nas interfaces, assim como o endereço IP, poisrunning-config” muitas vezes oa OSPF não sobe pelo IP no vizinho estar errado (rede diferente ou IPs repetidos).


  

 






  




Página 129  



 


Capítulo 5 - Redistribuição e Otimização de Roteamento Agora que aprendemos a configuração avançada dos protocolos OSPF e EIGRP vamos tratar de alguns assuntos para aperfeiçoar o roteamento dinâmico e fazer com que dois protocolos diferentes possam interagir trocando informação de roteamento, pois nem sempre temos um ambiente homogêneo tanto em termos de fabricante como de tecnologia.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Como realizar a redistribuição de rotas e seus principais desafios e problemas. Como otimizar o processo de redistribuição e roteamento. Criar e verificar mapas de rotas (route maps). Analisar e solucionar problemas relacionados à otimização do roteamento e redistribuição. 







Nesse capítulo vamos estudar como aplicar a redistribuição e técnicas para prevenir possíveis problemas que normalmente são causados pela redistribuição de rotas.

Bons estudos.


  

 






  




Página 130  



 



Introdução à Redistribuição de Rotas 132

2 Comando “Redistribute”Configurando – Múltiplos Protocolos ________________ 133

2.1 Problemas Relacionados à Redistribuição de Rotas _______________ 136 3 Otimizando o Roteamento com Redistribuição _____________________ 137

3.1

Passive Interface _______________ 137

3.2

Distância Administrativa _________ 138

3.3

Listas de Prefixos – Prefix Lists ____ 142

3.4

Listas de Distribuição – Distribute Lists 144

3.4.1

3.5

Configurando uma Lista de Distribuição 145

Route Maps ___________________ 147

3.5.1 Utilizando Route Map para controlar a Redistribuição __________________________ 149 3.5.2 Marcando e Bloqueando Rotas em Redistribuições com Route Map ___________ 150

4

Verificando a Redistribuição ______ 151

5 Planejamento e Considerações Finais sobre Redistribuição ________________ 152


  

 





5.1

Redistribuição One-way ou Two-way? 152

5.2

Recomendações Finais___________ 153


  




Página 131  



 


1 Introdução à Redistribuição de Rotas Muitas vezes em um ambiente de redes precisamos fazer com que diferentes fontes de informação de roteamento interajam e troquem informações. Por exemplo, uma empresa inteira com roteadores Cisco, a qual implementou como IGP o EIGRP adquire uma segunda empresa que não utiliza roteadores Cisco e tem implementado OSPF e agora deseja fazer a comunicação imediata de ambas as redes sem alterar protocolos de roteamento ou até mesmo os equipamentos em um primeiro momento. Como atender esse projeto se roteadores não-Cisco não suportam o EIGRP e sem trocar de EIGRP para OSPF nos roteadores Cisco atuais? A resposta para esse desafio é a redistribuição de rotas através do comando “redistribute” em modo de configuração de protocolo de roteamento. Veja a figura abaixo com o cenário básico de redistribuição.

Por enquanto vamos ignorar a configuração, porém no roteador CR01 temos o EIGRP e o OSPF configurados simultaneamente e dentro do EIGRP foi realizada a redistribuição das rotas do OSPF, ou seja, o roteador BR01 receberá rotas externas, vindas do OSPF e passará para os demais roteadores no AS 100 do EIGRP. Portanto, em alguns projetos você precisará ir além de apenas ativar o protocolo de roteamento na rede, será necessário também fazer a interação entre dois ou mais protocolos, controlar quais as rotas anunciadas ou redistribuídas ou quais caminhos serão escolhidos. Porém, a redistribuição pode trazer alguns inconvenientes relativos ao desempenho da rede quando o encaminhamento não é otimizado ou um excesso de atualizações de roteamento gera aumento noa uso CPU ou ememória RAM das por atualizações. causa da quantidade de configurar informações de roteamento ser de processada a frequência Além disso, vários protocolos e fazer redistribuição pode resultar em caminhos não otimizados e até loops de roteamento, assim como filtros de rotas configurados incorretamente podem levar a problemas de roteamento.


  

 






  




Página 132  



 


Por isso o IOS Cisco fornece várias maneiras de controlar atualizações de roteamento que vamos estudar nesse tópico:    

Route Maps Prefix Lists Distribute Lists Passive Interface

Nos próximos tópicos desse capítulo estudaremos a redistribuição de rotas e como evitar problemas de redistribuição com os recursos citados acima. 2 Comando “Redistribute” – Configurando Múltiplos Protocolos Conforme já citamos anteriormente, pode haver várias razões para a necessidade de executar múltiplos protocolos de roteamento dentro de uma rede. Os principais fatores são: 







Migração de um protocolo de roteamento para outro, onde ambos os protocolos serão executados na rede temporariamente. Necessidades específicas de aplicações e aplicativos que utilizam somente determinado tipo específico de protocolo de roteamento para seu funcionamento em rede. Regiões da rede com diferente controle administrativo, por exemplo, duas empresas parceiras trocando rotas para funcionamento de seus negócios. Ambiente com dispositivos de múltiplos fabricantes com diferentes requisitos de rede, por exemplo, uma região com equipamentos Cisco e EIGRP e outra região da rede com dispositivos de outro fabricante utilizando RIP ou OSPF que precisam trocar informações de roteamento.

A redistribuição de rotas é utilizada quando as informações de roteamento devem ser trocadas entre os diferentes protocolos de roteamento ou domínios de roteamento. Somente rotas que estão na tabela de roteamento e aprendidas através do protocolo específico são redistribuídas. Também é importante lembrar que cada protocolo tem algumas características próprias que devem ser levadas em conta quando redistribuídos. Outro ponto importante é que só é possível redistribuir protocolos que utilizam a mesma pilha de protocolo roteador, por exemplo, não dá para redistribuir rotas do IPX dentro do protocolo IP. Para configurar a redistribuição de rotas utilizamos o comando “redistribute” dentro do modo de configuração do protocolo de roteamento, veja as opções básicas do comando ao lado: R1(config-router)#redistribute ? bgp Border Gateway Protocol (BGP) connected Connected eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) isis ISO IS-IS iso-igrp IGRP for OSI networks maximum-prefix Maximum number of prefixes redistributed to protocol metric Metric for redistributed routes metric-type OSPF/IS-IS exterior metric type for redistributed routes mobile Mobile routes nssa-only Limit redistributed routes to NSSA areas odr On Demand stub Routes ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) route-map Route map reference static Static routes subnets Consider subnets for redistribution into OSPF tag Set tag for routes redistributed into OSPF


  

 






  




Página 133  



 


Principais características da redistribuição por protocolo: 









RIP: Usa métrica padrão igual a infinito, por isso ela deve ser definida no comando “default-metric” ou no momento da redistribuição com a opção “metric”, exceto quando fazendo a redistribuição de rotas estáticas (static) ou diretamente conectadas (connected), as quais têm métrica padrão igual a 1. Se a métrica não for definida o RIP atribui o valor 16 para a rede, porém esse valor é considerado inalcançável (métrica infinita) e não será anunciada. OSPF: Usa métrica padrão 20 exceto para o BGP que terá suas rotas anunciadas com métrica“metric-type”. 1. Pode ser especificado de métrica (E1ouousomente E2 - o padrão é E2) com a opção Deve-se usaro atipo opção “subnets” redes classful serão redistribuídas, esse é um erro comum na redistribuição do OSPF. Na tabela de roteamento as rotas externas podem ser “O E1” ou “O E2”. EIGRP: Usa métrica padrão igual a infinito, por isso ela deve ser definida no comando exceto quando fazendo a redistribuição de rotas estáticas (static) ou diretamente conectadas (connected), as quais têm a métrica padrão da sua métrica da interface. A métrica valor é "largura de banda, atraso, confiabilidade, carga, MTU", nessa sequência. As rotas redistribuídas têm distância administrativa maior que as rotas internas (170). Na tabela de roteamento rotas externas recebem a designação “D EX”. Static / Connected: A opção “connected” insere as redes diretamente conectadas não anunciadas no comando “network” dentro da redistribuição, assim como a opção “static” insere as rotas estáticas locais na redistribuição. BGP: A métrica (MED) é o valor da métrica do IGP que está sendo redistribuído dentro do BGP.

Opções do comando redistribute para o EIGRP: redistribute | as-number] [metric bw delay2}] reliability load mtu ] [match protocol {internal[process-id | nssa-external | external 1 | external [tag tagvalue] [route-map name]

Opções do comando para o OSPF: redistribute protocol [process-id | as-number] [metric metric-value] [metric-type type-value] [match {internal | external 1 | external 2 | nssa-external}] [tag tag-value] [route-map map-tag] [subnets]

Agora veja ao lado a figura mostrada no tópico anterior onde estamos redistribuindo as informações do OSPF dentro do EIGRP com AS 100 através do roteador ASBR CR01. Note que as rotas do processo “ospf 1” estão sendo redistribuídas no EIGRP com uma métrica de largura de banda igual a 64kbps, atraso ou delay 10000 micro segundos, confiabilidade de 255, carga igual a 1 e MTU 1500. Lembrando que, por padrão, o EIGRP utilizará para calcular a métrica apenas a largura de banda e o delay.


  

 






  




Página 134  



 


Se quiséssemos redistribuir as informações do EIGRP 100 dentro do OSPF poderíamos utilizar o comando dentro do ospf: “redistribute eigrp 100 subnets”. A opção subnets no OSPF garante que as sub-redes serão anunciadas no domínio de roteamento. Agora vamos supor que desejamos deixar a métrica das rotas aprendidas via EIGRP com o valor de métrica 100 e garantir que elas sejam rotas externas do tipo 2 (O E2), veja o comando para realizar essa ação no OSPF: R1(config)#router ospf 1 R1(config-router)#redistribute eigrp 100 metric 100 metric-type 2 subnets

A opção “metric 100” definiu o valor da métrica e o “metric -type 2” garante que a rota seja do tipo “O E2” na tabela de roteamento do OSPF. Além disso, o comando subnets foi utilizado para realizar a redistribuição das sub-redes e não somente de redes classfull. Vamos agora a um exemplo de redistribuição do EIGRP com número de AS 100. Existem duas maneiras de configurar, a primeira definindo a métrica inicial (seed metric) no comando redistribute. dltec(config)#router rip dltec(config-router)#redistribute eigrp 100 metric 5

A segunda é com o comando default-metric que define uma métrica inicial igual para a redistribuição vinda de qualquer srcem de roteamento. O comando “default -metric” existe também para os protocolos EIGRP e OSPF. dltec(config)#router rip dltec(config-router)#redistribute eigrp 100 dltec(config-router)#default-metric 5


  

 






  




Página 135  



 


Quando estamos redistribuindo rotas do OSPF dentro de outro protocolo, seja no RIP, EIGRP ou OSPF, existe uma opção para escolher apenas as rotas externas (LSA tipo 5) do tipo 1 e/ou 2 (E1 e/ou E2) chamada “match”. Veja um exemplo de redistribuição abaixo no BGP com AS 51000 onde vamos redistribuir apenas as rotas externas tipo 1 e 2 srcinadas no OSPF. dltec(config-router)#redistribute ospf 1 match external 1 external 2 ? internal Redistribute OSPF internal routes metric Metric for redistributed routes nssa-external Redistribute OSPF NSSA external routes route-map Route map reference dltec(config-router)#redistribute ospf 1 match external 1 external 2

Note que ainda poderíamos redistribuir apenas rotas internas (internal – LSA tipo 3) e externas vindas de redes NSSA (nssa-external – LSA tipo 7). Para verificar o sucesso da redistribuição basta entra com o comando “show ip route” nos roteadores EIGRP e verificar se as rotas do OSPF foram aprendidas e vice versa. 2.1 Problemas Relacionados à Redistribuição de Rotas Lembre-se que a redistribuição é realizada entre protocolos que tem métrica e distância administrativa diferente, por isso em redes redundantes pode ocorrer um roteamento que não é o mais apropriado (suboptimal routing) ou então loops de roteamento, principalmente em redistribuições de duas vias conforme exemplo na figura abaixo.

Atente para o fato de que as rotas externas (aprendidas por redistribuição) não têm informações detalhadas sobre o caminho. Isso porque essas rotas srcinalmente utilizam uma métrica (por exemplo, custo no OSPF) que deve ser convertida para a métrica nativa de outro protocolo (totalmente diferente). Como por exemplo na topologia mostrada acima onde uma métrica arbitrada pelo administrador ao inserir asderotas paraoutro o EIGRP e vicepor versa, portantofoi esta nova métrica não traz a informação todadoa OSPF rede do protocolo ser arbitrada, concorda?


  

 






  




Página 136  



 


Esse é o conceito de “metric seeding”, ou seja, significa que uma métrica inicial será atribuída às rotas externas que estão sendo redistribuídas dentro de outro protocolo. Por exemplo, sob processo de roteamento RIP o “redistribute ospf 1 metric 1” coloca as rotas do OSPF com um salto de métrica. Essa característica faz com que os prefixos externos pareçam estar "ligados" com o roteador de borda com uma métrica “nativa” atribuída, porém isso é uma simplificação arbitrada pelo administrador de redes, conforme já mencionado. Devido a essas "simplificações" e perda das informações detalhadas o roteamento subótimo pode ocorrer. Nessa situação nem sempre o melhor caminho será escolhido, esse é o primeiro dos problemas que a redistribuição pode trazer. Outro problema, ainda mais perigoso, é possibilidade de loops de roteamento devido a redistribuição. Cada protocolo de roteamento é capaz de convergir com caminhos livres de loops porque possuem informações completas sobre a topologia existente. Por exemplo, o OSPF precisa ter uma visão do estado dos links completo de uma área, assim como ter conectividade com a área de backbone. Já o EIGRP requer a realização de cálculos pelo DUAL em todos os roteadores para garantir um roteamento livre de loops. Já o RIP converge lentamente pela execução do algoritmo de Bellman-Ford (gradiente-driven optimization) em toda a topologia. Como a redistribuição acaba encobrindo e ocultando a informação srcinal, um protocolo de roteamento IGP como RIP, EIGRP ou OSPF não poderá garantir uma topologia livre de loops ao final do processo de convergência, pois essa nova informação de roteamento não é completa e tem uma métrica atribuída pelo administrador. Os loops de roteamento em ambientes com redistribuição geralmente são causados quando o IGP devolve rotas internas ao domínio de roteamento como prefixos externos devido à utilização de redistribuição em duas vias. Por exemplo, você está fazendo redistribuição entre o RIP e OSPF e faz o retorno no mesmo roteador do OSPF para o RIP, nesse caso o OSPF ou o RIP acabam devolvendo as rotas um do outro com métrica e distância administrativas diferentes, “enganando” um ao outro e podendo causar um loop. 3 Otimizando o Roteamento com Redistribuição A seguir vamos estudar algumas técnicas para resolver os problemas que a redistribuição pode causar e aprender a realizar implementações seguras e eficientes. 3.1 Passive Interface O uso do passive interface já foi estudado nos capítulos anteriores, porém no caso da redistribuição ele evita que informações de um protocolo de roteamento sejam passadas entre os diferentes domínios de roteamento nos roteadores de borda. É importante lembrar que no EIGRP e OSPF o passive interface não envia Hellos nas interfaces passivas, portanto não formam vizinhanças. Já no RIP esse comando evita o envio de anúncios de roteamento, porém a interface ainda pode receber anúncios e sincronizar com informações indevidas. Veja o exemplo na figura abaixo, onde devemos inserir o passive interface nas interfaces que não rodam o protocolo no roteador de borda, ou seja, a interface s0 deve estar passiva no OSPF e a s1 no EIGRP, assim não corremos o risco do estabelecimento de adjacências nos domínios de roteamento indevidamente.


  

 






  




Página 137  



 


3.2 Distância Administrativa Como você já deve saber a distância administrativa (AD ou Adminsitrative Distance, em inglês) é um valor que os roteadores utilizam para selecionar o melhor caminho quando há duas ou mais rotas para o mesmo destino descobertas através de duas ou mais fontes distintas de roteamento. Por exemplo, se uma rota é descoberta pelo RIP e outra pelo EIGRP para o mesmo destino quem determina que rota entra na tabela de roteamento é a distância administrativa. A distância administrativa é o primeiro critério para determinar qual rota usar. Quanto menor o valor distância mais confiável o protocolo. Por exemplo, se um roteador recebedauma rota deadministrativa ambos os protocolos de roteamento OSPF (distância administrativa 110) e RIP (distância administrativa 120), o roteador escolhe o OSPF para colocar na tabela de roteamento. É importante lembrar que a distância administrativa tem significado no roteador local, e não pode ser anunciada em protocolos de roteamento dinâmico. Veja na tabela abaixo dos valores padrões de distância administrativa: Origem da Rota Interface diretamente conectada Rota estática com IP como referência Rota estática com Interface como referência rota EIGRP sumário – 5 External Border Gateway Protocol (BGP) EIGRP interno IGRP OSPF Intermediate System-to-Intermediate System (IS-IS) Routing Information Protocol (RIP) Exterior Gateway Protocol (EGP) On Demand Routing (ODR) rota EIGRP externa– 170 BGP interno Desconhecido


  

 






  

Distância Adm 0 1 0 20 90 100 110 115 120 140 160 200 255




Página 138  



 


Com o comando "distance" (em modo de configuração de roteamento) é possível alterar esses valores padrões do IOS da Cisco caso seja preciso, fazendo com que uma rota de um determinado protocolo entre com uma prioridade maior ou menor. As opções do comando seguem abaixo: distance number] 







admin-distance

{ip-source-address

{wildcard-mask}}

[ip-acces-list-

admin-distance: valor da distância administrativa de 1 a 255. ip-source-address: IP de srcem das atualizações de roteamento. wildcard-mask: máscara curinga para definir uma faixa de IPs (0.0.0.0 define um único IP e 255.255.255.255 pega qualquer IP). ip-access-list-number: pode ser utilizada uma ACL para definir que rotas devem ter sua AD alterada (opcional).

Para o RIP e OSPF a alteração da distância administrativa pode ser realizada para rotas específicas ou para todo o protocolo de roteamento, vamos iniciar vendo um exemplo da alteração para todas as rotas do RIP e OSPF para 125. Router(config)#router rip Router(config-router)#distance 125 Router(config-router)#router ospf 1 Router(config-router)#distance ? <1-255>

Administrative distance

Router(config-router)#distance 125

Para o EIGRP existe uma diferença por haver distância administrativa diferente para rotas internas e externas, por isso o comando trás primeiro a configuração da AD para rotas internas e depois para as externas. Veja abaixo um exemplo alterando de 90/170 para 100/180. Router(config-router)#router eigrp 100 Router(config-router)#distance ? eigrp

IP-EIGRP distance

Router(config-router)#distance eigrp ? <1-255> Distance for internal routes Router(config-router)#distance eigrp 100 ? <1-255>

Distance for external routes

Router(config-router)#distance eigrp 100 180 ? Router(config-router)#distance eigrp 100 180


  

 






  




Página 139  



 


O BGP, além das rotas internas e externas, também permite a configuração da AD de rotas geradas localmente, veja exemplo abaixo. Router(config)#router bgp 32000 Router(config-router)#distance ? <1-255> bgp

Administrative distance BGP distance

mbgp

MBGP distance

Router(config-router)#distance bgp ? <1-255> Distance for routes external to the AS Router(config-router)#distance bgp 100 ? <1-255>

Distance for routes internal to the AS

Router(config-router)#distance bgp 100 100 ? <1-255> Distance for local routes Router(config-router)#distance bgp 100 100 100 ? Router(config-router)#distance bgp 100 100 100

Além disso, podemos alterar a distância administrativa de uma ou mais rotas específicas com o comando: Router(config-router)#distance AD-da-rota {address máscara-curinga} [número-deACL | nome-de-ACL] Veja a figura a seguir onde vamos mostrar um exemplo de roteamento subótimo que pode ser pela redistribuição e como resolver configurando a AD no roteador que está realizando acausado redistribuição.

Na figura acima você pode notar que a rede 10.1.1.0 será redistribuída dentro do OSPF pelo roteador R2, o qual irá anunciar essa rota para os roteadores R4 e R3 como se fosse uma rota externa do OSPF (O E2). No roteador R3 a rota 10.1.10 virá por duas fontes de aprendizado, pelo OSPF com AD 110 e pelo RIP através de R1 que está diretamente conectado com AD 120, portanto o que R3 fará nesse caso? A resposta é o padrão, ou seja, vai para tabela de roteamento a informação com melhor (menor) AD que é a rota aprendida por R4, esse é o melhor caminho a ser seguido? Veja a figura novamente abaixo e analise sozinho a resposta.


  

 






  




Página 140  



 


Para evitar esse problema podemos alterar a distância administrativa da rede 10.1.1.0 quando ela for redistribuída pelo roteador R2 conforme exemplo de configuração abaixo. R2(config)#access-list 1 permit 10.1.1.0 R2(config)#router ospf 1 R2(config-router)#redistribute rip subnets R2(config-router)#distance 130 0.0.0.0 255.255.255.255 1

Com o comando acima quando o roteador R2 receber uma rota para a rede 10.1.1.0 ele irá automaticamente inserir a AD 130, por isso caso ele receba a mesma rota vindo a partir de R3 o R2 vai continuar utilizando a rota aprendida pelo RIP, pois essa nova entrada terá AD 130 e a que ele deve utilizar via RIP tem AD 120. O OSPF permite também configurar a distância externa, inter-area e intra-area. O exemplo anterior poderia ser configurado com o comando “distance ospf external 130”. Veja um exemplo com o comando completo abaixo com AD externo 130, intra-área 125 e inter-área 128. dltec(config-router)#distance ospf external 130 intra-area 125 inter-area 128

Porém com o comando anterior todas as rotas externas no roteador teriam a métrica 130, já o comando para alterar a distância administrativa por rede com ACL permite uma maior granularidade.


  

 






  




Página 141  



 


3.3 Listas de Prefixos – Prefix Lists Uma lista de prefixos ou “prefix list” utiliza uma sub-rede ou prefixo (com o número de bits na máscara de sub-rede) de maneira parecida com uma lista de acesso (ACL), ou seja, são regras com uma ou mais declarações (statements) que permitem ou negam prefixos de rede para fins de seleção ou filtragem. Os roteadores avaliam esta lista de regras em ordem (da primeira criada para a última) e param quando há correspondência (match). Da mesma forma que em uma ACL, aqui também existe um “deny all” implícito no final da prefix list. Veja abaixo a sintaxe do comando e logo a seguir o que significa cada campo. ip prefix-list {list-name [seq number] {deny | permit} network/length [ge gelength] [le le-length] 











list-name: a lista pode ser nomeada ou numerada e nesse campo definimos esse nome ou número de identificação. seq number: opcionalmente podemos definir um número de sequência para cada regra ou declaração da lista, sendo que por padrão cada statement é numerado de 5 em 5, permitindo que outras declarações sejam inseridas no meio da lista ou até mesmo removidas. deny | permit: nega ou permite caso haja correspondência na lista. network/length: Configura o prefixo e número de bits que devem ser verificados na lista. Sem os opcionais “ge” ou “le” o tamanho a ser verificado é igual ao da máscara definida. Ge / ge-length: “Ge” quer dizer “greater than” ou “equal to” (m aior ou igual ao prefixo) e serve para especificar o número mínimo de bits que uma máscara de sub-rede deve ter para que haja correspondência com a regra em questão. Le / le-length: O opcional “le” quer dizer “lesser than” ou “equal to” (menor ou igual ao prefixo) e é utilizado para especificar o número máximo de bits que uma máscara de rede deve ter para que haja a correspondência da regra em questão.

Portanto, essa lista de prefixo criada será utilizada em outro comando, por exemplo, em um “route map” para selecionar ou excluir determinadas rotas dos anúncios de roteamento. Vamos a alguns exemplos de uso da lista de prefixo para facilitar o entendimento e construção do comando. Exemplo 1: selecionando uma rede e máscara /24: “ip prefix-list TESTE permit 1.2.3.0/24” Com esse comando estamos fazendo a correspondência (match) exata para o prefixo 1.2.3.0 com a máscara 255.255.255.0, ou seja, não inclui a rede 1.2.0.0/24 nem 1.2.3.4/32, por exemplo. Exemplo 2: selecionando a rota padrão (default): “ip prefix-list TESTE1 permit 0.0.0.0/0” Assim como o exemplo 1 esse prefix-list seleciona exatamente a rede 0.0.0.0 com a máscara 0.0.0.0.


  

 






  




Página 142  



 


Até agora você deve estar pensando que se fosse usada uma ACL conseguiríamos fazer a mesma coisa. Filtrando por “Access-list 1 permit 1.2.3.0 0.0.0.0” teríamos o mesmo resultado do exemplo 1 e com “Access-list 1 permit 0.0.0.0 0.0.0.0” teríamos o do exemplo 2, porém com o uso das opções “Ge” e “le” muda um pouco a interpretação, pois eles se referem a maior e menor ou igual a um prefixo e não a faixa de IPs, veja os próximos exemplos para entender o funcionamento. Exemplo 3: “ip prefix-list TESTE3 permit 1.2.3.0/24 ge 28” Nesse exemplo indicamos com o “permit 1.2.3.0/24” que vamos utilizar sempre o prefixo “1.2.3” em um range que possui máscara /28 ou maior, ou seja, máscaras de 255.255.255.240 a 255.255.255.255. Portanto, nesse exemplo, um anúncio com uma rede 1.2.3.0/24 não passaria porque a máscara deve ser maior que /28 (/28, /29, /30, /31 ou /32). Exemplo 4: “ip prefix-list TESTE4 permit 1.2.3.0/24 le 28” Nesse exemplo continuamos com o mesmo prefixo, porém agora a máscara é menor ou a igual a /28 (por causa do “less than or equal”) indo no máximo até /24 (anunciado com o prefixo). Portanto, ao contrário do exemplo anterior, o prefixo 1.2.3.0 com uma máscara 255.255.255.0 será permitido. Nesse exemplo podemos ter máscaras /24, /25, /26, /27 e /28. Exemplo 5: “ip prefix-list TESTE4 permit 1.2.3.0/24 ge 26 le 28” Agora nesse exemplo estamos especificando máscaras entre /26 e /28 (/26, /27 e /28), assim como no exemplo 3 a rede 1.2.3.0/24 não será permitida com esse comando, pois sua máscara não está entre a faixa de valores permitidos. Condições de uso especial: 





Valores de “Ge” e “le” iguais combinando os bits de c lasse seleciona redes classfull, por exemplo, a rede classe A tem sempre o bit 1 igual a zero e máscara /8, podemos utilizar a regra “ip prefix-list TESTE permit 0.0.0.0/1 ge 8 le 8”, pois 0.0.0.0/1 deixa fixo somente o primeiro bit da máscara que identifica a classe A e “Ge=le=8” pega apenas redes /8 ou 255.0.0.0, ou seja, máscara padrão da classe A. o Classe B: “ip prefix-list TESTE permit 128.0.0.0/2 ge 16 le 16” o Classe C: “ip prefix-list TESTE permit 192.0.0.0/3 ge 24 le 24” Permitir todas as redes ("permit any any"): “ip prefix-list TESTE permit 0.0.0.0/0 le 32” Selecionar IPs privativos (RFC 1918): o Classe A: “ip prefix-list TESTE permit 10.0.0.0/8 le 32” o Classe B: “ip prefix-list TESTE permit 172.16.0.0/12 le 32” o Classe C: “ip prefix-list TESTE permit 192.168.0.0/16 le 32”

você verificar Para verá a aplicação a lista dede prefixos uma lista utilize deoprefixos comandoutilizada “show ip emprefix listas-list”. de distribuição Nos tópicos de a seguir rotas (distribution list) ou mapas de rotas (route map).


  

 






  




Página 143  



 


3.4 Listas de Distribuição – Distribute Lists Uma lista de distribuição permite filtrar atualizações de roteamento e também rotas que estão sendo redistribuídas através do uso de uma lista de acesso, listas de prefixo, route map ou gateway. As ACLs podem ser numeradas ou nomeadas, padrões ou estendidas. dltec(config-router)#distribute-list ? <1-199> <1300-2699>

IP access list number IP expanded access list number

WORD gateway

Access-list name Filtering incoming updates based on gateway

prefix

Filter prefixes in routing updates

route-map

Filter prefixes based on the route-map

Com lista de acesso (ACL) basta criar uma lista que permita as rotas a serem anunciadas ou redistribuídas e depois indicar a lista de acesso na lista de distribuição dentro do modo de configuração do protocolo de roteamento. As listas de distribuição podem ser de entrada (in) ou de saída (out): 



“distribute-list num-ACL in”: Filtra atualizações entrantes em uma interface. Para o OSPF o controle é feito nas rotas inseridas na tabela de roteamento, não na base de dados. Para os outros protocolos ela controla as rotas que o protocolo conhece. “distribute-list num-ACL out”: filtra atualizações que estão saindo da interface e também atualizações sendo redistribuídas de outro protocolo de roteamento.

A lista de distribuição permite que você defina as rotas que serão anunciadas ou recebidas evitando, por exemplo, o retorno de uma rota anunciada em uma redistribuição de duas vias com métrica diferente. No exemplo que utilizamos com a distância administrativa poderíamos também configurar no roteador R3 uma lista de distribuição de entrada filtrando a rota para a rede 10.1.1.0/24 que ele já conhece via R1.


  

 






  




Página 144  



 


3.4.1 Configurando uma Lista de Distribuição

Nesse tópico vamos mostrar os passos para a configuração de uma lista de distribuição utilizando ACL. Veja os passos abaixo. Passo 1 – Definir as rotas a serem filtradas Nesse exemplo queremos filtrar rotas que estão entrando no roteador (inbound route). Vamos iniciar analisando a tabela de roteamento do roteador e escolher que rota vamos quere filtrar. Router#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloade d static route Gateway of last resort is not set 100.0.0.0/8 is variably subnetted , 3 subnets, 2 masks O 100.200.200.1/32 [110/11] via 172.16.100.29, 00:00:10, Ethernet0 O 100.200.100.1/32 [110/11] via 172.16.100.29, 00:00:10, Ethernet0 C 100.100.250.0/24 is directly connected, Loopback0 172.16.0.0/24 is subnetted, 1 subnets C 172.16.100.0 is directly connected, Ethernet0

Nesse exemplo vamos filtrar a rota 100.200.100.1/32. Passo 2 – Criar uma ACL para filtrar a rota Agora vamos criar uma ACL que filtre a rota indesejada e permita as demais informações de roteamento. Veja a ACL sugerida abaixo. Router(config)#access-list 10 deny 100.200.100.1 Router(config)#access-list 10 permit any

Passo 3 – Criar a Distribute-List Agora com a ACL (numerada – 10) e a direção definida (entrada – in) vamos criar a distributelist referenciando a ACL criada na direção correta. Veja a seguir a configuração dentro do modo de configuração do roteamento OSPF (protocolo usado nesse exemplo). Router(config)#router ospf 1 Router(config-router)#distribute-list ? <1-199>

IP access list number

<1300-2699> IP expanded access list number WORD

Access-list name

gateway

Filtering incoming updates based on gateway

prefix Filter prefixes in routing updates Router(config-router)#distribute-list 10 ? in

Filter incoming routing updates


  

 






  




Página 145  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br out Filter outgoing routing updates Router(config-router)#distribute-list 10 in Router(config-router)#end Router#

Passo 4 – Verificar se a rota foi removida da tabela de roteamento Com o comando “show ip route” verificamos se a rota 10.200.100.1/32 foi realmente filtrada. Router#sh ip ro (truncated) 100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O 100.200.200.1/32 [110/11] via 172.16.100.29, 00:11:39, Ethernet0 C 100.100.250.0/24 is directly connected, Loopback0 172.16.0.0/24 is subnetted, 1 subnets C 172.16.100.0 is directly connected, Ethernet0 Router#

Poderíamos ainda referenciar a distribute-list com uma prefix-list, veja o mesmo exemplo usando uma lista de prefixos abaixo. R1(config)#ip prefix-list teste deny 10.200.100.1/32 R1(config)#ip prefix-list teste permit 0.0.0.0/0 le 32 R1(config)#router ospf 1 R1(config-router)#distribute-list prefix teste in R1(config-router)#end R1#sho ip prefix-list ip prefix-list teste: 2 entries seq 5 deny 10.200.100.1/32 seq 10 permit 0.0.0.0/0 le 32 R1#

No comando “ip prefix-list teste deny 10.200.100.1/32” estamos bloqueando a rede que desejamos filtrar e logo abaixo no comando “ip prefix-list teste permit 0.0.0.0/0 le 32” fazemos a liberação para as demais redes, pois a lista de prefixos possui um deny implícito no final. Depois no comando “distribute-list” referenciamos a lista de prefixos com o comando “prefix” mais o nome da lista criada, definindo no final o sentido de entrada (in) conforme direção escolhida. Outra opção de filtrados, configuração de uma lista de distribuição é identificar interface por as onde os anúncios serão por exemplo, o comando “distribute-list 10 in afast 0/0” filtra redes definidas na ACL padrão 10 somente na entrada da interface fast 0/0.


  

 






  




Página 146  



 


3.5 Route Maps Route Maps ou Mapas de Rotas se parecem um pouco com uma linguagem de programação que utiliza recursos como if/then/else para tomada de decisão. Ela verifica o tráfego em relação a certas condições pré-estabelecidas e define uma ação a ser tomada com esse tráfego. Assim como uma ACL nomeada, cada instrução de um route map tem um número de sequência e as declarações (statements) são lidas do menor para o maior número. Da mesma maneira que uma ACL o roteador para de ler as instruções e executa uma ação assim que há correspondência (match). O número de sequência pode ser usado para inserir ou excluir declarações, além disso, como em uma ACL há uma negação implícita no final de cada mapa de rotas, ou seja, se o tráfego não corresponder com uma declaração por padrão ele é negado. Os usos mais comuns de route maps são nos seguintes cenários: 





Filtragem de rotas redistribuídas: utilizando a palavra-chave route-map no comando redistribute. Roteamento baseado em política (policy-based routing - PBR): estabelece uma política de roteamento baseada em controles mais precisos, estudaremos no próximo capítulo mais sobre esse recurso. Política de encaminhamento do BGP: utilizado para controlar atualizações de roteamento e manipular atributos de caminho do protocolo BGP.

Mapas de rotas são criados em modo de configuração global com o comando abaixo: R1(config)#route-map {tag} permit | deny [sequence_number]

Os mapas de rota são criados definindo um nome ou tag, depois permitindo ou negando, seguido por um número de sequência opcional. Se nada for definido o IOS inicia em 10 como número de sequência. Permitir ou permit significa que qualquer tráfego que atenda às condições definidas internamente do route-map é processado. Negar significa que qualquer tráfego correspondente às condições não será processado pela instrução do route-map. Ao digitar o comando para definir o route-map você entrará em outro modo de configuração para definir as declarações com “match” e “set”. A opção “match” é utilizada para f azer a correspondência ou, em inglês, o “matching” e o “set” é utilizado para definir a ação a ser tomada. Por exemplo, em redistribuições o set pode ser utilizado para alterar a métrica, tipo da métrica no OSPF ou então marcar (tag) a rota para permitir uma filtragem posterior. Veja um exemplo abaixo para ficar mais clara a sequência de explicações. dltec(config)#ip prefix-list teste permit 10.20.10.0/24 dltec(config)#route-map teste1 permit 10 dltec(config-route-map)#match ip address prefix-list teste dltec(config-route-map)#set tag 51


  

 






  




Página 147  



 


No comando o match foi vinculado a uma lista de prefixos chamada teste, portanto se um anúncio contendo a rede 10.20.10.0/24 chegar dará a correspondência e no comando set está para inserir uma marcação (tag) com o número 51 nessa rota. Como ao final de um route-map existe um deny implícito nada mais precisa ser feito, pois nossa regra quer selecionar uma rota específica para mudar o valor do tag. Caso a regra fosse bloquear determinada rota e depois permitir as demais seria necessário um “permit any” no final que é realizado com o comando “route-map teste1 permit 20”, pois sem nenhum “match/set” definido a regra deixa passar tudo. O match pode ser ainda utilizado com uma expressão utilizando AND ou OR. O OR apenas uma das condições precisa ser satisfeita para que haja correspondência e ele é ativado quando colocamos as condições do match em uma mesma linha (match a b c -> match a OR b OR c). Já o AND é realizado se colocamos as declarações do match uma em cada linha, ou seja, dessa maneira TODAS as condições devem ser verdadeiras, por exemplo, “match a AND b AND c” ficaria (a, b e c são condições): route-map 1 permit Match a Match b Match c

As principais opções que podem ser utilizadas como condição de teste no comando match são:   



   

ip address: faz referência a uma ACL para fazer a seleção das redes. ip address prefix-list: utiliza uma prefix-list como referência para seleção das redes. ip next-hop: utiliza também como referência uma access-list que permite ou nega endereços de vizinhos diretamente conectados (next-hop IP address). ip route-source: faz referência a uma ACL que permite ou nega o IP de roteadores que estão trocando anúncios de roteamento com o roteador local. length: permite ou nega pacotes com base em seu tamanho em bytes. metric: faz referência em rotas com determinada métrica. route-type: faz a escolha por tipo de rota (interna ou externa). tag: faz o processo de verificação através das marcações (tags) aplicadas às rotas.

Já para a opção set temos (principalmente em redistribuição de rotas) as seguintes opções mais utilizadas:   

metric: define uma métrica para as rotas. metric-type: define o tipo de métrica da rota, por exemplo, E1 ou E2 para o OSPF. tag: identifica uma rota com uma marcação (tag) que pode ser utilizada para o processo

de identificação de rotas por outros route maps, por exemplo. Agora vamos nos próximos tópicos estudar algumas aplicações práticas do route-map.


  

 






  




Página 148  



 


3.5.1 Utilizando Route Map para controlar a Redistribuição

Vamos mostrar na prática a criação de um route-map chamado BGP-TESTE com três regras para controlar as rotas que serão redistribuídas do OSPF 1 para dentro do BGP com AS 51000. Para o processo de match das redes serão criadas duas access lists padrão numeradas 1 e 2 selecionando as redes 10.0.10.0 e 192.168.1.0 respectivamente. R1(config)#access-list 1 permit 10.0.10.0 R1(config)#access-list 2 permit 192.168.1.0

Na primeira regra ou declaração do route map (match statement) vamos utilizar o número de sequência 10 e uma permissão. O objetivo dessa condição é utilizar a ACL 1 para identificar o tráfego permitido que será redistribuído no BGP. Além disso, existe uma condição set informando o valor da preferência local do BGP (local preference) para essa rota para 200. Caso o tráfego não corresponda a primeira ACL (access list 1) o roteador irá testar com o segundo statement do route map que tem o número de sequência 20. Essa regra bloqueia (deny) a rede 192.168.1.0 conforme definido na access list 2, portanto esse tráfego não será redistribuído. Se o tráfego não bater com as ACLs 1 ou 2 ele será confrontado com a terceira regra configurada no route map com o número de sequência 30. Nesse terceiro statement temos um “permit any”, pois ele tem um permit sem nenhuma condição, portanto ele permite a redistribuição do restante do tráfego sem alteração nenhuma. Se não houvesse essa condição todo o restante do tráfego seria negado. Veja abaixo a configuração dos três statements no Route Map BGP-TESTE: R1(config)#route-map BGP-TESTE permit 10 R1(config-route-map)#match ip address 1 R1(config-route-map)#set local-preference 200 R1(config-route-map)#route-map BGP-TESTE deny 20 R1(config-route-map)#match ip address 2 R1(config-route-map)#route-map BGP-TESTE permit 30 R1(config-route-map)#exit

Por último, vamos vincular o route-map com o comando redistribute dentro do processo do BGP com AS 51000. R1(config)#router bgp 51000 R1(config-router)#redistribute ospf 1 route-map BGP-TESTE

Para verificar o route-map criado você pode utilizar o comando “show route-map” e para ver um mapeamento específico utilize o nome ao final do comando, por exemplo, “show route-map BGP-TESTE ”.


  

 






  




Página 149  



 


3.5.2 Marcando e Bloqueando Rotas em Redistribuições com Route Map

Outra maneira de utilizar um route map é marcar com uma tag as rotas enquanto elas estão sendo redistribuídas de um protocolo para outro. Com essa marcação realizada você pode então utilizá-lo para bloquear (deny) a redistribuição dessas rotas para dentro do protocolo de roteamento srcinal no caso de redistribuição em duas vias. Portanto, estamos evitando que rotas subótimas sejam criadas, ou até mesmo loops de roteamento, devido a redistribuição mútua. Vamos a um exemplo prático onde as rotas do EIGRP serão redistribuídas no OSPF e um routemap o nome dois statements faráO asegundo marcação da rota 2 (set tag 2) e ocom bloqueio deEIGRP-OSPF rotas com a etag 1 (match tag 1). route map com comaotag nome OSPFEIGRP fará a marcação das rotas que serão redistribuídas do OSPF para dentro do EIGRP, sendo que a marcação dessas rotas será com a tag 1 (set tag 1) e serão bloqueadas rotas marcadas com a tag 2 (match tag 2). R1(config)#route-map EIGRP-OSPF deny 5 !  bloqueia R1(config-route-map)#match tag 1 R1(config-route-map)#route-map EIGRP-OSPF permit 10 R1(config-route-map)#set tag 2 R1(config-route-map)#exit R1(config)#route-map OSPF-EIGRP deny 5 !  bloqueia R1(config-route-map)#match tag 2 R1(config-route-map)#route-map OSPF-EIGRP permit 10 R1(config-route-map)#set tag 1 R1(config-route-map)#exit

as rotas de retorno com tag 1

!

 marca as rotas com tag 2

as rotas de retorno com tag 2

!

 marca as rotas com tag 1

Uma vez definidas os route maps vamos criar os comandos de redistribuição vinculando cada R1(config)#router um deles com o protocolo eigrpde1roteamento correto, veja abaixo. R1(config-router)#redistribute ospf 2 route-map OSPF-EIGRP metric 1 1 1 1 1500 R1(config-router)#router ospf 2 R1(config-router)#redistribute eigrp 1 route-map EIGRP-OSPF subnets

Veja a figura abaixo com uma ilustração do que está acontecendo com a configuração realizada. Portanto, as rotas aprendidas do EIGRP pelo OSPF (O E2) serão marcadas com a tag 2, como os roteadores internos consideram essa rota vinda do OSPF pode haver um retorno para o roteador A, porém ele está bloqueando a redistribuição de rotas marcadas como 2 para dentro do EIGRP, por isso loops de roteamento serão evitados assim como o roteamento subótimo.

Se você acompanhar imagem da direita, o roteador A marca as rotas vindas do EIGRP como 2, devido a topologia essa rota é inserida no domínio OSPF como "O E2" pela redistribuição e retorna ao roteador A, porém como essa rota foi marcada com a tag 2 a route-map manda bloquear essa tag, a rota de retorno não é reenviada para dentro do domínio do EIGRP. Apostila/E-B     

  

 






  




Página 150  



 


4 Verificando a Redistribuição Para realizar a verificação e troubleshooting na redistribuição de rotas é necessário na fase do planejamento da implantação ter o levantamento das rotas que deveriam estar presentes na tabela de roteamento dos roteadores onde o comando redistribute será implementado e antes da implementação checar se realmente todas as rotas estão presentes. Tenha em mente que muitas vezes o problema encontrado pode não estar na redistribuição e sim no próprio protocolo de roteamento que não possui todas as rotas esperadas em sua tabela de roteamento por outros motivos, por exemplo, links que estão down ou falhas inesperadas. Para verificar a tabela de roteamento utilizamos o comando “show ip route”. Esse comando deve ser utilizado tanto nos roteadores de borda (no OSPF são os ASBRs) que executam a redistribuição como nos roteadores que não estão executando a redistribuição. Nos roteadores de borda também utilizamos o comando “show ip protocols” para verificar se a redistribuição foi configurada corretamente, assim como no comando “show runningconfiguration” pode ser utilizado para verificar a redistribuição e demais configurações relacionadas. No OSPF um problema comum é a falta da opção “subnets” no comando de redistribuição. Já para o RIP e o EIGRP a falta da definição da métrica da rota distribuída também é um problema comum, pois as rotas acabam sendo anunciadas com métrica infinita se não for definida uma métrica inicial. Esses problemas citados fazem com que as rotas não sejam distribuídas e não apareçam na tabela de roteamento dos demais roteadores que não estão realizando a redistribuição. Outros problemas comuns são relacionados à aplicação incorreta das técnicas de filtragem de rotas e/ou ajuste de parâmetros para melhorar a redistribuição. Uma ACL errada em uma lista de distribuição, por exemplo, pode impedir que determinadas rotas sejam anunciadas durante o processo de redistribuição.


  

 






  




Página 151  



 


5 Planejamento e Considerações Finais sobre Redistribuição É importante no momento do planejamento da redistribuição entre protocolos de roteamento lembrar que os protocolos muitas vezes utilizam informações de roteamento incompatíveis e com tempos de convergência também diferentes. Portanto, é importante definir um protocolo que será o principal (core ou main) e o ou os protocolos que ficarão nas pontas da rede (edge protocol), dessa maneira é possível redistribuir as rotas dos protocolos das pontas para o central e do central para as pontas utilizar uma rota estática, por exemplo, para evitar roteamento subótimo ou loops de roteamento provocados pela redistribuição mútua. Portanto, é importante decidir no momento de planejamento da redistribuição também se será realizada a redistribuição em uma via (one-way) ou duas vias (two-way), assim como se ela será em apenas um ponto (single point) ou realizada em diversos pontos (multipoint ou multiponto), pois com essas informações é possível definir as medidas para evitar o roteamento subótimo e também possíveis loops de roteamento. 5.1 Redistribuição One-way ou Two-way? Com redistribuição em uma via ou one-way você deve fazer a redistribuição dos protocolos das pontas ou “edge routing protocol” dentro de um “core protocol” que normalmente abrange o núcleo da rede ou uma região principal de roteamento. Nesse caso, para os roteadores edge conhecerem os caminhos para o core utilizam-se rotas estáticas ou roteamento default. Quando utilizamos redistribuição two-way as rotas são redistribuídas mutuamente entre os protocolos core e edge, não necessitando de rotas estáticas para que os diversos protocolos conheçam as rotas uns dos outros. Ambas as redistribuições, em uma ou duas vias, são consideradas seguras quando utilizamos apenas um ponto, ou seja, a redistribuição está configurada em apenas um roteador, pois dessa maneira existe apenas um ponto de saída entre os domínios de roteamento e loops não serão um problema, apenas o roteamento subótimo que pode ser resolvido com as técnicas estudadas nesse capítulo. Já a redistribuição em múltiplos roteadores dentro da rede pode causar loops e também roteamento subótimo. Recomendações para redistribuição multiponto em uma via: 



Utilizar preferencialmente protocolos que usam valores diferentes de ADs para rotas internas e externas (EIGRP, OSPF e BGP). Garanta que a AD das rotas externas redistribuídas sejam maiores que a AD do protocolo srcinal para não haver roteamento subótimo ou rotas de retorno que podem causar loops.

Recomendações para redes com redistribuição em duas vias multiponto: 





Garantir que somente rotas internas sejam redistribuídas a partir de cada protocolo de roteamento. Isso pode ser feito com a marcação das rotas (tagging) e filtragem das rotas no momento da redistribuição utilizando essas tags, conforme mostramos em tópico anterior. Ajustar a métrica de rotas redistribuídas. Considerar o uso de roteamento default para os protocolos de edge para evitar o uso de redistribuição two-way.


  

 






  




Página 152  



 


5.2 Recomendações Finais Procure fazer um design o mais seguro possível, ou seja, seguindo algumas recomendações básicas: 





Redistribuir rotas de todo edge para o core, porém enviar apenas uma rota padrão do core para o edge ou então múltiplas rotas estáticas em designs de uma via. Se redistribuir em ambas as direções filtrar o retorno das rotas redistribuídas em seus domínios de roteamento srcinais para evitar que elas voltem e causem possíveis loops. Quando redistribuir as rotas em ambas as direções incrementar a AD das rotas externas, para caso elas voltem ao seu domínio de roteamento srcinal não interfiram nas rotas que srcinaram as informações da redistribuição.

Os comandos utilizados no IPv6 para redistribuição entre protocolos ou múltiplas instâncias são idênticos aos estudados aqui para o IPv4. Em modo de configuração do protocolo de roteamento entre com o comando “redistribute protocolo-de-roteamento” e especifique as opções como route maps, se necessário. Pontos importantes sobre redistribuição e considerações finais: 













O roteador vai redistribuir apenas rotas aprendidas pelo protocolo de srcem. Por exemplo, se as rotas conectadas forem redistribuídas no protocolo de roteamento elas serão anunciadas e não redistribuídas. Se as rotas forem distribuídas em diversos roteadores é importante checar o caminho que o tráfego seráque encaminhado, o roteamento subótimo podeerroneamente. ocorrer (suboptimal routing) e rotas não são as pois melhores podem ser escolhidas Uma maneira de corrigir é ajustando a distância administrativa (AD - administrative distance) das rotas que estão sendo redistribuída para no caso de retorno elas terem uma AD pior que as rotas do domínio de roteamento srcinal. Certifique-se de inserir uma métrica inicial (seed metric) quando redistribuir rotas no RIP ou então as rotas serão redistribuídas com métrica 16, ou seja, para o RIP serão rotas inalcançáveis (“unreachable”). Quando distribuímos rotas entre dois processos OSPF as rotas anunciadas no novo processo serão do tipo 2 (O E2). Incluir a opção “subnets” quando redistribuir rotas de outro protocolo dentro do OSPF ou senão somente rotas classful serão redistribuídas. Na redistribuição de rotas dentro do BGP a opção “include-connected” pode ser utilizada para anunciar rotas conectadas no BGP. O BGP não redistribui rotas aprendidas pelo IBGP dentro de um protocolo IGP por padrão. Para alterar esse comportamento pode ser utilizado o comando “bgp redistribute-internal” dentro do modo de configuração do BGP.


  

 






  




Página 153  



 


Capítulo 06 - Controle de Encaminhamento de Tráfego

Nesse capítulo vamos estudar técnicas utilizadas para configurar o roteamento entre múltiplos links de maneira mais previsível e estável, sem depender exclusivamente de protocolos de roteamento.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: 

A redundância é sempre desejável, mas em alguns casos pode trazer consequências negativas, por isso muitas vezes é importante executar uma configuração para determinados serviços ou aplicações de maneira que o tráfego flua por caminhos bem determinados.

 



 

Os principais métodos para controle de caminhos – Path Control Configurar Offset-Lists Compreender e configurar Roteamento Baseado em Políticas – Policy Based Routing A filosofia e configuração do Cisco IOS IP Service Level Agreements (IP SLA) Optimized Edge Routing (OER) Virtual Routing and Forwarding (VRF)


Nesse capítulo estudaremos técnicas como Offset-lists, IP SLA, Policy-based Routing (PBR), Optimized Edge Routing e Virtual Routing and Forwarding (VRF).

1 Introdução ao Controle de Caminhos – Path Control _______________________ 155 2

Configurando Offset-Lists_________ 155

3 Roteamento Baseado em Políticas – Policy Based Routing ________________ 157

3.1

Bons estudos!

Configurando uma PBR __________ 158

4 Cisco IOS IP Service Level Agreements (IP SLA) _____________________________ 160

4.1 Configurando o IP SLA para Controle de Caminho ___________________________ 161 4.2 5

Combinando o IP SLA com PBR ____ 163

Virtual Routing and Forwarding (VRF-

Lite) _____________________________ 164

5.1


  

 






  

Configuração Básica do VRF-Lite ___ 165




Página 154  



 


1 Introdução ao Controle de Caminhos – Path Control Em geral a redundância de links entre localidades ou da saída de Internet é desejável e recomendável, porém pode levar a alguns problemas de rede. Por isso em alguns casos é preciso controlar manualmente o caminho que todo o tráfego ou parte dele irá tomar, fazendo com que o fluxo de informações tenha uma saída previsível e bem determinada.

O “path control” (controle de caminho) proporciona os seguintes recursos e vantagens:   



Impedir roteamento subótimo, facilitando na escolha do melhor caminho; Garantir a disponibilidade de caminho proporcionando redundância; Fornecer um desempenho otimizado para aplicações específicas, por exemplo, você pode escolher que caminho somente o protocolo HTTPS deve seguir diferente de outros protocolos. Balanceamento de carga entre vários caminhos diferentes.

A estratégia de se fazer um bom controle de caminho é entender que o tráfego é bidirecional, considerando o tráfego de entrada e saída. Tenha em mente que algumas vezes pode ocorrer o roteamento assimétrico, ou seja, o tráfego sai através de um link e entra através de outro link diferente (o que não é inerentemente ruim). Porém, é preciso minimizá-lo ao utilizar dispositivos stateful, por exemplo, como os firewalls ou aplicações sensíveis a atraso e jitter como a voz e vídeo sobre IP. A seguir vamos estudar as principais técnicas que permitem o controle de caminho.

2 Configurando Offset-Lists Uma offset-list é utilizada para aumentar a métrica de determinadas rotas com a finalidade de alterar o comportamento padrão do protocolo de roteamento na escolha do melhor caminho. Por exemplo, você precisa que o roteador utilize um caminho que o protocolo de roteamento considera pior ou deseja fazer balanceamento de carga utilizando rotas de diferentes custos sem o suporte do comando "variance" do EIGRP ou no RIP (que não suporta o Unequal Cost Path Load Sharing).


  

 






  




Página 155  



 


As offset-lists foram, srcinalmente, criadas para o RIP, uma vez que ele apenas usa o salto (hop count) como métrica e muitas vezes poderia escolher um caminho com menos largura de banda porque simplesmente ele tem menos salto que o de maior largura de banda. Nessa situação, com uso das offset-list seria possível manipular a escolha do melhor caminho. Somente o RIP e EIGRP suportam o recurso de offset-lists e sua configuração deve ser feita em modo de configuração de protocolo de roteamento. Abaixo segue o comando e sua sintaxe: Router(config-router)#offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]

No RIP o valor “offset” é adicionado ao número de saltos da rota, já no EIGRP ele é adicionado ao “delay”. Principalmente no EIGRP é preciso ter cuidado ao alterar a métrica testando cuidadosamente depois da alteração se o objetivo foi cumprido. Vamos ao primeiro exemplo onde temos o valor de atraso (delay) 1000 sendo adicionado à métrica do EIGRP. As redes permitidas foram definidas na ACL padrão de número 51 e terão a métrica alterada quando os anúncios forem recebidos via FastEthernet 0/0, pois é uma lista de entrada (in). R1(config)#access-list 51 permit 10.0.0.0 0.0.0.255 R1(config)#access-list 51 permit 172.16.0.0 0.0.0.255 R1(config)#router eigrp 51 R1(config-router)#offset-list 51 in 1000 fa0/0

Agora veja o segundo exemplo onde no roteador R2 foi configurado uma offset-list de saída pela serial 0/1 que adiciona 13 à métrica das rotas 1.1.1.1/32 e 2.2.2.2/32 (ACL 1). Como essas rotas foram srcinadas em R1 elas chegam a R2 com a métrica 1, ao serem enviadas para R3 soma-se 13, ficando 14 e em R3 será 15, conforme a tabela de roteamento. Quando essas rotas chegarem a R4 elas terão métrica infinita (16) e por isso não aparecem na tabela de roteamento, conforme a saída em R4.

Você pode configurar mais de uma offset-list, porém quando vinculada a uma interface (como no exemplo acima) terá precedência sobre uma offset-list normal (sem interface especificada).


  

 






  




Página 156  



 


3 Roteamento Baseado em Políticas – Policy Based Routing O roteamento IP normal escolhe um caminho com base no endereço IP de destino, mas e se você precisar enviar o tráfego HTTP para uma interface e o restante para outra (veja a figura abaixo)? É aí que pode entrar o “Roteamento Baseado em Políticas (Policy Based Routing - PBR)”, pois ele permite direcionar o tráfego com base em outras variáveis que são definidas em um routemap.

Portanto, o PBR usa um mapa de rotas para fazer o processo de correspondência com o tráfego (match) e, definindo um endereço de um próximo salto ou uma interface de saída na configuração, encaminhar o tráfego. Na figura acima o tráfego HTTP será encaminhado pela fast 0/0 e os demais tráfegos para a fast 0/1 através de uma PBR configurada em R1, permitindo que o tráfego HTTP seja inspecionado por um firewall ou IPS antes de entrar ou sair da rede. Além disso, o PBR também pode ser utilizado para marcar o tráfego para fins de QoS, por exemplo. Se o tráfego não corresponder aos testes do route-map ele é roteado normalmente. O roteamento baseado em políticas pode ser aplicado tanto no tráfego entrante no roteador como no srcinado pelo roteador (tráfego de saída). Os principais benefícios do roteamento baseado em política são:   



Capacidade de rotear pela srcem do tráfego (source) e outros atributos; Capacidade de definir marcações de QoS; Capacidade de forçar o balanceamento de carga entre os caminhos com métricas desiguais sem alterar parâmetros em protocolos de roteamento; Capacidade de alocar o tráfego entre vários links com base em atributos de tráfego, ou seja, fazer reserva de banda por aplicação (importante para Voz e Vídeo sobre IP).


  

 






  




Página 157  



 


3.1 Configurando uma PBR Para configurar uma PBR siga os seguintes passos: 







Passo 1: Configurar um route-map para selecionar tráfego desejado (comando match), utilizar o comando “set” para definir as ações caso o tráfego selecionado corresponder com o teste do comando “match”. Passo 2: Opcionalmente permitir a PBR através de fast-switching, sendo que o CEF é utilizado por padrão para a PBR quando ela está ativada, ou seja, se o CEF está ativado na interface a PBR também utilizará para o de processamento Passo 3: Aplicar o route-map na CEF interface entrada ou dos ao pacotes tráfego IP. gerado pelo roteador. Passo 4: Verificar a configuração com os comandos “show ip policy” e “show route-map {nome-da-route-map}”.

Para fazer a correspondência dos pacotes com o comando match podemos utilizar parâmetros como endereço de srcem ou de destino, lista de acesso e tamanho do pacote. Se não for definido nada todos os pacotes serão correspondidos (“dão match”). Com o comando “set” você pode definir a precedência do pacote IP, o TOS (Type of Service) para fins de marcação de QoS ou determinar como o tráfego irá sair do roteador. Há quatro maneiras de encaminhar tráfego com uma PBR, sendo que se houver mais de uma instrução o roteador fará a avaliação ou encaminhamento nesta ordem: 1. set ip next-hop ip-address: com essa opção o roteador verifica se o endereço do próximo salto está alcançável, se sim o tráfego é encaminhado para esse endereço. Se não ele usa a tabela de roteamento. 2. set interface interface-type interface-number : quando é utilizado roteador verifica se existe uma rota explícita para a redeeste de comando destino na tabela deo roteamento antes de encaminhar o tráfego na saída da interface especificada no comando. Se não houver rota este comando é ignorado e a rota padrão não é considerada rota explícita. Listando múltiplas interfaces no comando “set” é possível ter redundância, ou seja, se a primeira interface falhar ou ficar down, o roteador usa a primeira interface ativa listada no comando. 3. set ip default next-hop ip-address: esse comando se comporta como uma rota padrão, ou seja, se a tabela de roteamento tem uma entrada para a rede de destino o roteador usa essa rota mais específica, porém senão existe rota para esse destino o comando é executado e o pacote é encaminhado para o IP definido nele. Uma rota padrão não é considerada um caminho ou rota explícita. 4. set default interface interface-type interface-number: esse comando é igual ao anterior, porém a saída padrão agora é uma interface de saída e não mais um IP. Para aplicar a PBR na interface utilizamos o comando “ip policy route-map nome-da-routemap”. Para aplicar a PBR nos pacotes srcinados pelo próprio roteador utilizamos o comando “ip local policy route-map nome-da-route-map”.


  

 






  




Página 158  



 


Vamos ver dois exemplos de configuração de PBRs a seguir. Exemplo 1: O objetivo desse exercício é configurar uma PBR que ao receber o tráfego da rede 10.0.0.0/24 pela interface fast 0/0 ele deve ser encaminhado para o IP do próximo salto 10.1.1.1. Abaixo seguem os passos para configuração Definindo o tráfego interessante (poderia ser uma ACL IP padrão): R1(config)#access-list 100 permit ip 10.0.0.0 0.0.0.255 any

Configurando o route-map: R1(config)#route-map ex-1 permit 10 R1(config-route-map)#match ip address 100 R1(config-route-map)#set ip next hop 10.1.1.1

Aplicando o route-map na interface fast 0/0 R1(config)#interface FastEthernet0/0 R1(config-if)#ip policy route-map ex-1

Verificando as configurações: R1#sho ip policy Interface Route map Fa0/0 ex-1 R1#sho route-map ex-1 route-map ex-1, permit, sequence 10 Match clauses: ip address (access-lists): 100 Set clauses: ip next-hop 10.1.1.1 R1# Policy routing matches: 0 packets, 0 bytes

Note que com o comando “show ip policy” conseguimos visualizar os route -maps aplicados nas interfaces, já com o comando “show route-map ex-1” conseguimos verificar a configuração do route-map e também se houveram “matches” nessa política. Exemplo 2: Nesse segundo exemplo vamos configurar uma política de roteamento fazendo com que o tráfego vindo da rede de srcem 10.0.0.0/24 seja encaminhado para o IP de próximo salto 192.168.1.1, mas a rede de srcem 10.0.1.0/24 deve ser encaminhada para o IP de próximo salto 192.168.1.5. Definindo a ACL para seleção do tráfego interessante: R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#access-list 2 permit 10.0.1.0 0.0.0.255

Configuração dos route-maps: R1(config)#route-map ex-2 permit 10 R1(config-route-map)#match address 192.168.1.1 1 R1(config-route-map)#set ipipnext-hop R1(config-route-map)#! R1(config-route-map)#route-map ex-2 permit 20 R1(config-route-map)#match ip address 2 R1(config-route-map)#set ip next-hop 192.168.1.5

Aplicando a política na interface de LAN: R1(config-route-map)#interface fast 0/0 R1(config-if)#ip policy route-map ex-2


  

 






  




Página 159  



 


Verificando a configuração: R1#sho ip policy Interface Route map Fa0/0 ex-2 R1#sho route-map ex-2 route-map ex-2, permit, sequence 10 Match clauses: ip address (access-lists): 1 Set clauses: ip next-hop 192.168.1.1 Policy routing matches: 0 packets, 0 bytes route-map ex-2, permit, sequence 20 Match clauses: ip address (access-lists): 2 Set clauses: ip next-hop 192.168.1.5 Policy routing matches: 0 packets, 0 bytes

4 Cisco IOS IP Service Level Agreements (IP SLA) O Cisco IOS IP Service Level Agreements (SLAs) é um recurso que possibilita ativar em roteadores e switches Cisco “probes” ou “pacotes de teste” que simulam tipos específicos de tráfego que são enviados a um endereço IP address ou a um receptor (receiver), o qual é chamado de “responder”. Com os dados das transmissões e recepções das probes é possível obter estatísticas da rede e também prover controle de caminho através do chaveamento do tráfego entre links redundantes.


  

 






  




Página 160  



 


Os principais tráfegos que as probes do IP SLA podem simular são:       

HTTP FTP DHCP UDP jitter UDP echo TCP connect ICMP echo

  

echo ICMP path jitter DNS

A escolha de como gerar o tráfego, o endereçamento IP e portas TCP/UDP a serem utilizadas pelas probes é bem flexível e com boa granularidade permitindo, por exemplo, escolher valores de TOS e prefixos de endereços IP. Portanto, as principais funções do IP SLA são a medição do desempenho da rede (measure network performance) e também o alcance até determinados hosts (host reachability). Nesse tópico estudaremos o uso desse recurso para o “path control” (controle de caminho) porque ele permite a monitoração de vias e o chaveamento para um caminho backup caso o desempenho do link principal esteja degradado ou em casos de falha do link principal. Segue abaixo as principais aplicações do IP SLA:  

    

Monitoração de serviços de rede como voice-over-IP (VoIP), vídeo e VPN Monitoração de níveis de acordo de serviço (SLA) Monitoração da estado performance e visibilidade da rede Monitoração do de serviços IP ou assessment Monitoração da disponibilidade da rede fim a fim Troubleshooting de operações de redes Monitoração de redes Multiprotocol Label Switching (MPLS)

4.1 Configurando o IP SLA para Controle de Caminho Antes de iniciar a configuração, na fase de planejamento deve ser verificado se o IOS rodando atualmente nos roteadores suporta o recurso (feature) de IP SLA. Outro passo importante é definir o dispositivo de srcem, o dispositivo de destino, o que será monitorado e utilizando que tipo de probe. Normalmente para controle de caminho se usa o ping do ICMP. Os passos para configuração do IP SLA para fazer o controle de caminho (path control) seguem abaixo:  

 



Passo 1: Criar uma sessão de monitoração no dispositivo que irá srcinar as probes. Passo 2: Definir o tipo de probe específica para o tipo de tráfego que será monitorado, IP de destino (responder) e demais variáveis necessárias, por exemplo, valores de DSCP para QoS (Qualidade de Serviço). Passo 3: Agendar (schedule) a probe com a data/hora inicial e final do teste. Passo 4: Definir um objeto de monitoramento (tracking object) que está ligado à sessão de monitoração. Passo 5: Vincular o objeto de monitoramento com uma rota estática.

O IP de destino pode ser qualquer dispositivo confiável que responda ao tipo de tráfego enviado através das probes. Mais especificamente para usar o IP SLA para chavear um fluxo para um link backup o destino a ser escolhido deve ser o caminho para o provedor de serviços reserva.


  

 






  




Página 161  



 


Esse destino (ou responder) pode ser um dispositivo qualquer, porém se for Cisco esse dispositivo pode incluir “time stamps” (marcação de data/hora) na resposta ao probe para ajudar na medição da latência (latency) e jitter (variações no atraso). Além disso, a configuração de um Cisco responder é bastante simples, é só utilizar o comando em modo de configuração global “ip sla responder”. Vamos agora a um exemplo de configuração com uma rede que possui duas conexões com a Internet, sendo uma principal e outra backup. O roteador da ponta (edge router) tem rotas estáticas apontando para cada saída dos provedores de serviço de Internet.

Primeiro vamos configurar duas sessões de monitoração (ip sla 1 para o ISP principal e ip sla 2 para o ISP backup) utilizando o “icmp-echo” (nosso conhecido “ping”) em um intervalo de 10 segundos (frequency 10). Os IPs utilizados como “responder” (destino) são servidores DNS dos provedores de serviço. Veja as configurações abaixo onde os passos 1 e 2 da configuração do IP SLA são realizados. R1(config)#ip sla 1 R1(config-ip-sla)#icmp-echo 200.200.200.1 R1(config-ip-sla-echo)#frequency 10 R1(config-ip-sla-echo)#ip sla 2 R1(config-ip-sla)#icmp-echo 171.22.2.52 R1(config-ip-sla-echo)#frequency 10

Agora vamos definir o agendamento (schedule) dos testes, ou seja, quando os testes irão iniciar e parar. Nesse exemplo vamos fazer os testes iniciarem no mesmo momento e sem data de fim (life forever now) R1(config)#ip sla schedule 1 life forever start-time now R1(config)#ip sla schedule 2 life forever start-time now

Por último vamos criar os objetos de monitoração ou Tracking Objects e vinculá-los às rotas estáticas. Note que foram criados dois objetos (tracking object – track 1 e track 2) para verificar o alcance (reachability) aos responders, assim como foram criadas duas rotas estáticas padrão, sendo que na rota principal será usada um a AD (administrative distance) igual a 2 e para a rota backup AD igual a 3, porém somente se os objetos de monitoração estiverem respondendo ou alcançáveis. Veja as configurações abaixo. R1(config)#track 1 ip sla 1 R1(config)#track 2 ip sla 2 R1(config)#ip route 0.0.0.0 R1(config)#ip route 0.0.0.0

reachability reachability 0.0.0.0 10.1.1.1 2 track 1 ! Rota Principal 0.0.0.0 172.22.2.2 3 track 2 ! Rota backup


  

 






  




Página 162  



 


Note que a rota estática foi vinculada ao comando “track”, o qual está vinculado com o comando “ip sla” pelo número criado nele. Portanto, em operação normal a rota padrão com AD igual a 2 será instalada na tabela de roteamento, porém se o servidor DNS do ISP 1 ficar inalcançável a rota primária é retirada e a backup com AD igual a 3 é instalada na tabela de roteamento. Para verificar as configurações do IP SLA você pode utilizar o comando “show ip sla configuration” e as estatísticas “show ip sla statistics”. 4.2 Combinando o IP SLA com PBR É possível ainda combinar o uso do IP SLA com uma Policy-based Routing para prover redundância por tráfego ou por interface, proporcionando um maior controle do tipo de tráfego que pode utilizar a saída backup em caso de falhas. Por exemplo, você pode criar uma ACL definindo as redes e tipos tráfegos (tráfego interessante - interesting traffic) que podem acessar a redundância através da interface giga 0/1 e criar um route-map. Veja a configuração abaixo levando em conta a mesma topologia utilizada no tópico anterior. route-map Backup permit 10 match ip address 101 set ip next-hop verify-availability x.x.x.x 10 track 1 set ip next hop verify-availability y.y.y.y 20 track 2 ! interface Giga 0/1 description LAN Interface ip policy route-map Backup

Nesse exemplo o tráfego foi definido na ACL 101 (omitida) e as opções “track 1” e “track 2” vinculam o route-map com as configurações do IP SLA realizadas anteriormente. Os IPs de próximo salto foram deixados como genéricos x.x.x.x e y.y.y.y. Para aplicar essa política na interface seguimos o processo normal de uma policy routing.

Nesse caso o tráfego interessante vai ser encaminhado para o IP x.x.x.x se o servidor DNS principal estiver respondendo aos probes, caso não esteja o tráfego será encaminhado para o IP y.y.y.y, os quais podem ser os IPs dos roteadores do ISP diretamente conectados ao R1. Os dois capítulos a seguir não fazem parte do conteúdo oficial do CCNP, porém foram inseridos de maneira geral por poderem ser encontrados em sua vida prática como profissional de redes.


  

 






  




Página 163  



 


5 Virtual Routing and Forwarding (VRF-Lite) As VRFs em geral são utilizadas para segmentar tráfego, podemos comparar com as VLANs em Layer 3. As VLANs criam switches virtuais com tabela de endereços MAC (CAM tables) segregadas, assim como as VLANs as VRFs criam roteadores virtuais com tabelas de roteamento segregadas, assim podemos separar, por exemplo, o tráfego de uma rede de visitantes (guest) da rede corporativa ou então, por exemplo, separar os tráfegos de Voz, Dados e Vídeo em diferentes redes virtuais por aplicação ou serviço de rede. O tráfego de diferentes VRFs podem seguir inclusive caminhos distintos para o encaminhamento dos pacotes. Veja uma ilustração na figura a seguir.

Outro exemplo do uso de VRF é um ISP (provedor de serviços de Internet) que deseja ter mais de um usuário em uma mesma infraestrutura, com a VRF ele pode criar roteadores virtuais e segregar as tabelas de roteamento, isso é muito comum com o uso do MPLS. Isso permite que o tráfego de um cliente cruze a núvem do provedor de serviços sem que esteja exposto ou "visível" para outros clientes do mesmo provedor. Portanto além do fator de segurança, o VRF pode ajudar a diminuir a complexidade em usar a segregação das redes com NAT e ACL dentro do ISP ou de uma rede corporativa que precisa segregar tráfego. A versão de VRF chamada VRF-Lite (objetivo de estudo da revisão atual do CCNP ROUTE) permite que o roteador tenha diferentes tabelas de roteamento agrupadas por interfaces, assim o departamento de vendas não poderia rotear para o departamento de operações no mesmo roteador, por exemplo, porém os dois departamentos podem compartilhar a mesma conexão de saída para a nuvem ou para a Internet. Uma tecnologia mais recente chamada Cisco Easy Virtual Network (EVN) traz um novo conceito de configuração para o VRF, mais comparável ao VRF-Lite. Com o VRF-Lite quando queremos enviar tráfego para diversas redes virtuais entre dois roteadores é preciso criar uma sub-interface por VRF em cada um dos roreadores, vamos estudar essas configurações a seguir. A diferença com o Cisco EVN é que ao invés de precisarmos de sub-interfaces, podemos criar um trunk chamado "Virtual Network Trunk" (VNET) entre os roteadores para encaminhar o tráfego das diferentes redes virtuais.


  

 






  




Página 164  



 


Com isso, o EVN trafega as diversas redes virtuais em uma única interface trunk utilizando tags (etiquetas) para marcar e identificar a que rede virtual aquele pacote pertence, processo similar ao 802.1Q. Apesar do EVN reduzir a complexidade das configurações em comparação ao VFR, o VRF-Lite continua sendo utilizado nas redes e vamos estudar nesse tópico as configurações básicas exigidas no conteúdo do CCNP ROUTE. O VRF funciona apenas em Layer 3, portanto deve ser configurado em interfaces físicas ou lógicas (SVI). 5.1 Configuração Básica do VRF-Lite A configuração do VRF-Lite é relativamente simples, você precisa seguir três passos básicos: 1. Criar as VRFs com o comando "ip vrf nome" em modo de configuração global. 2. Vincular a uma interface com o comando "ip vrf forwarding nome" (modo de configuração de interface). 3. Configurar o roteamento (opcional dependendo da necessidade). Você pode configurar o roteamento via OSPF utilizando o comando router " ospf process-id vrf nome" e fazendo as configurações normais que estudamos para o OSPF, ou seja, cada VRF vai ter sua configuração de OSPF.

Com rota estática o comando fica da seguinte maneira "ip route vrf nome rede-destino máscara GW-ou-Int-Saída". Você vai notar que no final cada VRF terá sua própria tabela de roteamento, as quais trabalham de forma independente da tabela de roteamento "normal" do roteador. Vamos ao exemplo de configuração, onde vamos configurar duas VRFs e atribuir duas interfaces a cada VRF criada. R1(config)#ip vrf VRF1 R1(config-vrf)#! criando a VRF chamada .VRF1. R1(config-vrf)#! R1(config-vrf)#ip vrf VRF2 R1(config-vrf)#! criando a VRF chamada .VRF2. R1(config-vrf)#! R1(config-vrf)#! Configurando as Interfaces R1(config-vrf)#! R1(config-vrf)#interface FastEthernet0/0 R1(config-if)# ip vrf forwarding VRF1 R1(config-if)# ip address 192.168.10.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet0/1 R1(config-if)# ip vrf forwarding VRF1 R1(config-if)# ip address 192.168.20.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet1/0 R1(config-if)# ip vrf forwarding VRF2 R1(config-if)# ip address 192.168.10.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet1/1 R1(config-if)# ip vrf forwarding VRF2 R1(config-if)# ip address 10.10.10.1 255.255.255.0 R1(config-if)# no shut


  

 






  




Página 165  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1(config-if)#! OSPF para as VRFs 1 e 2 R1(config-if)#router ospf 1 vrf VRF1 R1(config-router)#network 0.0.0.0 255.255.255.255 area 0 R1(config-router)#! R1(config-router)#router ospf 2 vrf VRF2 R1(config-router)#network 0.0.0.0 255.255.255.255 area 0 R1(config-router)#exit R1(config)#! Default gateway R1(config)#ip route vrf VRF1 0.0.0.0 0.0.0.0 192.168.10.2 R1(config)#ip route vrf VRF2 0.0.0.0 0.0.0.0 192.168.10.2

Visualizando as VRFs criadas. R1#show ip vrf Name VRF1

Default RD

VRF2

Interfaces Fa0/0 Fa0/1 Fa1/0 Fa1/1

R1#

Com o comando show ip route vamos verificar a tabela de roteamento. Note que a tabela de roteamento normal do roteador está vazia, pois não configuramos nenhum IP glogal no roteador e sim apenas IPs em VFRs. R1#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate defau lt, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is not set

Agora vamos analisar as tabelas de roteamento das VRFs com o comando " show ip route vrf nome-vrf". R1#sho ip route vrf VRF1 Routing Table: VRF1 ### Saídas Omitidas ### Gateway of last resort is 192.168.10.2 to network 0.0.0.0 S*

0.0.0.0/0 [1/0] via 192.168.10.2

C L O

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks 172.16.1.0/24 is directly connected, Loopback1 172.16.1.1/32 is directly connected, Loopback1 172.16.15.1/32 [110/2] via 192.168.20.2, 00:00:03, FastEthernet0/1 [110/2] via 192.168.10.2, 00:00:03, FastEthernet0/0 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.10.0/24 is directly connected, FastEthernet0/0 192.168.10.1/32 is directly connected, FastEthernet0/0 192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.20.0/24 is directly connected, FastEthernet0/1 192.168.20.1/32 is directly connected, FastEthernet0/1

C L C L R1#


  

 






  




Página 166  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1#show ip route vrf VRF2 Routing Table: VRF2 ### Saídas Omitidas ### Gateway of last resort is 192.168.10.2 to network 0.0.0.0 S* C L C L R1#

0.0.0.0/0 [1/0] via 192.168.10.2 10.0.0.0/8 is variably subnetted , 2 subnets, 2 masks 10.10.10.0/24 is directly connected, FastEthernet1/1 10.10.10.1/32 is directly connected, FastEthernet1/1 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.10.0/24 is directly connected, FastEthernet1/0 192.168.10.1/32 is directly connected, FastEthernet1/0

Com o comando ping podemos testar a conectividade com um host remoto utilizando a seguinte sintaxe: "ping vrf nome-vrf IP-Remoto". Veja exemplo abaixo. R1#ping vrf VRF1 192.168.10.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/52/84 ms

R1#


  

 






  




Página 167  



 


Capítulo 07 Implementando o BGP Nesse capítulo vamos estudar "o protocolo", pois o BGP ou Border Gateway Protocol é o protocolo de

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Funcionamento básico do BGP4 do lado do cliente. Configurações do BGP4. Otimizações no roteamento e escolha do melhor caminho com BGP. Comandos e técnicas de verificação de problemas com o protocolo BGP.

roteamento utilizado na Internet (o único utilizado). O foco do CCNP ROUTE para o BGP é a configuração em um cliente que deseja conectar seu Sistema Autônomo (AS – Autonomous System) com a Internet utilizando roteadores Cisco.



 



O BGP dentro de um Provedor de Serviços de Internet (ISP ou Operadora de Telecom) é foco de outra linha de certificações, portanto aqui vamos estudar como você (como CCNP) poderia conectar uma empresa que tem uma faixa própria de endereçamento IP, característica de um AS, à Internet através de diversos ISPs, chamado de Multihoming, possibilitando caminhos redundantes.

Aproveitem o material e bons estudos!


  

 






  




Página 168  



 



4

Monitoração e Troubleshooting do BGP 202

4.1 1

1.1 2

Problemas Comuns com o BGP ____ 205

Internet e BGP __________________ 170

Tipos de Conexões com ISPs ______ 172

Funcionamento do BGP ___________ 174

2.1 Entendendo o ASN - Número de Sistema Autônomo __________________________ 175 2.2

Banco de Dados e Mensagens do BGP 176

2.3

Atributos do BGP _______________ 177

2.4 Sessões BGP e Troca de Informações de Roteamento _________________________ 177 2.5 IBGP e EBPG – BGP Interno versus Externo_____________________________ 178 2.6 Selecionando o Próximo Salto – Atributo Next-Hop ___________________________ 179 2.7 3

Regras de Sincronização do BGP ___ 180

Implementando o BGP____________ 180

3.1 Exemplo de Configuração Básica – Sem Loopback ___________________________ 181 3.2

Configuração Básica com Loopback _ 184

3.3 Considerações sobre os Comandos Network ____________________________ 186 3.4 Considerações sobre o Comando Neighbor e Estabelecimento de Peers ____ 186 3.5

Configurando Vizinhos com Peer Groups 187

3.6

Seleção de Caminhos pelo BGP ____ 189

3.6.1 BGP

Entendendo os Principais Atributos do 190

3.7

Processo de Escolha da Melhor Rota 194

3.8

Filtrando Rotas do BGP – Route Filtering 196

3.8.1 Exemplo Prático 1 – Evitando rotas de trânsito 198 3.8.2 Exemplo Prático 2 – RFC 1918 _____ 198

3.9

Agregação de Rotas no BGP _______ 200

3.10

Configurando a Autenticação no BGP 201


  

 






  




Página 169  



 


1 Internet e BGP Até o momento, com os protocolos internos ou IGPs (Internal Gateway Protocol), a saída de Internet estava sendo realizada considerando normalmente uma rota estática, ou seja, não trocamos informações de roteamento com os roteadores de Internet. Nesses casos a faixa de IPs válidos para navegar na Internet pertence aos provedores de serviço e "alugamos" esses endereços para navegar na Internet. Você já deve ouvido no "IPdeseja Fixo", um utilizado designar cliente que conecta ao umterprovedor de termo serviços IP depara Internet para quando colocar um servidores paraseo lado de fora de sua rede corporativa, ou seja, possibilitando acesso externo através de um IP bem conhecido. Nesse tipo de solução tudo que precisamos é uma conexão de Internet, com apenas um ou poucos IPs válidos, e utilizar o Network Address Translation (NAT) para realizar a tradução dos endereços privados (da RFC 1918) internos para endereços de Internet e permitir a navegação de uma via, ou seja, os usuários internos acessando a Internet. Se usuários externos necessitam usar a rede interna ou parte de seus serviços normalmente um NAT reverso pode ser utilizado para resolver essas questões de acesso externo à rede interna.

Mas agora vamos aumentar um pouco a escala e supor que a empresa tem diversos usuários e sites remotos que precisam acessar recursos internos e você deseja fornecer uma solução mais robusta e escalável, ou seja, que permita o uso de links redundantes de fora para dentro da sua rede, como isso pode ser resolvido? Antes de darmos a resposta vamos a algumas outras questões importantes para esse tipo de cenário: 







Quantos endereçosà IPs públicos serão que necessários? Isso pensando em acesso usuários internos Internet, usuários estão na Internet e precisam acessar de a Intranet, sites remotos que devem se conectar via VPN site-to-site, ect. Será que conseguiremos compartilhar os IPs utilizados pelo NAT com o NAT reverso para acesso externo com segurança? Será utilizada solução de DMZ para fornecer serviços à usuários da Internet? Quantos servidores serão utilizados na DMZ? Conforme as respostas acima podemos ainda ter outras questões: o Devo continuar usando a faixa de IPs fornecida pelo provedor de serviços (ISP) ou adquirir uma faixa própria para conexão direta com a Internet?


  

 






  




Página 170  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br o o o

Que tipo de conexões e banda deverá ser utilizado para suportar tanto os acessos internos como os vindo da Internet em direção à rede interna? Continuo com roteamento estático ou devo utilizar roteamento dinâmico? Utilizando roteamento dinâmico com a Internet, o roteador e links suportarão a sobrecarga de banda e uso de recursos de processamento e memória exigidos pelo protocolo de roteamento externo (BGP)?

Essas são algumas perguntas que devem ser respondidas dentre outras que surgirão ao longo desse capítulo. Apesar de até o momento os capítulos anteriores considerarem que a conexão com a Internet é realizada diretamente "alugando" IPs de um ISP é importante saber que é possível conectar-se diretamente com a Internet e ter uma faixa própria de IPs. Para isso existe em cada país um órgão responsável pela alocação de IPs válidos de Internet e também número de AS válido (Autonomous System Number ou ASN ou Número de Sistema Autônomo). Esse número de sistema autônomo identifica a empresa na Internet, no Brasil a instituição responsável por esse processo é o Registro-br. Os sistemas autônomos conectam-se com a Internet usando seus próprios IPs e rodando o protocolo de roteamento BGP ou através de rotas estáticas, dependo do porte de cada AS (Sistema Auntônomo). Isso traz independência em relação à faixa de IPs que a empresa possui e de sua relação com o ISP. Quando estamos elaborando um projeto de conexão via Internet com um ISP, cada um tem uma característica. Por exemplo, se você precisa conectar com apenas um ISP através de uma rota padrão, ou seja, não precisa trocar rotas, uma rota estática pode ser utilizada. Nesse caso, do lado do ISP também são criadas rotas estáticas apontando para a rede da empresa e depois essas rotas são redistribuídas no protocolo de roteamento do ISP. Já o uso do BGP torna-se interessante quando a empresa possui vários ISPs e você precisa controlar como o tráfego entra ou sai da sua rede em direção à Internet ou então precisa reagir frente a mudanças de topologia na própria Internet. Existem basicamente três maneiras de se receber rotas de um ou vários ISPs através do BGP: 1. Rotas padrões de cada um dos ISPs: Esta é a mais simples das três opções e resulta em um menor uso de largura de banda e recursos do roteador de borda. Quem determina o ISP a ser utilizado nessa configuração é a métrica configurada internamente no IGP, pois não há como fazer a manipulação de caminhos através do BGP. A desvantagem dessa opção de configuração em um sistema autônomo multihoming é que pode haver um roteamento não otimizado (subótimo ou suboptimal), principalmente quando temos fluxo da Internet em direção à empresa. 2. Rotas padrões misturadas com algumas rotas mais específicas: Na segunda opção temos uma utilização média de largura de banda e recursos do roteador de borda, mas com a vantagem de possibilitar a manipulação de algumas rotas específicas através do BGP para que o tráfego possa ser roteado pelo melhor caminho dentro do ISP, permitindo também um encaminhamento mais previsível. Assim como no exemplo anterior quem definirá a saída da rota padrão será a métrica configurada no IGP. 3. Todas as rotas de todos os ISPs: Essa terceira opção de configuração é chamada de "Full Routing", ou seja, o ISP passa para o cliente TODAS as rotas que conhece. Isso acarreta em um maior uso de largura de banda e recursos (CPU e memória RAM) do roteador de borda que faz a interface com o ISP. Nesse modelo de conexão a escolha da saída para todas as rotas externas pode ser controlada via BGP e suas ferramentas de controle e política de roteamento.


  

 






  




Página 171  



 


Você deve estar se perguntando aqui por que seria importante saber a rota que o roteador irá tomar na Internet? Grandes empresas que utilizam serviços de interconexão como VPNs para conectar filiais (Branch Office) à sua Unidade Central (Head-office ou Headquarter) podem ter determinada filial com melhor caminho até a unidade central através de um determinado ISP, portanto com o roteador podendo anunciar suas rotas no BGP esse melhor caminho será escolhido automaticamente através da troca de informações de roteamento pelos ISPs. Além disso, todas as formas de conexão proporcionam redundância. Uma situação um pouco diferente onde muitas vezes o BGP é utilizado para conexão de redes corporativas é com soluções MPLS (MPLS layer 3), nesse caso (BGP), pode serporém utilizado rota estática, IGPs (EIGRP, OSPF ou com RIP)VPNs ou Border Gateway Protocol muitas empresas preferem implementar o BGP por questões de compatibilidade e estabilidade da rede WAN. 1.1 Tipos de Conexões com ISPs Uma empresa pode ser conectada com um ou mais ISPs, conforme abaixo:   

Single-homed: Conexão com apenas um ISP. Dual-homed: Dois links de saída para o mesmo ISP. Multihoming: Duas ou mais saídas para mais de um ISP simultaneamente.

Como já citado, um site com uma conexão ao ISP é chamado de single-homed. Seu uso é recomendado para empresas que não dependem fortemente de conectividade de Internet ou com a WAN. Pode usar rotas estáticas ou anunciar as rotas do site para o ISP com o BGP, recebendo uma rota padrão do ISP. Veja a figura abaixo.


  

 






  




Página 172  



 


A solução dual-homed usa duas conexões para o mesmo ISP, podendo ser com um ou dois roteadores, onde podemos utilizar um link principal e outro backup ou então configurando o balanceamento de cargas. Pode ser utilizado roteamento estático ou dinâmico com soluções dual-homed. Veja a figura abaixo.

Multihoming significa que a empresa tem conexões com mais de um ISP ao mesmo tempo. Esta topologia oferece redundância e backup se um provedor falhar. Esta solução oferece a oportunidade de roteamento na Internet sem dependência do ISP, ou seja, utilizando o protocolo de roteamento dinâmico pode-se conseguir um melhor desempenho por poder ter influência na escolha do melhor caminho para redes mais utilizadas. O BGP é o protocolo utilizado para arquiteturas multihoming. Além das topologias citadas podemos ter uma arquitetura multihomed e a conexão com cada ISP dual-multihomed, ou seja, múltiplos ISPs com duas conexões para cada um deles para ter maior redundância. Veja a figura a seguir.

Na solução multihomed o sistema autônomo pode permitir o tráfego passar por ele ou não, ou seja, a empresa pode ser utilizada ou não para encaminhar tráfego entre os ISPs. Esse tráfego transiente pode afetar o funcionamento do AS e deve ser considerado no momento do planejamento se deve ser permitido ou não.


  

 






  




Página 173  



 


2 Funcionamento do BGP O BGP (Border Gateway Protocol) é um protocolo de roteamento externo (EGP ou External Gateway Protocol), ou seja, sua função é trocar informações de roteamento entre redes ou sistemas autônomos diferentes. É o protocolo usado entre os prestadores de serviços de Internet (ISPs) e também pode ser usado entre uma empresa e um ou mais ISPs. Acompanhe na figura abaixo onde temos uma nuvem de roteadores BGP interconectando vários sistemas autônomos, tais como ISP’s e demais empresas que são AS’s.

Um detalhe interessante de se notar é que o BGP foi construído para a confiabilidade, controle e escalabilidade, porém não se preocupando com a velocidade, portanto, ele se comporta de maneira diferente dos protocolos de roteamento internos ou IGPs que estudamos até o momento. Você vai notar quando iniciar suas configurações de BGP que até para subir ele é mais lento que o OSPF e EIGRP. Vamos abaixo a algumas definições e termos importantes do mundo do BGP:  













Os roteadores rodando BGP são denominados "BGP speakers". Utiliza o conceito de Sistemas Autônomos (AS - Autonomous Systems), sendo que um sistema autônomo é um grupo de redes sob uma administração comum. Normalmente os sistemas autônomos executam um Interior Gateway Protocols (IGP) dentro do sistema, tais como OSPF, EIGRP, RIP ou IS-IS. Para conexão entre os ASs utilizamos um Exterior Gateway Protocol (EGP), o qual temos o BGP versão 4 como única opção de EGP atualmente utilizada na Internet. O roteamento entre sistemas autônomos é chamado "roteamento interdomain" ou "interdomain routing". Existem duas versões de BPG: EBGP (BGP Externo para uso entre ASs) e IBPG (BGP Interno para uso dentro do AS). A distância administrativa para rotas EBGP é 20, já a distância administrativa para rotas IBGP é de 200. Os vizinhos do BGP são chamados de "pares" ou "peers" e devem ser configurados estaticamente, há descoberta dinâmica vizinhos no OSPF e EIGRP. O BGP utiliza anão camada de transporte nade porta TCP como 179 para troca incremental de mensagens, atualizações de roteamento e keepalives periódicos. Os roteadores podem executar apenas uma instância de BGP (apenas um número de AS configurado em cada roteador).


  

 






  




Página 174  



 


O BGP é um protocolo considerado "path-vector" ou "vetor de caminho", sendo que uma rota BGP para determinada rede de destino é formada por uma lista de sistemas autônomos que determinam o caminho até aquela rede. Se compararmos com os IGPs o BGP é bem parecido com o RIP, porém ao invés de número de saltos entre roteadores ele utiliza a quantidade de sistemas autônomos que essa rota irá atravessar até o destino. Essa métrica pode também ser composta por outros valores de decisão, ou seja, o administrador de redes pode influenciar de maneira mais flexível nessa tomada de decisão. O mecanismo de prevenção de loop do BGP é o próprio número de sistema autônomo de todos os ASs por ondesai uma deveautônomo, passar até esse alcançar a rede Quando umade atualização de roteamento do rota sistema número de de ASdestino. é prefixado na lista sistemas autônomos da atualização de roteamento. Quando um sistema autônomo recebe uma atualização ele examina essa lista e se encontrar seu próprio número de sistema autônomo nela a atualização é descartada, pois existe um loop nesse caminho. Veja a figura abaixo com um exemplo da detecção de loop pelo AS 1000 quando recebe a rota para a rede 1.1.1.0/24 anunciada por ele mesmo através do AS 400.

2.1 Entendendo o ASN - Número de Sistema Autônomo A Internet Assigned Numbers Authority (IANA) é responsável por atribuir os números de sistema autônomo para empresas e provedores de serviços, chamado de ASN - Autonomous System Number ou número de sistema autônomo. Além de identificar as empresas o ASN é utilizado para determinar o caminho que o pacote vai seguir entre srcem e destino no BGP, chamado "AS Path", atributo que será estudado mais para frente. O ASN padrão é um número de 16 bits (2 bytes) que varia de 0 até 65.535. Abaixo segue a divisão das faixas dos números de AS: De 1 a 64511 como ASN's públicos utilizados na Internet para identificar os AS's. Esses números não podem ser repetidos, devem ser únicos por organização na Internet. De 64512 a 65535 são considerados ASN's privativos, conceito similar aos IPs privativos que podem ser utilizados na internamente pelos ISP's (provedores de Internet) e não são permitidos na Internet por poderem ser repetidos. Os ASN's Zero e 65.535 são reservados. De 64.496 até 64.511 são reservados para uso em documentação. 



 


  

 






  




Página 175  



 


Um AS privativo ou "Private ASN" normalmente é utilizado quando o outro sistema autônomo comunica-se com apenas um provedor via BGP. Dessa maneira as políticas de roteamento entre esses dois AS's não serão visíveis na Internet, ficando "escondidas" pelo provedor que tem a conexão final de Internet. Claro que o ISP terá que remover esse ASN privativo da sequência de AS's em seu anúncio antes de sair para a Internet, isso é feito pelo comando em modo de configuração do roteador BGP: "neighbor IP-do-Vizinho remove-private-as". Com o crescente provedores e empresas à Internet de sistema autônomonúmero públicosdeestão acabando, portantoconcetados assim como o IPv6 os foi números criado para resolver problema semelhante que o IPv4 sofre com a escassez de endereços públicos, foi criado um novo número de AS chamado "4-byte ASN" (RFC 4893), com isso teremos 2^32 ASN's com mais de 4 bilhões de endereços ( de 0 até 4.294.967.295). A faixa antiga de 2-bytes (de 0 a 65.535) é chamada "mappable-ASN" nesse novo padrão "4byte", sendo que podemos representar os números de AS de três maneiras: 





asplain - Notação em decimal simples, por exemplo ASN 7747 será representado como 7747. asdot+ - Nessa notação o número de AS de 32 bits é dividido em dois números de 16 bits separados por um "ponto" ("high-order"."low-order"). Os ASs antigos de 2 bytes podem ser representados com o valor "low-order", por exemplo, o ASN 65535 fica 0.65535 nessa nova notação. Já valores maiores ficam da seguinte maneira, por exemplo, 65536 será 1.0, 65537 será 1.1 e assim por diante até o último valor de ASN 4294967296 que será representado em asdot+ como 65535.65535. asdot - Notação que mistura asplain com asdot+, ou seja, ASN's de 2 bytes são escritos em enquanto valores serão escritos em asdot+, porOexemplo, ASNasplain, 65000 será escrito como acima 65000de e o65536 ASN 65536 será escrito como 1.0. Cisco IOSo utiliza esse formato para representar AS's de 4 bytes.

O 4-byte AS é suportado a partir da família ISR-G1 com Cisco IOS 12.4(24)T. O número de AS é utilizado pelo BGP nos seguintes casos: - Mensagens iniciais de "OPEN". - Atributo AS_PATH. - Atributo AGGREGATOR. - Atributo COMMUNITY. 2.2 Banco de Dados e Mensagens do BGP O BGP utiliza quatro tipos de mensagens para troca de informações: 







Open: Após os vizinhos (neighbor) serem configurados, o BGP envia uma mensagem de "open" para tentar estabelecer uma vizinhança (chamada aqui de "peering"), ou seja, formar um par com seu vizinho BGP. Essa mensagem inclui informações como o número do AS (autonomous system number), router ID e hold time. Update: Mensagens utilizadas para transferir informações de roteamento entre os pares, por exemplo, novas rotas, rotas removidas e atributos dos caminhos. Keepalive: O keepalive no BGP é trocado a cada 60 segundos (por padrão) e garante que uma sessão com o peer está ativa. Notification: Quando ocorre um problema que faz com o que o roteador finalize uma sessão do BGP essa mensagem de notificação é enviada para avisar ao vizinho que a conexão será finalizada.


  

 






  




Página 176  



 


Em relação aos bancos de dados (Data Base) o BGP utiliza três, sendo que os dois primeiros são específicos do BGP e o terceiro é compartilhado com os demais processos de roteamento, veja cada um abaixo: 1. Neighbor database: Nessa tabela temos a listagem de todos os vizinhos do BGP configurados. Para visualizar os vizinhos utilize o comando "show ip bgp summary". 2. BGP database ou RIB (Routing Information Base): Contém as informações de todas as rotas aprendidas pelo BGP com seus caminhos e atributos. Para visualizar essas informações utilize o comando "show ip bgp". 3. Routing : A tabela de roteamento com o BGP roteador. continua aOmesma, oupara seja,visualizar lista os melhores table caminhos para cada rede a partir daquele comando a tabela de roteamento é o "show ip route". 2.3 Atributos do BGP Os atributos do BGP são um conjunto de parâmetros utilizados para controlar informações específicas relativas a rotas, como informação sobre o caminho (path), grau de preferência da rota, o valor do next-hop (próximo salto) da rota e informações sobre agregação. Estes parâmetros são usados pelo algoritmo do BGP como elementos para decisão da escolha das rotas e para decisão sobre filtragem de rotas. Alguns dos atributos do BGP são:     

   

AS_path Next hop Local preference Multi-Exit Discriminator (MED) Origin Atomic Aggregator Agregator Community Weight

Os principais atributos serão discutidos ao longo do material. 2.4 Sessões BGP e Troca de Informações de Roteamento Antes do estabelecimento de uma sessão BGP, os roteadores "vizinhos BGP" trocam mensagens de OPEN entre si para entrar em acordo sobre quais serão os parâmetros da sessão BGP a ser estabelecida, por exemplo, número do AS e tempo máximo de espera entre mensagens ou hold time. Não havendo discordância e/ou erros durante a negociação dos parâmetros entre as partes, a sessão BGP é estabelecida. Caso haja erros ou discordâncias serão enviadas mensagens de erro e a sessão BGP não será aberta (fica em estado de Active). Quando a sessão é estabelecida entre os roteadores, são trocadas mensagens contendo todas as informações de roteamento com todos os melhores caminhos selecionados para os destinos conhecidos. Após a convergência, os pares BGP trocarão apenas mensagens de atualização das informações de roteamento (mensagens do tipo UPDATE) de forma incremental. Ou seja, com o objetivo de diminuir o uso de carga nas CPUs dos roteadores e economizar da largura de banda dos links, o BGP envia somente mensagens de atualizações quando ocorrem mudanças nas rotas (por exemplo: uma rota se tornou inválida) e informando novas rotas. Caso não existam atualizações a serem informadas, os roteadores trocam apenas mensagens do tipo KEEPALIVE para certificar que a comunicação entre eles está ativa. As mensagens de KEEPALIVE são pequenas (19 bytes) e não sobrecarregam a CPU dos roteadores e nem o enlace entre eles.


  

 






  




Página 177  



 


Uma característica das tabelas de rotas BGP é a existência de um número de versão, que é incrementado a cada atualização feita (através das mensagens tipo UPDATE), permitindo a verificação de inconsistências das informações de roteamento. Se existe um rápido aumento no número da versão das tabelas, pode ser indicativo de instabilidade na rede. Você pode verificar essa informação com o comando "show ip bgp". 2.5 IBGP e EBPG – BGP Interno versus Externo O BGP Interno (Internal BGP ou IBGP) é utilizado para fazer a vizinhança do BGP entre roteadores internos do Sistema Autônomo.através Já o BGP (External BGP de ou ASs EBGP) é utilizado para estabelecer relacionamento do Externo BGP entre roteadores diferentes. Aqui é importante ter em mente que o BGP trata os updates enviados por pares internos de maneira diferenciada em relação aos updates de pares externos recebidos pelo EBGP. Outro conceito importante em relação ao IBGP é que os neighbors (vizinhos) não têm a obrigação de estar diretamente conectados através de um circuito físico, ou seja, pode-se criar conexões virtuais entre os pares IBGP. Já os peers que trocam informações via EBGP devem estar diretamente conectados através de um link serial ou interface LAN, por exemplo. Veja a figura abaixo onde os roteadores R1, R3 e R5 estão conectando diferentes ASs através do BGP externo. Note também que no AS 200 os roteadores R5, R6 e R7 formam conexões internas no AS através do IBGP, além disso, não há conexão física entre R5 e R7, porém mesmo assim é possível fazer com que o IBGP seja trocado entre esses roteadores.

Antes que os roteadores BGP ou "BGP speaker" possam ser um par ou "peer" com seu vizinho, há a necessidade de uma configuração estática que definirá essas vizinhanças. Após definidos os vizinhos via comando, uma sessão TCP deve ser estabelecida, por isso o endereço IP utilizado na configuração dos pares e vizinhos deve ser alcançável, ou seja, pertencer a uma rede diretamente conectada ou que seja conhecida entre os vizinhos. É importante que os roteadores internos do AS que rodam o IBGP tenham conexões fullmeshed entre si, pois o BGP também está sujeito ao split horizon e impede que vizinhos IBGP recebam atualizações uns dos outros dentro do mesmo AS, por isso conexão entre todos os vizinhos internos é necessária.


  

 






  




Página 178  



 


2.6 Selecionando o Próximo Salto – Atributo Next-Hop O IP do próximo salto ou "next hop" para uma rota recebida através de um vizinho EBGP é o próprio endereço IP do vizinho que enviou o update. Porém, quando o roteador BGP recebe esse update de um vizinho externo, ele precisa repassar essas informações para seus vizinhos internos através do IBGP sem alterar o atributo "next-hop", portanto o IP de próximo salto será o endereço do roteador do AS vizinho que enviou aquela rota. Mas qual o problema nisso? O IP de "next-hop" nesse caso pertence a uma rede de outro systemesse e osroteador roteadores obrigatoriamente, ter uma explícita aautonomous rede que conecta de IBGP bordadevem, do sistema autônomo vizinho. Por rota exemplo, na para figura a seguir o roteador RA envia um update ao RB com um IP de próximo salto (next hop) igual a 10.2.2.1. Quando RB encaminhar esse update para RC o endereço de próximo salto ainda será o IP 10.2.2.1, forçando RC a ter uma rota que aponte para a rede 10.2.2.0 para que o endereço de próximo salto seja considerado válido.

Para alterar esse comportamento podemos utilizar o comando "neighbor [ip address] next-hopself" em modo de configuração do protocolo de roteamento BGP. Por exemplo, considerando a mesma topologia anterior, se utilizássemos esse comando em RB, o IP do próximo salto que será anunciado para RC para as redes do AS 65100 seria o endereço 10.3.3.3 ao invés do endereço 10.2.2.1 relativo a interface serial de RA. Portanto, dessa maneira RC não precisará conhecer sobre a rede externa entre RA e RB (10.2.2.0) para que o encaminhamento seja possível. Em redes multiacesso (LANs) o atributo next-hop do BGP pode ser ajustado para que não haja um salto exemplo, ainda naRC figura anterior os roteadores RC e RD são pares EBGP, porém RCextra. é par Por IBGP de RB. Quando enviar um update para RD sobre a rede 10.2.2.0 normalmente é utilizado o IP da própria interface como "next hop", porém isso traria um salto desnecessário, pois B enviaria para C, depois C enviaria para D sendo que todos estão na mesma LAN e B poderia ser o endereço do próximo salto evitando passar por C. Esse comportamento também deve ser ajustado no comando "neighbor [ip address] next-hop-self".


  

 






  




Página 179  



 


2.7 Regras de Sincronização do BGP No caso de um AS servir de trânsito entre outros dois ASs, o BGP não deverá anunciar uma rota antes que todos os roteadores do AS tenham aprendido a rota através do IGP ou através de uma rota estática. Assim, ele deverá aguardar até que o IGP tenha propagado a rota por todo o AS e somente após faça o anúncio para os vizinhos BGP externos, por isso esse processo é chamado de "sincronização". Mas por que é importante aguardar essa sincronização? Em situações em que algum roteador do AS anuncie para os umroteadores vizinho externo quedotem rota para um determinado destino em terceiro AS, porém internos mesmo AS deste roteador anunciante nãoum têm a menor ideia da existência deste destino, pois ainda não receberam informações sobre a rota para a rede do terceiro AS através do IGP (que deve ser recebida por redistribuição do BGP). Nesse caso, assim que pacotes enviados para este destino alcançarem algum destes roteadores internos do AS de trânsito, os mesmos serão simplesmente descartados. A sincronização é importante para evitar "buracos negros" de roteamento. É possível "desligar" a sincronização caso ela não seja necessária com o comando "no synchronization" dentro do modo de configuração do BGP. Por exemplo, se o AS não serve de trânsito entre outros ASs ou se todos os roteadores estiverem usando BGP sem rodar nenhum IGP. Assim, há a vantagem de se ter menos entradas na tabela de rotas e uma maior rapidez de convergência do BGP. 3 Implementando o BGP Antes de iniciar as configurações do BGP é preciso levantar alguns dados para elaborar um plano de implantação bem sucedido, tais como:  



Vai haver necessidade de IBGP entre roteadores internos do sistema autônomo? Quais as necessidades de conexão externa e como será realizado (número de ISPs, atributos, políticas de roteamento, single-homed, multihomed, ect.)? Parâmetros de configuração tais como endereço IP e número de AS dos vizinhos, redes que serão anunciadas via BGP, etc.

A configuração básica do BGP envolve configurar os vizinhos e também definir as redes a serem anunciadas, abaixo seguem os principais comandos que envolvem a configuração básica do BGP em roteadores Cisco:  





router bgp AS-number: inicia o processo do BGP no roteador. neighbor ip-address remote-as AS-number: Estabelece vizinhança entre roteadores BGP. O endereço IP deve corresponder a srcem dos updates de roteamento. neighbor peer-group-name peer-group: Cria um grupo de pares (peer group) onde vizinhos podem ser configurados. neighbor ip-address peer-group peer-group-name: Configura um vizinho a um grupo de pares (peer group).





 

ip-address neighborconectada Força com que seja o roteador local envie seu IP da interface aos next-hop-self seus vizinhos, :fazendo anunciada como próximo salto (next hop) das rotas para todos os vizinhos. neighbor ip-address update-source interface-type number: Configura um IP de srcem específico como srcem das atualizações de roteamento que serão enviadas aos seus vizinhos. no synchronization: Desativa a sincronização do BGP. network prefix [mask subnet-mask]: Inicia o anúncio de uma rede no protocolo BGP.


  

 






  




Página 180  



 


3.1 Exemplo de Configuração Básica

–

Sem Loopback

Veja a topologia abaixo onde os roteadores serão configurados com o básico do BGP.

Nesse exemplo o AS 100 faz par via EBGP com os ASs 200 e 300 e também terá um link IBGP entre os roteadores R1 e R2, pois eles pertencem ao mesmo AS. Veja as configurações básicas a seguir considerando que as interfaces estão devidamente configuradas e ativas. R1(config)#router bgp 100 Roteador R1: R1(config-router)#!--- Ativa o BGP no sistema autônomo 100 R1(config-router)#! R1(config-router)#neighbor 200.200.200.2 remote-as 200 R1(config-router)#! R1(config-router)#!--- Especifica que o endereço 200.200.200.2 R1(config-router)#!--- do AS remoto 200 faz uma conexão EBGP R1(config-router)#!--- entre R1 e R3 R1(config-router)#! R1(config-router)#neighbor 100.100.100.2 remote-as 100 R1(config-router)#! R1(config-router)#!--- Especifica que o endereço 100.100.100.2 R1(config-router)#!--- dentro do mesmo AS faz uma conexão IBGP R1(config-router)#!--- entre R1 e R2 R1(config-router)#

Roteador R2: R2(config)#router bgp 100 R2(config-router)#!--- Ativa o BGP no sistema autônomo 100 R2(config-router)#! R2(config-router)#neighbor 201.201.201.2 remote-as 300 R2(config-router)#! R2(config-router)#!--- Especifica que o endereço 201.201.201.2 R2(config-router)#!--- do AS remoto 200 faz uma conexão EBGP R2(config-router)#!--- entre R2 e R4 R2(config-router)#! R2(config-router)#neighbor 100.100.100.1 remote-as 100 R2(config-router)#! R2(config-router)#!--- Especifica que o endereço 100.100.100.1 R2(config-router)#!--- dentro do mesmo AS faz uma conexão IBGP


  

 






  




Página 181  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R2(config-router)#!--- entre R2 e R1 R2(config-router)#

Com essa configuração a vizinhança entre os roteadores R1 e R2 deve subir e a seguinte mensagem será mostrada em R1: *Mar

1 00:21:12.923: %BGP-5-ADJCHANGE: neighbor 100.100.100.2 Up

Em R2 a mensagem será: *Mar

1 00:21:21.675: %BGP-5-ADJCHANGE: neighbor 100.100.100.1 Up

Com o comando "show ip bgp summary" podemos ver a vizinhança estabelecida: R1#sho ip bgp summary BGP router identifier 200.200.200.1, local AS number 100 BGP table version is 1, main routing table version 1 Neighbor 100.100.100.2 200.200.200.2 R1#

V 4 4

AS MsgRcvd MsgSent 100 4 4 200 0 0

TblVer 1 0

InQ OutQ Up/Down State/PfxRcd 0 0 00:01:16 0 0 0 never Active

Note que para o vizinho 200.200.200.2 o estado de Up/Down está como "never" (nunca) e em State temos a palavra "Active", o que quer dizer que o processo de inicialização está ativo, ou seja, não houve resposta ao OPEN enviado por R1. Agora vamos configurar R3 e R4 para verificar as alterações nas vizinhanças. Roteador R3: R3(config)#router bgp 200 R3(config-router)#!--- Ativa o BGP no sistema autônomo 200 R3(config-router)#! R3(config-router)#neighbor 200.200.200.1 remote-as 100 R3(config-router)#! R3(config-router)#!--- Especifica que o endereço 200.200.200.1 R3(config-router)#!--- do AS remoto 200 faz uma conexão EBGP R3(config-router)#!--- entre R3 e R1 Roteador R4: R4(config)#router bgp 300 R4(config-router)#!--- Ativa o BGP no sistema autônomo 300 R4(config-router)#! R4(config-router)#neighbor 201.201.201.1 remote-as 100 R4(config-router)#! R4(config-router)#!--- Especifica que o endereço 201.201.201.1 R4(config-router)#!--- do AS remoto 100 faz uma conexão EBGP R4(config-router)#!--- entre R4 e R2

Com as configurações acima as vizinhanças entre R1/R3 e R2/R4 irão subir e a mensagem de sucesso deve ser mostrada conforme abaixo: R3(config-router)# *Mar 1 00:27:12.539: %BGP-5-ADJCHANGE: neighbor 200.200.200.1 Up R4(config-router)# *Mar 1 00:26:05.559: %BGP-5-ADJCHANGE: neighbor 201.201.201.1 Up


  

 






  




Página 182  



 


Com o comando "show ip bgp summary" podemos verificar que agora R1 tem os dois vizinhos funcionando normalmente: R1#sho ip bgp summary BGP router identifier 200.200.200.1, local AS number 100 BGP table version is 1, main routing table version 1 Neighbor 100.100.100.2 200.200.200.2

V 4 4


TblVer 1 1

InQ OutQ Up/Down State/PfxRcd 0 0 00:07:53 0 0 0 00:02:01 0

R1#

Agora vamos configurar o comando "network" para iniciar a troca de informações de roteamento: R1(config)#router bgp 100 R1(config-router)#network 200.200.200.0 mask 255.255.255.252 R1(config-router)#network 100.100.100.0 mask 255.255.255.0 R2(config)#router bgp 100 R2(config-router)#network 201.201.201.0 mask 255.255.255.252 R2(config-router)#network 100.100.100.0 mask 255.255.255.0 R3(config)#router bgp 200 R3(config-router)#network 200.200.200.0 mask 255.255.255.252 R4(config)#router bgp 300 R4(config-router)#network 201.201.201.0 mask 255.255.255.252

Com os comandos "show ip bgp" podemos ver o banco de dados do BGP e com o "show ip route" a tabela de roteamento, veja a saída do roteador R1 após a configuração completa: R1#show ip bgp BGP table version is 4, local router ID is 200.200.200.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i100.100.100.0/24 100.100.100.2 0 100 0 i *> 0.0.0.0 0 32768 i * 200.200.200.0/30 200.200.200.2 0 0 200 i *> 0.0.0.0 0 32768 i *>i201.201.201.0/30 100.100.100.2 0 100 0 i R1# R1#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate defau lt, U - per-user static route o - ODR, P - periodic downloaded stati c route Gateway of last resort is not set

C

200.200.200.0/30 is subnetted, 1 subnets 200.200.200.0 is directly connected, FastEthernet0/1 201.201.201.0/30 is subnetted, 1 subnets


  

 






  




Página 183  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br B C R1#

201.201.201.0 [200/0] via 100.100.100.2, 00:02:14 100.0.0.0/24 is subnetted, 1 subnets 100.100.100.0 is directly connected, FastEthernet0/0

3.2 Configuração Básica com Loopback Os peers no BGP devem estar conectados diretamente quando usamos o EBGP, se eles não estiverem conectados dessa maneira podemos utilizar o comando "neighbor ebgp-multihop" em conjunto com uma rota via IGP ou estática para que haja alcance entre os roteadores vizinhos, possibilitando assim o estabelecimento de uma relação de vizinhança. Esses conceitos possibilitam a criação de interfaces de loopback e a configuração do EBGP apontando para elas (ou quaisquer outras interfaces operacionais), porém uma interface de loopback garante mais estabilidade e também alcance às redes através de múltiplos caminhos, possibilitando o balanceamento de cargas. Veja um exemplo onde R1 e R3 serão configurados através de router IDs utilizando IPs de loopback. Vamos configurar o IP 1.1.1.1 para R1 e 3.3.3.3 para R3.

Configuração em R1: interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! router bgp 100 no neighbor 200.200.200.2 remote-as 200 neighbor 3.3.3.3 remote-as 200 neighbor 3.3.3.3 ebgp-multihop 2 !--- Este comando altera o TTL do pacote !--- permitindo que ele alcance o vizinho BGP !--- que não está mais conectado diretamente !--- ou usando outra interface que não a diretamente conectada ! neighbor 3.3.3.3 update-source Loopback0 ! !--- Este comando especifica para que a sessão TCP !--- que será formada com o BGP externo !--- use o IP da interface loopback como IP de srcem ! ip route 3.3.3.3 255.255.255.255 200.200.200.2


  

 






  




Página 184  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br !--- Esta rota estática garante conectividade com R3

Inserindo essa configuração encima da anterior realizada deve cair a vizinhança estabelecida anteriormente entre R1 e R3. Vamos configurar R3 para normalizar a situação. Configuração em R3: interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! router bgp 200 no neighbor 200.200.200.1 remote-as 100 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 ebgp-multihop 2 !--- Este comando altera o TTL do pacote !--- permitindo que ele alcance o vizinho BGP !--- que não está mais conectado diretamente !--- ou usando outra interface que não a diretamente conectada ! neighbor 1.1.1.1 update-source Loopback0 ! !--- Este comando especifica para que a sessão TCP !--- que será formada com o BGP externo !--- use o IP da interface loopback como IP de srcem ! ip route 1.1.1.1 255.255.255.255 200.200.200.1 !--- Esta rota estática garante conectividade com R1

Após a configuração nas duas pontas temos a vizinhança estabelecida: R1# *Mar 1 01:04:45.035: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up R1#sho ip bgp summary BGP router identifier 200.200.200.1, local AS number 100 BGP table version is 4, main routing table version 4 3 network entries using 360 bytes of memory 5 path entries using 260 bytes of memory 4/2 BGP path/bestpath attribute entries using 496 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 2 (at peak 3) using 64 bytes of memory BGP using 1204 total bytes of memory BGP activity 3/0 prefixes, 6/1 paths, scan interval 60 secs Neighbor 3.3.3.3 100.100.100.2 R1#

V 4 4



  

 





TblVer 4 4


  





Página 185  



 


3.3 Considerações sobre os Comandos Network Nos IGPs o comando network inicia o processo de roteamento em uma interface, ou seja, selecionamos as interfaces que farão parte do processo do IGP. No BGP esse comando diz ao roteador para srcinar anúncios sobre aquela rede, não necessitando que essa rede esteja diretamente conectada ao roteador, precisa apenas que ela esteja presente na tabela de roteamento. Teoricamente pode ser anunciada até mesmo uma rede que não pertence ao mesmo AS, porém isso não é recomendado. Ao anunciar uma rede com o comando network o BGP anuncia a rede padrão classful A, B ou C que a subnet pertence. Para anunciar uma subnet é preciso utilizar a opção "mask", conforme realizado no exemplo de configuração básica do BGP anteriormente onde especificamos a máscara de sub-rede em todos os anúncios. Na tabela de roteamento é preciso conter a mesma rede e máscara (prefixo e máscara de subrede) para que a rede listada no comando "network" antes que os anúncios do BGP possam repassar essa rota para seus vizinhos, processo chamado também de "injeção da rota" (injetar a rota ou route inject). 3.4 Considerações sobre o Comando Neighbor e Estabelecimento de Peers O BGP por padrão assume que vizinhos externos estão diretamente conectados e fazem par (peering) com um endereço IP diretamente conectado a interface que o conecta a esse vizinho. Como já vimos anteriormente se o vizinho não estiver conectado é preciso "dizer" ao BGP para "olhar" um ou mais saltos adiante pelo seu vizinho com o comando "neighbor ip-address ebgpmultihops Este comando devecomser utilizado principalmente quando configurandonum-de-saltos o peering com". vizinhos ebgp-multihop interfaces loopback. Já para o BGP interno é considerado, por padrão, que os vizinhos internos não precisam estar diretamente conectados e por isso esse comando não é necessário no IBGP. Em ambos os casos, se você estiver utilizando a loopback IP como referência para o BGP será necessário alterar a srcem dos pacotes do BGP para o endereço configurado na interface de loopback com o comando "neighbor ip-address update-source interface". Além disso, muitas vezes será necessário anunciar as interfaces de loopback no protocolo IGP ou com rotas estáticas quando estivermos fazendo a comunicação entre roteadores via EBGP, pois é preciso que haja alcance a esses endereços de loopback para que a sessão TCP seja fechada. Um comando interessante que permite desativar uma sessão BGP com um determinado par é o comando "neighbor ip-address shut-down", assim não é preciso desconfigurar o BGP. O comando "show ip bgp neighbors" mostra a lista de peers e o status das sessões BGP, sendo que podemos encontrar os seguintes estados do BGP: 

 

 

Idle: Sem relacionamento de vizinhança estabelecida e o roteador está procurando pelo vizinho. "Idle (admin)" significa que o relacionamento da vizinhança foi colocado em shutdown pelo administrador. Connect: Handshake do TCP foi completado com sucesso. OpenSent ou Active: Uma mensagem de open foi enviada para tentar estabelecer vizinhança mas ainda não teve resposta. OpenConfirm: O roteador local recebeu uma resposta à mensagem de open enviada. Established: A sessão BGP está estabelecida, este é o estado final desejado que representa que o relacionamento de vizinhança foi completado com sucesso.


  

 






  




Página 186  



 


Veja a inter-relação dos estados com a máquina de estados finitos (FSM) na figura abaixo.

Além dos comandos show podemos utilizar os seguintes comandos debug para visualizar o processo de estabelecimento do BGP. debug ip bgp events ou debug ip bgp ipv4 unicast (IOS versão 12.4 ou superior): utilizado para verificar onde o processo está falhando. As principais causas de falha no processo incluem: o Número de AS configurado errado; o Endereço IP do vizinho configurado errado; o Vizinho sem comando "neighbor" no roteador local; o Vizinho sem rota para o endereço de srcem para as mensagens de BGP enviadas pelo roteador local. 

3.5 Configurando Vizinhos com Peer Groups Se um roteador tem uma lista longa de vizinhos diretamente conectados a configuração do BGP pode começar a ficar com linhas em excesso e difícil de interpretar ou alterar, especialmente quando políticas de vizinhança são aplicadas. Os grupos de pares ou " peer groups" ajudam nesse tipo de cenário, principalmente dentro de um mesmo AS entre seus vizinhos IBGP. Os gruposÉ de pares são grupos um de vizinhos que compartilham umadepolítica de com atualização em comum. possível configurar grupo inteiro de declarações vizinhos um único comando, ficando muito mais fácil para redes BGP de grande porte. Pense em um grupo de pares como um agrupamento lógico de roteadores que são agrupados utilizando um nome em comum, tornando as mudanças mais rápidas e as configurações mais curtas. Os peer groups não apenas reduzem o número de linhas de configuração, mas eles reduzem a sobrecarga do roteador, pois o processo de atualização do BGP normalmente é executado para cada vizinho, porém, se um peer group é configurado apenas um processo de atualização pega todos os roteadores configurados no grupo.


  

 






  




Página 187  



 


É importante que todos os roteadores dentro de um grupo devem ser ou vizinhos iBGP ou eBGP. Segue um exemplo de configuração abaixo. Primeiro definimos o nome do grupo como "Teste" nesse exemplo, depois definimos as políticas para o grupo e por último inserimos os vizinhos nele. Nesse exemplo os três roteadores vizinhos pertencem ao mesmo AS com número 65300. R1(config)#router bgp 65300 R1(config-router)#! Definindo o nome do grupo R1(config-router)#neighbor Teste peer-group R1(config-router)#! Definindo as políticas do grupo Teste R1(config-router)#neighbor Teste remote-as 65301 R1(config-router)#neighbor Teste update-source loopback 0 R1(config-router)#neighbor Teste filter-list 10 out R1(config-router)#neighbor Teste filter-list 20 in R1(config-router)#! Inserindo os vizinhos no grupo Teste R1(config-router)#neighbor 1.1.1.1 peer-group Teste R1(config-router)#neighbor 2.2.2.2 peer-group Teste R1(config-router)#neighbor 3.3.3.3 peer-group Teste

Note que as políticas do grupo (nesse exemplo: remote-as, update-source e filter-list) foram todas definidas para o grupo nomeado como Teste e os vizinhos foram depois vinculados a essas políticas criadas. Sem o grupo teríamos que repetir os statements das linhas 5 a 8 para cada um dos vizinhos a serem configurados no comando neighbor. Agora vamos ao exemplo 2 onde será aplicada uma lista de prefixos em comum para evitar que nosso AS aprenda endereços privativos dos seus três ASs vizinhos distintos. Nesse segundo exemplo os ASs vizinhos são diferentes, ao contrário do anterior que todos pertenciam a um mesmo vizinho. R1(config)#router bgp 65300 R1(config-router)#! Definindo o nome do grupo R1(config-router)#neighbor Teste peer-group R1(config-router)#! Definindo as políticas do grupo Teste R1(config-router)#neighbor Teste update-source loopback 0 R1(config-router)#neighbor Teste prefix-list Block-1918 in R1(config-router)#! Inserindo os vizinhos no grupo Teste R1(config-router)#neighbor 1.1.1.1 remote-as 65301 R1(config-router)#neighbor 1.1.1.1 peer-group Teste R1(config-router)#neighbor 2.2.2.2 remote-as 65302 R1(config-router)#neighbor 2.2.2.2 peer-group Teste R1(config-router)#neighbor 3.3.3.3 remote-as 65303 R1(config-router)#neighbor 3.3.3.3 peer-group Teste

Abaixo segue a prefix-list aplicada para prevenir que endereços privativos sejam aprendidos pelo roteador R1 a partir dos vizinhos 1.1.1.1, 2.2.2.2 e 3.3.3.3. ip ip ip ip ip

prefix-list prefix-list prefix-list prefix-list prefix-list

Block-1918 Block-1918 Block-1918 Block-1918 Block-1918

seq seq seq seq seq


  

 





5 deny 10.0.0.0/8 le 32 10 deny 172.16.0.0/12 le 32 15 deny 192.168.0.0/16 le 32 20 permit 0.0.0.0/0 25 permit 0.0.0.0/0 ge 8


  




Página 188  



 


3.6 Seleção de Caminhos pelo BGP Os protocolos de roteamento internos como EIGRP e OSPF escolhem as melhores rotas através da menor métrica, normalmente procurando pelo caminho mais curto e mais rápido para encaminhar o tráfego até a rede de destino. Já o BGP faz a escolha da melhor rota de uma maneira um pouco diferente, ele na realidade estabelece vários atributos para cada caminho, os quais podem ser manipulados administrativamente para um melhor controle do caminho a ser selecionado. Estes atributos (attributes) são então analisados de maneira ordenada até que rota de sejaatributos escolhida entre as diversas opções de caminho encontradas pelo BGP, ou uma seja, única uma lista é criada por rota e essa lista é comparada, atributo a atributo, até afunilar na melhor rota. Portanto, em resumo, o BGP escolhe a melhor rota baseado nos atributos (attributes) do caminho e não através da menor métrica como nos IGPs. Os atributos dos caminhos do BGP são classificados em quatro categorias: 







Well-known mandatory: Esta categoria de atributos deve ser reconhecida por todos os roteadores BGP e estão presentes em todas as atualizações BGP, sendo repassadas para outros roteadores BGP vizinhos. Exemplos de atributos bem conhecidos e mandatórios são: AS path (ASs por onde o tráfego passa para chegar ao destino), srcin (srcem) e next hop (IP do próximo salto). Trata-se de um atributo definido na especificação srcinal do protocolo BGP. Well-known discretionary: Este atributo deve ser reconhecido por todos os roteadores BGP e repassado aos seus vizinhos, porém não necessariamente precisam estar presentes em uma atualização. Um exemplo de atributo bem conhecido do tipo "discretionary" é a local preference (preferência localpor deum rotas). Optional transitive : Pode ou não ser reconhecido roteador BGP, porém mesmo assim é repassado para os roteadores BGP vizinhos. Se esse atributo não for reconhecido pelo vizinho ele é marcado como "partial". Exemplos desse tipo de atributo são o aggregator e community. Optional nontransitive: Nesse último tipo de atributo, assim como o anterior, pode ou não ser reconhecido pelos vizinhos e não é passado aos demais roteadores BGP. Exemplos desses atributos são o Multi-Exit Discriminator (MED) e o srcinator ID.

Veja na tabela a seguir lista atual dos Tipos de Atributos do BGP e seus respectivos valores identificadores.


  

 






  




Página 189  



 


Código de Atributo Tipo 1 ORIGIN

Referência [RFC1771]

2

AS_PATH

[RFC1771]

3

NEXT_HOP

[RFC1771]

4

MULTI_EXIT_DISC

[RFC1771]

5

LOCAL_PREF

[RFC1771]

6

ATOMIC_AGGREGATE

[RFC1771]

7 8 9

AGGREGATOR COMMUNITY ORIGINATOR_ID

[RFC1771] [RFC1771] [RFC1998]

10

CLUSTER_LIST

[RFC1998]

11 12 13 14 15 16

DPA ADVERTISER RCID_PATH/CLUSTER_ID MP_REACH_NLRI MP_UNREACH_NLRI EXTENDED COMMUNITIES Reservado para desenvolvimento

[Chen] [RFC1863] [RFC1863] [RFC2283] [RFC2283] [Rosen]

... 255

Definido por:

Categoria Well-known mandatory Well-known mandatory Well-known mandatory

-

Optional transitiveNonWell-known discretionary Well-known discretionary Optional transitive Optional transitive Optional nontransitive Optional nontransitive -

-

-

-

-

Cisco Cisco Cisco MCI Baynet Baynet -

3.6.1 Entendendo os Principais Atributos do BGP

Abaixo segue uma explicação dos principais atributos do BGP que podem ser cobrados no CCNP. ATRIBUTO AS_PATH: É uma sequência de ASNs (números de AS) que uma rota atravessa para alcançar uma determinada rede de destino. O AS que srcinou a rota acrescenta seu ASN ao anunciar uma rota sua para seus vizinhos BGP externos. Daí pra frente, todos os AS que receberem a rota acrescentarão seu próprio ASN no início da sequência de ASNs e repassarão a rota para outros peers seus, que por sua vez, irão fazer o mesmo. A lista final representa todos os ASNs que uma rota cruzou com o ASN do AS de srcem da rota no final da sequência. É conhecido também como AS_Sequence. Caso um AS receba um anúncio de rota que contenha seu próprio ASN na sequência inclusa no AS_PATH, este anúncio será rejeitado e descartado, garantindo assim, que não haverá loop de roteamento na tabela BGP desse AS. Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informação contida no AS_PATH não é alterada. A informação contida no AS_PATH é uma das usadas no processo de seleção da melhor rota para determinado destino. Ao comparar duas rotas para um mesmo destino (considerando que os outros atributos sejam idênticos), o BGP vai preferir a que possuir o AS_PATH menor. Caso o caminho (path) seja do mesmo tamanho, o BGP vai usar outros atributos para fazer a sua escolha da melhor rota. Apostila/E-B     

  

 






  




Página 190  



 


ATRIBUTO ORIGIN: Indica a srcem do anúncio de rota ou NLRI (Network Layer Reachability Information - indica o prefixo e a máscara) em relação ao AS que o srcinou. Pode conter um dos valores:   

i = aprendido via comando network e = aprendida via EGP ? = redistribuída de outra srcem

ATRIBUTO NEXT_HOP: Basicamente, este atributo recebe o endereço IP da interface do próximo No roteador ou próximo salto (next hop) aincluídas ser dadonapara se chegar a determinado destino. caso, para alcançar as redes de destino mensagem UPDATE. Existem três situações diferentes que determinam o NEXT_HOP: 1. Em sessões eBGP, onde o NEXT_HOP será sempre o IP de um roteador de borda (peer BGP) de um AS vizinho que srcinou a rota. 2. Em sessões iBGP onde a rota foi srcinada dentro do AS, o NEXT_HOP será o endereço IP do vizinho que anunciou a rota srcinalmente. O NEXT_HOP aprendido pelo eBGP não é alterado pelo iBGP, permanecendo o endereço IP do peer eBGP que srcinou o anúncio da rota. 3. Quando a rota é anunciada em redes multiacesso (como Ethernet e Frame Relay), o NEXT_HOP geralmente é o endereço IP da interface do roteador conectada que srcinou a rota. ATRIBUTO MÉTRICA (MED - MULTI_EXIT_DISCRIMINATOR) : Este atributo tem como finalidade informar para os vizinhos BGP externos (peers) qual o melhor caminho (path) para uma determinada rota do próprio AS. Ele serve para influenciar qual caminho deve ser seguido quando BGP. um AS possuir diversos pontos de entrada. O menor valor de MED será o preferido pelo ATRIBUTO LOCAL PREFERENCE ou LOCAL_PREF : Este atributo serve para anunciar qual é o caminho preferencial de saída para uma determinada rota destinada a uma rede externa ao AS. Como o próprio nome do atributo sugere "local preference" ou "preferência local", ele somente é anunciado (repassado) entre os roteadores vizinhos BGP (iBGP) do mesmo AS, não sendo repassado aos roteadores vizinhos externos (eBGP). Caminhos (paths) que possuem o LOCAL_PREF com maior valor são preferidos pelo BGP. O valor padrão do LOCAL_PREF é 100. Veja a figura abaixo com um exemplo do uso do local preference para influenciar no balanceamento do tráfego de saída em um AS conectado a um ISP com dois links de saída. Nesse exemplo as redes 200.200.24.0/24 e 200.200.25.0/24 estão saindo pelo link entre R2 e R5 que conecta ao ISP, já o tráfego da rede 200.200.32.0/24 sai pelo link de saída entre R3 e R6. O problema que está ocorrendo é que com essa configuração o link entre R2/R5 está com 65% de carga e o link entre R3/R6 está com somente 20% do seu tráfego utilizado.


  

 






  




Página 191  



 


Para melhorar a divisão da carga de saída podemos utilizar o parâmetro local preference, criando um route-map em R3, marcando a preferência local para a rede 200.200.25.0/24 para 150, por exemplo. Dessa forma, as redes 200.200.25.0 e 200.200.32.0 serão enviadas pelo link entre R3 e R5 e teremos um link com 45% e o segundo com 40% do tráfego, deixando a carga entre eles mais equilibrada, conforme figura abaixo.

ATRIBUTO ATOMIC_AGGREGATE: Este atributo é usado por um roteador que, ao ter que selecionar uma rota dentre várias recebidas de seu peer que se sobrepõem, escolhe uma, ignorando a mais específica. Então, ele deve incluir o atributo ATOMIC_AGGREGATE à rota quando for propagá-la a seus vizinhos (caso o atributo ainda não esteja presente na rota menos específica recebida). ATRIBUTO AGGREGATOR: Este atributo pode ser incluído em mensagens UPDATE que sejam formadas por agregação. O atributo AGGREGATOR contém o ASN do último roteador que formou uma rota agregada, seguido de seu próprio ASN e endereço IP.


  

 






  




Página 192  



 


ATRIBUTO COMMUNITY: Este atributo é usado para representar um agrupamento de destinos que compartilhem uma ou mais características, não sendo estas restritas a um mesmo AS, rede ou conjunto de redes. As delimitações do agrupamento são políticas, podendo envolver mais de um AS inclusive. As comunidades (communities) podem ser compostas de diversas redes pertencentes a qualquer AS usadas para simplificar políticas de roteamento identificando rotas por algum parâmetro lógico ao invés de prefixos CIDR ou ASNs. Usando esses atributos, um roteador pode combiná-los com outros para determinar, para cada comunidade, quais rotas devem ser aceitas, descartadas, preferidas ou repassadas para outros vizinhos. ATRIBUTO WEIGHT: Definido pela Cisco Systems, o WEIGHT não é propriamente um atributo BGP. Ele influencia no processo de seleção da melhor rota do roteador onde for definido e, como é um atributo local ao roteador, não é repassado e nem propagado aos seus vizinhos nas mensagens UPDATE. O WEIGHT é um valor decimal entre 0 e 65535, sendo o valor padrão igual a 32768, assumido para rotas srcinadas pelo roteador. Outras rotas possuem o WEIGHT igual a 0 (zero), por padrão. Havendo mais de uma possível rota para um mesmo destino, o BGP-4 seleciona a que possuir o atributo WEIGHT com maior valor. Este atributo é comumente usado pelos operadores de redes para influenciar o processo de escolha de rotas do BGP. Esse parâmetro pode ser configurado diretamente em um vizinho para definir a rota preferencial por determinado caminho, por exemplo, veja a figura abaixo onde o comando "neighbor 3.3.3.3 weight 120" foi aplicado no roteador A. Note que ele recebe a rota para 172.20.0.0 a partir de B (3.3.3.3) e C (2.2.2.2), porém as rotas enviadas pelo vizinho 3.3.3.3 serão marcadas com o peso 120 e terão preferência sobre a rota recebida através de 2.2.2.2, portanto o roteador A utilizará o caminho através do roteador B para a rede 172.20.0.0.

O mais interessante é que esse atributo é local e não repassado para os demais vizinhos, servindo como decisão somente nesse AS.


  

 






  




Página 193  



 


3.7 Processo de Escolha da Melhor Rota Como já mencionado anteriormente o BGP tenta avaliar os atributos das diversas rotas para chegar a uma melhor rota, pois por padrão o BGP não faz balanceamento de cargas. Mas como esse processo de escolha é feito? A análise dos atributos é feita entre os caminhos livres de loop, sincronizados (caso esteja habilitada a sincronização) e com próximo salto (netx hop) alcançável na seguinte ordem: Veja a figura abaixo com o resumo do processo de seleção. 1. Escolhe a rota com maior valor de "weight". 2. Se o weight não estiver configurado, escolhe a rota com maior local preference. 3. Escolhe as rotas srcinadas pelo próprio roteador. 4. Escolhe a rota com menos ASpath. 5. Escolhe a rota com menor código de srcem (srcin: i < e < ?). 6. Escolhe a rota com menor valor de MED se o mesmo AS anunciar possíveis rotas. 7. Escolhe uma rota EBGP preferencialmente uma rota IBGP. em relação a 8. Escolhe a rota através do vizinho IGP mais próximo determinado pela menor métrica IGP. 9. Escolha a rota mais antiga. 10. Escolha o caminho através do vizinho com menor router ID. 11. Escolha o caminho através do vizinho com menor endereço IP.

Para habilitar o balanceamento de cargas é necessário utilizar o comando "maximum-paths num-de-caminhos" em modo de configuração do protocolo BGP. O valor normalmente vai até

seis rotas para balanceamento, porém em IOSs mais atuais esse valor pode ir até 16. Veja exemplo abaixo onde vamos configurar o balanceamento de carga entre quatro rotas. R4(config)#router bgp 300 R4(config-router)#max R4(config-router)#maximum-paths ? <1-16> Number of paths ibgp iBGP-multipath R4(config-router)#maximum-paths 4

Para realizar o balanceamento de carga entre links de mesma largura de banda conectados a apenas um ISP é recomendado o uso da configuração do BGP através de endereços de interfaces de loopback com eBGP Multihop. Apostila/E-B     

  

 






  




Página 194  



 


Podemos também influenciar na decisão de que melhor rota o BGP irá tomar através de comandos. Como o BGP não foi criado para ser rápido, e sim propiciar maior controle sobre a tomada de decisões de melhor caminho, podemos influenciar a escolha das rotas de várias maneiras diferentes através da manipulação dos atributos dos caminhos ou então utilizando "route maps", algumas vezes a alteração do atributo é realizada dentro do route map. É possível alterar a preferência local configurando um padrão (default local preference) através do comando "bgp default local-preference" e também alterar o MED padrão para rotas redistribuídas utilizando o comando "default-metric", ambos dentro do modo de configuração do BGP. Outra maneira influenciar a tomada decisãoadministrativa é configurando a distância administrativa com ode comando "distance" (a de distância não é utilizada diretamente pelo BGP e sim pelo roteador na análise das rotas entre os diversos protocolos), veja exemplos dos comandos citados abaixo. R4(config)#router bgp 300 R4(config-router)#default-metric ? <1-4294967295> Default metric R4(config-router)#default-metric 1000 R4(config-router)#bgp default ? ipv4-unicast Activate ipv4-unicast for a peer by default local-preference local preference (higher=more preferred) route-target Control behavior based on Route-Target attributes R4(config-router)#bgp default local-preference ? <0-4294967295> Configure default local preference value R4(config-router)#bgp default local-preference 50 R4(config-router)#distance ? <1-255> Administrative distance bgp BGP distance mbgp MBGP distance R4(config-router)#distance bgp ? <1-255> Distance for routes external to the AS R4(config-router)#distance bgp 10 ? <1-255> Distance for routes internal to the AS R4(config-router)#distance bgp 10 100 ? <1-255> Distance for local routes R4(config-router)#distance bgp 10 100 200 R4(config-router)#

Utilizando route maps podemos filtrar atributos de vizinhos ou rotas específicas, aumentando a granularidade da ação a ser tomada. No exemplo abaixo mostramos a aplicação de um route maps utilizado para configurar o atributo "local preference" igual a 200 para determinadas rotas redistribuídas do ospf dentro do bgp. Como o novo valor é maior que a "local preference" padrão de 100, os roteadores dentro do AS irão preferir esse caminho de preferência local 200 ao invés de rotas com preferência local padrão. As redes que terão a preferência local alterada estão na ACL 23 (statement 10), já as rotas dentro da ACL 103 não serão redistribuídas (statement 20) e as demais serão redistribuídas com a preferência local padrão (statement 30). R4(config)#route-map BGP-Test permit 10 R4(config-route-map)#match ip address 23 R4(config-route-map)#set local-preference 200 R4(config-route-map)#!


  

 






  




Página 195  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R4(config-route-map)#route-map BGP-Test deny 20 R4(config-route-map)#match ip address 103 R4(config-route-map)#! R4(config-route-map)#route-map BGP-Test permit 30 R4(config-route-map)#exit R4(config)#router bgp 300 R4(config-router)#redistribute ospf 1 route-map BGP-Test R4(config-router)#

Os route maps podem ser aplicados tanto em rotas enviadas como recebidas de um vizinho, por exemplo, na configuração abaixo temos um route map que altera o valor do atributo MED e adiciona mais duas cópias do seu próprio número de AS no atributo de caminho "AS-path" em todas as rotas anunciadas para fora através de um link EBGP para seus vizinhos: R4(config)#route-map MED-Test permit 10 R4(config-route-map)#set metric 50 R4(config-route-map)#set as-path prepend 300 300 R4(config-route-map)#! R4(config-route-map)#router bgp 300 R4(config-router)#neighbor 201.201.201.1 route-map MED-Test out

O comando "bgp always-compare-med" pode ser utilizado para que o BGP compare o MED entre prefixos que foram srcinados em diferentes sistemas autônomos. Quando a política de roteamento entre vizinhos do BGP é alterada, a sessão do BGP deve ser reinicializada (cleared) para que essas mudanças tenham efeito. Existem três tipos de resets: "hard reset", "soft reset" e "route refresh". A maiorpois vantagem "route refresh" é quepor eleúltimo exige menos uso de memória hard ou soft reset, com osdo dois métodos citados o roteador com várias que rotaso pode gastar muitos recursos para recalcular todas as rotas. O "route refresh" pode ser ativado com o comando "neighbor soft-reconfiguration inbound". O hard reset pode ser aplicado através do comando "clear ip bgp *" e quando utilizamos um "*" resetamos todas as vizinhanças, porém você pode inserir o IP de um vizinho específico. Já o soft reset é aplicado com o comando "clear ip bgp * soft in | out", sendo que o asterisco pode ser substituído pelo IP do vizinho específico que teve a política alterada. Outra forma de reinicializar a vizinhança é com o comando "neighbor shutdown" e "no neighbor shutdown", porém menos aconselhável, pois os comandos acima são menos destrutivos. 3.8 Filtrando Rotas do BGP

–

Route Filtering

Podemos ainda utilizar route maps e listas de prefixos (prefix lists) para filtrar rotas anunciadas ou recebidas de um determinado roteador BGP vizinho, assim podemos controlar a redistribuição de rotas dentro BGP e também configurar determinados atributos para rotas específicas simultaneamente. Uma lista de prefixos pode ser aplicada diretamente a um vizinho (no comando neighbor) para filtrar atualizações de roteamento. Para utilizar a lista de prefixo com esse fim devemos: 1. 2. 3. 4.

Planejar a implementação e determinar os requisitos (o que desejamos filtrar). Criar a lista de prefixos que corresponde aos prefixos a serem filtrados. Permitir as redes que devem ser anunciadas e negar todas as outras. Aplicar a lista de prefixos ao vizinho BGP com o comando neighbor no sentido inbound (entrada) ou outbound (saída).


  

 






  




Página 196  



 


5. Verificar a configuração com o comando "show ip prefix-list" e analisando a tabela de roteamento do vizinho para certificar-se que as rotas filtradas e permitidas estão de acordo com o planejamento inicial. Vamos a um exemplo onde somente as redes com o prefixo 172.31.0.0 /16 a /20 podem ser anunciadas, as demais rotas devem ser bloqueadas por padrão. Veja a configuração abaixo onde a lista com o nome Ex-1 foi criada e aplicada ao comando neighbor do vizinho 201.201.201.1 conectado ao roteador R4. R4(config)#ip prefix-list Ex-1 permit 172.31.0.0/16 le 20 R4(config)#! R4(config)#router bgp 300 R4(config-router)#neighbor 201.201.201.1 prefix-list Ex-1 out R4(config-router)# R4(config-router)#do show ip prefix-lis ip prefix-list Ex-1: 1 entries seq 5 permit 172.31.0.0/16 le 20 R4(config-router)#end R4#

O comando "show ip prefix-list" mostra a lista criada e para limpar o contador podemos utilizar o comando "clear ip prefix-list command". Combinando listas de prefixos com route maps podemos redefinir os atributos nas rotas permitidas pela lista. Veja o exemplo a seguir onde a lista de prefixos com o nome Ex-1, criada no exercício anterior, será utilizada em um route map para alterar o MED para 100 quando forem anunciadas no sentido de saída, além disso, o MED das demais rotas será configurado com o valor 200. Veja os comandos abaixo: R4(config)#route-map Test permit 10 R4(config-route-map)#match ip address prefix-list Ex-1 R4(config-route-map)#set metric 100 R4(config-route-map)#route-map Test permit 20 R4(config-route-map)#set metric 200 R4(config-route-map)#! R4(config-route-map)#router bgp 300 R4(config-router)#neighbor 201.201.201.1 route-map Test out R4(config-router)#end R4#show route-map route-map Test, permit, sequence 10 Match clauses: ip address prefix-lists: Ex-1 Set clauses: metric 100 Policy routing matches: 0 packets, 0 bytes route-map Test, permit, sequence 20 Match clauses: Set clauses: metric 200 Policy routing matches: 0 packets, 0 bytes R4#

Com o comando "show route-map" podemos analisar os mapeamentos criados e também a estatística de quantos pacotes deram correspondência (match) com cada statement criado. É importante na preparação para o CCNP saber interpretar listas de prefixos, route maps e demais comandos utilizados para manipulação de rotas nos protocolos de roteamento.


  

 






  




Página 197  



 


3.8.1 Exemplo Prático 1 – Evitando rotas de trânsito

Um dos problemas quando utilizamos solução com BGP multihomed é a utilização do AS pelos ISPs como encaminhamento de rotas transientes, fazendo com que rotas que não são do AS local transitem entre os roteadores de borda, fazendo o encaminhamento entre os ISPs conectados ao AS local, por isso chamamos esse tipo de AS como "trânsito" (system transit). A solução para evitar esse tipo de problema é configurar uma lista de distribuição de saída filtrando todas as redes que não foram srcinadas no próprio AS, assim as rotas aprendidas pelo BGP não serão repassadas pelos roteadores de borda do AS local para os roteadores de borda do ISP que fazem a vizinhança BGP entre eles. Por exemplo, abaixo temos uma configuração utilizando expressão regular que permite apenas que rotas sem nada no atributo AS-Path, ou seja, rotas do próprio roteador, sejam anunciadas na direção de saída do vizinho. ip as-path access-list 1 permit ^$ ! router bgp 100 neighbor 201.201.201.202 filter-list 1 out

No comando "ip as-path Access-list 1" o "permit ^$" significa que o AS Path deve estar vazio, pois o ^ é o início da linha e o $ o final e não tem nada entre eles, portanto é uma linha vazia. Quando o roteador anunciar as rotas ao vizinho 201.201.201.2 ele vai retirar quaisquer anúncios que venham com o campo AS-Path preenchido, portanto não vai repassar as rotas aprendidas pelo outro ISP. As expressões regulares são bastante poderosas, mas não fazem parte do material do CCNP. Nota: expressões regulares são muito utilizadas no "mundo linux", caso você queira conhecer mais a respeito, visite nossa página de cursos linux. 3.8.2 Exemplo Prático 2 – RFC 1918

Outro exemplo prático que normalmente é aplicado nos roteadores de borda de Internet é o bloqueio de IPs relativos à RFC 1918 para redes privativas. Normalmente pensamos apenas nos IPs reservados para as classes A, B e C pelo RFC 1918, porém na prática costuma-se inserir ainda as seguintes faixas:  







IPs reservados para loopback (127.0.0.0/8). Endereços reservados para link local em IPv4, ou seja, a 169.254.0.0/16 com exceção da primeira e última sub-rede /24, portanto as redes de 169.254.1.0 a 169.254.254.255 são reservadas para alocação aleatória quando um servidor DHCP não está presente. Endereços de Multicast de 240.0.0.0 a 254.255.255.254 (240.0.0.0/4 exceto 255.0.0.0/8). Rede 192.0.2.0/24, pois ela geralmente é citada como exemplo em documentações, chamada de TEST-NET. Rede 0.0.0.0/8 deve ser bloqueada (rede classe A iniciando em 0), porém a rede 0.0.0.0/0 utilizada como anúncio de uma rota padrão deve ser liberada.


  

 






  




Página 198  



 


Portanto, para selecionar essas redes a lista de prefixos completa fica como abaixo: R4(config)#ip R4(config)#ip R4(config)#ip R4(config)#ip R4(config)#ip R4(config)#ip R4(config)#ip R4(config)#ip

prefix-list prefix-list prefix-list prefix-list prefix-list prefix-list prefix-list prefix-list

rfc1918 rfc1918 rfc1918 rfc1918 rfc1918 rfc1918 rfc1918 rfc1918

deny deny deny deny deny deny deny deny

10.0.0.0/8 le 32 172.16.0.0/12 le 32 192.168.0.0/16 le 32 127.0.0.0/8 le 32 169.254.0.0/16 le 32 224.0.0.0/3 le 32 192.0.2.0/24 le 32 0.0.0.0/8 le 32

R4(config)#ip prefix-list rfc1918 permit 0.0.0.0/0 le

32

Para visualizar o efeito da configuração vamos inserir o comando "show ip prefix-list", veja abaixo. R4(config)#do sho ip prefix ip prefix-list Ex-1: 1 entries seq 5 permit 172.31.0.0/16 le 20 ip prefix-list rfc1918: 9 entries seq 5 deny 0.0.0.0/8 le 32 seq 10 deny 10.0.0.0/8 le 32 seq 15 deny 127.0.0.0/8 le 32 seq 20 deny 169.254.0.0/16 le 32 seq 25 deny 172.16.0.0/12 le 32 seq 30 deny 192.0.2.0/24 le 32 seq 35 deny 192.168.0.0/16 le 32 seq 40 deny 224.0.0.0/3 le 32 seq 45 permit 0.0.0.0/0 le 32

Agora vamos inserir as listas de prefixos tanto na entrada como na saída dos anúncios enviados para o vizinho 201.201.201.1 via o comando "neighbor". R4(config)#router bgp 300 R4(config-router)#neighbor 201.201.201.1 prefix-list rfc1918 in R4(config-router)#neighbor 201.201.201.1 prefix-list rfc1918 out

Essa filtragem de IPs especiais é chamada de "Documenting Special Use Addresses" ou DUSA. Outro tipo de filtragem recomendada é relativo aos Bogons, que são vários blocos de IPv4 reservados pela IANA que ainda têm que ser alocados para um RIR (http://www.iana.org/assignments/ipv4-address-space), portanto esses blocos de endereços IPv4 nunca devem ser anunciados na tabela global de rotas da Internet, por isso filtros devem ser aplicadas nas bordas filtrando anúncios de entrada e saída. Existem ainda outras recomendações de filtragem como, por exemplo, se um ISP alocou uma faixa a um cliente ele não deve deixar que o cliente anuncie faixas diferentes da alocada por ele, pois isso pode ser a tentativa de injeção de rotas falsas via o ISP conectado.


  

 






  




Página 199  



 


3.9 Agregação de Rotas no BGP A agregação de rotas no BGP é realizada através do comando "aggregate-address" dentro do modo de configuração do roteamento BGP. Para que a rota agregada seja anunciada deve haver na tabela de roteamento rotas para redes que fazem parte do endereço agregado, senão a rota agregada não será anunciada para outros vizinhos BGP. Veja um exemplo do comando abaixo, onde a rota 100.100.100.0/24 será agregada em um anúncio 100.0.0.0/8, note que após a sumarização com o comando "show ip bgp" a rota /24 terá um "s" de "suppressed" na frente indicando que ela foi suprimida. R1(config)#router bgp 100 R1(config-router)#aggregate-address 100.0.0.0 255.0.0.0 summary-only R1(config-router)#end R1#sho ip bgp *Mar 1 00:03:50.103: %SYS-5-CONFIG_I: Configured from console by console R1#sho ip bgp BGP table version is 6, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 100.0.0.0 s i100.100.100.0/24 s> * 200.200.200.0/30 *>

Next Hop 0.0.0.0 100.100.100.2 0.0.0.0 3.3.3.3 0.0.0.0

Metric LocPrf Weight 32768 0 100 0 0 32768 0 0 0 32768

*>i201.201.201.0/30 100.100.100.2 R1#

0

100

Path i i i 200 i i

0 i

A opção "summary-only" utilizada no final do comando evita que as sub-redes sejam anunciadas juntamente com a rota sumarizada, sem esse comando o roteador acaba anunciando tanto a rota sumarizada como as sub-redes que fazem parte dessa sumarização. Na tabela de roteamento em R1 você também irá notar que uma rota será criada apontando para a null0 para evitar possíveis loops de roteamento. R1#sho ip rout ###Saídas Omitidas ### 200.200.200.0/30 is subnetted, 1 subnets C 200.200.200.0 is directly connected, FastEthernet0/1 201.201.201.0/30 is subnetted, 1 subnets B 201.201.201.0 [200/0] via 100.100.100.2, 00:05:23 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 100.0.0.0/8 is variably subnetted , 2 subnets, 2 masks C 100.100.100.0/24 is directly connected, FastEthernet0/0 B S R1#

100.0.0.0/8 [200/0] via 0.0.0.0, 00:03:13, Null0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [1/0] via 200.200.200.2

A agregação de rotas e o comando "network" são os dois métodos indicados para anunciar redes internas para ISPs externos, a redistribuição não é recomendada para anúncio de rotas via BGP para um ISP. Uma exceção para essa regra é quando estamos utilizando o BGP para conectar redes internas do AS através de uma rede MPLS, pois nesse caso não estamos conectando apenas a rede corporativa e não fazendo a conexão com a Internet via MPLS.


  

 






  




Página 200  



 


3.10 Configurando a Autenticação no BGP O BGP suporta autenticação com chaves pré-compartilhadas utilizando o MD5 realizada por vizinho com o comando "neighbor {ip-address | peer-group-name} password senha". A mesma senha ou chave deve ser configurada em ambos os lados, caso um dos lados não tenha a mesma senha ou a autenticação ainda não tenha sido habilitada um erro será gerado, veja exemplo abaixo. R4(config)#router bgp 300 R4(config-router)#neighbor 201.201.201.1 password cisco R4(config-router)# *Mar 1 02:03:24.183: %TCP-6-BADAUTH: No MD5 digest 201.201.201.2(179) *Mar 1 02:03:24.479: %TCP-6-BADAUTH: No MD5 digest 201.201.201.2(179) *Mar 1 02:03:24.487: %TCP-6-BADAUTH: No MD5 digest 201.201.201.2(179) *Mar 1 02:03:25.103: %TCP-6-BADAUTH: No MD5 digest 201.201.201.2(179)

from

201.201.201.1(35056)

to

from

201.201.201.1(35056)

to

from

201.201.201.1(35056)

to

from

201.201.201.1(35056)

to

Como o vizinho de R4 ainda não foi configurado essa mensagem de erro é gerada constantemente até que R2 seja configurado corretamente. Veja como estava o roteador R2, onde tivemos a queda da sessão BGP e depois ao configurar corretamente a autenticação a sessão subiu novamente. R2# *Mar 1 03:44:24.971: %BGP-3-NOTIFICATION: received from neighbor 201.201.201.2 4/0 (hold time expired) 0 bytes *Mar 1 03:44:24.979: %BGP-5-ADJCHANGE: neighbor 201.201.201.2 Down BGP Notification received R2#conf t R2(config)#router bgp 100 R2(config-router)#neighbor 201.201.201.2 password cisco R2(config-router)# *Mar 1 03:47:52.871: %BGP-5-ADJCHANGE: neighbor 201.201.201.2 Up R2(config-router)#do show ip bgp summ BGP router identifier 201.201.201.1, local AS number 100 BGP table version is 4, main routing table version 4 3 network entries using 360 bytes of memory 4 path entries using 208 bytes of memory 3/2 BGP path/bestpath attribute entries using 372 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 2 (at peak 4) using 64 bytes of memory BGP using 1004 total bytes of memory BGP activity 3/0 prefixes, 6/2 paths, scan interval 60 secs Neighbor V 100.100.100.1 4 201.201.201.2 4 R2(config-router)#


TblVer 4 4


Normalmente conexões com ISPs exigem a configuração da autenticação.


  

 






  




Página 201  



 


4 Monitoração e Troubleshooting do BGP O comando mais importante para verificação e troubleshoot do BGP é o "show ip bgp", o qual mostra a tabela de topologia do BGP (topology database). A saída desse comando lista uma tabela contendo:    

Todas as redes que o BGP conhece; Próximo salto de cada rede; Alguns atributos das rotas; Caminho (AS-path) para todas as rotas.

Abaixo segue um exemplo do comando. BGP-router >show ip bgp BGP table version is 22285573, local router ID is 12.0.1.28 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 3.0.0.0 12.123.137.124 0 7018 2914 9304 80 i *> 12.123.1.236 0 7018 2914 9304 80 i * 3.51.92.0/23 12.123.137.124 0 7018 ? * 12.122.125.4 2366 0 7018 ? *> 12.123.1.236 0 7018 ? * 8.6.6.0/24 12.123.137.124 0 7018 701 14744 14744 14276 i * 12.123.145.124 0 7018 701 14744 14744 14276 i *> 12.123.1.236 0 7018 701 14744 14744 14276 i

As redes são mostradas em ordem numérica, da menor para a maior (3.0 < 3.51 < 8.6). As três primeiras colunas são referentes ao status de cada rota, sendo que se houver um asterisco (*) na primeira coluna quer dizer que a rota tem um "next hop" (próximo salto) válido. Outras opções podem aparecer na primeira coluna, veja o que cada uma delas representa: 



 



"s" (Suppressed): O BGP conhece a rota e não a anuncia, ou seja, ela foi suprimida (suppressed), por exemplo, a rota faz parte de uma sumarização. "d" (Dampened): Significa que o BGP parou de anunciar a rota por motivos de estabilidade, por exemplo, a rota está com muito flap (fica up e down) até ficar estável após certo período de tempo. "h" (History): O BGP conhece a rede, mas não tem rota válida para ela. "r" (RIB failure): A rota foi anunciada para o BGP, mas não foi instalada na tabela de roteamento. Este problema pode ter sido causado por outro protocolo de roteamento ter anúncio para a mesma rede com melhor distância administrativa. "S" (Stale): Usado com encaminhamento sem parar (non-stop) para indicar que a rota está obsoleta e precisa ser atualizada quando a vizinhança for restabelecida.

Na segunda coluna temos um sinal de maior (>) ao lado da rota escolhida como melhor caminho para a redesendo de destino. Na saídafoi doescolhida comandocomo dado melhor como exemplo duas rotas para a rede 3.0.0.0, que a segunda caminho temos (identificado com o símbolo ">"). Considerando ainda a mesma rota, a terceira coluna para ela está em branco, pois as rotas foram aprendidas de protocolos externos. Se a rota fosse aprendida pelo IBGP o vizinho teria um "i" na terceira coluna, veja exemplo a seguir.


  

 






  




Página 202  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R2#sho ip bgp ###Saída Omitida ### Network Next Hop * i100.100.100.0/24 100.100.100.1 *> 0.0.0.0 *>i200.200.200.0/30 100.100.100.1

Metric LocPrf Weight Path 0 100 0 i 0 32768 i 0 100 0 i

Na quarta coluna temos as redes conhecidas pelo BGP, sendo que a rede que não possui máscara de sub-rede, por exemplo, a rede 3.0.0.0, está usando máscara classfull (nesse exemplo uma /8). Quando a rede é aprendida por várias fontes de roteamento ela é mostrada apenas uma vez e abaixo dela são mostradas as rotas sem nada no campo da rede. Na quinta coluna temos o próximo salto (next-hop address) para cada uma das rotas aprendidas. Um valor de next-hop igual a 0.0.0.0 significa que a rota foi srcinada pelo roteador local (comando network), via redistribuição de um IGP dentro do BGP ou então via agregação de rotas (comando aggregate). Na sexta coluna temos o MED recebido para aquela rota, esta coluna se chama "Metric". Note, por exemplo, que a rede 3.51.92.0/23 aprendida a partir do roteador 12.122.125.4 tem um valor de MED igual a 2366. Na sétima coluna temos o Local Preference. Na saída de comando do exemplo todas as rotas estão usando o valor default para o Local Preference, por isso nenhum valor é mostrado. Na oitava coluna temos o atributo Weight, o qual tem o valor padrão igual a 0, sendo mostrado mesmo assim, ao contrário do local preference. A nona coluna mostra o caminho para cada rede, ou seja, o atributo "AS path". A leitura deve ser feita da esquerda para a direita, ou seja, o primeiro número de AS mostrado é o número do AS vizinho conectado ao roteador local. A sequência mostra em ordem os ASs que o pacote deve cruzar até encontrar a rede de destino. O último número de AS é o que srcinou a rota. Vamos pegar mais uma vez a rede 3.0.0.0 como exemplo, temos para essa rede a sequência de ASs "7018 2914 9304 80", portanto essa rota foi aprendida a partir do AS 7018 (diretamente conectado ao AS local), o qual aprendeu a rota pelo AS 2914, o qual aprendeu a rota via o AS 9304, que aprendeu a rota via AS 80, o qual srcinou a rota. Se o AS path estiver em branco significa que a rota foi srcinada pelo AS local. Se você encontrar um número de AS repetido, como para a rota 8.6.6.0 que mostra o AS 14744 duplicado na lista do AS path, significa que houve uma manipulação de rotas e o valor do AS foi adicionado na frente (prepended) para fazer com que essa rota seja menos atrativa quando enviada para outro sistema autônomo. Já mostramos um exemplo dessa configuração nos tópicos anteriores. Na última coluna temos como o BGP aprendeu essa rota, qual a srcem dessa informação de roteamento. Por exemplo, as redesque 3.0.0.0 e 8.6.6.0 mostram "i" comonetwork. "srcin code" (código de srcem), o que significa elas foram aprendidas via um o comando Já a rede 3.51.92.0 mostra o símbolo "?" como srcem, o que significa que essa rede foi redistribuída dentro do BGP, considerado como uma rota "incomplete" (incompleta). O símbolo "e" provavelmente você nunca verá, pois significa que o BGP aprendeu a rota via Exterior Gateway Protocol (EGP), o qual não está mais em uso. Abaixo seguem outros comandos show que podem ser utilizados no troubleshooting e verificação do BGP:


  

 






  




Página 203  



 








show ip bgp rib-failure: mostra as rotas que não foram inseridas na tabela de roteamento e o motivo delas não estarem sendo utilizadas. show ip bgp summary : mostra a quantidade de memória usada pelos bancos de dados do BGP, estatísticas de atividade e lista os vizinhos do BGP. show ip bgp neighbors: mostra detalhes de cada vizinho, podendo ser utilizado com o IP do vizinho para se obter mais detalhes sobre ele, por exemplo, "show ip bgp neighbors 201.201.201.1". show ip bgp neighbors address [received | routes | advertised]: permite a monitoração das rotas recebidas e anunciadas a um vizinho específico.

Um exercício interessante é procurar por servidores de roteamento públicos, os quais permitem acesso telnet e alguns comandos show relacionados ao BGP. Você pode se conectar ao servidor ou roteador e verificar o "show ip bgp" ou "show ip bgp summ" de roteadores que fazem "full routing", ou seja, trocam tabelas completas de roteamento na internet, assim você se familiariza com o porte de tais roteadores. No site http://routeserver.org/ você encontra essa lista, veja o comando "show ip bgp summ" para um dos roteadores que faz full route. Nesse exemplo o roteador usa mais de 100M bytes de sua memória RAM com a tabela de roteamento! mtnghana-route-server>sho ip bgp summary BGP router identifier 196.201.61.246, local AS number 37255 BGP table version is 71236599, main routing table version 71236599 435238 network entries using 52228560 bytes of memory 870476 path entries using 45264752 bytes of memory 70212/70212 BGP path/bestpath attribute entries using 8706288 bytes of memory 5 BGP rrinfo entries using 120 bytes of memory 63998 BGP AS-PATH entries using 2599882 bytes of memory 3 BGP community entries using 72 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 108799674 total bytes of memory BGP activity 2459963/2024725 prefixes, 8656289/7785813 paths, scan interval 60 secs Neighbor V State/PfxRcd 196.201.61.1 4 435238 196.201.61.2 4 435238 mtnghana-route-server>

AS MsgRcvd MsgSent

  

 



InQ OutQ Up/Down

37255 14457312

141637 71236599

0

0 12w5d

37255 22085357

141592 71236599

0

0 12w5d


TblVer




  




Página 204  



 


4.1 Problemas Comuns com o BGP Motivos para problemas na formação de vizinhança:   



Falta do comando neighbor. Vizinho não está diretamente conectado e o comando ebgp-multihop não foi utilizado. Falta de rota para que o IP do vizinho seja alcançado (normalmente no EBGP uma rota estática apontando para o IP da loopback do vizinho). Número de AS errado na declaração do comando neighbor.



ACL bloqueando tráfego TCP entre os vizinhos. Uma vez formada a vizinhança para que as rotas sejam anunciadas é preciso o comando network, algumas dicas abaixo para evitar problemas com anúncios: 



O comando network sozinho anuncia rede classfull e não as sub-redes, para anunciar a sub-rede deve-se utilizar a opção "mask". Em rotas sumarizadas, se não houver nenhuma rota que faz parte do range que faz parte da sumarização a rota sumarizada não será anunciada para os vizinhos.

Para uma rota ser considerada dentro da escolha do melhor caminho algumas condições devem ser atendidas, senão elas simplesmente não entram no processo, seguem abaixo os principais requisitos: 

 

A rota deve estar sincronizada, ou seja, ter sido marcada como sincronizada no comando "show ip bgp". Deve ter next-hop alcançável. Não ter seu próprio AS listado na lista de ASs do atributo AS-Path, pois significa um possível loop de roteamento.


  

 






  




Página 205  



 


Capítulo 08 Implementando Roteamento em IPv6

O IPv6 não é somente um assunto importante para realizar o exame do CCNP Route mas também para sua vida profissional. O aumento da procura por serviços na web e a escassez de endereços IPv4 está fazendo com que cada vez mais empresas iniciem o processo de preparação para a migração para o IPv6.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Funcionamento e principais características do IPv6. Processo de descoberta de vizinhos e roteadores. Configuração do IPv6 em interfaces Dual Stack. Técnicas de migração e convivência entre o IPv4 e IPv6. Configuração de túneis GRE, 6to4 e MCT. Tipos de NAT para IPv6. Configurações dos protocolos de roteamento para IPv6. Configuração do OSPFv3. Configuração do EIGRPv6 e Named EIGRP para IPv4 e IPv6. Configuração do MP-BGP para IPV6. 





Lembrem-se que o lançamento oficial em nível mundial do IPv6 aconteceu no ano de 2012 e por um bom tempo as duas versões do protocolo IP devem coexistir, pois até uma total migração da comunicação pela Internet e nas redes corporativas para a





 

 

versão 6 do protocolo IP teremos um longo caminho pela frente e muitas oportunidades para os profissionais que realmente conheçam o assunto na teoria e principalmente na prática.



No CCNA o IPv6 já foi abordado, porém tem sido cobrado de maneira bem tímida. No entanto, não espere o mesmo no CCNP ROUTE, pois aqui serão cobrados conceitos mais avançados e configurações. Aproveitem bem o material e bons estudos!


  

 






  




Página 206  



 



3.1

Roteamento Estático ....................... 228

3.2

Configurando o RIPng ...................... 229

Introdução ao IPv6 ............................ 207

3.3

Configurando o EIGRPv6 Tradicional 231

1.1 Formato do Quadro IPv6 e Comparação com IPV4 ........................... ....................... . 209

3.4

Named EIGRP - IPv4 e IPv6 ........ ....... 233

1.2 Entendendo e Simplificando um Endereço IPv6............. ....................... ........211

3.4.1 3.4.2

Configurando o Named EIGRP ...........234 Ativando EIGRP em VRFs (IPv4 e IPv6) 235

1.3 Endereços Globais de Unicast e Divisão em Sub-redes .................... ....................... . 211

3.5

1.4 Atribuindo Endereços Globais de Unicast IPv6......... ...................... ................214

3.6 Redistribuição de Rotas nos IGPs IPv6 e outros Recursos............................... ..........241

1.4.1 EUI-64

Autoconfiguração Stateless e Endereços 215

1.5

Endereços IPv6 de Unicast Local ....... 217

1.6

Endereços de Multicast ......... ........ ... 217

1.7

Outros Endereços IPv6 de Uso Especial 218

1.8

ICMPv6 e seus Recursos ........ ........ ... 219

1.8.1 1.8.2 1.8.3

Neighbor Discovery Protocol (NDP) .. 219 Descoberta de IPs Duplicados (DAD) 220 Inverse Neighbor Discovery .............. 221

2 Configurações Básicas do IPv6 – Ativação e Interfaces ............................................. 221

2.1 Testando a Conectividade das Interfaces IPv6 224 2.2

Tipos de Redes Suportadas pelo IPv6 225

2.2.1 2.2.2 2.2.3

Redes Multiacesso com Broadcast ... 225 Redes Ponto a Ponto ......................... 225 Redes Ponto a Multiponto NBMA ..... 226

Configurando o OSPFv3 ................... 237

3.5.1 OSPFv3

Exemplo de Configuração Tradicional do 238

3.6.1 Configurando a Redistribuição Sem Route-Map ........................................................ 242 3.6.2 Configurando a Redistribuição Com Route-Map ........................................................ 243

3.7 Configurando Roteamento IPv6 através do MP-BGP........ ...................... ..................245 3.7.1 Sequência de Configuração do MP-BGP com IPv6 sobre uma Sessão BGP IPv4 ............... 246 3.7.2 Roteamento IPv6 através de uma sessão BGP IPv6 249

4 Técnicas de Convivência e Migração entre IPv4 e IPv6 ..................................... 253

4.1

Dual Stack ..................................... .. 253

4.2

Técnicas de Tunelamento................. 254

4.3

Técnicas de T radução IPv6/IPv4 ....... 255

4.3.1

Tradução via NAT-PT ......................... 255

4.4

Tradução Via NPTv6 ......... ........ ........ 256

4.5

Tradução Via NAT64 ........................ 256

2.3 MTU Path Discovery no IPv6 - Flow Label 227 3 Configurando o Roteamento em Redes IPv6 ........................................................ 228

1 Introdução ao IPv6 O principal motivo para o desenvolvimento do IPv6 foi a necessidade de mais endereços IPs públicos para a Internet, pois o aumento dos usuários, dispositivos e serviços que cada vez mais crescem em uma escala global tornou o IPv4 insuficiente para os requisitos atuais e futuros. No IPv4 temos 4,294,967,296 endereços (mais de 4 bilhões), enquanto no IPv6 temos um total de 340,282,366,920,938,463,463,374,607,431,768,211,456 endereços IP. Note abaixo como a diferença é gritante: IPv4: 000,000,000,000,000,000,000,000,000,004,294,967,296 Apostila/E-B     

  

 






  




Página 207  



 


IPv6: 340,282,366,920,938,463,463,374,607,431,768,211,456 Outro motivo é o crescimento no tamanho da tabela de roteamento da Internet, pois com endereços IPv4 o nível de sumarização atingiu um ponto máximo e na realidade a carga nos roteadores tende a aumentar. Veja abaixo o gráfico com o crescimento da tabela do BGP na Internet de 1994 a 2012 (fonte: http://bgp.potaroo.net/) onde atualmente temos aproximadamente 450.000 entradas na base de dados do BGP (RIB – Routing Information Base).

Além disso, apesar de esforços como NAT terem postergado o uso do IPv4 eles acabam quebrando o modelo de rede fim a fim proposto pelo modelo TCP/IP. Já com o IPv6 não haverá a necessidade de uso de endereços privativos (RFC-1918) e NAT, pois teremos endereços suficientes para todos os dispositivos se conectarem com endereços válidos na rede mundial de computadores.


  

 






  




Página 208  



 


Porém o IPv6 vai além de somente estender a faixa de endereços de Internet, abaixo seguem outros recursos e melhorias em relação ao IPv4 que iremos ver durante esse capítulo:      

Cabeçalho (header) simplificado para maior eficiência no roteamento Não utiliza mais broadcasts Autoconfiguração de endereços (stateless autoconfiguration) Suporte nativo a mobilidade (Mobile IP) Suporte nativo a segurança e IPsec Diversos mecanismos de transição, tais como pilha dupla, tunelamento e NAT-PT

  

Fácil reconfiguração de endereços Suporte a múltiplos endereços em uma mesma interface Suporte a protocolos de roteamento e muito mais

O IPv6 é ativado em modo de configuração global com o comando “ipv6 unicast-routing” e o comando “ipv6 enable” em modo de configuração de interface ativa o protocolo IPv6 naquela interface. A seguir vamos estudar mais características e recursos gerais do IPv6 e também como configurá-lo. 1.1 Formato do Quadro IPv6 e Comparação com IPV4 O formato do quadro do IPv6 é bastante simples e tem praticamente duas vezes menos bytes que o cabeçalho do IPv4, além disso, o quadro do IPv6 não inclui checksum como no IPv4 e para funções mais avançadas são utilizados cabeçalhos de extensão. Veja na figura abaixo o formato do quadro base do IPv6 e depois as explicações de cada campo.

Os campos significam:   



Version: versão fica em 6. Priority: similar ao DSCP do IPv4 com 8 bits para descrever a prioridade do pacote. Flow Label: são 20 bits para identificação do fluxo (flow label) que habilita a marcação dos pacotes de maneira similar ao MPLS. Payload Length: tamanho dos dados que serão inseridos no pacote.


  

 






  




Página 209  



 


 

Next Header: indica se vai haver ou não cabeçalhos de extensão e seu valor indica como esse cabeçalho de extensão deve ser interpretado, por exemplo, pode ser um segmento TCP, UDP ou um cabeçalho de extensão. Hop Limit: limite de saltos similar ao TTL. Source e Destination: endereços IP de srcem (source) e destino (destination) com 128 bits cada um.

No IPv4 seu cabeçalho base continha todas as informações principais e opcionais (mesmo que não fossem utilizadas), o que acaba fazendo com que o cabeçalho do IPv4 não seja tão eficiente. Para resolverchamados esse problema, no IPv6 as informações adicionais são tratadas como cabeçalhos opcionais de “cabeçalhos de extensão ” (extension headers). Os cabeçalhos de extensão são indicados no campo next-header do cabeçalho base do IPv6, podendo ser utilizados ou não. Eles podem incluir os seguintes tipos de opções: 



 



Hop-by-hop Options (next header = 0): Transporta informações adicionais que devem ser examinadas por todos os roteadores de caminho, por isso o nome Hop-byhop que em português significa salto a salto. Source Routing (next header = 43): Definido para ser utilizado como parte do mecanismo de suporte a mobilidade do IPv6 e definir por onde o pacote deve trafegar. Fragment (next header = 44): Indica se o pacote foi fragmentado na srcem. Encapsulating Security Payload (next header = 50) e Authentication Header (next header = 51): fazem parte do protocolo de segurança IPSec, utilizados para criptografia e autenticação do payload, tornando a criptografia nativa no cabeçalho do IPv6. Destination Options (next header = 60): Transporta informações que devem ser processadas apenas pelo computador de destino.

Veja na figura abaixo mostramos três base exemplos onde next-header o que deve conter na sequência do cabeçalho do IPv6. Nono exemplo 1 temostemos depoisdefinido do cabeçalho base um segmento TCP, identificado pelo código 6 no campo next-header. No exemplo 2 temos um cabeçalho de extensão de source routing depois um segmento TCP, por último, no exemplo 3 depois do cabeçalho base do IPv6 temos dois de extensão, o cabeçalho de routing e depois o de fragmentação e aí sim o cabeçalho do TCP e os dados. Como podemos perceber um pacote IPv6 pode ter quantos cabeçalhos de extensão forem necessários.

Portanto, em comunicações simples o IPv6 usa somente os campos base (mais simples) e para comunicações ou necessidades mais complexas são adicionados cabeçalhos de extensão específicos para cada recurso necessário.


  

 






  




Página 210  



 


1.2 Entendendo e Simplificando um Endereço IPv6 O endereço IPv4 tem 32 bits e é escrito em quatro bytes no formato decimal separado por pontos, por exemplo, 192.168.1.1. Já o IPv6 possui 128 bits e por isso adotou-se a escrita em hexadecimal (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F -> A=10, B=11,..., F=15) são 8 conjuntos de 4 algarismos em hexadecimal, como cada número em hexa tem 4 bits temos 8x4x4=128 bits, por exemplo: AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:1111:2222 Assim comoa orede IPv4, IPv6 tem uma máscara prefixo de 128 o bit entre 1 no 64 prefixo representa e oobit zero a porção de host.ou Normalmente um bits, IPv6 onde é dividido bits para rede e 64 bits para host, ou seja, utilizando um /64 que pode ainda ser dividido em subredes. Portanto, o endereço IPv6 é bastante grande e a única maneira de simplificação que existe é através dos bits zero presentes no endereço, sendo que podemos fazer de três maneiras: 1. Zeros à esquerda podem ser omitidos, por exemplo, o endereço IPv6 abcd:0151:0010:0012:cada:00aa:bacd:baba pode ser escrito como abcd:151:10:12:cada:aa:bacd:baba. 2. Sequências de 4 zeros podem ser substituídas por apenas um zero entre dois pontos “:0:”, por exemplo, abcd:0000:0000:0012:0000:00aa:bacd:baba pode ser escrito como abcd:0:0:12:0:aa:bacd:baba. 3. Várias sequências de zero contíguas podem ser substituídas por “::”, por exemplo, o endereço abcd:0000:0000:0012:dddd:00aa:bacd:baba pode ser escrito como abcd::0012:dddd:aa:bacd:baba, assim o roteador ou computador preencherá automaticamente os dois campos faltantes com zeros. A terceira opção de simplificação deve ser utilizada com cuidado, pois não pode haver ambiguidade no momento de escrevê-lo. Por exemplo, veja o endereço abcd:0000:0000:0012:0000:00aa:bacd:baba, se escrevermos como abcd::12::aa:bacd:baba como o dispositivo vai saber qual a posição correta dos zeros a serem preenchidos se há mais de uma possibilidade? Veja o que poderia ser feito com o IPv6 abcd::12::aa:bacd:baba: 1. abcd:0000:12:0000:0000:aa:bacd:baba ou 2. abcd:0000:0000:12:0000:aa:bacd:baba Portanto há uma ambiguidade para o roteador na representação do exemplo anterior e não seria possível definir qual das duas opções utilizar. Nesse caso, o correto seria o seguinte: abcd::12:0:aa:bacd:baba ou abcd::12:0000:aa:bacd:baba, assim o roteador saberia que precisaria preencher com dois conjuntos de quatro zeros apenas antes do algarismo :12:. 1.3 Endereços Globais de Unicast e Divisão em Sub-redes Assim como no IPv4 o IPv6 foi dividido em diversas faixas pela IANA para divisão entre as regiões que administram os endereços de Internet, seus ISPs e empresas. Essa divisão gerou o que é chamado de “Global Address Space” e na Internet a faixa reservada para Unicast é a 2000::/3, o que resulta na faixa iniciando em 2000:0:0:0:0:0:0:0 até 3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF para endereçamento. Portanto a IANA dividiu essa faixa de endereços entre cada uma das regiões (RIR) e o bloco 2800::/12 corresponde ao espaço reservado para o LACNIC alocar na América Latina. O NIC.br (responsável pelas alocações do IPv6 no Brasil) por sua vez, trabalhará com um /16 que faz parte deste /12.


  

 






  




Página 211  



 


Essa divisão de endereços é top-down, ou seja, a IANA definiu um bloco de IPv6 para cada região ou RIR, os quais passarão para seus ISPs, que por sua vez distribuirão suas faixas de IPv6 em regiões para seus clientes e usuários finais, possibilitando uma agregação de rotas mais eficiente do que a atual para o IPv4. No projeto do IPv6 para sair de uma região para outra apenas uma rota IPv6 será necessária, por exemplo, para que um roteador de borda da Europa alcance determinada rede nos Estados Unidos apenas uma rota será necessária, assim como para um cliente alcançar as rotas do seu ISP também apenas uma rota será necessária, reduzindo a tabela de roteamento e aumentando a eficiência do IPv6 em relação ao roteamento no IPv4. Os endereços globais de Unicast ou “Global Routing Prefix” são divididos em porção de rede e porção de host, porém a porção de rede terá algumas “fatias” que representam a região. Por exemplo, 2800::/12 representa que é um IP da LACNIC (América Latina), depois terá mais um pedaço que representará o Brasil (/16) e mais um pedaço do seu service provider ou ISP, normalmente um /32. Quando o ISP passar o bloco de endereço para o cliente será passado um /48 aí ele terá mais 16 bits para fazer sub-rede, uma vez que normalmente os hosts utilizam 64 bits para sua identificação. Veja a figura abaixo com um resumo do que será um endereço de Internet em IPv6. Temos três campos básicos, o de identificação do ISP (/48) que tem dentro dele também a identificação do RIR e da entidade local que administra os IPv6 (por exemplo, NIC.BR), depois mais 16 bits de sub-rede e 64 bits para host.

Note que a máscara de sub-rede utiliza a notação Classless Interdomain Routing (CIDR) com a barra “/” e a quantidade de bits de rede da máscara, conforma já citada anteriormente. E o prefixo ou rede IPv6 é representada como um endereço IPv6 normal, porém com a porção de hosts toda em zero (assim como já era no IPv4). Portanto a notação e simplificação de um prefixo IPv6 é como para um endereço comum do IPv6 e sempre precisamos ter os dois pontos no final seguidos da barra (/) e o número de bits de sub-rede, por exemplo: 2800::/12 que é a faixa de IPs da América Latina é o mesmo que 2800:0000:0000:0000:0000:0000:0000:0000, porém as sequências de zero foram substituídas pelo “::”. Seria errado escrever 28::/12, porque somente o zero a esquerda pode ser suprimido. Seria errado escrever 2800/12, porque 2800 não é um IPv6 

 


  

 






  




Página 212  



 


Veja o exemplo na figura abaixo onde a IANA fornece o bloco 2340::/12 para a ARIN (RIR que representa a região de Américas), a qual fornece para o ISP1 a faixa 2340:1111::/32, o qual alocou o bloco 2340:1111:AAAA::/48 para seu cliente chamado Company1.

Dentro da rede de Company1 ele pode agora subdividir esse /48 em diversas sub-redes conforme suas necessidades internas. Por exemplo, na figura abaixo temos quatro sub-redes alocadas: 1. 2. 3. 4.

2340:1111:AAAA:0001::/64 para a LAN de R1; 2340:1111:AAAA:0002::/64 para a WAN entre R1 e R2; 2340:1111:AAAA:0003::/64 para a LAN de R3 2340:1111:AAAA:0004::/64 para a WAN entre R1 e o roteador do ISP.


  

 






  




Página 213  



 


Com 16 bits o cliente tem 2^16 sub-redes ou 65.536 sub-redes com 64 bits de host ou 18,7x10^18 endereços de hosts. Devido a esse número elevado de hosts é possível quebrar mais ainda as sub-redes para um melhor aproveitamento no endereçamento de redes WAN ou dispositivos que utilizam IPs fixos. Por exemplo, pegar a sub-rede 2340:1111:AAAA:0002::/64 e dividi-la em sub-redes /112, ou seja, 48 bits para sub-rede (mais que o espaço do IPv4 de 32 bits) e 16 bits para host, dando mais 281 trilhões de sub-redes com 65536 IPs versão 6 cada sub-rede. Esta é a lógica para você planejar e endereçar seus laboratórios e cenários de estudo relativos ao IPv6 ou atéfigura mesmo a implantação IPv6hosts na empresa ondedevocê trabalha, por exemplo, veja a mesma anterior já com os de alguns e endereços interfaces abaixo

Para verificar a alocação de prefixos atuais pela IANA consulte o link: http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-addressassignments.xml 1.4 Atribuindo Endereços Globais de Unicast IPv6 No IPv4 podemos atribuir IPs para hosts e dispositivos de rede através de IPs fixos ou utilizando um servidor DHCP, sendo que para um host se comunicar na Internet ele precisa de IP, Máscara, gateway padrão e pelo menos um endereço de servidor DNS. Os requisitos para que um host IPv6 navegue na Internet são os mesmos, continuamos precisando de um IPv6 válido (dentro da faixa de global Unicast), máscara de sub-rede ou tamanho do prefixo de rede (notação CIDR), um gateway ou roteador padrão e também pelo menos um endereço de servidor DNS para tradução das URLs em endereços IPv6. Para configurar um IPv6 em um cliente (seja um host ou um roteador CPE) podemos utilizar IP fixo (configuração estática pelo administrador de redes) e também as seguintes novas formas de atribuição de endereço IPv6 que não existem no IPv4: 



IP fixo com ou sem EUI-64: o EUI-64 atribui o endereço de host do IPv6 utilizando o endereço MAC da interface de rede como base, portanto você pode definir um prefixo e o endereço de host é criado pelo EUI-64 ou então definir o IPv6 completo como normalmente fazemos em hosts IPv4, por exemplo, alocando o IPv6 2000::1/64 na interface. Autoconfiguração stateless (Stateless Address Autoconfiguration - SLAAC): permite que o computador utilize informações coletadas através do protocolo NDP (Neighbor Discovery Protocol) para atribuir automaticamente um IP a sua interface utilizando um prefixo de rede anunciado por um roteador mais o EUI-64 para definir a


  

 






  




Página 214  



 




porção de host do seu endereço. Existe a opção do cliente definir a porção de host mesmo utilizando SLAAC. Configuração via DHCP stateless: utilizada em conjunto com a autoconfiguração para atribuir as demais informações necessárias para que o computador navegue na Internet ou utilize determinados serviços de rede, tais como endereço do servidor DNS ou de um servidor TFTP para telefonia IP. Portanto o IP e gateway são definidos pelo SLAAC e o DNS, por exemplo, é passado pelo DHCP stateless. Nesse caso é preciso que o flag "other-config" esteja ativo para que o cliente saiba que deve pegar outras informações via DHCP stateless.





Configuração via DHCP statefull:é aa função umo servidor seja, que guarda o estado da atribuição, mesmadeque conceito DHCP para ostatefull, IPv4, ouou seja, o IPv6 do host, assim como sua máscara, roteador padrão e servidor DNS serão passados pelo servidor DHCPv6, por isso ele consegue guardar as informações sobre que host tem determinado endereço IPv6 e é chamado statefull. Para que o host pegue suas informações do DHCPv6 ele deve ter o flag "managed-config" ativo. DHCPv6 Prefix Delegation (DHCPv6-PD): ao invés de alocar um único endereço IPv6 a um roteador, o DHCPv6-PD permite que um servidor DHCPv6 aloque faixas de redes IPv6 ao roteador ou cliente DHCPv6. Com isso o roteador pode alocar diferentes faixas de redes IPv6 em suas diversas interfaces.

Existem algumas diferenças entre o DHCPv6 e o DHCP convencional, tais como a utilização multicast e não unicast para troca de mensagens entre o cliente DHCPv6 e seu servidor, porém o funcionamento e mensagens básicas permanecem as mesmas. A palavra statefull e stateless significam “com informações do estado” e “sem informações de estado”. Lembre-se do CCNA que os servidores DHCP no IPv4 guardam as informações do estado dos clientes, tais como o IP que foi alocado pelo host, tempo de empréstimo desse IP, o endereço MAC do computador que alocou de determinado IP, etc., pois ele guarda o estado de cada alocação IPv4 feita por ele. ou seja, o DHCPv4 é statefull, Nos servidores DHCPv6 nós podemos ter as duas opções, stateful igual ao IPv4 ou stateless, na qual o servidor apenas fornecerá algumas informações mas não vai guardar o estado dessas informações fornecidas. Portanto, se usarmos a opção de IPv6 fixo ou DHCPv6 statefull os clientes já estarão com todas as informações necessárias para funcionar. 1.4.1 Autoconfiguração Stateless e Endereços EUI-64

Na opção autoconfiguração stateless o DHCPv6 stateless é usado em conjunto porque a autoconfiguração não passa todas as informações necessárias para um computador, ela ajuda apenas a montar o endereço IP e ter seu roteador padrão, sendo que o DNS e demais informações serão passadas pelo DHCPv6. Portando, um computador com autoconfiguração utilizará os seguintes passos para atribuição de suas informações de rede: 1. Através de mensagens do protocolo NDP (substituto do ARP no IPv6) solicita informações do roteador local (utilizando mensagens de router solicitation - RS e router advertisement - RA), prefixo de rede com a máscara (tamanho do prefixo) e o endereço do seu roteador padrão; 2. Utilizando o EUI-64 fará um cálculo para determinar a porção de host e com o prefixo passado pelo roteador montará seu endereço IPv6 Unicast Global; 3. Através do DHCPv6 stateless recebe o endereço IP do servidor DNS e demais serviços necessários.


  

 






  




Página 215  



 


O padrão EUI-64 é utilizado para formação do endereço Global Unicast tanto na autoconfiguração stateless como na configuração estática com EUI-64, além disso, ele também é utilizado para determinar o endereço de Link Local (será estudado posteriormente). O objetivo básico do EUI-64 é utilizar o endereço MAC da placa de rede do host para formar um Interface ID (porção de host do IPv6) de 64 bits. Para isso os seguintes passos são seguidos no processo: 1. Como o endereço MAC tem 48 bits e já é escrito em hexadecimal para completar os 64 bits faltam 16 bits, no ou seja, algarismos em algarismos hexadecimal. 2. Isto é feito apenas com a inserção meio quatro do endereço MAC dos 0xfffe (FF-FE). 3. O sétimo bit mais a esquerda (chamado de bit U/L – Universal/Local) do endereço MAC deve ser invertido, isto é, se for 1 será alterado para 0 e se for 0 será alterado para 1. 4. Está formado o Host ID de 64 bits. Veja a figura abaixo, note que no meio do endereço MAC foi inserida a palavra em hexadecimal 0xfffe e como os dois primeiros algarismos do MAC são 00, que em binário é 00000000, se trocarmos o sétimo bit ele fica 00000010 ou 02 em hexadecimal, pois a cada 4 bits temos um algarismo em hexadecimal.

Lembre-se que se recebermos um prefixo /64 podemos perfeitamente utilizar o EUI-64 para formar o Interface ID e assim termos o endereço Global do computador (endereço de Internet), além do link local. Esse processo se chama autoconfiguração do IPv6. Por exemplo, um computador que tem como endereço MAC 001e.130b.1aee e recebe um prefixo do seu roteador 2001::/64 terá os seguintes endereços: Link Local: FE80::21E:13FF:FE0B:1AEE -> prefixo FE80::/64 Global Unicast: 2001::21E:13FF:FE0B:1AEE -> Prefixo 2001::/64  

Como chegamos nesses valores acima? Note que o MAC é 001e.130b.1aee, portanto vamos achar o sétimo bit e fazer a inversão: 00 -> 00000000 -> 00000010 -> 02. Agora vamos inserir o FF-FE no meio e formar o EUI 64: 021e:13ff:fe0b:1aee.


  

 






  




Página 216  



 


1.5 Endereços IPv6 de Unicast Local O IPv6 possui alguns tipos de endereços de unicast local: 









Link Local: prefixo FE80::/64 e ID de host formado pelo EUI-64. Utilizado para enviar e receber mensagens em uma única sub-rede. São endereços utilizados para envio de mensagens do NDP e como próximo salto em rotas do IPv6. Veja a figura abaixo.

Unique Local: prefixo FD00::/8 é para uso em redes privativas, assim como a RFC 1918 do IPv4. Veja a figura abaixo, onde o ID da interface pode ser configurado de maneira estática ou com EUI-64.

Site local: prefixo FECO::/10, não será utilizado pois tinha função parecida com o endereço unique local e foi retirado de uso Endereço de Loopback: apenas um endereço “::1/128” e tem a mesma função da loopback o IPv4 (127.0.0.1) Não especificado (Unspecified): também apenas um endereço “::/128” utilizado quando uma interface IPv6 não possui endereço definido.

Portanto, uma interface IPv6 pode ter vários tipos de endereços configurados simultaneamente, sendo que no mínimo ela terá o endereço de loopback e seu endereço de link local, pois eles não dependem de nenhuma configuração para serem atribuídos. 1.6 Endereços de Multicast A faixa de endereços de multicast pega o prefixo FF::/8. Veja a figura seguinte com o formato do endereço.


  

 






  




Página 217  



 


Os flags são definidos da seguinte forma: 







O primeiro bit mais a esquerda é reservado e deve ser marcado com 0; Flag R: Se o valor for 1, indica que o endereço multicast “transporta” o endereço de um Ponto de Encontro (Rendezvous Point). Se o valor for 0, indica que não há um endereço de Ponto de Encontro embutido; Flag P: Se o valor for 1, indica que o endereço multicast é baseado em um prefixo de rede. Se o valor for 0, indica que o endereço não é baseado em um prefixo de rede; Flag T: Se o IANA. valor for indica o endereço multicastmulticast é permanente, ou seja, é atribuído pela Se o0,valor for que 1, indica que o endereço não é permanente, ou seja, é atribuído dinamicamente.

Já os quatro bits que representam o escopo do endereço multicast (Scope), são utilizados para delimitar a área de abrangência de um grupo multicast. Os valores atribuídos a esse campo são os seguintes: 1 – abrange apenas a interface local 2 – abrange os nós de um enlace 3 – abrange os nós de uma sub-rede 4 – abrange a menor área que pode ser configurada manualmente Abaixo seguem alguns outros endereços de multicast reservados: FF02::1 -> todos os Hosts no Link, como se fosse um broadcast na sub-rede; FF02::2 -> todos os Roteadores no Link; FF02::5 e FF02::6 -> mensagens do OSPFv3; FF02::9 -> mensagens de atualização do RIPng; FF02::A -> mensagens do EIGRPv6; FF02::1:2 -> todos os Relay-Agents DHCP; FF05::1:3 -> todos os Servidores DHCP; FF05::101 -> todos os Servidores NTP. 1.7 Outros Endereços IPv6 de Uso Especial Segue abaixo uma lista de outras faixas de endereços IPv6 de uso especial:  



 



::/0 -> Rota padrão. ::/96 -> Reservado para compatibilidade com IPv4, porém seu uso foi descontinuado. Seria um endereço como ::192.168.1.1 ou em hexadecimal ::C0A8:0101. O motivo do /96 é que como temos 32 bits no IPv4 dá um total de “96+32=128 bits”. ::FFFF:0:0/96 -> Endereço IPv4 mapeado como IPv6. É aplicado em técnicas de transição para que hosts IPv6 e IPv4 se comuniquem, exemplo,->::FFFF:192.168.1.1 ou em hexadecimal ::FFFF:C0A8:0101 (método para por conversão ::FFFF:11000000. 10101000.00000001.00000001 = ::FFFF: 1100000010101000:0000000100000001 = ::FFFF:C0A8:0101). 2001::/32 -> prefixo utilizado no mecanismo de transição teredo. 2001:DB8::/32 -> prefixo utilizado para representar endereços IPv6 em textos e documentações. 2002::/16 -> Prefixo utilizado no mecanismo de transição 6to4.


  

 






  




Página 218  



 


1.8 ICMPv6 e seus Recursos O ICMP do IPv6 recebe o nome de ICMPv6 e acaba englobando vários processos que no IPv4 são realizados pelo ARP, pois no IPv6 não temos mais broadcast mas ainda precisamos dos endereços MAC de srcem e destino para montar um quadro de camada 2 na comunicação em rede local, por exemplo. Os demais de recursos de reporte de erros e testes continuam existindo, tais como ping, tracert, etc. Vamos agora ver alguns dos processos que utilizam mensagens do ICMPv6. 1.8.1 Neighbor Discovery Protocol (NDP)

Assim como a comunicação do IPv4, para enviar um pacote IPv6 para um vizinho o computador precisa saber o endereço MAC de srcem (dele mesmo, portanto já sabe) e o endereço MAC do destino (computador remoto), o que é função do ARP na versão 4 do protocolo IP. Já no IPv6 o processo é realizado através da troca de mensagens ICMPv6 e funciona com um host enviando uma mensagem Neighbor Solicitation (NS) informando no campo de Dados seu endereço MAC e também solicitando o endereço MAC do vizinho. Ao receber a mensagem, o vizinho a responde enviando uma mensagem Neighbor Advertisement (NA) informando seu endereço MAC. Após essa troca de mensagens o computador de srcem tem condições de iniciar a troca de pacotes com o computador de destino. Veja a figura abaixo.

O endereço de destino que o PC1 utiliza na mensagem de NS não é o IPv6 do vizinho e sim um endereço especial chamado “solicited node multicast address”, o qual é composto pelo prefixo FF02::1:FF:0/104 e os últimos 24 bits são formados com os últimos 24 bits do endereço IPv6 de destino, ou seja, para quem está sendo mandada a mensagem de NS. Por exemplo, veja como ficaria o “solicited node multicast address” dado o endereço IPv6 do roteador R1 de exemplo:  

Endereço IPv6 de R1: 2340:1111:AAAA:1:213:19FF:FE7B:5004 Solicited node address de R1: FF02::1:FF:7B:5004


  

 






  




Página 219  



 


Essa convenção permite que os roteadores utilizem como endereço MAC de multicast o início em hexa 01005E, com a adição de um zero mais 23 bits do endereço IPv6 do dispositivo remoto (o que está recebendo a mensagem de NS), assim quando o host receber esse endereço de multicast ele sabe que deverá responder à solicitação. Para o exemplo acima o MAC de multicast seria 0100.5E7B.5004. Um processo muito parecido é utilizado para localizar roteadores vizinhos dentro do mesmo enlace bem como aprender prefixos e parâmetros relacionas à autoconfiguração de endereço. O processo se inicia com o envio de um Router Solicitation (RS) pelo host. O roteador local responde uma mensagem de Router Advertisement (RA) para o endereço multicast nodes comcom as informações configuradas nele. Mais para frente você aprenderá mais sobre a allautoconfiguração e o DHCPv6, os quais utilizam o processo de descoberta de roteadores no seu funcionamento.

É importante lembrar que o IPv6 não usa broadcast, por isso a mensagem de RS é envida para o endereço de multicast de destino FF02::2 que representa todos os roteadores na rede local, já a resposta do roteador é enviada para o endereço de multicast FF02::1 que representa todos os hosts na rede local, ou seja, essas mensagens ficam confinadas à rede local. Resumindo: 1. O processo de solicitação de vizinhos (NS/NA) substituem o ARP do IPv4,, ou seja, são utilizados para descobrir o MAC dos vizinhos. 2. O processo de solicitação de roteadores (RS/RA) são utilizados para descobrir o prefixo de rede (o prefixo de determinado link LAN) e seu tempo de vida (lifetime). 1.8.2 Descoberta de IPs Duplicados (DAD)

No IPv4 a detecção de IPv6 IPs duplicados é feitaé pelo protocolo ARP utilizando ARPs"Neighbor gratuitos (Gratuitous ARP). No essa detecção realizada utilizando mensagens Solicitation" para o endereço "All-nodes Multicast" da seguinte maneira: 1. O host envia seu endereço IPv6 em uma mensagem "Neighbor Solicitation" e aguarda uma resposta. 2. Caso haja uma resposta ele sabe que o IPv6 que ele utiliza está duplicado. 3. Se não houver resposta em um tempo determinado (aging time) o IPv6 pode ser utilizado.


  

 






  




Página 220  



 


1.8.3 Inverse Neighbor Discovery

O Inverse Neighbor Discovery (IND) foi introduzido no IPv6 para resolver o problema do mapeamento inverso no frame-relay. Lembre-se que o frame-relay conhece primeiro o endereço de camada 2 e precisa mapear um endereço de camada 3 remoto para que haja comunicação. No IPv4 isso é feito com o inverse ARP. O IND define as mensagens de Inverse NS (INS) e Inverse NA (INA), sendo que a mensagem de INS lista o endereço de camada 2 do vizinho (DLCI para o Frame Relay) e pergunta qual o endereço IPv6 daquele dispositivo. Na mensagem de INS vamos encontrar: 







Endereço IPv6 de srcem do próprio roteador que está enviando a INS Endereço IPv6 de destino FF02::1 (all IPv6 hosts multicast) Endereço de camada 2 (DLCI) Solicitação do IPv6 remoto

Assim como no IPv4, o comando “show frame-relay map” mostra os endereços aprendidos via o processo do IND. 2 Configurações Básicas do IPv6 – Ativação e Interfaces Para configurar o IPv6 devemos começar habilitando o protocolo com o comando em modo de configuração global “ipv6 unicast-routing”. R4#conf t Enter configuration commands, one per line.

End with CNTL/Z.

R4(config)#ipv6 unicast-routing R4(config)#

O próximo passo é configurar os endereços globais de Unicast, pois por padrão, os endereços de link-local são automaticamente configurados via EUI-64. Lembrem que podemos configurar os endereços globais das seguintes maneiras: 1. 2. 3. 4. 5.

Configuração estática: “ipv6 address end-ipv6/tamanho-do-prefixo” Configuração estática com EUI-64: “ipv6 address prefixo-de-rede/64 eui-64” Autoconfiguração stateless: “ipv6 address autoconfig” DHCP statefull: “ipv6 address dhcp” Anycast: “ipv6 address end-ipv6/tamanho-do-prefixo anycast”

Nas opções 1 e 2 o servidor DNS e roteador padrão deverão ser configurados manualmente. Na autoconfiguração é preciso um DHCP stateless ou configuração estática do DNS, pois o roteador padrão é passado via protocolo NDP (mensagens de RS e RA). Na opção DHCP statefull tudo é passado pelo servidor DHCP. Veja abaixo de configuração opções a 3 que são foco docom CCNP Nesse exemplo deexemplos configuração a interfacedasfast 0/0 1 será configurado o ROUTE. IPv6 estático 2000:100::1/112, já a interface fast 0/1 será configurada via EUI-64 com o prefixo 2001:100::/64 e a interface fast 2/0 será configurada via autoconfiguração. R1(config)#int f0/0 R1(config-if)#ipv6 address 2000:100::1/112 ? anycast Configure as an anycast eui-64 Use eui-64 interface identifier R1(config-if)#ipv6 address 2000:100::1/112


  

 






  




Página 221  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1(config-if)#int f0/1 R1(config-if)#ipv6 address 2001:100::/64 eui-64 R1(config-if)#int f2/0 R1(config-if)#ipv6 address autoconfig R1(config-if)#end R1#

Com o comando “show ipv6 interface brief” temos um resumo das interfaces IPv6 e os endereços configurados, veja abaixo a saída para o R1 configurado anteriormente. R1#sho ipv6 interface brief FastEthernet0/0 [up/up] FE80::C001:33FF:FE7C:0 2000:100::1 FastEthernet0/1 [up/up] FE80::C001:33FF:FE7C:1 2001:100::C001:33FF:FE7C:1 FastEthernet2/0 [up/up] FE80::C001:33FF:FE7C:20 2002:100::C001:33FF:FE7C:20

-> endereço de link-local via EUI-64 -> endereço global unicast estático -> link local e global usam EUI-64 e tem -> mesmo interface ID “C001:33FF:FE7C:1”

-> na autoconfig também é utilizado o -> EUI-64 para definir o interface ID

Com o comando “show ipv6 interface fast 0/0”, por exemplo, você pode ver as opções completas referentes ao IPv6, veja exemplo abaixo da saída para as interfaces f0/0 e f2/0. R1#sho ipv6 int f0/0 -> Interface usando configuração estática FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C001:33FF:FE7C:0 -> link local via EUI-64 utilizando o MAC da interface No Virtual link-local address(es): Global unicast address(es): 2000:100::1, subnet is 2000:100::/112 -> end global e sub-rede Joined group address(es): -> endereços de multicast FF02::1 FF02::2 FF02::1:FF00:1 FF02::1:FF7C:0 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 -> detecção de endereços duplicados está habilitada e rodou uma vez (attempts) ND reachable time is 30000 milliseconds -> tempo de vida do protocolo de descoberta de hosts vizinhos ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds ND advertised default router preference is Medium Hosts use stateless autoconfig for addresses. R1#


  

 






  




Página 222  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1#sho ipv6 int fast 2/0 -> interface usando autoconfiguration FastEthernet2/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C001:33FF:FE7C:20 No Virtual link-local address(es): Global unicast address(es): 2002:100::C001:33FF:FE7C:20, subnet is 2002:100::/64 [EUI/CAL/PRE] valid lifetime 2591872 preferred lifetime 604672 Joined group address(es): FF02::1 FF02::2 FF02::1:FF7C:20 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds ND advertised default router preference is Medium Hosts use stateless autoconfig for addresses.

Quando utilizamos a autoconfiguração note na saída do comando “show ipv6 int f2/0” que embaixo do IPv6 global aparece uma linha destacada com um “lifetime” e “preferred lifetime” que são os timers do tempo de vida do prefixo recebido via NDP pelo roteador vizinho. Como o IPv6 suporta a reconfiguração da rede (network renumbering), quando é preciso trocar um prefixo antigo por um novo é possível anunciar a rede antiga com um lifetime mais curto e a rede ou prefixo mais novo com um lifetime mais longo, para que haja a troca do antigo pelo novo. Outra opção é expirar um determinado prefixo em determinada data e hora. Isto é útil para a reconfiguração de prefixos em redes de grande porte com diversos hosts na mesma subrede. Outro detalhe sobre o uso da autoconfiguração stateless ou estática é que o roteador ou dispositivo local que recebe um prefixo utiliza o DAD (descoberta de IPs duplicados) para verificar se não existe outro IP igual na rede. Note que em ambas as saídas temos a linha “ ND DAD is enabled, number of DAD attempts: 1 ”, ou seja, o DAD está ativo e foi rodado 1 vez (number of DAD attempts: 1). Para as redes com configuração estática não existe life-time ou tempo de vida para os prefixos, pois eles foram definidos pelo administrador e não tem sentido expirar! Para verificar a tabela de vizinhanças gerada pelo NDP você pode utilizar o comando show ipv6 neighbors que é semelhante a saída do show arp do IPv4, porém aqui relacionando o endereço IPv6 ao MAC do vizinho. Veja abaixo. R1#show ipv6 neighbors IPv6 Address 2000::D0E8:BFF2:67B5:7338 2000::F425:F9B5:A425:A531 FE80::161A:A3FF:FE67:27F1 FE80::26B6:FDFF:FE06:BE40 FE80::C218:85FF:FEE5:ECBF FE80::D448:D6BC:8EF6:F347 FE80::F425:F9B5:A425:A531

Age 0 5 51 0 52 2 3

Link-layer Addr 24b6.fd06.be40 24b6.fd06.dc17 141a.a367.27f1 24b6.fd06.be40 c018.85e5.ecbf 90e6.bad0.3f0d 24b6.fd06.dc17

State STALE STALE STALE STALE STALE STALE STALE

Interface Gi0/0 Gi0/0 Gi0/0 Gi0/0 Gi0/0 Gi0/0 Gi0/0

R1#


  

 






  




Página 223  



 


2.1 Testando a Conectividade das Interfaces IPv6 Como já citado, o ICMP do IPv4 foi trocado pelo protocolo ICMPv6 no IPv6, porém recursos como ping e trace continuam presentes para realizar os testes de conectividade entre hosts e interfaces IPv6. A diferença é que em determinadas versões de IOS será solicitada a interface de saída escrita de maneira completa e com o número da interface sem espaço, veja dois exemplos abaixo. dltec#ping fe80::1 Output Interface: fastethernet0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::1, timeout is 2 seconds: Packet sent with a source address of FE80::1%FastEthernet0/0 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms

Assim como para o IPv4 existem opções que você pode utilizar com o comando ping, veja um exemplo abaixo do ping com uma repetição de 100 vezes. dltec#ping data repeat size source timeout verbose

2000:100::1 ? specify data pattern specify repeat count specify datagram size specify source address or name specify timeout interval verbose output

dltec#ping fe80::1 fastethernet0/0 repeat 100 Output Interface: Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to FE80::1, timeout is 2 seconds: Packet sent with a source address of FE80::1%FastEthernet0/0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 0/0/4 ms

Podemos também utilizar o ping estendido digitando apenas “ping”, dando um “enter” e no momento de escolher o protocolo digite “ipv6”, veja exemplo abaixo. dltec#ping Protocol [ip]: ipv6 Target IPv6 address: fe80::1 Repeat count [5]: 100 Datagram size [100]: 1000 Timeout in seconds [2]: Extended commands? [no]: y Source address or interface: fastethernet0/0 UDP protocol? [no]: Verbose? [no]: Precedence [0]: DSCP [0]: Include hop by hop option? [no]: y Include destination option? [no]: Sweep range of sizes? [no]: Output Interface: fastethernet0/0 Type escape sequence to abort. Sending 100, 1000-byte ICMP Echos to FE80::1, timeout is 2 seconds:


  

 






  




Página 224  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br Packet sent with a source address of FE80::1%FastEthernet0/0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 0/0/4 ms dltec#

Antes de iniciar a configuração de protocolo de roteamento ou recursos mais avançados em seus labs lembre sempre de primeiro verificar a conectividade das interfaces através do ping. Teste tanto com os IPs globais como locais, iniciando sempre pelo de link-local, assim se houver um problema de camada 2 ou 3 simples você resolverá antes da ativação do roteamento e pode evitar tempo perdido tentando resolver um problema que não existe! 2.2 Tipos de Redes Suportadas pelo IPv6 Os tipos redes suportadas pelo IPV6 são multiacesso com broadcast (LAN da família Ethernet) ou sem broadcast (NBMA – Frame-relay), ponto a ponto (point-to-point) e ponto a multiponto (point-to-multipoint). A configuração do endereço IPv6 é a mesma em todos os tipos de interface, porém no caso do frame-relay existem necessidades específicas em redes multiponto devido ao split-horizon imposto pela topologia NBMA. Vamos a seguir ver as principais características de cada um dos tipos de rede e dicas de configuração. 2.2.1 Redes Multiacesso com Broadcast

Em dispositivos com links multiacesso (broadcast multiaccess links) como o Ethernet precisam construir uma tabela mapeando o endereço de Layer 3 com o endereço de Layer 2 do equipamento remoto que ele deseja se comunicar (como é feito pelo ARP no IPv4). Como já estudamos, ao invés do ARP, o IPv6 utiliza o protocolo de descoberta de vizinhos (NDP ou Neighbor Discovery) do ICMPv6 para esse fim, pois não existe mais broadcast no IPv6. Lembre que a mensagem de Neighbor Solicitation (NS) é enviada para o endereço de multicast com prefixo FE02 e o vizinho responde com uma mensagem de Neighbor Advertisement (NA) contendo seu endereço MAC. Assim como para o ARP, esse mapeamento tem um tempo de vida chamado “reachable time”, dessa forma uma mensagem NS pode ser enviada perio dicamente para verificar se o vizinho ainda está ao alcance. O endereço de srcem utilizado pelo solicitante na mensagem de solicitação NS é o seu endereço de link local, o qual é por padrão formado com o prefixo FE80::/64 mais um interface ID de 64 bits através do EUI-64. É possível definir esse endereço de link local através do comando “ipv6 address endereço-link-local” dentro do modo de configuração de interface, lembrando que esse endereço deve ser único dentro da mesma LAN. É possível também inserir uma entrada estática na tabela do Neighbor Discovery com o comando “ipv6 neighbor endereço-ipv6 tipo-de-interface número-da-interface MAC-do-vizinho”, assim essa entrada estática não sofre o efeito do “aging -time” e nunca será apagada, mesmo que o vizinho não esteja alcançável. 2.2.2 Redes Ponto a Ponto

Os links seriais ponto a ponto utilizam o endereço MAC de uma interface ethernet para formar seu endereço de link local via EUI-64 ou então o endereço de link-local pode ser configurado manualmente para que ele seja mais fácil de reconhecer. Os links point-to-point não necessariamente precisam ter um endereço global de unicast (global unicast addresses ou endereço de Internet), pois os roteadores podem se comunicar somente


  

 






  




Página 225  



 


utilizando endereços de link-local, porém essas interfaces não são alcançáveis por roteadores ou dispositivos IPv6 remotos porque os endereços de link-local não são roteáveis e tem apenas significância local. Uma subinterface frame-relay point-to-point se comporta como um link serial ponto a ponto HDLC ou PPP, com a diferença de ser configurado em uma subinterface e precisar da definição do DLCI com o comando “frame-relay interface-dlci dlci”. 2.2.3 Redes Ponto a Multiponto NBMA

Em redes multiponto tais como é as do Frame Relay configuradas diretamente na interface(point-to-multipoint), ou com suninterface multiponto, necessário mapear o endereço IPv6 de destino (vizinho) com o DLCI de saída, assim como era feito para o IPv4. Como o IPv6 pode ter vários endereços em uma única interface é recomendado também mapear o endereço de link-local remoto ao DLCI de saída devido a ele ser usado como próximo salto pelos protocolos de roteamento. O comando para fazer o mapeamento é o “frame -relay map ipv6 ipv6-destination-address out-dlci-number broadcast”. Veja abaixo um exemplo do comando utilizado em uma interface frame-relay (o mesmo vale para subinterfaces multiponto) e referente a topologia da figura mostrada a seguir. interface Serial0/1/0 ip address 192.168.50.1 255.255.255.252 encapsulation frame-relay ipv6 address FE80::1 link-local ipv6 address 2000:12::1/64 clock rate 2000000 frame-relay map ipv6 2000:12::2 100 frame-relay map ipv6 FE80::2 100 broadcast

A opção broadcast no final do mapeamento do link-local serve tanto para broadcast quanto para multicast, portanto como o endereço de link local é utilizado na descoberta de vizinhos e verificação (NDP) de IPs duplicados (DAD) a opção “broadcast” permite que as mensagens multicast sejam passadas pelo PVC, pois não existe broadcast mais no IPv6. Com o comando “show frame-relay map” podemos analisar o mapeamento estático do frame-relay. R1#sho frame-relay map Serial0/1/0 (down): ipv6 2000:12::2 dlci 100(0x64,0x1840), static, CISCO,ipv6 status defined, Serial0/1/0 (down): FE80::2 dlci inactive 100(0x64,0x1840), static, broadcast, CISCO, status defined, inactive

Uma observação interessante é que o link-local foi configurado também estaticamente para que a configuração do mapeamento do frame-relay seja mais simples. Caso contrário, precisaríamos primeiro entrar com o comando “show ip int brief”, verificar o IPv6 link-local determinado pelo EUI-64 e aí sim configurar o comando. Dessa forma, com a definição estática do link local em seriais, várias configurações que usam o link-local como referência são facilitadas.


  

 






  




Página 226  



 


2.3 MTU Path Discovery no IPv6 - Flow Label Como já estudamos no capítulo-2 desse curso, assim como para o IPv4 o IPv6 também permite a descoberta do MTU de um caminho para evitar fragmentação de pacotes, ajudando a rede funcionar de maneira mais eficiente e diminuindo a sobrecarga nos roteadores do caminho. Porém no IPv6 a fragmentação e o MTU Path Discovery ou descoberta do MTU do caminho é feito pela srcem dos pacotes e não mais pelos roteadores da rede. Portanto, o host que está srcinando os pacotes IPv6 que cuida de ambas as operações. Com o IPv6 path MTU discovery o dispositivo de srcem do tráfego IPv6 guarda um cachê com os valores de MTU recebidos nas mensagens de "toobig" recebidas através do ICMPv6. Lembrese que o ICMPv6 é utilizado para descobrir o MTU do caminho. Outro detalhe é que o host de srcem mantém e atualiza apenas os destinos na tabela que ele mesmo srcinou tráfego, ou seja, apenas para caminhos ou destinos que ele enviou pacote e testou o MTU e aceita mensagens IPv6 de "toobig" novas se o destino bate com um dos que ele tem mapeado em seu cachê de MTU. Se um atacante descobrir os destinos com quem esse host está normalmente conversando ele pode enviar pacotes com mensagens falsas de ICMPv6 "toobig" falsas e injetar suas informações no cachê de MTU do host. Com isso o host vai começar a fragmentar tráfego para aquele destino e ter seu desempenho afetado negativamente, sendo que muitas vezes afeta significamente o desempenho. É aí que entra em ação o recurso chamado "flow-label marking" ou marcação de fluxo, uma "etiqueta" ou "marcação" gerada para mitigar esse tipo de ataque ao IPv6. O princípio de funcionamento é simples, os pacotes srcinados localmente são marcados com uma "etiqueta de fluxo" ou "flow label" que é gerada dinamicamente e trocada a cada minuto, com isso o roteador consegue verificar se os pacotes com mensagens de ICMPv6 "toobig" realmente foram enviadas pelo srcinador do tráfego ou são respostas falsas. A não ser que o atacante consiga falsificar o fluxo todo (snoop traffic) ele não vai saber que marcação ou "flow label" deve utilizar e as mensagens falsas de "toobig" serão descartadas. A configuração é bem simples, primeiro ativamos o flow label com o comando "ipv6 flowset" em modo de configuração global depois limpamos o cachê do MTU com o comando "clear ipv6 mtu" em modo privilegiado para garantir que não haja nada suspeito gravado. Veja exemplo abaixo. R1#enable R1#configure terminal Enter configuration commands, one per line. R1(config)#ipv6 flowset R1(config)#exit

End with CNTL/Z.

R1#clear ipv6 mtu R1#

Lembre-se que no IPv6 o MTU mínimo de um link é de 1280 bytes e a Cisco recomenda um valor de MTU de 1500 bytes para os links IPv6. O "flow-label marking" ou marcação do fluxo é feita em pacotes de 1280 bytes ou maiores que foram enviados a partir das redes locais do roteador configurado. Para verificar o MTU da interface é só utilizar o comando "show ipv6 interface".


  

 






  




Página 227  



 


3 Configurando o Roteamento em Redes IPv6 O roteamento no IPv6 é bem parecido com o que temos estudado tanto no CCNA quanto aqui no CCNP ROUTE, pois os protocolos de roteamento IGP continuam com a mesma estrutura, ou seja, o RIP, EIGRP e OSPF utilizados no IPv4 foram adaptados para transportar e rotear prefixos de rede IPv6. O nome dos protocolos mudou um pouco:   

RIP passa a se chamar RIPng e tem a mesma base do RIP versão 2. EIGRP passa a ser chamado de EIGRPv6. OSPFv2 ou OSPF agora passa a ser OSPFv3 para o IPv6.

A versão do BGP não mudou, porém para ele ser capaz de rotear IPv6 são necessárias extensões ao protocolo. Em todos os protocolos IGP ou no BGP a distância administrativa e métrica continuam a mesma, porém os comandos de configuração podem variar entre o protocolo para IPv4 e IPv6, sendo que a principal mudança é o comando “network” que não é mais necessários para os protocolos IGP, pois agora o roteamento IGP no IPv6 é iniciado ou habilitado diretamente na interface. Já o BGP continua utilizando o comando network para definir as redes a serem anunciadas aos seus vizinhos. Agora vamos estudar as configurações de roteamento para o IPv6 iniciando pelas rotas estáticas. 3.1 Roteamento Estático Também é possível utilizar rotas estáticas e/ou padrões para o IPv6 com o comando “ipv6 route”. A sintaxe do comando segue abaixo e tem algumas opções a mais: Router(config)#ipv6 route ipv6-prefix/prefix-length {ipv6-address | interfacetype interface-number [ipv6-address]} [administrative-distance] [administrativemulticast-distance unicast multicast] [tag tag]

Veja um exemplo abaixo onde será criada a rota para a rede 2000::/64 através da fast0/0 com AD 1 e marcada com a tag 2: dltec(config)#ipv6 route 2000::/64 fastEthernet 0/0

1 tag 2

Ao invés de uma interface podemos também definir a rota através do IPv6 de próximo salto. Também é possível criar rotas para descarte de pacotes através da Null0 ou interfaces nulas, úteis em protocolos de roteamento quando configurados com sumarização de rotas, assim como rotas flutuantes utilizando diferentes valores de AD (Administrative Distance ou Distância Administrativa), lembrando que: “quanto menor o AD melhor será a rota”. Veja abaixo um exemplo de rota apontando para a Null0 e de rotas flutuantes. dltec(config)#ipv6 route 2001:DB8:42:1::/64 null0 dltec(config)#ipv6 route 2001:DB8:1::/64 fast 0/0 2001:DB8:1::1 dltec(config)#ipv6 route 2001:DB8:1::/64 fast 0/1 2000:DB8:1::1 200

Note que nas rotas criadas para a rede 2001:DB8:1::/64 foi utilizada uma interface de saída como referência e também um IPv6, isso se chama “Fully Specified Static Routes”, assim a rota será válida somente se a f0/0 ou a f0/1 estiverem UP e também trazem qual o IP de próximo salto a ser utilizado, pois em redes multiacesso é necessário definir qual o IP de quem receberá os pacotes para roteá-los para fora da rede.


  

 






  




Página 228  



 


Com o comando “show ipv6 route” podemos visualizar a tabela de roteamento IPv6. dltec#sho ipv6 route IPv6 Routing Table - default - 4 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary D - EIGRP, EX - EIGRP external, ND - Neighbor Discovery S 2000::/64 [1/0], tag 2 via FastEthernet0/0, directly connected S

2001:DB8:1::/64 [1/0] via 2001:DB8:1::1, FastEthernet0/0 S 2001:DB8:42:1::/64 [1/0] via Null0, directly connected L FF00::/8 [0/0] via Null0, receive dltec#

Note que a rota para 2001:DB8:1::/64 através da fast 0/1 não estará presente, pois ela tem distância administrativa maior. As regras de distância administrativa no IPv6 são iguais as que estudamos para o IPv4, ou seja, rotas estáticas que apontam para uma interface de saída tem AD zero (como se fosse diretamente conectada) e rotas que apontam para o próximo salto tem AD 1 por padrão. Uma diferença entre a tabela de roteamento IPv4 e IPv6 é a inclusão na tabela do IPv6 de uma rota local identificada como “L” e para endereços globais são anunciadas com um comprimeto de prefixo /128, ou seja, um endereço de host, assim como um /32 do IPv4. A rota padrão podefica sera configurada forma semelhante IPv4, porém no IPv6 a rota padrão é ::/0, veja como rota padrão de considerando que ela ao tem próximo salto o endereço IPv6 2000:100::1. dltec(config)#ipv6 route ::/0 2000:100::1

3.2 Configurando o RIPng O “RIP next generation” (RIPng) é o RIP versão 2 adaptado para o protocolo IPv6 e definido na RFC 2080. Portanto, assim como o RIPv2 do IP versão 4, o RIPng é um protocolo de roteamento vetor de distância (distance vector) que utiliza como métrica a contagem de saltos (hop count), tem limite máximo de saltos igual a 15 e utiliza o split-horizon (assim como as demais técnicas do RIP v2) para evitar loops de roteamento. Além disso, seguem mais características comuns entre o RIPng e RIPv2:   

Utiliza o UDP na porta 521 como transporte em camada 4 (o RIPv2 é na porta 520). Tem 120.30 segundos através do endereço de multicas FF02::9. Enviadistância updates administrativa periódicos a cada (para o RIP v2 o IPv4 é 224.0.0.9.)

O endereço IP de srcem das mensagens de update do RIPng não é o global unicast e sim seu endereço de link-local da interface de saída (outbound) dos updates. Essa informação é importante para configuração de ACLs, comando “neighbor” e filtros de atualizações.


  

 






  




Página 229  



 


Principais diferenças entre o RIPv2 e o RIPng: 





O RIPng suporta múltiplos processos simultaneamente identificados por um número ou identificação de processo. O RIPng é inicializado em modo de configuração global, porém não utiliza mais o comando “network”, pois ele é ativado dentro da própria interface que fará parte do processo de roteamento. A autenticação do RIPng utiliza “IPv6 AH/ESP”, ou seja, a facilidade de autenticação e criptografia já presente no cabeçalho do IPv6 (o mesmo vale para o EIGRPv6 e OSPFv3).

A configuração do RIPng pode ser iniciada diretamente dentro da interface, pois o roteador criará sozinho o comando de definição do RIPng em modo de configuração global, porém você deve iniciar a configuração como era o RIPv2, ou seja, ativar o protocolo RIPng em modo global e depois seleciona as interfaces que participarão do processo em modo de configuração de interface. O comando do modo de configuração global é utilizado para as configurações ou ajustes (tunning) que precisam ser feitos no RIPng, tais como desabilitar o split-horizon ou criar listas de distribuição conforme mostrado no exemplo abaixo. Depois nas interfaces ativamos o RIPng utilizando o mesmo nome criado no comando "ipv6 router rip", nesse exemplo utilizamos o nomento "Ex-1" para o processo do RIPng. dltec(config)#ipv6 router rip Ex-1 dltec(config-rtr)#no split-horizon dltec(config-rtr)#redistribute static dltec(config-rtr)#exit dltec(config)#int f0/0 dltec(config-if)#ipv6 rip Ex-1 enable dltec(config-if)#int f0/1 dltec(config-if)#ipv6 rip Ex-1 enable dltec(config-if)#

Possíveis problemas na configuração inicial do RIPng: 



Se o comando “ipv6 router rip” for rejeitado pelo roteador é porque falta o comando “ipv6 unicast-routing” em modo de configuração global. Caso a mensagem “RIPv6: No IPV6 enabled on this interface” seja mostrada quando você tentar iniciar o RIPng em uma interface, é porque provavelmente não há endereço IPv6 configurado na interface.

Para verificar se as informações estão sento trocadas e a tabela de roteamento está sendo alimentada com as rotas do RIPng podemos utilizar o comando “show ipv6 route [rip]”. Caso haja algum problema e não aparecerem rotas na tabela podemos utilizar o comando “show ipv6 protocols” (similar ao show ip prot do IPv4) e também o “debug ipv6 rip” para verificar a troca de mensagens do RIP. Veja exemplo abaixo do show ipv6 prot. dltec#show ipv6 protocols IPv6 Routing Protocol is "connected" IPv6 Routing Protocol is "ND" IPv6 Routing Protocol is "static" IPv6 Routing Protocol is "rip 1" Interfaces: FastEthernet0/0 Redistribution: None IPv6 Routing Protocol is "rip Ex-1" Interfaces:


  

 






  




Página 230  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br FastEthernet0/1 FastEthernet0/0 Redistribution: Redistributing protocol static

Além dos comandos acima podemos utilizar o “show ipv6 route prefixo-ipv6/tamanho-doprefixo” para listar informações mais específicas daquela entrada da tabela de roteamento, veja exemplo abaixo. dltec#show ipv6 route 2000::/64 Routing entry for 2000::/64 Known via "static", distance 1, metric 0 Tag 2 Redistributing via rip Ex-1 Route count is 1/1, share count 0 Routing paths: directly connected via FastEthernet0/0 Last updated 04:37:11 ago

Os comandos show que é um pouco diferente no RIPng é o “show ipv6 rip next-hops”, que mostra a lista dos IPv6 de srcem dos updates recebidos. 3.3 Configurando o EIGRPv6 Tradicional Em algumas documentações você pode ter o EIGRP para versão 6 chamado de “EIGRP for IPv6”, porém o termo EIGRPv6 também pode ser utilizado, mas alguns autores preferem não utilizar para não induzir ao leitor pensar que estamos na versão 6 do protocolo EIGRP, pois o 6 refere-se ao suporte ao IP versão 6. Outro detalhe importante antes de iniciar o conteúdo é lembrar IOS o IPv6 não era nativo, por isso é importante verificar que se oem IOSversões suportamais esseantigas recursodee também o EIGRPv6. O EIGRP para IPv6 foi baseado na versão utilizada para o IPv4 version, sendo que podemos rodar os dois no mesmo roteador e interfaces sem problemas. Características comuns do EIGRPv6 e EIGRP:  





O EIGRPv6 continua classificado como “advanced distance vector routing protocol” Utiliza a métrica composta assim como em sua versão para o IPv4 (BW, delay, reliability e load). Utiliza o mesmo mecanismo confiável para troca de atualizações de roteamento e o DUAL para manter as rotas livres de loop. Envia hellos em multicast a cada 5 segundos através do endereço de multicast FF02::A.

As mensagens utilizam o endereço de link-local como srcem (source address), o que pode fazer com que roteadores com interfaces em diferentes sub-redes formem adjacências. Assim como estudamos para o RIPng, não existe mais o comando network e o roteamento EIGRP é habilitado por interface. A diferença aqui é que você precisa definir uma identificação para o roteador ou “router ID” no formato do IPv4 (endereço de 32 bits). Esse endereço não precisa ser roteável e se não for definido o roteador vai pegar o maior IP de loopback configurado ou o maior IP de interface configurado, assim como é feito no OSPF para definir o DR/BDR, por isso é importante antes de iniciar o processo nas interfaces já ter o RID definido. Outra característica do EIGRPv6 é que o protocolo vem em um estado de shutdown, ou seja, ele vem desligado e é preciso dar um “no shut” para ativá-lo dentro do modo de configuração de roteamento. Além disso, por padrão ele tem a autossumarização desativada, pois como não existe redes classfull no IPv6 esse recurso não tem sentido no IPv6.


  

 






  




Página 231  



 


Vamos ver abaixo a configuração do EIGRPv6 com número de AS 100 e router ID 1.1.1.1 (o comando “ipv6 unicast-routing” foi inserido anteriormente, sem ele o EIGRPv6 não sobe). dltec(config)#ipv6 router eigrp 100 dltec(config-rtr)#eigrp router-id 1.1.1.1 dltec(config-rtr)#no shutdown

Agora vamos ativar o roteamento EIGRP nas interfaces com endereços IPv6 configurados. dltec(config-if)#int f0/0 dltec(config-if)#ipv6 eigrp 100 dltec(config-if)#int f0/1 dltec(config-if)#ipv6 eigrp 100 dltec(config-if)#int s0/1/0 dltec(config-if)#ipv6 eigrp 100

A configuração de redes stub continua também valendo no EIGRPv6 para melhorar o desempenho, assim como as recomendações sobre a configuração da largura de banda em interfaces multiacesso sem broadcast, tais como frame-relay em interface ou em subinterface multiponto. dltec(config-rtr)#eigrp stub ? connected Do advertise connected routes leak-map Allow dynamic prefixes based on the leak-map receive-only Set receive only neighbor redistributed Do advertise redistributed routes static Do advertise static routes summary Do advertise summary routes dltec(config-rtr)#eigrp stub receive-only

Outra facilidade que continua presente é a de sumarização manual por interface, veja um exemplo do comando abaixo onde as redes que iniciam com o prefixo 2001:: serão sumarizadas via interface fast 0/0. dltec(config)#int f0/0 dltec(config-if)#ipv6 summary eigrp 100 2001::/32

Os comandos show para o EIGRPv6 são praticamente os mesmos e também podemos utilizar os comandos “show ipv6 prot”, “show ipv6 route [eigrp]” e demais comandos gerais vistos para o RIPng no troubleshooting e verificação do EIGRPv6, veja abaixo a lista. dltec#sho ipv6 eigrp ? <1-65535> Autonomous System events Events logged interfaces interfaces neighbors Neighbors sia-statistics SIA Statistics timers Timers topology Select Topology traffic Traffic Statistics


  

 






  




Página 232  



 


Abaixo segue uma lista comparando comandos show e debug do IPv4 com IPv6: Objetivo do comando

Sintaxe IPv4

Sintaxe IPv6

show ip route

show ipv6 route

show ip route eigrp

show ipv6 route eigrp

show ip route subnet mask

show ipv6 route prefix/length

show ip protocols

show ipv6 protocols

Verificar todas as rotas na tabela de roteamento Verificar apenas as rotas do EIGRP Detalhes sobre uma rota para um prefixo específico Interfaces onde o EIGRP está habilitado com sua métrica, weights, variance, redistribuição, maxpaths e admin distance Listar as srcens de roteamento Intervalo de Hello EIGRP database Debug das mensagens de update enviadas e recebidas

show ip protocols show ipv6 eigrp neighbors show ip eigrp neighbors show ip eigrp interfaces detail show ipv6 eigrp interfaces detail show ip eigrp topology [all-links] show ipv6 eigrp topology [all-links] debug ip eigrp notifications

debug ipv6 eigrp notifications

3.4 Named EIGRP - IPv4 e IPv6 O "EIGRP Named Mode" ou também chamado de "Multi-AF Mode" é uma nova maneira de se configurar o EIGRO que foi implementada no Cisco IOS versão 15.x. Suas vantagens são a simplificação da configuração do EIGRP colocando tudo em um único lugar, por exemplo, no EIGRP tradicional a configuração era feita nos modos de configuração global e de interface, ficando mais difícil de ver a correlação entre os comandos de maneira geral. Sobre o funcionamento do EIGRP nada muda e não importa se o roteador é configurado tradicionalmente ou com a nova forma que eles irão se comunicar entre si normalmente. Além disso, a configuração pode ser feita tanto para o IPv4 como para IPv6, apesar de estarmos introduzindo essa nova forma aqui no capítulo de IPv6. O named EIGRP divide as configurações em três módulos: Address-Family: esse é o modo geral de configuração do EIGRP e você entra em modo 





de configuração global. Nesse modo de vamos configurar router-ID, network stub. Podemos configurar várias famílias protocolo roteado, tais como IPv4 eeEIGRP IPv6 numa mesma instância virtual de EIGRP. Address-Family-Interface: aqui entramos com os comandos que seriam feitos nas interfaces no EIGRP tradicional. Comandos como temporizadores e passive-interface são feitos nesse modo de configuração. Address-Family-Topology: aqui entramos com comandos que afetam a topologia do EIGRP, tais como variance e redistribution.


  

 






  




Página 233  



 


3.4.1 Configurando o Named EIGRP

Podemos utilizar os cinco passos abaixo para configurar o Named EIGRP: 1. Configurar a instância virtual do "Named EIGRP" com o comando "router eigrp nomeda-virtual-instance" em modo de configuração global. 2. Especificar dentro do modo do roteador as famílias de protocolo e o número de AS com o comando "address-family { ipv4 | ipv6 } autonomous-system ASN". 3. Configure os parâmetros gerais do EIGRP no modo de configuração do Address-Family que entramos na atapa anterior. Você vai configurar nesse modo a métrica , network, stub e eigrp router-id. 4. eigrp Opcionalmente entre no modo de configuração do "Address-Family-Interface" com o comando "af-interface { default | interface-id }". A opção default vale para todas as interfaces simultaneamente, se você quer configurar os parâmetros de uma interface específica devemos entrar com o ID da interface. Os comandos desse modo incluem authentication, bandwidthpercent, hello-interval, hold-time, passive-interface e splithorizon. 5. Saindo do modo de configuração do "Address-Family-Interface" você pode entrar no modo de configuração do "Address-Family-Topology" com o comando "topology base". Os comandos desse modo incluem autosummary, maximum-paths, redistribute e variance. Veja um exemplo abaixo da configuração do EIGRP para IPv4 e IPv6 onde a instância virtual utiliza o nome DlteC. Claro que antes disso o IPv6 deve estar ativado e as configurações das interfaces como endereços IPv4 e IPv6 também. router eigrp DlteC ! address-family ipv4 unicast autonomous-system 100 ! af-interface default hello-interval 2 hold-time 10 passive-interface exit-af-interface ! af-interface FastEthernet0/0 no passive-interface exit-af-interface ! topology base variance 3 exit-af-topology network 0.0.0.0 exit-address-family ! address-family ipv6 unicast autonomous-system 200 ! topology base variance 2 exit-af-topology exit-address-family

Como você pode notar em uma mesma instância virtual do EIGRP configuramos os parâmetros para IPv4 e IPv6 sem precisar trocar como na maneira tradicional entrando no "router eigrp 100" e depois em "ipv6 router eigrp 200". Para verificar o EIGRP utilize os mesmo comandos para o IPv4 e IPv6, continua tudo igual. Apostila/E-B     

  

 






  




Página 234  



 


3.4.2 Ativando EIGRP em VRFs (IPv4 e I Pv6)

Deixamos a ativação do EIGRP em VRFs para esse capítulo devido a necessidade do uso do "address-family" que foi introduzido somente no tópico anterior. Tanto com EIGRP convencional como com o Named EIGRP precisamos do address-family na configuração do EIGRP para uso com VRFs. Veja abaixo exemplo de configuração considerando a mesma base que utilizamos no capítulo específico de VRF sem as configurações do OSPF. R1(config)#ip vrf VRF1 R1(config-vrf)#! criando a VRF chamada VRF1. R1(config-vrf)#! R1(config-vrf)#ip vrf VRF2 R1(config-vrf)#! criando a VRF chamada VRF2. R1(config-vrf)#! R1(config-vrf)#! Configurando as Interfaces R1(config-vrf)#! R1(config-vrf)#interface FastEthernet0/0 R1(config-if)# ip vrf forwarding VRF1 R1(config-if)# ip address 192.168.10.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet0/1 R1(config-if)# ip vrf forwarding VRF1 R1(config-if)# ip address 192.168.20.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet1/0 R1(config-if)# ip vrf forwarding VRF2 R1(config-if)# ip address 192.168.10.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#! R1(config-if)#interface FastEthernet1/1 R1(config-if)# ip vrf forwarding VRF2 R1(config-if)# ip address 10.10.10.1 255.255.255.0 R1(config-if)# no shut R1(config-if)#exit R1(config)#! Default gateway R1(config)#ip route vrf VRF1 0.0.0.0 0.0.0.0 192.168.10.2 R1(config)#ip route vrf VRF2 0.0.0.0 0.0.0.0 192.168.10.2

Vamos agora configurar o EIGRP tradicional como protocolo de roteamento, considerando que temos uma VPN L3 MPLS e a vizinhança é fomada entre CE e PE. Vamos utilizar o ASN 20 para a VRF1 e ASN 21 para a VRF2. R1(config)#router eigrp 100 R1(config-router)#address-family ipv4 vrf VRF1 autonomous-system 20 R1(config-router-af)#network 0.0.0.0 R1(config-router-af)#no auto-summary R1(config-router-af)#exit R1(config-router)#address-family ipv4 vrf VRF2 autonomous-system 21 R1(config-router-af)#network 0.0.0.0 R1(config-router-af)#no auto-summary R1(config-router-af)#end

Em versões de IOS mais antigas a opção "autonomous-system" que está na declaração do address-family pode ser um comando separado, porém ele tem a mesma função de definir o


  

 






  




Página 235  



 


sistema autônomo do EIGRP para aquela VRF específica. Veja exemplo a seguir como seria a configuração antiga para a VRF1. router eigrp 100 address-family ipv4 vrf VRF1 net 0.0.0.0 autonomous-system 20 no auto-summary

A seguir veja alguns comandos show para verificar o EIGRP nas VRFs. R1#sho ip eigrp vrf VRF1 neighbors EIGRP-IPv4 VR(VRF-Test) Address-Family Neighbors for AS(100) VRF(VRF1) EIGRP-IPv4 Neighbors for AS(20) VRF(VRF1) H Address Interface Hold Uptime SRTT (sec) (ms) 1 192.168.10.2 Fa0/0 14 00:04:01 162 0 192.168.20.2 Fa0/1 13 00:04:01 163 R1#sho ip eigrp vrf VRF2 neighbors EIGRP-IPv4 Neighbors for AS(21) VRF(VRF2) H Address Interface 0 10.200.1.1 R1#

Se2/0

Hold Uptime SRTT (sec) (ms) 14 00:04:02 159

RTO

Q Cnt 972 0 978 0

Seq Num 6 5

RTO

Q Seq Cnt Num 954 0 3

R1#show ip route vrf VRF1 Routing Table: VRF1 ### Saídas Omitidas ### Gateway of last resort is 192.168.10.2 to network 0.0.0.0 S* C L D

C L C L R1#

0.0.0.0/0 [1/0] via 192.168.10.2 172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 172.16.1.0/24 is directly connected, Loopback1 172.16.1.1/32 is directly connected, Loopback1 172.16.15.0/24 [90/156160] via 192.168.20.2, 00:05:06, FastEthernet0/1 [90/156160] via 192.168.10.2, 00:05:06, FastEthernet0/0 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.10.0/24 is directly connected, FastEthernet0/0 192.168.10.1/32 is directly connected, FastEthernet0/0 192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.20.0/24 is directly connected, FastEthernet0/1 192.168.20.1/32 is directly connected, FastEthernet0/1

R1#show vrf ipv4 interfaces Interface VRF Fa0/0 VRF1 Fa0/1 VRF1 Lo1 VRF1 Fa1/0 VRF2 Fa1/1 VRF2 Lo2 VRF2 Se2/0 VRF2 R1#

Protocol up up up up up up up


  

 






  

Address 192.168.10.1 192.168.20.1 172.16.1.1 192.168.10.1 10.10.10.1 10.100.1.1 10.200.1.2




Página 236  



 


3.5 Configurando o OSPFv3 O OSPFv3 está descrito na RFC 2740 e assim como o OSPFv2 é um protocolo de roteamento link-state, utiliza o algoritmo de Dijkstra (SPF ou Shortest Path First) para o cálculo da melhor rota e tem como métrica o custo da interface, portanto ele é também organizado hierarquicamente em áreas, onde a área zero é a de backbone e todas as demais áreas devem se conectar. Outras características comuns do OSPFv3 em relação ao OSPFv2:  



  



Utiliza a mesma terminologia para os dispositivos (ABR, ASBR, Backone, áreas, etc.). Utiliza os mesmos tipos de pacotes estudados para o OSPFv2, porém com algumas diferenças no LSDB e LSAs (duas renomeadas e duas novas incluídas). Forma adjacências (vizinhanças) da mesma maneira, com o protocolo de hello e passando pelos mesmos estados do OSPFv2. Eleição de DR/BDR através do maior RID (router ID) permanece a mesma. Inundação periódica a cada 30 minutos caso não hajam alterações de rede (reflooding). Suporta os mesmos recursos para otimização do OSPFv2, tais como redes Stub, NSSA, Totally-NSSA, comando para definir o tipo de interface (ipv6 ospf network tipo) e sumarização nos ABRs e ASBRs (area x range prefixo-ipv6 /tamanho-do-prefixo). Pode rodar simultaneamente com o OSPFv2, uma vez que eles usam bases de dados separadas para o cálculo do algoritmo SPF.

As principais diferenças do OSPFv3 para o OSPFv2 é o formado do endereçamento, pois agora usamos o IPv6 e os endereços para envio dos anúncios de roteamento são os de multicast FF02::5 e FF02::6, porém utilizando o endereço de link-local como srcem desses pacotes. Com isso, o OSPF para IPv6 pode acabar formando adjacências com vizinhos que não estão na mesma diferença é no processo assim como para o RIPng e sub-rede. EIGRPv6, Outra conta com os recursos nativos de do autenticação cabeçalho do que IPv6agora, para sua realização. Outra diferença interessante entre o OSPF para IPv6 e IPv4 é que na versão 3 do OSPF ele suporta múltiplas instâncias de OSPF em uma mesma interface, enquanto o OSPFv2 suporta uma única instância por link. Por exemplo, você cria o “ipv6 router ospf 1” e “ipv6 router ospf 2” e pode ter esses dois processos de OSPF rodando na mesma interface. Abaixo seguem os tipos de LSA utilizadas pelo OSPFv3. Tipo da LSA (Type) 1 2 3 4 5 6 7 8 9

Descrição Router LSA Network LSA Interarea prefix LSA for ABRs Interarea prefix LSA for ASBRs AS-external LSA Group Membership LSA Type-7 (NSSA) LSA Link LSA (Nova) Intra-Area Prefix LSA (Nova)

A configuração do OSPFv3 é bem parecida com o que fizemos até o momento para o RIPng e EIGRPv6, ou seja, o processo de roteamento e suas propriedades são criadas em modo de configuração global e a definição das interfaces que farão parte do processo de roteamento é realizada dentro das interfaces, porém para o OSPF precisaremos definir a área que cada rede irá se conectar.


  

 






  




Página 237  



 


Antes de definir as interfaces que irão participar do processo do OSPF é preciso definir um router ID de 32 bits igual a um IPv4 (decimal pontuado), pois o router ID não é criado automaticamente no caso do OSPFv3. Outro ponto importante é que o comando “ipv6 unicastrouting” e os endereços IPv6 das interfaces devem estar definidos antes da implementação dos comandos do OSPFv3, o que é mandatório para os três IGPs que estudamos para o IPv6. Resumindo, os passos da configuração são: 

Ativar o protocolo de roteamento em modo de configuração global.

 





o router ID (dentro do como modoredes de configuração roteamento – config-rtr). Definir os recursos adicionais sutb, filtros,decomando neighbor, sumarização etc. Entrar nas interfaces que irão participar do processo e ativar o OSPFv3 definindo a área que ele irá se conectar. Dentro da interface definir opcionalmente a prioridade em links multiacesso (para influenciar na eleição de DR/BDR), definir manualmente o custo, ect.

Não é preciso o “no shutdown” para ativar o OSPFv3 como fizemos para o EIGRP, porém esse comando pode ser utilizado, por exemplo, para reiniciar o processo podemos dentro do modo de configuração do roteamento dar um “shut” e “no shut”. 3.5.1 Exemplo de Configuração Tradicional do OSPFv3

Vamos abaixo a um exemplo de configuração básica do OSPFv3, onde inserimos as configurações básicas do OSPFv3 mais a sumarização das redes internas das áreas zero, 18 e 51 com prefixo de tamanho /16. O router ID a ser configurado é 3.3.3.3. As configurações exclusivas do OSPF estão em destaque. Veja a figura seguinte com a topologia onde o roteador R3-DR está inserido.

Configuração do roteador R3: R3-DR(config)#interface FastEthernet0/0 R3-DR(config-if)#ipv6 address 2000:101::1/64 R3-DR(config-if)#ipv6 ospf 1 area 0 R3-DR(config-if)#ipv6 ospf priority 100 R3-DR(config-if)#! R3-DR(config-if)#interface Serial0/0


  

 






  




Página 238  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R3-DR(config-if)#bandwidth 512 R3-DR(config-if)#ipv6 address 2002:104::1/64 R3-DR(config-if)#ipv6 ospf 1 area 18 R3-DR(config-if)#clock rate 512000 R3-DR(config-if)#! R3-DR(config-if)#interface FastEthernet0/1 R3-DR(config-if)#ipv6 address 2000:100::1/64 R3-DR(config-if)#ipv6 ospf 1 area 0 R3-DR(config-if)#ipv6 ospf priority 100 R3-DR(config-if)#! R3-DR(config-if)#interface Serial0/1 R3-DR(config-if)#bandwidth 256 R3-DR(config-if)#ipv6 address 2003:104::1/64 R3-DR(config-if)#ipv6 ospf 1 area 51 R3-DR(config-if)#clock rate 256000 R3-DR(config-if)#! R3-DR(config-if)#ipv6 router ospf 1 R3-DR(config-rtr)#router-id 3.3.3.3 R3-DR(config-rtr)#log-adjacency-changes R3-DR(config-rtr)#area 0 range 2000::/16 R3-DR(config-rtr)#area 18 range 2002::/16 R3-DR(config-rtr)#area 51 range 2003::/16

Quando fazemos a sumarização de rotas no OSPFv3 a métrica utilizada pelas rotas sumarizadas por padrão é o maior valor entre as rotas que farão parte da sumarização. Veja o exemplo da saída das rotas OSPF do roteador R3 e note a saída do roteador R5 para verificar a métrica utilizada pela sumarização. R3-DR#sho ipv6 route ospf IPv6 Routing Table - 22 entries ###Saída Omitida### O 2000::/16 [110/0] via ::, Null0 O 2002::/16 [110/0] via ::, Null0 O 2002:100::/64 [110/196] via FE80::C001:43FF:FEA0:0, O 2002:101::/64 [110/196] via FE80::C001:43FF:FEA0:0, O 2002:102::/64 [110/196] via FE80::C001:43FF:FEA0:0, O 2002:103::/64 [110/196] via FE80::C001:43FF:FEA0:0, O 2002:105::/64 [110/ 585] via FE80::C001:43FF:FEA0:0, O 2003::/16 [110/0] via ::, Null0 O 2003:100::/64 [110/391] via FE80::C002:43FF:FEA0:0, O 2003:101::/64 [110/391] via FE80::C002:43FF:FEA0:0, O 2003:102::/64 [110/391] via FE80::C002:43FF:FEA0:0, O 2003:103::/64 [110/391] via FE80::C002:43FF:FEA0:0, O 2003:105::/64 [110/585] via FE80::C002:43FF:FEA0:0,


  

 





Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/0

Serial0/1 Serial0/1 Serial0/1 Serial0/1 Serial0/1


  




Página 239  



 


A métrica mais alta entre as rotas com prefixo 2002::/16 é 585. Agora veja como R5 aprendeu o caminho para essas rotas, uma vez que foi configurada a sumarização em R3 (area 18 range 2002::/16) com a métrica 585. R5-ASBR#sho ipv6 route ospf IPv6 Routing Table - 11 entries ###Saída omitida ### O 2000:100::/64 [110/20] via FE80::C000:43FF:FEA0:0, via FE80::C003:43FF:FEA0:0, OI 2002::/16 [110/595] via FE80::C003:43FF:FEA0:0, OI 2003::/16 [110/595] via FE80::C000:43FF:FEA0:0,

FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0

Caso haja a necessidade da configuração da autenticação no OSPFv3 deve ela pode ser ativada em modo de configuração global ou por interface, veja dois exemplos abaixo: Int f0/0 ipv6 ospf 1 area 51 ipv6 ospf authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF ipv6 router ospf 1 area 51 authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF

O SPI é o Security Parameter Index e deve ser o mesmo em ambos os roteadores ou áreas, já a criptografia pode ser feita com MD5 ou SHA1 e a chave deve ser a mesma em ambos os lados. No caso do MD5 é uma palavra em hexa de 32 caracteres e com SHA1 deve ser de 40 caracteres. Com o comando “show ipv6 ospf interface” podemos ver se a interface foi configurada com criptografia ou não e seu valor de SPI. Para verificar as configurações e estado do OSPF podemos começar com o comando “show ipv6 route” e verificar se há entrada de roteamento aprendida através do OSPF. Caso os roteadores OSPF não estejam trocando rotas podemos verificar se os vizinhos foram encontrados ou estão com problemas com o comando “show ipv6 ospf neighbor” e com o comando “show ipv6 ospf interface” podemos verificar se os timers de hello e dead estão iguais em ambos os lados. Além disso, temos outros comandos show bem parecidos com os utilizados no OSPFv2, veja a tabela a seguir com os principais comandos em comparação entre o OSPFv3 e v2. Objetivo do comando

Sintaxe IPv4

Verificar as rotas aprendidas pelo OSPF Verificar o router ID, temporizadores e estatísticas dos ABRs Listar informações das srcens de roteamento

Sintaxe IPv6

show ip route ospf

show ipv6 route ospf

show ip ospf

show ipv6 ospf

show ip protocols show ip ospf neighbor

show ipv6 ospf neighbor

Verificar as interfaces que pertencem a cada show ip protocols área show ip ospf interface brief Verificar custos das interfaces do OSPF e número de vizinhos show ip interface brief Obter informações detalhadas sobre as interfaces OSPF (DR/BDR, tipo de link, autenticação, dead e hello timers, ect.) show ip ospf interface Mostrar informações resumidas sobre o banco de dados do OSPF show ip ospf database


  

 






  

show ipv6 protocols show ipv6 ospf interface brief show ipv6 interface brief

show ipv6 ospf interface show ipv6 ospf database




Página 240  



 


3.6 Redistribuição de Rotas nos IGPs IPv6 e outros Recursos A redistribuição para os IGPs no IPv6 é bem parecida com o que estudamos para o IPv4, seguem abaixo as semelhanças entre eles: 



A redistribuição utiliza rotas da tabela de roteamento e não da tabela de topologia ou banco de dados do protocolo de roteamento de srcem. Podemos utilizar route maps na redistribuição para fazer filtragem de rotas, alterar métricas ou definir a marcação (route tag).







A distância administrativa dos protocolos roteamento nomesmos IPv6 sãomecanismos as mesmas de (tanto para rotas internas como para externas), de inclusive com os alteração dos valores padrões. Utiliza os mesmos mecanismos para evitar loops de roteamento, tais como alteração da distância administrativa, route tags e filtragem de rotas. A sintaxe dos comandos é praticamente a mesma.

Existem algumas diferenças conceituais e de configuração na redistribuição dos protocolos de roteamento do IPv6 importantes de serem conhecidas, conforme abaixo: 







Qualquer correspondência feita com listas de distribuição (distribution lists) ou mapas de rotas (route maps) que usam listas de prefixo IPv6 (prefix-lists) e ACLs IPv6 fazem correspondência com base no prefixo IPv6 e no comprimento da máscara. A versão IPv6 do comando "redistribute" utiliza apenas rotas aprendidas a partir de um IGP e não redistribuem rotas diretamente conectadas nas interfaces habilitadas para esse IGP, portanto para redistribuir as rotas conectadas devemos incluir o parâmetro “include-connected” no comando. Lembre que para o IPv4 quando redistribuimos ele passa as rotas aprendidas pelo IGP e também as interfaces diretamente conectadas naquele IGP.OSPFv2 o OSPFv3 não requer o parâmetro “subnets” na redistribuição, uma Ao contrário vez que, no IPv6 não temos o conceito de redes classful e sub-redes dentro de redes classfull. A redistribuição no IPv6 ignora os endereços "locais" na tabela de roteamento, as quais são rotas /128 que representam o endereço de host da própria interface IPv6. No IPv4 não temos conceito equivalente.


  

 






  




Página 241  



 


3.6.1 Configurando a Redistribuição Sem Route-Map

A redistribuição pode ser implementada utilizando ou não route maps e é importante lembrar que serão redistribuídas as rotas aprendidas pelo IGP de srcem que estão na tabela de roteamento, porém as interfaces diretamente conectadas não são redistribuídas, por isso é importante utilizar o parâmetro “include-connected” no comando. Vamos considerar a mesma topologia utilizada anteriormente conforme abaixo.

Vamos configurar a redistribuição no roteador R5 para ensinar as rotas aprendidas no OSPFv3 para RIPng atravésnão da podemos interface fast 0/1. As regras de redistribuição valemdentro para odoIPv6, portanto esquecer demesmas definir uma métrica quando a do IPv4 redistribuição tiver como destino o RIPng e o EIGRPv6, veja os comandos abaixo. Vamos iniciar analisando as tabelas de roteamento dos roteadores R5 e R6 antes da redistribuição. R5-ASBR#sho ip *Mar 1 00:32:04.527: %SYS-5-CONFIG_I: Configured from console by console R5-ASBR#sho ipv6 route ###Saída Omitida### O 2000:100::/64 [110/20] via FE80::C000:38FF:FE74:0, FastEthernet0/0 via FE80::C003:38FF:FE74:0, FastEthernet0/0 C 2000:101::/64 [0/0] via ::, FastEthernet0/0 L 2000:101::3/128 [0/0] via ::, FastEthernet0/0 OI 2002::/16 [110/595] via FE80::C003:38FF:FE74:0, FastEthernet0/0 OI 2003::/16 [110/595] via FE80::C000:38FF:FE74:0, FastEthernet0/0 C 2004:100::/64 [0/0] via ::, FastEthernet0/1 L 2004:100::1/128 [0/0] via ::, FastEthernet0/1 L FF00::/8 [0/0] via ::, Null0 R5-ASBR#


  

 






  




Página 242  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R6#sho ipv6 route ###Saída Omitida### C 2004:100::/64 [0/0] via ::, FastEthernet0/0 L 2004:100::2/128 [0/0] via ::, FastEthernet0/0 L FF00::/8 [0/0] via ::, Null0

As rotas que R5 conhece e deve passar para R6 estão em destaque, sendo que temos uma conectada e três aprendidas via OSPFv3, veja os comandos para redistribuição abaixo. R5-ASBR(config)#ipv6 router rip 1 R5-ASBR(config-rtr)#redistribute ospf 1 include-connected metric 3

Se analisarmos a tabela de roteamento do R6 veremos que as rotas redistribuídas agora aparecem com a métrica 4, pois no comando informamos para enviar a métrica como 3 e o roteador local irá somar 1 antes de inserir em sua tabela de roteamento. R6#sho ipv6 route ###Saída Omitida### R 2000:100::/64 [120/4] via FE80::C004:1BFF:FEC8:1, R 2000:101::/64 [120/4] via FE80::C004:1BFF:FEC8:1, R 2002::/16 [120/4] via FE80::C004:1BFF:FEC8:1, R 2003::/16 [120/4] via FE80::C004:1BFF:FEC8:1, C 2004:100::/64 [0/0] via ::, FastEthernet0/0 L 2004:100::2/128 [0/0] via ::, FastEthernet0/0 L FF00::/8 [0/0] via ::, Null0

FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0

3.6.2 Configurando a Redistribuição Com Route-Map

Quando utilizamos route maps na redistribuição do IPv6 podemos alterar valores de métrica para diferentes rotas, fazer a filtragem de rotas e definir route tags para identificar algumas rotas. Com isso podemos controlar melhor a redistribuição e evitar loops de roteamento, assim como estudamos para a redistribuição no IPv4. Nesse exemplo vamos fazer a redistribuição das rotas do RIP em R5 para o OSPF, porém vamos alterar a métrica via route map para 200 e marcá-las com a tag 10. Veja a configuração abaixo. R5-ASBR(config)#ipv6 router ospf 1 R5-ASBR(config-rtr)#redistribute rip 1 route-map Ex-1 include-connected R5-ASBR(config-rtr)#! R5-ASBR(config-rtr)#ipv6 prefix-list Ex-1 permit 2004:100::/64 R5-ASBR(config)#! R5-ASBR(config)#route-map Ex-1 permit R5-ASBR(config-route-map)#match ipv6 address prefix-list Ex-1 R5-ASBR(config-route-map)#set metric 200 R5-ASBR(config-route-map)#set tag 10 R5-ASBR(config-route-map)#exit R5-ASBR(config)#! R5-ASBR(config)#ipv6 prefix-list Ex-1 permit 2004:100::/64


  

 






  




Página 243  



 


Vamos agora analisar a tabela de roteamento de R3 para verificar se a configuração teve sucesso. Varias linhas da tabela foram omitidas para facilitar a visualização, a rota aparecerá em R3 como OSPF externa do tipo 2 (O E2) com métrica 200 e marcada como 10. R3-DR#sho ipv6 route ###Saída Omitida### via ::, Serial0/1 L 2003:104::1/128 [0/0] via ::, Serial0/1 O 2003:105::/64 [110/585] via FE80::C002:38FF:FE74:0, Serial0/1 OE2 2004:100::/64 [110/200], tag 10 via FE80::C004:1BFF:FEC8:0, FastEthernet0/0 L FF00::/8 [0/0] via ::, Null0 R3-DR#


  

 






  




Página 244  



 


3.7 Configurando Roteamento IPv6 através do MP-BGP O MP-BGP ou “Multiprotocol BGP” está definido na RFC 2858, sendo composto por duas novas extensões ao protocolo BGP4. Essas extensões permitem que informações de alcançabilidade de outros protocolos sejam suportadas, tais como IPv6 (unicast e multicast), multicast para IPv4 e MPLS. Para que o IPv6 seja suportado pelo BGP4 o NEXT_HOP e NLRI (network layer reachability information) precisam entender os prefixos IPv6, o que é feito com o comando “addressfamily” em modo do roteador BGP. de O 32 router ID deve ser configurado manualmente para o de IPv6configuração e continua sendo um endereço bits, como um endereço IPv4. Os vizinhos no comando “neighbor” devem utilizar o endereço global unicast, depois precisam ser ativados dentro do modo de configuração do “address family”, assim como quaisquer políticas referentes à extensão do mBGP. As rotas IPv6 a serem anunciadas pelo BGP são definidas pelo comando “network” e não nas interfaces como para os IPGs em IPv6. O MP-BGP contém elementos que não existem no BGP-4, tais como: Address Family Identifier (AFI): especifica que família de protocolo está em uso no comando "Address Family". Subsequent Address Family Identifier (SAFI): fornece informações adicionais para as famílias de endereços. Multiprotocol Reachable Network Layer Reachability Information (MP_REACH_NLRI): atributo que transporta as redes que estão alcançáveis com a informação do próximo salto incluída. Multiprotocol Unreachable Network Layer Reachability Information (MP_UNREACH_NLRI): atributo que transporta prefixos não alcançáveis e indica 









normalmente disponíveis. que uma ou mais das redes do atributo anterior não estão mais BGP Capabilities Advertisement: utilizado para dizer ao seu vizinho BGP os recursos que são suportados, normalmente utilizado na negociação da sessão BGP.

Apesar dos novos elementes o MP-BGP é capaz de formar vizinhança com o BGP-4 convencional. Isso é possível porque o roteador BGP-4 tradicional simplesmente ignora as mensagens que contém as extensões não reconhecidas.


  

 






  




Página 245  



 


3.7.1 Sequência de Configuração do MP-BGP com IPv6 sobre uma Sessão BGP IPv4

A sequência de configuração básica do MP-BGP para suportar IPv6 através de uma sessão IPv4 estabelecida segue abaixo. 1. Como sempre começar ativando o "ipv6 unicast-routing" em modo de configuração global caso ainda não tenha ativado. 2. Criar uma route map com o comando "route-map nome" especificando o endereço IPv6 da interface que vai se conectar ao vizinho com o comando "set ipv6 next-hop endipv6". 3. 4. 5.

Entrar no modo modo de de configuração configuraçãoglobal. do BGP como já estudamos com o comando "router bgp ASN" em Definir o vizinho BGP IPv4 com o comando "neighbor ipv4-do-vizinho remote-as". Com o comando "address-family ipv4" dentro do modo de configuração do BGP entre nas configurações do IPv4. 6. Entre com o comando "network rede-ipv4 [ mask máscara-subrede ]". O comando "neighbor IPv4-do-vizinho activate" é configurado automaticamente quando voê entra nas configurações address-family do IPv4. 7. Saia do modo do address-family do IPv4 digitando "exit-address-family". 8. Afora entre nas configurações do address-family do IPv6 com o comando "addressfamily ipv6". 9. Configure o comando "network rede-ipv6/prefixo" dentro do address-family IPv6. 10. Ative o vizinho IPv6 com o comando "neighbor IPv4-do-vizinho activate" ainda no mesmo modo de configuração. 11. Vincule a route map criada anteriormente no passo 2 com o endereço do vizinho com o comando "neighbor endereço-IPv4-vizinho route-map nome out". 12. Entre com os comandos "show bgp ipv6 unicast" e "show bgp ipv6 unicast summary" para verificar as configurações e o estado do BGP. Abaixo segue exemplo de configuração conforme a topologia.


  

 






  




Página 246  



 


Abaixo seguem as configurações de R1 e R2 respectivamente. R1(config)#ipv6 unicast-routing R1(config)#! R1(config)#route-map NEXT-HOPIPv6 permit 10 R1(config-route-map)#set ipv6 next-hop 2000:51::1 R1(config-route-map)#exit R1(config)#! R1(config)#router bgp 64700 R1(config-router)#neighbor 10.0.0.2 remote-as 64702 R1(config-router)#! R1(config-router)#address-family ipv4 R1(config-router-af)#network 10.0.10.0 R1(config-router-af)#exit-address-family R1(config-router)#! R1(config-router)#address-family ipv6 R1(config-router-af)#network 2000:10::/64 R1(config-router-af)#neighbor 10.0.0.2 activate R1(config-router-af)#neighbor 10.0.0.2 route-map NEXT-HOPIPv6 out R1(config-router-af)#exit-address-family R2(config)#ipv6 unicast-routing R2(config)#! R2(config)#route-map NEXT-HOPIPv6 permit 10 R2(config-route-map)#set ipv6 next-hop 2000:51::2 R2(config-route-map)#exit R2(config)#! R2(config)#router bgp 64702 R2(config-router)#neighbor 10.0.0.1 remote-as 64700 R2(config-router)#! R2(config-router)#address-family ipv4 R2(config-router-af)#network 10.20.0.0 R2(config-router-af)#exit-address-family R2(config-router)#! R2(config-router)#address-family ipv6 R2(config-router-af)#network 2000:20::/64 R2(config-router-af)#neighbor 10.0.0.1 activate R2(config-router-af)#neighbor 10.0.0.1 route-map NEXT-HOPIPv6 out R2(config-router-af)#exit-address-family R2(config-router)# *May 9 03:28:39.959: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up R2(config-router)#

Ao final da configuração de R2 a mensagem "%BGP-5-ADJCHANGE" informa que a vizinhança com 10.0.0.1 (R1) foi estabelecida.


  

 






  




Página 247  



 


Vamos agora ver alguns comandos show úteis para verificar a configuração começando pela tabela de roteamento IPv6 em R1 e R2. R1#show ipv6 route IPv6 Routing Table - default - 6 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 C L B C L L

OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP 2000:10::/64 [0/0] via FastEthernet0/0, directly connected 2000:10::1/128 [0/0] via FastEthernet0/0, receive 2000:20::/64 [20/0] via FE80::C802:18FF:FEA0:1C, GigabitEthernet1/0 2000:51::/64 [0/0] via GigabitEthernet1/0, directly connected 2000:51::1/128 [0/0] via GigabitEthernet1/0, receive FF00::/8 [0/0] via Null0, receive

R2#show ipv6 route ###Saídas Omitidas ### B C L C L L

2000:10::/64 [20/0] via FE80::C801:22FF:FE30:1C, GigabitEthernet1/0 2000:20::/64 [0/0] via FastEthernet0/0, directly connected 2000:20::1/128 [0/0] via FastEthernet0/0, receive 2000:51::/64 [0/0] via GigabitEthernet1/0, directly connected 2000:51::2/128 [0/0] via GigabitEthernet1/0, receive FF00::/8 [0/0] via Null0, receive

Marcada como B de BGP em R2 aparece a rota da LAN remota 2000:10::/64 com distância ADM 20 e métrica zero. Vamos agora ao segundo comando para verificar as rotas conhecidas pelo BGP com o próximo salto. R1#show bgp ipv6 unicast BGP table version is 3, local router ID is 10.0.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found

*> *> R1#

Network 2000:10::/64 2000:20::/64

Next Hop :: 2000:51::2


  

 





Metric LocPrf Weight Path 0 32768 i 0 0 64702 i


  




Página 248  



 


Para verificar os vizinhos podemos utilizar o comando "show bgp ipv6 unicast summary". R1#show bgp ipv6 unicast summary BGP router identifier 10.0.10.1, local AS number 64700 BGP table version is 3, main routing table version 3 2 network entries using 336 bytes of memory 2 path entries using 208 bytes of memory 2/2 BGP path/bestpath attribute entries using 272 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 840 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs Neighbor 10.0.0.2

V 4

AS MsgRcvd MsgSent 64702 11 11

TblVer 3

InQ OutQ Up/Down State/PfxRcd 0 0 00:05:38 1

3.7.2 Roteamento IPv6 através de uma sessão BGP IPv6

Você pode também pode criar uma sessão BGP diretamente através do IPv6. Nesse caso se for necessário também sessão BGP para IPv4 basta criá-la da maneira convencional que estudamos para manter as configurações separadas. Precisamos seguir 5 passos básicos para configurar o roteamento IPv6 através da sessão BGP IPv6 pura, veja abaixo: 1. Com o roteamento IPv6 ativado defina o número sistema autônomo do BGP com o comando que já utilizamos anteriormente "router bgp ASN" em modo de configuração global. 2. Configure o endereço dentro IPv6 dodaroteador BGP vizinho com oBGP. comando "neighbor IPv6-dovizinho ASN-Romoto" configuração do roteador 3. Entre no modo de configração do "Address-Family" para o IPv6 com o comando "address-family ipv6" ainda dentro da configuração do BGP. 4. Especifique com o comando Network as interfaces que irão participar do processo de roteamento com o comando "network Rede-IPv6/prefixo" dentro do modo de configuração do address family que entramos no passo anterior. 5. Ative o vizinho BGP com o comando "neighbor IPv6-do-Vizinho activate" ainda no modo de configuração do address family para o IPv6. Veja exemplo de configuração para a topologia abaixo. Na sequência vamos analisar alguns comandos show para verificação das configurações, vizinhança e aprendizado de rota.


  

 






  




Página 249  



 


Abaixo seguem as configurações de R1 e R2 respectivamente. Para esse laboratório foram utilizados roteadore modelo 7200, simulador GNS3 e Cisco IOS versão 15.2 "c7200adventerprisek9-mz.152-4.S6.bin" R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ipv6 unicast-routing R1(config)#int g1/0 R1(config-if)#ip add 10.0.0.1 255.255.255.0 R1(config-if)#ipv6 add 2000:51::1/64 R1(config-if)#no shut R1(config-if)#exit R1(config)#int f0/0 R1(config-if)#ip add 10.0.10.1 255.255.255.0 R1(config-if)#ipv6 add 2000:10::1/64 R1(config-if)#no shut R1(config-if)#exit R1(config)#router bgp 64700 R1(config-router)#neighbor 2000:51::2 remote-as 64702 R1(config-router)#address-family ipv4 R1(config-router-af)#no neighbor 2000:51::2 activate R1(config-router-af)#exit-address-family R1(config-router)#address-family ipv6 R1(config-router-af)#network 2000:10::/64 R1(config-router-af)#neighbor 2000:51::2 activate R1(config-router-af)#exit-address-family R1(config-router)# R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ipv6 unicast-routing R1(config)#int g1/0 R1(config-if)#ip add 10.0.0.2 255.255.255.0 R1(config-if)#ipv6 add 2000:51::2/64 R1(config-if)#no shut R1(config-if)#exit R2(config)#int f0/0 R2(config-if)#ip address 10.20.0.1 255.255.255.0 R2(config-if)#ipv6 address 2000:20::1/64 R2(config-if)#no shut R2(config-if)#exit R2(config)#router bgp 64702 R2(config-router)#neighbor 2000:51::1 remote-as 64700 R2(config-router)#address-family ipv4 R2(config-router-af)#no neighbor 2000:51::1 activate R2(config-router-af)#exit-address-family R2(config-router)#address-family ipv6 R2(config-router-af)#network 2000:20::/64 R2(config-router-af)#neighbor 2000:51::1 activate R2(config-router-af)#exit-address-family R2(config-router)# *May 9 02:31:29.847: %BGP-5-ADJCHANGE: neighbor 2000:51::1 Up R2(config-router)#

Note que ao final da configuração de R2 o BGP reconheceu a vizinhança e subiu indicando com a mensagem marcada em amarelo "%BGP-5-ADJCHANGE". Agora vamos aproveitar que subiu e vamos analisar a tabela de roteamento nos roteadores R1 e R2. Quando você montar seu laboratório lembre que as rotas podem demorar alguns minutos para subir, por isso repita o show ipv6 route até que a LAN remota seja mostrada como "B", conforme linha em destaque. Apostila/E-B     

  

 






  




Página 250  



 


R1#sho ipv6 route ###Saídas Omitidas ### C

2000:10::/64 [0/0] via FastEthernet0/0, directly connected 2000:10::1/128 [0/0] via FastEthernet0/0, receive 2000:20::/64 [20/0]

L B

via FE80::C802:18FF:FEA0:1C, GigabitEthernet1/0 2000:51::/64 [0/0] via GigabitEthernet1/0, directly connected 2000:51::1/128 [0/0] via GigabitEthernet1/0, receive FF00::/8 [0/0] via Null0, receive

C L L R1#

Portanto o show ipv6 route confirma a troca de mensagens e o aprendizado das rotas por R1 e R2. R2#sho ipv6 route ###Saídas Omitidas ### B

2000:10::/64 [20/0] via FE80::C801:22FF:FE30:1C, GigabitEthernet1/0 2000:20::/64 [0/0]

C

via FastEthernet0/0, directly connected 2000:20::1/128 [0/0] via FastEthernet0/0, receive 2000:51::/64 [0/0] via GigabitEthernet1/0, directly connected 2000:51::2/128 [0/0] via GigabitEthernet1/0, receive FF00::/8 [0/0] via Null0, receive

L C L L R2#

O comando "show bgp ipv6 unicast" mostra as rotas que estão na base de dados do BGP com os parâmetros que já estudamos para o BGP tradicional. R1#show bgp ipv6 unicast BGP table version is 3, local router ID is 10.0.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found

*> *>

Network 2000:10::/64 2000:20::/64

Next Hop :: 2000:51::2


  

 





Metric LocPrf Weight Path 0 32768 i 0 0 64702 i


  




Página 251  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R2#show bgp ipv6 unicast BGP table version is 3, local router ID is 10.20.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found

*>

Network 2000:10::/64

Next Hop 2000:51::1

*>

2000:20::/64

::

Metric LocPrf Weight Path 0 0 64700 i 0

32768 i

Com o comando "show bgp ipv6 unicast summary" podemos verificar informações como router ID do roteador BGP, ASN local e a lista de vizinhos com seus números de AS. R1#show bgp ipv6 unicast summary BGP router identifier 10.0.10.1, local AS number 64700 BGP table version is 3, main routing table version 3 2 network entries using 336 bytes of memory 2 path entries using 208 bytes of memory 2/2 BGP path/bestpath attribute entries using 272 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 840 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs Neighbor 2000:51::2

V 4


TblVer 3


R2#show bgp ipv6 unicast summary BGP router identifier 10.20.0.1, local AS number 64702 BGP table version is 3, main routing table version 3 2 network entries using 336 bytes of memory 2 path entries using 208 bytes of memory 2/2 BGP path/bestpath attribute entries using 272 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 840 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs Neighbor 2000:51::1

V 4



  

 





TblVer 3


  





Página 252  



 


4 Técnicas de Convivência e Migração entre IPv4 e IPv6 Com a diminuição constante das faixas de IPv4 disponíveis em cada uma das regiões que administram os endereços de Internet a migração para o IPv6 vem cada vez mais sendo falada, planejada e muitas vezes executada em ambientes de teste nas grandes empresas. Para isso foram desenvolvidas diversas estratégias de migração do IPv4 para o IPv6. Cada uma dessas estratégias poderão ser utilizadas pelas empresas ao decidir fazer a migração para o protocolo IPv6 para que essa transição seja o mais suave e tranquila possível. Atualmente não existe política ou definição global sobre como essa transição deverá ser feita, porém existem três mecanismos que poderão ser utilizados: 





Dual stack: em português “pilha dupla”, ou seja, rodar o IPv6 e IPv4 ao mesmo tempo em uma mesma interface. Tunneling ou Tunelamento: o tunelamento pode ajudar que ilhas isoladas em IPv6 atravessem a nuvem IPv4 atualmente que compõe a Internet para poderem se conectar, ou seja, é encapsular os pacotes IPv6 dentro de pacotes IPv4 para cruzar a Internet. Translation ou Tradução: a tradução nada mais é que uma extensão do NAT, chamado de “NAT Protocol Translation” ou “NAT-PT”, o "NPTv6" e o NAT64.

Cada um desses mecanismos é recomendado para cenários específicos e tem configurações próprias, a seguir vamos estudar as principais estratégias e suas configurações. Outros cuidados com essa migração são: Compatibilidade e suporte ao IPv6, pois muitos equipamentos de Infraestrutura de rede preisarão de Upgrade de Software e outros até mesmo serem substituídos. Suporte ao IPv6 por parte dos provedores de serviços de Internet (ISPs). Suporte ao IPv6 pelos clientes de rede e servidores. 

 

4.1 Dual Stack Na prática a implementação da pilha dupla nada mais é do que configurar endereços IPv4 e IPv6 na mesma interface, ou seja, em uma só interface termos os comandos “ip address” e “ipv6 address” simultaneamente. É importante saber que apesar de termos as duas pilhas do protocolo IP instalados os computadores com IPv6 não terão capacidades de se comunicar com os hosts IPv4, pois são duas redes diferentes rodando “em paralelo” na mesma interface. R3-DR(config-if)#interface FastEthernet0/1 R3-DR(config-if)#ipv6 address 2000:100::1/64 R3-DR(config-if)#ip address 192.168.1.1 255.255.255.0 R3-DR(config-if)#ipv6 address FE80::1 link-local R3-DR(config-if)#no shut R3-DR(config-if)#end R3-DR#

Hosts configurados com IPv4 e IPv6 geralmente seguem o mesmo processo do IPv4 e precisam utilizar um servidor DNS para traduzir os nomes de Internet, os quais podem devolver um IPv4 ou IPv6 como endereço da URL pesquisada, assim o host pode utilizar o protocolo de rede correto para comunicação com o servidor ou host remoto. Para verificar as configurações do IPv6 utilizamos o “show ipv6 interface brief” ou “show ipv6 interface”.


  

 






  




Página 253  



 


4.2 Técnicas de Tunelamento Na figura abaixo temos uma representação básica do que é um túnel. Note que temos duas redes IPv6 que precisam cruzar uma rede IPv4 para se comunicar e para que isso seja possível um nó de rede configurado com pilha dupla receberá o pacote IPv6 e o colocará dentro de um pacote IPv4 (como seu payload). Quando o pacote chegar ao seu destino o cabeçalho do IPv4 é removido e o pacote IPv6 encaminhado dentro da rede IPv6 de destino até o host correto.

Portanto, os túneis são utilizados para criar um caminho virtual entre dois domínios IPv6 através de uma rede IPv4. Existem vários tipos de túneis, porém os mais importantes são:    

Manual Configured Tunnels (MCT – túneis manuais) Túneis GRE (Generic Routing Encapsulation) Túneis 6 para 4 (6to4 Tunnels) Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

Os túneis manuais e GRE são considerados manuais e estáticos ponto a ponto, já os demais são túneis gerados dinamicamente ou “Dynamic Multipoint IPv6 Tunnels” (Túneis IPv6 Multiponto Dinâmicos). Os túneis multipontos se comportam como redes multiacesso, parecido com LANs ou redes NBMA (por exemplo, frame-relay multiponto). A vantagem dos túneis multiponto é que a decisão sobre o caminho a ser tomado é feita de maneira dinâmica baseada no endereço de destino, pois o roteador determina o próximo salto dinamicamente, o que resulta normalmente em menos configurações quando existem diversas localidades em relação aos túneis manuais. Veja a figura abaixo.


  

 






  




Página 254  



 


4.3 Técnicas de Tradução IPv6/IPv4 O Address Family Translation (AFT) ou simplesmente "Tradução" visa facilitar a comunicação entre redes/hosts IPv6 puras e redes/hosts IPv4 puras, sejam em que posição da rede eles se encontrem (trânsito, acesso ou nas pontas da rede) fazendo uma tradução do cabeçalho do protocolo IP entre as duas famílias (IPv4/IPv6 - IPv6/IPv4). A tradução não deve ser uma estratégia de longo prazo e sim de médio prazo visando a coexistência dos protocolos para a transição completa do IPv6 tanto em empresas como em ISPs. Vamos estudar aqui três tipos de tradução: NAT-PT, NPTv6 e NAT64. 4.3.1 Tradução via NAT-PT

Em vez de substituir o IPv4 existem várias maneiras de coordenar o funcionamento do IPv4 e IPv6 simultaneamente, sendo que o NAT Protocol Translation (NAT-PT) é um exemplo desta estratégia de convivência, definido na RFC 2766, e atualmente considerado em desuso, pois outras tecnologias mais eficientes estão sendo desenvolvidas para o mesmo fim. O NAT-PT faz a tradução bidirecional entre endereços IPv4 e IPv6, recomendado quando hosts utilizando o IPv4 tem a necessidade de estabelecer uma sessão com hosts configurados com IPv6 e vice-versa. Se os hosts se comunicam usando nomes de DNS um aplicativo como o DNS ALG (DNS Application Layer Gateway) pode resolver nomes para endereços IPv4 e IPv6. Para habilitar o NAT-PT em um roteador utilizamos o comando "ipv6 nat" em modo de configuração de interface onde o tráfego precisa ser traduzido, além disso deve ser configurado pelo menos um prefixo para o NAT-PT, o qual é usado para decidir qual o tráfego será permitido pelo NAT, pois apenas o tráfego que dê correspondência com o prefixo definido será traduzido. Essa configuração é feita tanto no modo de configuração global (para aplicar ao roteador todo) ou no modo de configuração de interface (para aplicar apenas ao tráfego nessa interface) com o comando "ipv6 nat prefix prefixo/comprimento-do-prefixo". Veja a figura abaixo com o exemplo de funcionamento do NAT-PT estático e a seguir a explicação de cada passo executado na tradução da comunicação do PC1, o qual é totalmente IPv6, com o servidor S1 que por sua vez é totalmente IPv4.

1. O PC1 envia um pacote IPv6 para o destino 2333::1 e srcem 2111::1 (seu próprio endereço IPv6). O IPv6 2333::1 está configurado em R1, o qual receberá essa mensagem.


  

 






  




Página 255  



 


2. O roteador R1 está com o NAT-PT configurado e está “escutando” as requisições ao destino 2333::1, ao receber a mensagem o roteador R1 converte o cabeçalho IPv6 para outro pacote no padrão IPv4. 3. O pacote IPv4 é encaminhado pela rede até o servidor S1. 4. Por sua vez o servidor S1 recebe a requisição, processa e envia uma resposta através de um pacote IPv4 em direção ao endereço (que ele “pensa” que é do host PC1) com srcem 10.2.2.2 e destino 10.9.9.1. O endereço 10.9.9.1 está na realidade configurado em R1, portanto é ele quem recebe esse pacote IPv4 através da rede IPv4. 5. Quando R1 recebe o IPv4 10.9.9.1 ele converte o pacote para o padrão IPv6, pois ele estáúltimo, com o NAT-PT configurado. 6. Por o roteador R1 encaminha o pacote IPv6 para o host PC1, o qual “pensa” que se comunicou com um servidor IPv6. O NAT-PT pode ser estático ou dinâmico, assim como para o IPv4 temos o NAT estático e o PAT, veja a seguir maiores informações e os comandos utilizados em cada um dos casos. 4.4 Tradução Via NPTv6 O Network Prefix Translation version 6 (NPTv6) é também chamado algumas vezes de IPv6-toIPv6 Network Prefix Translation, sendo um tipo de NAT que não suporta overloading. Portanto, o NPTv6 traduz um profixo IPv6 para outro apenas, por exemplo, podemos configurar no roteador uma tradução NPTv6 que traduza o prefixo 2001:1::/64 para 2001:2::/64. Outro ponto é que ele não guarda o estado, ele não é stateful e apenas traduz ou reescreve os prefixos. Mas se o NPTv6 só faz isso qual será seu uso na prática? Ele vai ser utilizado quando tivermos um rede.host IPv6 que tem mais de um endereço global de unicast configurado em suas placas de Vão existir casos onde o endereço global de unicast tem permissão para alcançar um destino específico, enquanto os demais endereços serão descartados se tentarem acessar o mesmo destino devido a filtros aplicados. Como o host não tem como saber que endereço está ou não bloqueado, o uso do NPTv6 pode ajudar a evitar esse tipo de problema traduzindo os demais prefixos para a faixa permitida. Quando um host tem mais de um endereço global de unicast ele tem que tomar uma decisão sobre que interface utilizar, correto? E tudo isso sem saber nada do roteamento ou que rede realmente funciona para alcançar o destino, por isso o problema citado acima pode ocorrer e o NPTv6 pode ajudar nesses casos. 4.5 Tradução Via NAT64 O NAT64 permite que hosts IPv6 possam conversar com hosts IPv4 fazendo a tradução do cabeçalho inteiro do protocolo IP. Lembre-se que no NAT44 (IPv4 para IPv4) traduzimos apenas o enedereço de camada-3 e se tiver overloading também utilizamos a porta TCP ou UDP para auxiliar na tradução, aqui com o NAT64 (IPv6 para IPv4) o cabeçalho completo precisa ser traduzido. Para isso, o rotador que está configurado com o NAT64 precisa manter uma tabela que mapeia os endereços IPv4 que correspondem aos endereços IPv6. Esse mapeamento pode ser feito manualmente ou de maneira dinâmica. Quando o mapeamento é feito de maneira estática (manual) ele é chamado "stateless translation", ou seja, uma tradução que não guarda o estado. Esse tipo de tradução não é escalável e pode trazer uma grande sobrecarga de configuração manual em redes grandes, Apostila/E-B     

  

 






  




Página 256  



 


porém pode muito bem ser utilizada em redes de pequeno porte com poucos servidores IPv4 que precisam ser acessados por hosts IPv6. Outra forma do NAT64 trabalhar é de com "stateful translation", onde o roteador configurado com NAT64 stateful permite a tradução dinâmica de endereços IPv6 para IPv4, a qual é muito mais escalável em redes de maior porte. A tabela a seguir mostra uma comparação do NAT64 stateful e stateless.

NAT64 Stateless NAT64 Stateful Tradução 1:1 (um para um) Tradução 1:N (um para N) aplicável suporta apenas redes pequenas. em soluções de médio e grande porte, por exemplo, em aplicações carrier grade NAT (CGN) para service providers. Não guarda o endereço IPv4.

Guarda o endereço IPv4.

Dá mais transparência na tradução Utiliza overloading, o que traz menor fim a fim. transparência. A tradução não é gravada.

O estado ou binding é criado a cada tradução.

Necessita tabela de tradução de Não tem necessidade dessa alocação IPv4 a ser traduzido para cada manual, tudo é feito de maneira endereço IPv6. dinâmica. Precisa de DHCPv6 para os hosts Suporta hosts com alocação manual, IPv6. DHCPv6 ou SLAAC.

Diferente do NAT-PT o NAT64 separa completamente a função de tradução NAT da necessidade do serviço de DNS, não precisando do recurso de DNS para suas traduções. Normalmente com o NAT64 é utilizado opcionalmente o DNS64.


  

 






  




Página 257  



 


Capítulo 09 - Conectando Sites Remotos

Nesse capítulo vamos tratar do roteamento do ponto de vista das Unidades Remotas (“Branch Offices” ou Filiais), especialmente quando essa filial usa a Internet para sua conexão com a rede interna (Intranet) e aos recursos corporativos através do uso de Redes Virtuais Privadas (VPNs).

Objetivos do Capítulo Ao finalcompreender: desse capítulo você terá estudado e deverá    











  

 






  

Tecnologias VPN. Configuração e verificação do GRE Descrever o DMVPN (single hub) Descrever o Easy Virtual Networking (EVN) Outras tecnologias VPN importantes para conexão de sites remotos. Exemplo de Configuração de Unidade Remota. Considerações sobre DHCP e DHCPv6. Considerações sobre NAT, PAT e NVI.




Página 258  



 


Sumário do Capítulo 5 Unidades Remotas – Considerações Gerais e Design ....................................... 260

6

5.1

Unidades Remotas de Pequeno Porte 261

5.2 5.3

Unidades Remotas de Médio Porte .. 262 Unidades Remotas de Grande Porte . 263

5.4

Acesso VPN para Usuários Remotos . 264

Opções de VPN para Sites Remotos .. 265

6.1

VPNs em Redes MPLS ...................... 265

6.2

DMVPN - Single Hub ........................ 266

6.3

Easy Virtual Networking (EVN) ......... 267

6.4

GRE .................... ....................... ...... 268

6.4.1

Configurando o Túnel GRE ................ 270

6.5

Multipoint GRE e NHRP........ ........ .... 272

6.6

IPSec ...................... ....................... .. 273

6.6.1

Fases de Estabelecimento de um Túnel

IPSec

275

7 Configurações de Roteadores em Sites Remotos de Pequeno Porte ..................... 278

7.1 Exemplo de Unidade Remota com xDSL, NAT, ACL e DHCP ..................... .................. 278 7.2

Considerações sobre o PPPoE Client . 280

7.3

Serviço de DHCP - DHCPv4 e DHCPv6 281

7.3.1 DHCP Options .................................... 282 7.3.2 DHCP para IPv6 - DHCPv6 ..................283 7.3.3 Configurando o Stateless DHCPv6 .....284 7.3.4 Configurando o Servidor DHCPv6 Stateful Básico ................................................... 285

7.4


  

 





NAT e PAT ..........................................287

7.4.2 PAT 7.4.3

Configurando NAT Estático, Dinâmico e 288 NAT Virtual Interface (NVI) ................290


Considerações Sobre NAT, PAT e NVI 287

7.4.1

  




Página 259  



 


5 Unidades Remotas – Considerações Gerais e Design Conectar escritórios ou unidades remotas (Branch Offices) à rede corporativa de uma empresa pode ser feito de várias maneiras atualmente, porém podemos separar essas conexões em dois tipos básicos: 

Privativa: conexão utilizando linhas dedicadas ou privadas, tais como circuitos dedicados ponto a ponto, Frame-relay, Metroethernet e MPLS.



Via Internet podendo ser realizada com serviços de acesso banda larga, tais como ADSL e Cable :Modem. A diferença básica entre as duas opções é a exigência de segurança que uma conexão via Internet demanda, pois os dados estão sendo enviados através de uma rede pública e sujeitos a quaisquer tipos de interceptação ou ataques externos. Nesse caso recomenda-se o uso de VPNs (redes virtuais privadas) para garantir que se houver captura dos dados, esses não sejam lidos. Uma segunda opção de uso da conexão via Internet banda larga em escritórios remotos é para realização de backup de um circuito dedicado. Quando, na unidade remota, o circuito principal (dedicado) fica indisponível um túnel VPN é criado a partir do acesso de Internet banda larga, garantindo a conectividade da unidade remota com a rede corporativa. Quando o circuito principal (dedicado) está em funcionamento a conexão banda larga fica com o uso exclusivo para acesso à Internet local da unidade remota. Portanto, em pequenas unidades remotas os dois principais desafios de design é manter a conectividade com a Internet para seus hosts internos e também dar suporte ao acesso seguro aos recursos corporativos com a rede da Empresa. O acesso à Internet está ligado ao funcionamento básico de como acessos banda larga (DSL e/ou cable) funcionam e também como esse roteador banda larga irá aprender, alocar e traduzir endereços internos para comunicação com endereços públicos, basicamente tarefas realizadas pelo NAT e DHCP (já estudados no CCNA). O segundo desafio tem relação direta com as VPNs (Virtual Private Networks) que permitem que as unidades remotas sejam validadas e tenham seus pacotes protegidos ao cruzar a Internet até a rede corporativa. Não se esqueça que essas informações estão cruzando uma rede pública, portanto os roteadores remotos devem ser devidamente autenticados (identificados e validados como legítimos para entrar na rede corporativa) para ter seus pacotes protegidos. Vamos na sequência estudar questões relativas a escritórios remotos de pequeno, médio e grande porte, pois cada tipo de conexão com a rede corporativa pode ter uma necessidade específica.


  

 






  




Página 260  



 


5.1 Unidades Remotas de Pequeno Porte Normalmente uma unidade pequena (Small Office/Home Office ou SOHO) utiliza uma saída única de banda larga para o acesso à Internet e também corporativo através de uma VPN. Por isso é comum encontrarmos apenas um roteador provendo serviços de WAN, PSTN, NAT, firewall e DHCP. A infraestrutura interna normalmente consistem em switches Layer 2, computadores, telefones IP, Impressoras e Laptops. Nas unidades de pequeno porte existe também a opção de integrar tudo em apenas um(Ethernet roteador, Switch por exemplo, a família de roteadores ISR-G1 e ISR-G2 módulos de switch Module). Se a unidade demandar poucos pontossuportam de rede essa placa pode ser instalada no próprio roteador e as configurações de VLAN e switching serão realizadas nele mesmo, economizando em espaço e no custo total da implantação. Outra opção de dispositivo é a utilização de um ASA (Series Adaptive Security Appliances), o qual pode conectar unidades à Internet com a facilidade de ter o recurso de firewall e segurança nativos em seu IOS. Note que, por haver apenas uma saída para a Internet e rede corporativa, será necessário existir uma rota padrão apontando para a Internet e rotas mais específicas (normalmente estáticas) apontando para a rede corporativa através do túnel VPN. Portanto, quando um roteador interno quiser sair para a Internet o roteador utilizará uma rota padrão e quando quiser se comunicar com a rede corporativa deverá enviar os pacotes através do túnel VPN. Veja a figura abaixo.

Por questões de custos normalmente é utilizado apenas um roteador, o que o torna um ponto único de falhas (SPOF – Single Point of Failure), pois todo tráfego corporativo e de Internet passam apenas por ele.


  

 






  




Página 261  



 


5.2 Unidades Remotas de Médio Porte Em unidades remotas de médio porte a WAN normalmente está conectada via um circuito dedicado (T1, E1, MPLS, Metroethernert) como link principal e tem uma conexão secundária com um acesso banda larga (cable ou DSL) como opção de backup através de VPN IPsec (com ou sem o uso de túneis GRE). O chaveamento entre o link principal e o secundário pode ser feito com rotas estáticas flutuantes ou protocolo de roteamento dinâmico.

Quando a opção de roteamento nesse tipo de cenário for via IGP a solução recomendada é via túneis GRE e IPSec, pois o IPSec puro não suporta os protocolos de roteamento IGP. Como já estudamos no capítulo anterior, outras vantagens do GRE são:   

Suporte a multiprotocolos roteadores, como IPv4 e IPv6 simultaneamente. Suporte a protocolos de roteamento dinâmico, tais como RIP, EIGRP e OSPF. Suporte a tráfego Multicast e Broadcast.

Os túneis GRE formam circuitos ponto a ponto para a camada 3 do modelo OSI, podendo ser endereçados como em redes WAN ponto a ponto com máscaras /30 ou /31. A recomendação do uso do GRE também é aplicável para os cenários de pequenos escritórios remotos, basta escolher um modelo de roteador que possua suporte a este recurso. A configuração dos IGPs é realizada normalmente como já estudamos anteriormente e parâmetros como distância administrativa, métrica, variance do EIGRP e outros podem ser utilizados para manipular a escolha da melhor rota ou então propiciar o balanceamento de carga entre as duas conexões. Normalmente esse modelo de unidade não faz a saída de Internet localmente devido a políticas de uso e filtros necessários para navegação. Por isso, nesses casos, o link secundário é utilizado somente quando o principal fica indisponível ou realizando balanceamento de cargas para melhor aproveitamento da banda disponível. A segunda opção de roteamento nesse cenário é utilizando rotas estáticas flutuantes, onde o link principal recebe uma distância administrativa menor que a rota através do link backup, assim somente quando o link principal ficar indisponível o secundário será utilizado e o túnel VPN será fechado para passagem do tráfego interessante. Lembrando que ainda podemos limitar o tipo de protocolo permitido pelo link backup no caso do uso de circuitos de mais baixa velocidade.


  

 






  




Página 262  



 


5.3 Unidades Remotas de Grande Porte Escritórios remotos de grande porte utilizam design similar a um Campus, ou seja, normalmente em três camadas com redundância nas camadas de core e distribuição, porém normalmente sem redundância na camada de acesso. Nesse tipo de topologia podem ser utilizados firewalls, dispositivos (ou módulos) de otimização da WAN e agregação de outras unidades remotas através de uma rede MPLS com conectividade em malha. Por esse motivo normalmente a infraestrutura deve prever alta disponibilidade com roteadores de WANem duplicados, switches distribuição e com firewalls o modelo de projeto três camadas. Veja de a figura a seguir umaduplicados, comparaçãocomo entreprevê os três modelos de unidades remotas.

Como o design de uma unidade de maior porte traz naturalmente mais complexidade ao roteamento dinâmico, muitas vezes será necessário além da configuração básica dos IGPs também adicionar mais recursos de ajuste fino como redistribuição e filtragem de rotas, conforme já estudado anteriormente. Além disso, outros tipos de VPN podem ser necessários (overlay VPNs), tais como Dynamic Multipoint VPN (DMVPN) ou Group Encrypted Transport VPN (GET VPN), as quais serão estudadas posteriormente nesse tópico.


  

 






  




Página 263  



 


5.4 Acesso VPN para Usuários Remotos Outra opção atualmente disponibilizada é a conexão de usuários remotos com a rede local da empresa através da Internet utilizando uma VPN de acesso remoto (Client Remote Access). Essa conexão deve ser ativada em um roteador com Cisco IOS com recurso de segurança ativo, configurando o dispositivo como um "Servidor VPN" ou "Headend VPN" utilizando, por exemplo, o Easy VPN Client. No computador cliente existem opções acesso remoto: 1. Utilizandodoum cliente VPNduas (Cisco VPNde Client ) que precisa ser instalado e configurado previamente no computador do cliente. 2. Utilizando VPN SSL (SSL Client Access), a qual é uma ligação privada virtual (VPN Virtual Private Network) que pode ser estabelecida usando apenas um web browser (Internet Explorer, Firefox, Safari, Opera, etc), sem a necessidade de criar conexões e configurações complexas nos computadores dos clientes ou recorrer a software adicional de VPN Cliente. Veja imagem abaixo.

Este serviço é necessário para acessar aos recursos internos de uma empresa, que de outra forma só estariam disponíveis dentro dela, ou com recurso à tradicional ligação VPN. Então se eu precisar acessar recursos de rede através do web-browser, caso seja necessário acessar arquivos ou edição de páginas, por exemplo, uma VPN tradicional será necessária? Na realidade não, a VPN SSL pode também fazer o que chamamos de “ Full AnyConnect SSLVPN Client”, que através de um cliente SSL muito mais leve que um cliente VPN tradicional permite ao cliente acessar aos recursos de rede como se estivesse se conectando em uma VPN de acesso remoto tradicional. Tanto o ASA como os roteadores com Cisco IOS suportam as VPNs SSL, porém cada um tem suas limitações e requisitos, por exemplo, o ASA vem com licença para duas conexões simultâneas, se mais forem necessárias será preciso adquirir mais licenças. Vamos aprender em um tópico posterior mais sobre o assunto e como implementar VPNs SSL no ASA Firewall.


  

 






  




Página 264  



 


6 Opções de VPN para Sites Remotos A utilização de VPNs para conexão de sites remotos em relação ao uso dos convencionais curcuitos dedicados está cada vez mais presente no dia a dia das empresas. A teoria e configuração de uma VPN não está mais sendo cobrada segundo o atual blueprint da prova do CCNP ROUTE, o qual requer apenas conhecimento da configuração do Generic Routing Encapsulation (GRE) e entendimento de DMVPN e EVN. Porém resolvemos seguir a bibliografia atual do CCNP ROUTE e explicar outras tecnologias VPN para ajudar sua vida prática. Lembrando que já estamos na reta final do material e em breve você estará pronto para fazer a prova, por isso aproveite o capítulo porque aqui vamos inserir mais alguns reforços dos quesitos que podem ser cobrados, tais como ACL e NAT, porém vamos reforçar os conceitos que não fazem parte do CCNA. 6.1 VPNs em Redes MPLS O Multiprotocol Label Switching (MPLS) é uma tecnologia amplamente utilizada por provedores de serviço e também implantada no backbone de grandes empresas. A diferença do MPLS é que ele toma suas decisões de encaminhamento com base em labels (etiquetas ou marcações) ao invés de endereços IP, por isso algumas bibliografias classificam como uma tecnologia de camada "2.5". O label é um identificador de tamanho fixo e significado local. Todo pacote ao entrar numa rede MPLS recebe um label, o qual pode ser pensado como uma forma abreviada para o cabeçalho do pacote. Desta forma os roteadores só analisam os labels para poder encaminhar o pacote. Essa etiqueta do MPLS tem 32 bits e é inserida entre os cabeçalhos das camadas 2 e 3, por isso o cabeçalho do MPLS é normalmente chamado de "shim header", pois fica bem no meio das duas camadas. Veja a figura abaixo com um esquema do label MPLS. (Fonte Wikipedia)

Os túneis VPN baseados em redes MPLS podem ser classificados em duas categorias: MPLS VPNs de camada 2 (L2 ou Layer 2). MPLS VPNs de camada 3 (L3 ou Layer 3).  

Para entender a diferença das VPNs MPLS L2 e L3 temos que entender que a rede MPLS é formada por equipamentos do tipo CE (Custumer Edge Equipament) que são os equipamentos do cliente, PE (Provider Edge Equipamente - roteadores de borda do provedor) e P (Provider Equipament - roteadores de backbone do provedor). Quando temos uma VPN MPLS Layer 2 MPLS ela permite que os roteadores do cliente ou customer edge (CE) routers em localidades distantes formem vizinhança entre si como se


  

 






  




Página 265  



 


estivessem diretamente conectados via camada-2. É como se a VPN MPLS L2 fosse uma conexão lógica via portas de um switche, portanto o cliente pode utilizar qualquer protocolo de roteamento que desejar, pois a nuvem MPLS vai "tunelar" essa informação. Veja a figura a seguir.

Já uma VPN MPLS de camada-3 o roteador de borda do provedor, chamado de provider edge (PE) ou Edge Label Switch Router (ELSR), estabelece vizinhança com o roteador CE do cliente. As rotas aprendidas do roteador CE são envidas ao roteador PE remoto através da núvem MPLS normalmente utilizando multiprotocol BGP (MP-BGP) para aí serem encaminhadas ao roteador CE remoto. Veja a figura a seguir.

6.2 DMVPN - Single Hub Lembra do funcionamento do bom e velho Frame-relay hub-and-spoke? Então você já entende o princípio do DMVPN, onde vários sites remotos (spokes) tem uma conexão VPN com um site principal (hub). Essa solução é mais simples que criar conexões full mesh utilizando VPNs IPsec site-to-site, que apesar de parecer mais completa seria mais cara e muito complexa de se manter, por isso ter a comunicação entre as unidades passando pelo roteador central é bem aceitável. Além do Dynamic Multipoint VPN (DMVPN) manter uma conexão virtual permanente entre o hub e os spokes, como no caso do Frame-relay hub-and-spoke, ele também permite que um túnel VPN seja criado dinamicamente entre dois sites spokes conforme a necessidade utilizando o mGRE (GRE Multiponto) e o NHRP (Next Hop Resolution Protocol). O DMVPN cria túneis VPN seguros permanentes utilizando o IPsec entre os spokes e os HUBs, porém, não entre os spokes como citamos anteriormente. A medida que um spoke precisa enviar um pacote para outro spoke, ele realiza uma busca via NHRP (Next Hop Resolution Protocol) para encontrar o endereço público (roteável) do outro spoke em questão. Uma vez encontrado, o túnel entre os spokes é estabelecido via interface mGRE (Multipoint GRE). Portanto o DMVPN precisa dos protocolos Multipoint GRE, Next Hop Resolution Protocol (NHRP) e IPSec para funcionar corretamente, além disso ele tira vantagem do GRE suportar protocolos de roteamento e do CEF para melhor desempenho. Veja a figura a seguir com uma topologia que utiliza DMVPN. Apostila/E-B     

  

 






  




Página 266  



 


Apesar de não ser parte da prova a configuração do DMVPN, você pode facilmente criar e testar utilizando o Cisco Configuration Professional (CCP). Essa opção está no DMVPN wizard em Configure > Security > VPN > Dynamic Multipoint VPN. Depois é só selecionar a opção Create a spoke ou Create a hub e seguir o fluxo. Na prática o DMVPN também ajuda a economizar várias linhas de comando, facilitando a configuração e adição de novos spokes na VPN. 6.3 Easy Virtual Networking (EVN) O Easy Virtual Network (EVN) é uma solução IP de virtualização que permite a separação de tráfego e segregação de caminhos em redes compartilhadas. Ela utiliza a tecnologia Virtual Route Forwarding (VRF)-Lite para: Simplificar a virtualização de rede em camada-3. Melhorar o suporte a serviços compartilhados. Melhorar o gerencimento, troubleshooting e facilitar a utilização dos recursos.   

A maior vantagem do EVN é a redução da quantidade de configuração que normalmente é necessária quando utilizamos o VRF-Lite para encaminhar tráfego entre unidades. Com o VRFLite precisamos criar sub-interfaces nos switches e roteadores que estão envolvidos no caminho do tráfego. Já com o EVN é criado um Virtual Network Trunk (VNET Trunk) que reduz bastante o trabalho de configuração, veja figura a seguir.


  

 






  




Página 267  



 


O tráfego que é transportado em uma VNET Trunk é marcado com uma VNET tag, a qual identifica a que rede virtual esses pacotes pertencem. Um roteador EVN se conecta com um switch Cisco Catalyst através de um trunk 802.1Q. Com o EVN os serviços compartilhados são mais eficianets devido ao uso do recurso de " route replication". Com esse recurso várias usuários do EVN que precisam de recursos em comum tais como Internet, email, video, DHCP ou DNS que tradicionalmente precisariam ter suas rotas exportadas e importadas via BGP em redes virtuais são simplesmente acessadas diretamente via Routing Information Base (RIB) em cada VRF. Veja a figura a seguir ilustrando o route replication.

Com isso as rotas são compartilhadas nas diversas VRFs mantendo a separação que é necessária de acordo com os requisitos de rede. Além disso, removendo rotas duplicadas das tabelas de roteamento é possível economizar memória e CPU do roteador. 6.4 GRE Os Túneis GRE (Generic Routing Encapsulation) são geralmente configurados entre dois roteadores de srcem e destino, ou seja, os pacotes enviados ponto a ponto. O GRE foi desenvolvido pela Cisco e está descrito na RFC 4213. É importante frisar aqui que o GRE por si só não provê segurança, ou seja, os pacotes enviados no túnel não são protegidos por criptografia por padrão, sendo necessário um protocolo de segurança como o IPSec, por exemplo, para garantir a privacidade no envio dos dados através de uma rede pública. Em um túnel GRE os pacotes designados para serem enviados através do túnel (já encapsulados com um cabeçalho de um protocolo como, por exemplo, o IP) são encapsulados por um novo cabeçalho (cabeçalho GRE) e colocados no túnel com o endereço de destino do final do túnel. Ao chegar a este final, os pacotes são desencapsulados (retira-se o cabeçalho GRE) e continuarão seu caminho para o destino determinado pelo cabeçalho srcinal. Veja a figura abaixo com o diagrama do GRE.


  

 






  




Página 268  



 


Abaixo seguem as principais características do GRE: 



 

Multiprotocolo: encapsula uma grande variedade de tipos de protocolo de pacotes dentro de túneis IP, inclusive o IPv6. Cria um link virtual ponto a ponto para os roteadores Cisco em pontos remotos através de uma rede IP. Usa o IP para o transporte (camada 3) e suporta diversos protocolos de roteamento. Utiliza um cabeçalho adicional para suportar multicasting e qualquer outro protocolo da camada-3 do modelo OSI como carga útil (payload ou dados).

A grande vantagem do tunelamento GRE é permitir o tráfego de protocolos em cenários onde normalmente não seria possível. Devido a esta propriedade é muito utilizado em conjunto com protocolos de roteamento, pois o GRE encapsula todo o pacote IP srcinal com um cabeçalho IP padrão e um cabeçalho GRE, o qual contém pelo menos dois 2-bytes como campos obrigatórios:  

Flag GRE Tipo de protocolo

Ele utiliza um campo de tipo de protocolo no cabeçalho GRE para suportar o encapsulamento de diferentes protocolos de camada 3. O cabeçalho GRE, juntamente com o cabeçalho IP de encapsulamento, cria pelo menos 24 bytes de overhead adicional para os pacotes encapsulados (bytes a mais quando comparado a um pacote IP normal). Veja a figura a seguir.


  

 






  




Página 269  



 


6.4.1 Configurando o Túnel GRE

Vamos a configuração utilizando como base a figura a seguir. Nesse exemplo faremos a configuração de um túnel GRE entre os roteadores R1 e R4 para fazer a comunicação entre as redes IPv4 privativas 10.1.1.0/24 de R1 e 10.2.2.0/24 de R4 sem anunciá-las aos outros roteadores, também faremos as redes IPv6 200:100::/48 e 2001:100::/48 trafegarem simultaneamente utilizando o processo de tunelamento GRE, porém sem criptografia.

Os passos básicos a serem seguidos são: Etapa 1: Criar uma interface do túnel (comando “interface Tunnel x” – x é o número do túnel, como na criação de uma loopback); Etapa 2: Atribuir os endereços IPv4 e IPv6 ao túnel (comandos “ip address” e “ipv6 address"); Etapa 3: Configurar a interface de túnel de srcem (comando “tunnel source Serialx/y” podendo ser também um endereço IPv4 alcançável); Etapa 4: Identificar o IP de destino do túnel (comando “tunnel destination x.x.x.x”); Etapa 5: (Opcional) Configurar qual protocolo de camada-3 o GRE vai encapsular (comando “tunnel mode gre {ip | ipv6 | multipoint}”). Etapa 5: Repita os mesmos passos no roteador remoto. Vamos analisar as configurações do roteador R1: R1#config term R1(config)#ipv6 unicast-routing R1(config)#interface Tunnel0 R1(config-if)#ip address 1.1.1.1 255.255.255.252 R1(config-if)#ipv6 address 2002:100::1/64 R1(config-if)#ipv6 rip 1 enable R1(config-if)#tunnel source Serial0/0 R1(config-if)#tunnel destination 200.2.2.2 R1(config-if)#tunnel mode gre ip R1(config-if)#end R1#


  

 






  




Página 270  



 


Abaixo segue a configuração de R4. R4#config term R4(config)#ipv6 unicast-routing R4(config)#interface Tunnel0 R4(config-if)#ip address 1.1.1.2 255.255.255.252 R4(config-if)#ipv6 address 2002:100::2/64 R4(config-if)#ipv6 rip 1 enable R4(config-if)#tunnel source Serial0/0 R4(config-if)#tunnel destination 200.1.1.2 R4(config-if)#tunnel mode gre ip R4(config)#end R4#

Com a configuração acima, quando um micro da LAN de R1 quiser se comunicar com outro micro remoto da LAN de R4 através do protocolo IPv6 ou IPv4, e vice versa, o pacote será encapsulado dentro de um túnel GRE e será desmontado apenas quando chegar em seu destino. Com essa configuração os demais roteadores não precisam saber da existência das redes IPv4 10.1.1.0 e 10.2.2.0 ou das redes IPv6 configuradas nos roteadores R1 e R4, precisando conhecer apenas as redes WAN dos roteadores em questão. Para verificar um túnel GRE podemos utilizar os comandos: - show interface tunnel num-tunnel: verificar o estado do túnel e detalhes da conexão. - show ip interface brief: verificar resumidamente o IP e estado do túnel. - traceroute IP-LAN-Remota: verificar se o roteador pega a saída correta para a LAN remota via túnel. - Comandos para IPv6: show ipv6 interface tunnel num-tunnel, show ipv6 interface brief e traceroute. Veja exemplo abaixo. dltec#sho ipv6 int brief FastEthernet0/0 [up/up] unassigned FastEthernet0/1 [administratively down/down] unassigned Loopback0 [up/up] unassigned Tunnel0 [up/up] FE80::21E:13FF:FE0B:1AEE 2011::1 Tunnel1 [up/up] FE80::21E:13FF:FE0B:1AEE 2010:100::2 dltec#show ipv6 interface tunnel 1 Tunnel1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::21E:13FF:FE0B:1AEE No Virtual link-local address(es): Global unicast address(es): 2010:100::2, subnet is 2010:100::/64 Joined group address(es): FF02::1 FF02::2 FF02::9 FF02::1:FF00:2 FF02::1:FF0B:1AEE MTU is 1476 bytes ICMP error messages limited to one every 100 milliseconds


  

 






  




Página 271  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds (using 30000) ND RAs are suppressed (periodic) Hosts use stateless autoconfig for addresses. dltec#

Note que o MTU do túnel GRE é 1476 bytes e para a formação do endereço de link local é utilizado o prefixo FE80::/64 com o EUI-64 formado a partir do endereço MAC da primeira interface local do roteador, veja a saída abaixo. dltec#sho int f0/0 FastEthernet0/0 is up, line protocol is up Hardware is Gt96k FE, address is 001e.130b.1aee (bia 001e.130b.1aee)

Algumas condições devem estar estabelecidas para que o túnel GRE fique “UP”: 

  

Túneis de srcem e de destino devem estar configurados e os IPs de srcem e destino devem ser alcançáveis; A rede IP do túnel está na tabela de roteamento; Keepalives GRE são recebidos (se utilizado); GRE deve estar configurado como modo padrão de túnel.

A maior vantagem do túnel GRE é sua flexibilidade, pois com um único túnel GRE podemos transportar além do IPv4 e IPv6 vários outros tráfegos, recurso que outros túneis normalmente não suportam. 6.5 Multipoint GRE e NHRP Umagine que você tem uma empresa com 100 unidades e precisa através do GRE puro fazer com que elas se comuniquem entre si. No mínimo no HUB você precisaria de 99 interfaces túneis mais um túnel criado em cada unidade remota, certo? Com o mGRE e o NHRP isso pode ser reduzido bastante. Simplificando ao máximo, o NHRP (Next Hop Resolution Protocol) é um protocolo similar ao ARP para redes Ethernet, porém no caso de um túnel ele tem a capacidade de mapear o endereço IP de um túnel a um endereço IP Non-Broadcast Multi-Access (NBMA) em uma tabela. Esse recurso permite que o mGRE (GRE multiponto) dinamicamente crie túneis entre roteadores descobertos via NHRP que precisam se comunicar. Existem duas maneiras de configurar o mGRE no hub e deixar a configuração “normal” do GRE nos spokes. A primeira é fazer um mapeamento estático do NHRP no roteador que está atuando como HUB e a segunda é deixar que o NHRP faça o mapeamento dinâmico no roteador configurado como HUB. O DMVPN usa o recurso do NHRP dinâmico para mapear as unidades remotas fazendo com que o HUB atue como servidor e os Spokes como clientes, assim cada vez que um Spoke é adicionado na rede ele informa ao HUB seu endereço físico e lógico que será utilizado para formação de túneis mGRE. Quando o HUB está com sua tabela de vizinhos NHRP populada ele pode responder requisições de clientes que precisam se comunicar passando os endereços físico e lógico para formação do túnel dinâmico.


  

 






  




Página 272  



 


O comando "show ip nhrp [detail]" permite visualizar os vizinhos aprendidos. Veja exemplo abaixo. Router#show ip nhrp detail 10.1.1.2/32 via 10.2.1.2, Tunnel1 created 00:00:12, expire 01:59:47 Type: dynamic, Flags: authoritative unique nat registered used NBMA address: 10.12.1.2

Esse comando mostra os endereços IP e máscaras no cachê de endereços IP-para-NBMA. A máscara é /32 porque a implementação da Cisco do NHRP não suporta agregação de endereços nonbroadcast multiaccess (NBMA). Na sequência temos o túnel e quando ele foi criado. Por último temos o "authoritative flag", que indica que quem forneceu essa informação foi um servidor NHRP de próximo salto (next-hop server) ou um roteador. Se a entrada for estática (manual) no campo Type estaria escrito "static", nesse caso o dynamic indica que o NHRP resolveu o endereço. Normalmente quando um túnel DMVPN começa a subir e voltar (chamado em inglês de "flapping" ou "flap") é devido a problemas de vizinhança e o comando anterior pode ajudar a verificar qual vizinho está instável. 6.6 IPSec Normalmente utilizamos o termo “túnel VPN” para um túnel seguro, onde caso haja captura de pacotes essa comunicação não pode ser "decriptografada" e lida. Lembre-se que os túneis GRE formam túneis, porém não garantem a segurança dos pacotes trafegados por si só. Maioria das vezes o protocolo que não garante a segurança nas as comunicações IPsec. No entanto, como um túnel IPSec puro consegue transportar informações édeoroteamento dos IGPs IPv4 ou IPv6, a solução que normalmente é utilizada e que estudaremos nesse capítulo é utilizar um túnel GRE. Os túneis GRE suportam os IGPs porque conseguem encapsular mensagens de multicast e broadcast. Existem alternativas para o GRE, pois como ele forma um link ponto a ponto pode haver a necessidade de muitas configurações quando mais pontos são adicionados e em todos os roteadores que devem se comunicar com esse novo dispositivo. O Dynamic Multipoint VPN (DMVPN) , que já estudamos anteriormente, cria túneis VPN multiponto permitindo menos configurações na adição de pontos adicionais já com a parte de segurança via IPSec implementada. Os objetivos do protocolo IPSec são: 







Confidencialidade: A confidencialidade dos dados é feita através de processos de criptografia, assim se os pacotes forem capturados por um terceiro não poderão ser lidos. Integridade: Garante que os dados não foram adulterados em trânsito, normalmente realizado através de códigos de Hash (MD5 e SHA). Autenticação: Garante que o roteador de srcem tem realmente permissão para estabelecer uma sessão segura e está devidamente autenticado. Antireplay: O IPsec utiliza a proteção antireplay para garantir que os pacotes enviados não estão sendo duplicados.

O IPSec é um framework que utiliza vários protocolos para estabelecer um túnel seguro que pode funcionar em dois modos: Transporte ou Túnel.


  

 






  




Página 273  



 


No modo transporte, somente a mensagem (payload) é criptografada, sendo que o cabeçalho IP permanece intacto. Já no modo de tunelamento, o pacote IP é criptografado por inteiro. Deve, assim, encapsular um novo pacote IP para distribuí-lo. O tunelamento é usado para comunicações de rede-a-rede (túneis seguros entre roteadores, chamadas de VPNs site-to-site) ou comunicações de host-a-rede e de host-a-host sobre a internet. O framework IPSec, ou seja, sua estrutura, prevê dois tipos básicos de protocolos que podem ser utilizados dentro de um pacote IP. O Authentication Header (AH), que provê a autenticação e integridade dos dados, mas não a confidencialidade, e o Encapsulating Security Payload (ESP), que provê autenticação, confidencialidade dos dados e integridade da mensagem.

Na figura acima, cada funcionalidade do IPSec está em um blocos com espaços que podem ser preenchidos com os protocolos ao lado. No entanto, veja que a confidencialidade, que são os algoritmos de criptografia, não são suportados pelo AH. Para o IPSec fornecer a confidencialidade você terá que utilizar o protocolo ESP ou ESP trabalhando em conjunto com o AH (veja a linha do “Protocolo IPSec”). O segundo espaço representa o tipo de confidencialidade implementado usando um algoritmo de criptografia como DES, 3DES, AES ou SEAL. A escolha depende do nível de segurança exigido, a qual a ordem de nível de segurança (da esquerda para a direita – menos seguro para o mais seguro) segue ao lado: DES -> 3DES -> AES -> SEAL. O terceiro espaço representa a integridade que pode ser implementada usando hashs MD5 ou SHA. Essa garantia da integridade é realizada utilizando o Hashed Message Authentication Codes (HMAC), normalmente com o MD5 ou SHA-1. O quarto representa a forma como a chave secreta compartilhada é estabelecida. Os dois métodos são pré-compartilhada (preshared key ou PSK) ou com certificados digitais RSA. O IPSec utiliza o protocolo Internet Key Exchange (IKE) para autenticação e troca das chaves. O último grupo representa o algoritmo Diffie-Hellman ou DH utilizado para troca segura das chaves através da Internet. Há quatro algoritmos distintos DH de troca de chaves para se escolher incluindo DH Grupo 1 (DH1), DH Grupo 2 (DH2), DH Grupo 5 (DH5) e DH Grupo 7 (DH7). O tipo de grupo selecionado depende das necessidades específicas de cada projeto. Segue abaixo uma descrição breve de cada grupo e suas aplicações práticas: Apostila/E-B     

  

 






  




Página 274  



 






  

Os grupos DH 1, 2 e 5 exponenciação de um módulo principal com um tamanho de chave de 768 bits, 1024 bits e 1536 bits respectivamente. Os clientes Cisco 3000 suportam grupos 1, 2 e 5. As criptografias DES e 3DES suportam grupos DH 1 e 2. A criptografia AES suporta os grupos DH 2 e 5. Os Certicom movianVPN client suportam o grupo 7. O grupo 7 suporta Elliptical Curve Cryptography (ECC), que reduz o tempo para geração das chaves.

Durante a configuração do túnel os pares VPN negociam o grupo DH que irão utilizar. 6.6.1 Fases de Estabelecimento de um Túnel IPSec

Apesar de não ser parte do conteúdo do CCNP ROUTE, decidimos inserir as fases de estabelecimento de uma VPN IPSec no conteúdo porque essas informações podem ajudar na prática a resolver problemas de estabelecimento de uma sessão. Basicamente uma VPN IPSec tem 5 fases entre seu estabelecimento e finalização de um túnel: Identificação do tráfego interessante, IKE fase 1, IKE fase 2, transferência de dados e fim do túnel IPSec. Abaixo segue uma figura ilustrativa e uma breve explicação de cada fase.

1) Tráfego interessante: É o tráfego que deve ser criptografado, geralmente identificado através de access-lists padrões ou estendidas, portanto não é preciso que uma VPN fique sempre ligada, ela pode ser estabelecida somente quando há um problema no link principal e o tráfego definido como interessante quiser trafegar pelo túnel. Em ambientes de pequeno porte o trigger (gatilho) para ativar a VPN é a necessidade de comunicação com a rede corporativa. 2) IKE fase 1: Basicamente tem a função de negociar as políticas que serão utilizadas, autenticar os peers e fechar um túnel seguro por onde serão configurados os demais parâmetros. Podemos dizer que é um “primeiro túnel”, para proteger as mensagens de negociação do túnel principal. Opções do IKE fase 1:   

Algoritmo de criptografia: DES, 3DES, AES Algoritmo Hash: MD5, SHA-1 Método de autenticação: Pré Share, RSA Signature Apostila/E-B

    

  

 






  




Página 275  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br  

Key Exchange: DH group 1, group 2, group 5 IKE SA lifetime: até 86400 segundos

3) IKE fase 2: É a negociação do “segundo túnel”, o que realmente vai transportar os dados dos usuários. São definidos os parâmetros do IPSec e “transform sets”, são estabelecidos IPSecs SAs (Security Association – associações de segurança), que são renegociados de tempos em tempos. Pode também ocorrer a troca do DH (opcional). O Security Association (SA) é uma conexão entre os dois peers que determina quais serviços do IPSec estão disponíveis naquela conexão (tipo de algoritmo e autenticação utilizada, endereço IP, tempo de vida da key e demais opções).de Sãocriptografia unidirecionais, logo, para um túnel VPN são criados dois SAs. Lembre que o IPSec pode trabalhar de duas maneiras: Túnel e Transporte. O modo túnel é o padrão, e com ele o pacote inteiro é criptografado e um novo cabeçalho é criado. Já no modo transporte o cabeçalho não é alterado, sendo criptografado apenas os dados. Opções do IKE fase 2:   

Algoritmo de criptografia: DES, 3DES, AES Autenticação: MD5, SHA-1 SA lifetime: até 28.000 segundos

4) Transferência de dados: Após finalizada o IKE fase 2 o tráfego começa a ser enviado pelo túnel, de forma segura (criptografado). 5) Fim do túnel IPSec: O túnel é finalizado quando a SA é deletada (manualmente) ou ocorre o timeout, que pode ser configurado para ocorrer após um determinado espaço de tempo sem transmissão de dados ou após uma quantidade específica de dados transmitidos. Tanto o IKE SA e o IPSec SA têm um tempo de vida útil, ao se aproximar desse tempo os extremos IPSec devem criar novos parâmetros, criando novos IKE E IPSec SAs para a conexão. Geralmente, o tempo de vida útil não é maior que um dia. Trata-se do parâmetro “SA Lifetime” citado nas opções das fases 1 e 2 do IKE. Mesmo com as configurações sendo além do escopo do CCNP Route você precisa estar familiarizado com o comando "show crypto ipsec sa" que permite visulizar as informações sobre as SAs negociadas entre os vizinhos, informações como "inbound crypto-map" (tráfego interessante), "remaining key lifetime" (tempo de vida da chave de criptografia), "transformsets" (criptografia utilizada) e "path MTU" (MTU do caminho). Portanto o comando mostra as SAs construídas entre os dois roteadores que estão configurados com um túnel IPSec. A seguir você vai ver um comando show onde temos um túnel entre os endereços 12.1.1.1 e 12.1.1.2 para trafegar de maneira segura pacotes entre as redes 20.1.1.0 e 10.1.1.0. Existem duas SAs com Encapsulating Security Payload (ESP) e não está sendo utilizado o AH (Authentication Header), ambas SAs utilizam 3DES para criptografia e HMACMD5 para autenticação.


  

 






  




Página 276  



 


Veja a saída do comando show crypto ipsec sa abaixo. interface: FastEthernet0 Crypto map tag: test, local addr. 12.1.1.1 local ident (addr/mask/prot/port): (20.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) current_peer: 12.1.1.2 PERMIT, flags={srcin_is_acl,} #pkts encaps: 7767918, #pkts encrypt: 7767918, #pkts digest 7767918 #pkts decaps: 7760382, #pkts decrypt: 7760382, #pkts verify 7760382 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0, #send errors 1, #recv errors 0 local crypto endpt.: 12.1.1.1, remote crypto endpt.: 12.1.1.2 path mtu 1500, media mtu 1500 current outbound spi: 3D3 inbound esp sas: spi: 0x136A010F(325714191) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3442, flow_id: 1443, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: inbound pcp sas: outbound esp sas: spi: 0x3D3(979) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3443, flow_id: 1444, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:


  

 






  




Página 277  



 


7 Configurações de Roteadores em Sites Remotos de Pequeno Porte Nesse exemplo vamos fazer uma configuração completa de uma unidade remota de pequeno porte utilizando PPoE no roteador CPE. A sessão PPPoE será estabelecida entre o roteador CPE e o roteador de agregação do ISP utilizando Challenge Handshake Authentication Protocol (CHAP). A seguir vamos discutir algumas particularidades do serviço de DHCP e NAT com foco no CCNP ROUTE, assuntos como DHCP para IPv6 e NVI ou NAT Virtual Interface que não foram alvos de estudos no CCNA, CCENT ou ICND-2. 7.1 Exemplo de Unidade Remota com xDSL, NAT, ACL e DHCP Como nessa unidade remota temos diversos usuários precisaremos também configurar os serviços de DHCP e NAT para que os hosts tenham endereços IPs alocados e possam acessar a Internet. Para acesso corporativo vamos configurar um túnel GRE. Vamos considerar nesse exemplo que o ISP alocou um IP fixo para o CPE. Portanto, teremos que configurar os seguintes itens para que tudo funcione corretamente:     

Conexão DSL e o PPPoE. Interface Ethernet para a conexão LAN dos hosts locais. Servidor DHCP para prover endereços IPs aos hosts. PAT para compartilhamento da linha DSL e acesso dos hosts à Internet. Rota estática padrão para acesso à Internet.

1) Configuração da interface LAN com faixa de IP 172.16.1.0/24: interface FastEthernet0/0 description Conectada ao Switch Local ip address 172.16.1.1 255.255.255.0 ip nat inside duplex auto speed auto

2) Configuração da Interface Dialer sendo que os dados de autenticação são usuário DlteC e senha dltec123: interface Dialer1 description To SBC ip address negotiated no ip redirects no ip proxy-arp ip mtu 1492 ip nat outside encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 2 ppp authentication chap pap callin ppp chap hostname DlteC ppp chap password dltec123 ppp pap sent-username DlteC password dltec123 ppp ipcp dns request accept ppp ipcp route default ppp ipcp address accept dialer-list 2 protocol ip permit


  

 






  




Página 278  



 


3) Configuração da interface ADSL (ATM0/0): interface ATM0/0 description Linha ADSL no ip address ip route-cache flow no atm ilmi-keepalive bundle-enable dsl operating-mode auto hold-queue 224 in ! interface ATM0/0.35 point-to-point description VPI/VCI = 0/35 pvc 0/35 pppoe-client dial-pool-number 1

4) Rota padrão: O comando "ppp ipcp route default" vai gerar automaticamente a rota padrão, porém nem todas as imagens de IOS suportam essa opção, nesse caso você terá que utilizar o comando "ip route 0.0.0.0 0.0.0.0 Dialer1" para configurar a rota padrão. 5) Configuração do serviço de DHCP: ip dhcp excluded-address 172.16.1.1 172.16.1.10 ip dhcp pool Users network 172.16.1.0 255.255.255.0 default-router 172.16.1.1 dns-server 8.8.8.8 152.158.2.48

O primeiro comando exclui endereços “.1” a “.10” que não serão fornecidos via DHCP (ip dhcp excluded-address 172.16.1.1 172.16.1.10), como o endereço da interface LAN do roteador e outros que venham a ser configurados estaticamente em impressoras ou servidores. Caso exista um servidor DHCP centralizado o comando “ip helper-address ip-do-servidor” pode ser utilizado desde que haja conexão IP via o roteador e o servidor DHCP remoto, esse comando deve ser utilizado dentro do modo de interface. 6) Configurando o NAT: ip nat inside source list 10 interface Dialer1 overload ! access-list 10 permit 172.16.1.0 0.0.0.255

Na realidade não utilizamos o NAT e sim o PAT, que é o NAT com overload e permite que vários IPs internos sejam traduzidos com apenas um IP válidos na interface externa. A rede interna foi definida com o comando “ip nat inside” dentro da fast 0/1 e a dialer 1 foi definida como interface externa através do comando “ip nat outside”. Para definir os IPs internos que podem ser traduzidos, ou seja, a srcem do NAT, foi criada a ACL 1 e logo em seguida definida a regra do PAT, sendo que a srcem será a ACL 1 (ip nat inside source list 1) e o IP que será usado na tradução será o que a interface dialer 1 pegar via PPP do ISP (interface Dialer1 overload), normalmente um IP público.


  

 






  




Página 279  



 


7) Configurando o túnel GRE com a matriz: Dltec-Branch(config-if)#interface Tunnel1 Dltec-Branch(config-if)#description Conexao com a Matriz Dltec-Branch(config-if)#ip address 172.16.10.1 255.255.255.0 Dltec-Branch(config-if)#tunnel source Dialer1 Dltec-Branch(config-if)#tunnel destination 185.10.45.101

7.2 Considerações sobre o PPPoE Client O PPPoE, assim como o Point-to-Point Protocol (PPP) para redes discadas, fornece uma maneira de estabelecer conexões com autenticação, porém através de redes Ethernet. Os ISPs (provedores de Internet) utilizam o PPPoE tanto para autenticação dos clientes como para fornecer suas configurações relativas ao endereçamento IP, normalmente através de links DSL e outras conexões banda larga. Com isso é possível que o ISP controle o acesso e faça a cobrança dos clientes, pois os maus pagadores não conseguirão conexão ou terão seu acesso a Internet bloqueado. O PPPoE faz sua conexão em duas fases: Active Discovery Phase: nessa fase o cliente localiza o PPPoE server com pacotes PADI (PPPoE Active Discovery Initiation) enviados em broadcast. Quando o servidor (concentrador ou “Access Server”) recebe o PADI ele responde com uma mensagem chamada PADO (PPPoE Active Discovery Offer). PPP Session Phase: na segunda fase são negociadas as demais opções doo PPP, como autenticação e endereçamento. 



A configuração no cliente pode ser realizada utilizando interface Dialer, mais recomendado atualmente e mostrada na sequência, ou através do VPND (Virtual Private Dial-up Network) iniciando com o comando “vpdn enable” em modo de configuração global.

O comando "Dialer Persistent" pode ser utilizado dentro da interface dialer para que que a sessão PPPoE não seja encerrada caso não haja tráfego dos dados interessantes através da interface. Sem esse comando a interface cairia toda vez que o timeout de inatividade da interface fosse alcançado. Para a autenticação vale o que foi estudado no ICND-2 para o PPP, com CHAP se quiser autenticação com MD5 ou PAP para autenticação em texto claro, sem troca de hashs durante a fase de autenticação.


  

 






  




Página 280  



 


7.3 Serviço de DHCP - DHCPv4 e DHCPv6 O serviço de DHCP em empresas de grande porte normalmente é centralizado e realizado por servidores Linux ou Windows Server, porém esse recurso está presente nos roteadores e é muito comum de ser utilizado. Abaixo seguem as mensagens trocadas pelo servidor DHCP no IPv4.

Se analisarmos a configuração do DHCP feito no exemplo completo anterior temos os seguintes passos: 1) Exclusão dos IPs de 172.16.1.1 a 172.16.1.10 do pool a ser fornecido pelo roteador: Dltec-Branch(config)#ip dhcp excluded-address 172.16.1.1 172.16.1.10

2) Definição do nome do pool como "Users": Dltec-Branch(config)#ip dhcp pool Users

3) Definição do escopo do DHCP, ou seja, a faixa de IPs a ser fornecida excluindo os endereços do passo 1. Dltec-Branch(dhcp-config)#network 172.16.1.0 255.255.255.0

4) Endereço do roteador padrão ou gateway: Dltec-Branch(dhcp-config)#default-router 172.16.1.1

5) Comando para importação dos dados aprendidos do PPPoE como servidor DNS: Dltec-Branch(dhcp-config)#import all

Caso você queira definir o IP do DNS é só utilizar o comando "dns-server IP-do-DNS" e o tempo de aluguel dos IPs pelo DHCP você altera com o comando " lease num-dias". Para verificar a alocação de IPs utilize o comando "show ip dhcp binding". Com essa configuração o roteador Cisco vai começar a escutar por mensagens de solicitações DHCP (DHCP Requests) através da interface de LAN que tenha a rede configurada no comando "network" e passar as configurações para o cliente solicitante. Outra opção é uma requisição remota através do DHCP Relay por uma configuração de cliente recebida através da rede. O roteador da rede remota para fazer essa requisição via DHCP Relay precisa ter em sua interface LAN onde estão os clientes DHCP o comando " ip helper-address IP-do-DHCP-Server-Remoto". Por padrão esse comando encaminha tráfego UDP das portas 69 (TFTP), 67 (BOOTP/DHCP Client), 68 (BOOTP/DHCP Server), 37 (Time Protocol), 49 (TACACS), 53 (DNS), 137 (NetBios) e 138 (NetBios Datagram). Para limitar as portas UDP encaminhadas utilize o comando " no ip forward-protocol udp num-porta" em modo de configuração global, por exemplo, para desativar o reenvio para o servidor remoto do DNS o comando seria "no ip forward-protocol udp 53".


  

 






  




Página 281  



 


Se considerarmos a topologia da figura a seguir o comando "ip helper-address 10.150.40.1" deveria ser inserido em modo de configuração da interface LAN do roteador R1 para que os computadores locais pudessem ter contato com o servidor DHCP remoto.

Para que R1 envie como Relay apenas as requisições DHCP a configuração deve ser a seguinte: R1(config)#no ip forward-protocol udp 37 R1(config)#no ip forward-protocol udp 49 R1(config)#no ip forward-protocol udp 53 R1(config)#no ip forward-protocol udp 137 R1(config)#no ip forward-protocol udp 138 R1(config)#int f0/0 R1(config-if)#ip helper-address 10.150.40.1 R1(config)#

7.3.1 DHCP Options

Tipos de opção ou Options são outros parâmetros de configuração do cliente que um servidor DHCP pode atribuir aos clientes. Por exemplo, algumas opções usadas com frequência incluem endereços IP para o gateway padrão (roteadores) e servidores DNS (Domain Name System). Geralmente, esses tipos de opção são ativados e configurados para cada escopo com os comandos que vimos no exemplo de configuração. A maioria das opções são predefinida através da RFC 2132, porém algumas não tem os comandos como vimos anteriormente, sendo necessário definir a opção via seu número padrão, por exemplo, os telefones IP precisam do endereço do servidor TFTP onde eles conseguem fazer download do firmware e configurações, essa informação é passada pela opção ou option 150 inserindo na configuração o comando: "option 150 ip end-do-TFTP-Server". Veja exemplo de pool com option 150 para telefonia IP. CMERouter(config)#ip dhcp excluded-address 10.1.1.1 10.1.1.10 CMERouter(config)#ip dhcp pool meu-pool CMERouter(dhcp-config)#network 10.1.1.0 255.255.255.0 CMERouter(dhcp-config)#option 150 ip 10.1.1.1 CMERouter(dhcp-config)#default-router 10.1.1.1 CMERouter(dhcp-config)#dns-server 10.100.0.1 10.100.0.2 CMERouter(dhcp-config)#exit

Nesse exemplo o roteador CME será o próprio servidor TFTP para os telefones IP.


  

 






  




Página 282  



 


7.3.2 DHCP para IPv6 - DHCPv6

Quando falamos de alocação dinâmica de endereços no IPv6 você precisa lembrar que existem mais opções que no IPv4. Para IPv6 temos temos o SLAAC que é ativado por padrão assim que você coloca um prefixo na interface, o SLAAC com DHCPv6 stateless e o DHCPv6 stateful. Com "Stateful DHCP" ou DHCPv6 Stateful os clientes obtém seus endereços e demais opções de configuração através do servidor. Essa é a maneira mais parecida com o DHCP tradicional do IPv4, pois com ela o servidor é capaz de guardar o estado da alocação, ou seja, sabe cada endereço que alocou com host IPv6. As demais maneiras não guardam esse vínculo. O DHCPv6 está definido na RFC3315, sendo que os clientes utilizam a porta UDP 546 e os servidores e relays escutam as mensagens DHCP na porta UDP 547. Como o IPv6 não possui mais broadcast o multicast é utilizado para troca de informações com os seguintes endereços:  

ff02::1:2  todos os agentes DHCPv6 relay e servidores. ff05::1:3  todos os servidores DHCPv6.

As mensagens do DHCPv6 Stateful são um pouco diferentes do DHCP tradicional, além disso o IPv6 não possui mais broadcast por isso o cliente manda sua solicitação em Multicast.

O DHCPv6 stateful que pode ser implementado de duas maneiras: "Rapid-Commit" e "Normal Commit". No modo "Rapid-Commit" o cliente DHCP pega seus parâmetros de configuração a partir do servidor DHCPv6 com apenas duas mensagens (solicit e reply), por isso o nome "rápido" ou "rapid". Já no modo "Normal-Commit" o cliente utiliza as quatro mensagens normais para obter suas configurações (solicit, advertise, request e reply). O padrão é utilizar o normal-commit. Devido a sua diferença do padrão, o uso do rapid-commit precisa ser habilitado tanto no servidor como nos clientes para que eles "entendam" o processo em apenas duas mensagens. Uma dica que não faz tem partetanto da prova mas podeo te surpreender prática,por é isso que maioria dosimportante sistemas operacionais o SLAAC como cliente DHCPv6 na ativados, os computadores podem pegar vários endereços de formas diferentes se você não ajustar suas configurações através dos flags do DHCPv6 que citamos no capítulo referente ao IPv6. Essas configurações nos clientes são abordadas em nosso curso de IPv6 (http://www.dltec.com.br/index.php/redes-curso-ipv6-online.html). No DHCPv6 Stateful também existe a opção de servidor centralizado onde os clientes remotos fazem sua solicitação através de agentes Relay através do DHCPv6 Relay de forma análoga ao DHCP tradicional. Veja a figura abaixo com exemplos de servidores de rede local e DHCPv6 centralizado com DHCPv6 Relay. Apostila/E-B     

  

 






  




Página 283  



 


Apesar de não ficar claro se as configurações do DHCPv6 são realmente escopo da prova vamos passar como ativar o DHCPv6 stateless, DHCPv6 Stateful básico e DHCPv6 Relay. 7.3.3 Configurando o Stateless DHCPv6

No exemplo a seguir vamos configurar o serviço de DHCPv6 stateless para configurar o nome de domínio e passar o endereço dos servidores DNS aos clientes que irão pegar seus endereços via autoconfiguração (SLAAC). O DHCP pool está vinculado ao link de acesso onde os clientes estão conectados (Ethernet0/0) utilizando o comando "ipv6 dhcp server" dentro da interface. Essa é uma diferença importante entre o DHCP e o DHCPv6, pois no DHCP não precisamos fazer nenhum tipo de configuração na interface. Veja as configurações abaixo. ipv6 dhcp pool dhcp-pool dns-server 2001:DB8:A:B::1 dns-server 2001:DB8:3000:3000::42 domain-name dltec.com.br ! interface Ethernet0/0 description Link de Acesso dos Clientes ipv6 address 2001:DB8:1234:42::1/64 ipv6 nd other-config-flag ipv6 dhcp server dhcp-pool

Note que marcado em azul na configuração do link de acesso que o comando "ipv6 nd otherconfig-flag" foi ativado na interface. Esse comando passa nas mensagens de RA o flag setado informando que clientes além de seservidor autoconfigurarem precisam buscar no DHCPv6 por outras opções de os configuração, tal como DNS. Em termos práticos, no cliente será feita uma autoconfiguração utilizando o prefixo do comando "ipv6 address", o qual é "2001:DB8:1234:42::/64", via SLAAC e as informações do servidor DNS e nome do domínio serão passadas pelo DHCPv6 stateless. Se você for utilizar um roteador Cisco no GNS3 como cliente para testar a configuração, entre na interface e utilize o comando "ipv6 address autoconfig" para que o cliente utilize a autoconfiguração para alocação do seu endereço IPv6 via SLAAC/EUI-64.


  

 






  




Página 284  



 


Nessa configuração não temos como verificar as alocações, pois o roteador não grava o estado como no DHCP tradicional, portanto ele passa as informações mas não guarda informações dos solicitantes. 7.3.4 Configurando o Servidor DHCPv6 Stateful Básico

A configuração do servidor DHCPv6 stateful básica, onde um servidor irá atribuir endereços IPv6 aos seus clientes locais, é bem semelhante com a configuração do DHCP tradicional do IPv4, porém com a diferença que precisaremos vincular o "pool" criado a uma interface local onde os endereços serão atribuídos aos clientes. Vamos a um exemplo onde o servidor DHCPv6 Stateful passará para seus clientes endereços iniciando com o prefixo 2000:51:10::/64, servidores DNS AAAA:BABA:CA:100::10 e 2010:AA01::1 e também o nome de domínio "dltec.com.br". Veja abaixo a criação do pool com nome teste-ccnp. R1(config)#ipv6 dhcp pool teste-ccnp R1(config-dhcpv6)#address prefix 2000:51:10::/64 lifetime infinite infinite R1(config-dhcpv6)#dns-server AAAA:BABA:CA:100::10 R1(config-dhcpv6)#dns-server 2010:AA01::1 R1(config-dhcpv6)#domain-name dltec.com R1(config-dhcpv6)#exit R1(config)#

O comando "address-prefix" determina o prefixo que vamos utilizar para os clientes, sendo que a opção "lifetime infinite infinite" determina o tempo de lease do DHCPv6 semelhante ao que estudamos para o IPv4. Se você quiser determinar um tempo de lease configure o tempo no "valid lifetime" em segundos: "lifetime {valid-lifetime preferred-lifetime}", o preferred lifetime tem que ser menor que o tempo de "valid". Agora precisamos ativar o DHCPv6 server em uma das interfaces do roteador com o comando "ipv6 dhcp server nome-do-pool", veja a configuração abaixo. R1(config)#interface g1/0 R1(config-if)#ipv6 enable R1(config-if)#ipv6 address 2000:51:10::1/64 R1(config-if)#ipv6 dhcp server teste-ccnp R1(config-if)#no shut R1(config-if)#

Para verificar as configurações inclua um cliente DHCPv6 e utilize os comandos "show ipv6 dhcp pool" e "show ipv6 dhcp binding". Veja exemplos dos comandos a seguir. R1#show ipv6 dhcp pool DHCPv6 pool: teste-ccnp Address allocation prefix: 2000:51:10::/64 4294967295 (1 in use, 0 conflicts) DNS server: AAAA:BABA:CA:100::10 DNS server: 2010:AA01::1 Domain name: dltec.com Active clients: 1

valid

4294967295

preferred

Note no comando acima que os dados configurados no pool são confirmados e existe um cliente ativo via DHCPv6.


  

 






  




Página 285  



 


Vamos no comando abaixo ver o endereço IPv6 do cliente, note que está destacado em azul. R1#show ipv6 dhcp binding Client: FE80::C802:31FF:FE58:1C DUID: 00030001CA0231580000 Username : unassigned IA NA: IA ID 0x00040001, T1 43200, T2 69120 Address: 2000:51:10:0:BCA2:98A1:3F3D:5DED preferred lifetime INFINITY, , valid lifetime INFINITY,

Veja a configuração do roteador R2 colocado como cliente conectado a LAN de R1. Em seguida veja a saída do show ipv6 interfaces para confirmar o endereço que foi adquirido via DHCPv6. R2#show running-config interface gigabitEthernet 1/0 Building configuration... Current configuration : 101 bytes ! interface GigabitEthernet1/0 no ip address negotiation auto ipv6 address dhcp ipv6 enable end R2#show ipv6 interface gigabitEthernet 1/0 GigabitEthernet1/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C802:31FF:FE58:1C No Virtual link-local address(es): Global unicast address(es): 2000:51:10:0:BCA2:98A1:3F3D:5DED, subnet is 2000:51:10:0:BCA2:98A1:3F3D:5DED/128 Joined group address(es): FF02::1 FF02::2 FF02::1:FF3D:5DED FF02::1:FF58:1C ### Saídas omitidas ### R2#

Dicas para laboratório: Para seus testes em roteadores reais ou GNS3 utilize IOS 12.4(24T) ou superior. Uma dica é que nem todos os IOSs suportam o comando para o DHCPv6 Cliente "ipv6 address dhcp". Nos laboratórios desse capítulo utilizamos o Cisco IOS para 7200 "c7200spservicesk9-mz.150-1.M.bin". Para descobrir se o seu IOS suporta simplesmente entre na interface e digite "ipv6 address ?", se a opção DHCP não estiver presente utilize um host com Virtual Box, como Windows 7 ou superior. Para Linux maioria deles não tem o DHCPv6 cliente instalado, uma opção nesse caso é a utilização do Dibbler-client.


  

 






  




Página 286  



 


7.4 Considerações Sobre NAT, PAT e NVI Muitos conceitos exigidos nessa revisão do CCNP ROUTE fazem parte do CCNA, CCENT e ICND2, como por exemplo, NAT e ACL. Vamos revisar rapidamente esses conceitos aproveitando que fizemos um exemplo completo de configuração, porém focando nas diferenças e novidades solicitadas nesse novo exame. 7.4.1 NAT e PAT

No CCENT estudamos o conceito de NAT e PAT, sendo que ambos os recursos de tradução podem ser estáticos ou dinâmicos. O NAT é uma tradução pura e simples do endereço de camada-3 de srcem do pacote IP que cruza um roteador configurado para tradução entre duas ou mais redes, ou seja, uma rede Internet (Inside - Intranet, por exemplo) precisa acessar uma rede externa (Global - Internet, por exemplo) sem essa rede de fora conheça os endereços Internos da rede de srcem. Ao cruzar o roteador NAT que está na borda (entre a rede Interna/Inside e a Externa/Global) o pacote IP sofrerá uma tradução, ou seja, o IP de srcem do pacote que é da rede Interna/Inside será removido e um IP da rede Externa/Global será inserido pelo roteador. Assim o host remoto da rede externa (Outside Global) "pensará" que está se comunicando com o roteador de borda, o qual por sua vez quando receber o retorno do pacote o encaminhará para o host de srcem. Quando temos a tradução de um IP de srcem ou Inside Local para apenas um IP externo ou global do roteador (Inside Global) chamamos essa tradução de NAT estático ou "Static Nat" ou (1 para 1), ao passo que quando temos uma faixa de endereços externo (poll) chamamos a tradução de dinâmica ou "Dynamic NAT" ou "DNAT" (n para n). Tanto o NAT estático como o dinâmico tem limitações, pois o primeiro traduz um IP interno ou inside local para um IP externo ou outside local, já o segundo traduz uma faixa ou pool de endereços internos (inside local) para uma faixa ou pool de endereços externos (inside global). Mas e se tivermos 1000 hosts internos e apenas 15 endereços IPs válidos de Internet disponíveis? Com as configurações que estudamos somente 15 hosts vão falar simultaneamente, simples assim. Por isso existe uma terceira opção chamada PAT (Port Address Translation) que permite ir além de traduzir o endereço IP, permitindo utilizar portas TCP e UDP na tradução. Como o TCP e o UDP permitem mais de 65 mil número de portas é isso que teremos com apenas um endereço IP em um roteador fazendo PAT: mais de 65 mil conexões TCP e mais de 65 mil conexões UDP podem ser feitas simultaneamente.


  

 






  




Página 287  



 


7.4.2 Configurando NAT Estático, Dinâmico e PAT

A configuração do NAT, seja ela qual for, considera uma topologia onde temos uma rede interna a ser traduzida, chamada de rede Inside, e uma rede externa que tem os IPs utiizados na tradução, chamada de Outside. Os IPs da rede a ser traduzida são chamados de Inside Local, o endereço da interface do roteador NAT que está na rede externa é chamado de Outside Local e os endereços dos hosts da rede externa são chamados de Outside Global. Veja desenho abaixo com exemplo da nomenclatura que apesar estar representando um PAT é a mesma para o NAT ESTÁTICO e DNAT.

A configuração do NAT e PAT tem o mesmo princípio, escolher a rede inside (hosts com IPs inside local), quem será o endereço de outside local que será usado na tradução e dizer com o comando "ip nat inside" em modo de interface quem são as interfaces Inside ou Internas e com o comando "ip nat outside" que são as interfaces externas ou de Outside. Utilizando a mesma figura das nomenclaturas, para fazer a tradução estática ou NAT ESTÁTICO do endereço 10.10.10.1 para o IP válido do roteador 63.63.63.1 utilizamos o comando abaixo em modo de configuração global: ip nat inside source static 10.10.10.1 63.63.63.1

No comando acima estamos definindo o IP interno a ser traduzido como 10.10.10.1 e o endereço externo que o roteador vai usar para tradução 63.63.63.1, ou seja, quando um pacote de 10.10.10.1 for enviado para o servidor de e-mail, o endereço IP de srcem que o servidor receberá no pacote será 63.63.63.1. O NAT ESTÁTICO ativa automaticamente o NAT reverso, ou seja, se fizermos um ping de fora para 63.63.63.1 na realidade estaremos pingando o host 10.10.10.1. Para finalizar, supondo que a interface interna seja a fast0/0 e a externa a fast0/1 precisamos indicar que é rede interna/inside e externa/outside, veja os comandos abaixo em modo de configuração de interface: int ip ! int ip

f0/0 nat inside f0/1 nat outside


  

 






  




Página 288  



 


No NAT dinâmico ou DNAT a diferença é que ao invés de termos um IP interno e um externo temos vários internos e vários externos, por isso para definir a rede inside (srcem) precisamos de uma ACL para escolher vários IPs. A mesma coisa se aplica para os endereços inside global ou IPs externos do roteador, agora não será apenas um, mas vários. Para definir as interfaces inside e outside nada muda. Vamos ver um exemplo de configuração considerando que agora ou invés do IP único 63.63.63.1 o ISP alocou os endereços de 63.63.63.1 a 63.63.63.6 (rede 63.63.63.0/29) para o roteador NAT e vamos utilizarprecisamos dinamicamente IPsserá para atraduzir os hostscom internos. Para essa configuração primeiro definiresses quem rede interna uma ACL, lembrando que a rede é 10.10.10.0/24. access-list 1 permit 10.10.10.0 0.0.0.255

Agora vamos definir o pool de endereços válidos atribuídos pelo ISP, vamos utilizar para tradução os IPs de .2 a .6 criando um "pool" chamado "POOL-1" que tem o IP inicial (63.63.63.2) e o final da tradução (63.63.63.6), seguido da máscara de sub-rede (255.255.255.248). ip nat pool POOL-1 63.63.63.2 63.63.63.6 netmask 255.255.255.24 8

Agora vamos vincular srcem e destino com o comando "ip nat inside" abaixo, lembrando que primeiro vem a rede inside (ACL 1) e depois a rede outside (pool chamado POOL-1). ip nat inside source list 1 pool POOL-1

Com esse comando a rede inside será nano access-list 1 e a rede que Para vamos utilizar para traduzir a srcem dos pacotes seráa adefinida definida pool chamado POOL-1. definir a interface interna e externa utilizamos o mesmo comando do exemplo anterior. int ip ! int ip

f0/0 nat inside f0/1 nat outside

Para fazer o PAT seguimos o mesmo princípio do DNAT, porém apontando para a interface de saída da Internet e adicionando a opção "overload", a qual ativa o uso das portas TCP e UDP na tradução. Veja exemplo abaixo, onde utilizaremos a mesma topologia de exemplo. 1. Definir a rede a ser traduzida (inside) access-list 1 permit 10.10.10.0 0.0.0.255

2. Definir a interface de saída dos pacotes (outside) ip nat inside source list 1 interface fast0/1 overload

Note que não precisamos especificar o IP de saída, pois já indicamos que a interface fast0/1 será utilizada para traduzir os IPs internos através do PAT (overload). Vamos omitir a definição das interfaces inside e outside por serem iguais para esse exemplo. O comando "show ip nat translations" permite verificar as traduções realizadas pelo NAT e PAT.


  

 






  




Página 289  



 


7.4.3 NAT Virtual Interface (NVI)

A partir do Cisco IOS Release 12.3(14)T o recurso chamado NAT Virtual Interface (NVI) foi introduzido para que você possa fazer as configurações do NAT sem especificar que interfaces são inside ou outside. Os comandos "ip nat inside" ou "ip nat outside" que utilizamos dentro das interfaces na maneira convencional de configuração do NAT são substituídos pelo comando "ip nat enable". Isso permite mais facilidade de configuração e também que o tráfego entre duas interfaces consideradas inside no NAT tradicional fluam normalmente entre si. Portanto a configuração é praticamente a mesma com a diferença que não diremos mais que é interface inside ou outside, veja exemplo abaixo. interface FastEthernet0/0 ip address 10.10.10.254 255.255.255.0 ip nat enable ! interface FastEthernet0/1 ip address 63.63.63.1 255.255.255.248 ip nat enable exit ! ip nat source list 1 interface FastEthernet0/1 overload ! access-list 1 permit 10.10.10.0 0.0.0.255

Note que no comando “ip nat” não utilizamos o “inside” e vai direto para o source list, se você não fizer assim o NVI não irá funcionar. Por exemplo, para o DNAT ou NAT com Pool (com ou sem overload) você precisa criar o pool utilizando a opção “add-route” no final e depois vincular o pool no comando “ip nat” conforme exemplo abaixo: access-list 1 permit 10.10.10.0 0.0.0.255 ip nat pool NOMEDOPOOL 1.1.1.1 1.1.1.10 netmask 255.255.255.0 add-route ip nat source list 1 pool NOMEDOPOOL overload

Para o NAT Estático você deve inserir o “ip Nat enable” apenas na interface de saída e utilizar o comando abaixo para definir a tradução: ip nat source static local-ip global-ip

Para verificar as traduções você pode utilizar o comando “show ip nat translations” ou “show ip nat nvi translations”. O NVI pode ser feito com NAT Dinâmico, interface ou NAT Estático, não podendo ser utilizado com o NAT Statefull (SNAT – Statefull NAT), que é uma aplicação do NAT para service providers.


  

 






  




Página 290  



 


Capítulo 10 - Segurança em Roteadores e Serviços de Rede

Nesse capítulo vamos estudar tópicos de segurança em roteadores Cisco e os serviços de redes utilizados para gerenciamento e monitoração no dia a dia de um CCNP.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender:








  

 


  

 






  

Autenticação local e via servidor remoto (AAA). Listas de controle de acesso IPv4 e IPv6. Ativando serviços de rede nos roteadores (Telnet, HTTP, HTTPS, SSH, SCP, FTP e TFTP). Protocolo SNMP. Protocolo NTP. Alocação dinâmica de hosts em IPv4 e IPv6 (DHCP). Mensagens e logs. Netflow.




Página 291  



 



Introdução ....................................... 294

2

Controle de Acesso aos Dispositivos.. 294

2.1 Configurações básicas de acesso e proteções de senhas .................................. 295 2.2 Ativando outros serviços nos roteadores - HTTP, HTTPS, SSH, SCP e (T)FTP ............ .... 299 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7

Serviços de HTTP e HTTPS ................. 299 Serviço de SSH ................................... 301 Serviço de TFTP ................................. 302 Serviço de FTP ...................................303 Serviço de SCP ................................... 304 Arquivos de Core Dump .................... 305 Verificando as portas conectadas .....305

2.3 Cisco IOS AAA - Local database, TACACS+ e RADIUS .................................... 306 2.3.1 Protocolos TACAS+ e RADIUS ............307 2.3.2 Exemplo de configuração de autenticação com servidor TACACS+ ................ 309

3

Segurança em Roteadores - ACLs e uRPF 311 3.1 Unicast Reverse Path Forwarding - uRPF 311 3.1.1

3.2

Time-based ACLs ............................. 315

3.2.1

ACLs de Infraestrutura ..................... 316

3.4

Filtragem de pacotes IPv6 ........... ..... 318

Ativando e V erificando o L ogging ..... 321

4.1.1 4.1.2

Serviço de Syslog ............................... 323 Verificando as mensagens de log ......324

4.1.3 4.1.4 4.1.5

Utilizando Debugs ............................. 325 Utilizando Conditional Debugs ..........325 Melhorando o Log de ACLs e ACEs ....327

4.2

Entendendo e Ativando o NTP ........ . 328

4.2.1 4.2.2 4.2.3

4.3

  

 






  

Versões do NTP ................................. 330 Tipos de Configuração do NTP .......... 331 Autenticação do NTP .........................332

Entendendo e Ativando o SNMP ...... 333

4.3.1 4.3.2

    

Configurando uma ACL IPV6 .............. 318 Exemplo de ACL IPv6 ......................... 319

Gerenciando Dispositivos Cisco ......... 321

4.1

Apostila/E-B

Exemplo Prático .................................315

3.3

3.4.1 3.4.2

4

Ativando e Verificando o uRPF ..........312

Configurando o SNMP versão 2C ......335 SNMP versão 3 .................................. 336




Página 292  



 


4.4

Entendendo e Configurando o NetFlow 338

4.4.1 4.4.2 4.4.3 4.4.4

5

O que é um Fluxo para o NetFlow? ... 339 Configurando o NetFlow ................... 339 Verificando e utilizando o NetFlow ... 340 Flexible NetFlow ................................ 344

Conclusão ......................................... 345


  

 






  




Página 293  



 


1 Introdução Nos dias atuais existem vários riscos de segurança e ataques que podem ser realizados não somente aos usuários finais da rede, mas também aos roteadores que normalmente estão na borda das redes (edge). Uma vez invadindo o roteador ou simplesmente "tirando o roteador do ar" o atacante pode causar grandes prejuízos ao funcionamento do negócio da empresa ou organização atacada. É importante fazerautenticação, uma política níveis de segurança paraporostipo roteadores que contenha itensestarão como usuários, senhas, de acesso de usuário, serviços que ativos no próprio roteador (FTP, TFTP, SSH, Telnet, etc.), padrões de configuração do protocolo de roteamento, redundância, backups de arquivos de configuração e Cisco IOS, regras de filtragem (ACLs), monitoração (SNMP, Netflow, etc.), necessidades de updates e upgrades de software, dentre outros itens. Muitos desses assuntos já estão incluídos principalmente no ICND-2, pré-requisito do CCNP ROUTE, porém aqui vamos dar um enfoque mais integrado dessas necessidades de segurança e monitoração. 2 Controle de Acesso aos Dispositivos Como já estudamos anteriormente, podemos dividir a arquitetura do roteador em três partes chamadas de "planes" (planos): Managemente Plane, Data Plane e Control Plane. O blueprint atual do CCNP ROUTE traz técnicas para proteção de todos os planos, porém nesse tópico vamos estudar a proteção do Management Plane. O Management Plane está preocupado com o gerenciamento do roteador, por exemplo, com a proteção de um acesso remoto a linha de comando de um roteador através da rede IP. Se você puxar pela memória do CCNA ou CCENT vai lembrar que o acesso local a um roteador é feito via CLI através da linha de console e o gerenciamento remoto via VTY, o qual pode utilizar o Telnet (inseguro - mensagens em texto claro) ou SSH (seguro - mensagens criptografadas). Devido ao Telnet ser inseguro e suas mensagens capturadas em trânsito poderem ser lidas utilize sempre preferencialmente o SSH para acesso remoto. Além do Telnet e SSH podemos ativar vários outros serviços nos roteadores, alguns seguros outros inseguros. Abaixo segue a lista de serviços e seu principal uso na prática: Telnet: acesso a linha de comando via rede IP, sem segurança na troca de mensagens e utiliza TCP na porta 23. SSH: o Secure Shell também permite acesso a linha de comando via rede IP, mas mensagens são criptografadas e utiliza TCP na porta 22. HTTP: utilizado para acesso Web ao roteador diretamente ou via interfaces GUI como CCP (Cisco Configuration Professional), os dados são passados em texto claro e utiliza TCP na porta 80. 













HTTPSTCP : utilizado para utiliza na porta 443.acesso Web como o HTTP, porém os dados são criptografados e SCP: o Secure Copy (SCP) fornece uma maneira de copiar arquivos de configuração ou imagens de IOS com criptografia e autenticação. O SCP funciona em conjunto com o Secure Shell (SSH). Utiliza TCP na porta 22. TFTP: o Trivial File Transfer Protocol é utilizado para transferir arquivos de configuração e Cisco IOS como o SCP, porém ele não é seguro nem tem autenticação. Utiliza UDP na porta 69. FTP: o File Transfer Protocol no Cisco IOS tem a finalidade de transferir arquivos dos roteadores para um servidor FTP externo. O roteador não terá ativo um servidor FTP


  

 






  




Página 294  



 


nele, apenas você pode fazer backups e copiar arquivos para o router como se ele fosse um cliente FTP. Para um acesso remoto utilizamos um cliente como Putty para SSH e/ou Telnet e precisaremos especificar o endereço IP do roteador. Aqui nessa etapa podemos configurar uma lista de acesso na VTY, por exemplo, para limitar as redes que podem entrar remotamente no Management Plane do dispositivo. Uma vez conectado vem a etapa da autenticação, a qual pode ser através de uma senha ou teremos quecom digitar umde usuário e uma senha. Uma vezentrar autenticado o usuário vai ser executivo colocado por padrão nível privilégio 1 (usuário). Para em modo privilegiado (EXEC) você precisa digitar o comando "enable" e uma senha do modo privilegiado (enable password/secret) e o usuário passa para nível de privilégio 15, podendo alterar quaisquer configurações. 2.1 Configurações básicas de acesso e proteções de senhas Analise as configurações abaixo que você já estudou no CCENT e responda as questões que estão logo na sequência. Suponha que o roteador estava sem configurações e os comandos foram entrados pela primeira vez via console. Responda tudo sem consulta! R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#enable password dltec R1(config)#enable secret dltec123 R1(config)#line console 0 R1(config-line)#password cisco R1(config-line)#login R1(config-line)#line vty 0 15 R1(config-line)#password cisco123 R1(config-line)#login R1(config-line)#exit R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#access-list 1 remark rede de gerenciamento R1(config)#line vty 0 15 R1(config-line)#access-class 1 in R1(config-line)#end R1#

Quais as senhas para entrar em modo privilegiado? Qual a diferença entre os dois comandos? Qual a senha de console (se estiver configurado)? Qual a senha de Telnet (se estiver configurado)? Qual a senha do SSH (se estiver configurado)? Quais redes podem acessar remotamente o roteador R1? Porque? _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ Apostila/E-B     

  

 






  




Página 295  



 


Abaixo seguem as respostas e algumas considerações de segurança. R1#conf t Enter configuration commands, one per line. R1(config)#enable password dltec R1(config)#enable secret dltec123 R1(config-line)#line vty 0 15 R1(config-line)#password cisco123 R1(config-line)#login R1(config-line)#exit

End with CNTL/Z.

R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#access-list 1 remark rede de gerenciamento R1(config)#line vty 0 15 R1(config-line)#access-class 1 in R1(config-line)#end R1#

Quais as senhas para entrar em modo privilegiado? dltec ou dltec123 R1(config)#enable password dltec R1(config)#enable secret dltec123

Qual a diferença entre os dois comandos? O enable password é inserido em texto claro na configuração e o secret criptografado com Hash MD5. Qual a senha de console (se estiver configurado)? cisco R1(config)#line console 0 R1(config-line)#password cisco R1(config-line)#login

Qual a senha de Telnet (se estiver configurado)? cisco123 R1(config-line)#line vty 0 15 R1(config-line)#password cisco123 R1(config-line)#login

Qual a senha do SSH (se estiver configurado)? O SSH não está ativado. Quais redes podem acessar remotamente o roteador R1? Porque? A rede 10.0.0.0 255.255.255.0, IPs de 10.0.0.1 a 10.0.0.254. A access-class aplicada na VTY limita o acesso apenas para as redes permitidas na access-list 1. R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#access-list 1 remark rede de gerenciamento R1(config)#line vty 0 15 R1(config-line)#access-class 1 in

Vamos analisar a configuração realizada e ver mais alguns ajustes que precisam ser realizados. Note os campos marcados que você vai lembrar que o enable secret vem criptografado por padrão no show running-config, já o enable password não, ou seja, a senha é mostrada em testo claro no show running-config, assim como as senhas da VTY e console. Lembra como reoslver esse problema? R1#sho run Building configuration... Current configuration : 1843 bytes ! ! Last configuration change at 20:14:38 UTC Tue May 12 2015 ! upgrade fpd auto


  

 






  




Página 296  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br version 15.0 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! enable secret 5 $1$d2Y2$s/LRhI1TeOGG4v/TVBzdF1 enable password dltec ! !### Saídas Omitidas ### ! access-list 1 permit 10.0.0.0 0.0.0.255 access-list 1 remark rede de gerenciamento no cdp log mismatch duplex ! line con 0 exec-timeout 0 0 privilege level 15 password cisco logging synchronous login stopbits 1 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line vty 0 4 access-class 1 in password cisco123 login line vty 5 15 access-class 1 in password cisco123 login ! end

Sobre o enable secret for realizado em roteadores com Cisco IOS mais atuais irá aparecer um "4" ao invés do "5" de MD5, o que significa que o hash é feito com SHA-256, que é mais seguro que o MD5, veja exemplo abaixo. enable secret 4 tnhtc92DXBhelxjYk8LWJrPV36S2i4ntXrpb4RFmfqY

Nos que suportam SHA você vai poder até escolher digitando "enable secret 4" para criptografar com SHA ou "enable secret 5" para criptografar com MD5. Para resolver o problema das senhas em texto claro não criptografadas podemos utilizar o comando em modo de configuração geral "service password-encryption" que criptografa as senhas em modo texto utilizando um padrão chamado "Vigenere cipher" de nível 7, o qual é bastante fraca e pode ser quebrada facilmente em sites da Internet. Veja configuração e show run a seguir.


  

 






  




Página 297  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1(config)#service password-encryption R1(config)#do show run Building configuration... Current configuration : 1882 bytes ! ! Last configuration change at 20:14:38 UTC Tue May 12 2015 ! ! ### saídas omitidas ### ! enable secret 5 $1$d2Y2$s/LRhI1TeOGG4v/TVBzdF1 enable password 7 0300571F030C ! ! ### saídas omitidas ### ! ! line con 0 exec-timeout 0 0 privilege level 15 password 7 01100F175804 logging synchronous login stopbits 1 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous stopbits 1 line vty 0 4 access-class 1 in password 7 0822455D0A16544541 login line vty 5 15 access-class 1 in password 7 0822455D0A16544541 login ! end

Com essas configurações apenas uma senha é solicitada quando tentamos entrar nas lines e apenas o Telnet está ativado, pois ele é o padrão. Para ativar o SSH é preciso configurar. Outra forma de configurar a autenticação na console e VTY é através de um banco de dados local de usuários e senhas configurados com o comando "username" em modo de configuração global e definido o "login local" dentro da linha. Veja exemplo abaixo. R1(config)#username dltec ? aaa AAA directive access-class Restrict access by access-class autocommand Automatically issue a command after the user logs in callback-dialstring Callback dialstring callback-line Associate a specific line with this callback callback-rotary Associate a rotary group with this callback dnis Do not require password when obtained via DNIS nocallback-verify Do not require authentication after callback noescape Prevent the user from using an escape character nohangup Do not disconnect after an automatic command nopassword No password is required for the user to log in one-time Specify that the username/password is valid for only one


  

 






  




Página 298  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br time Specify the password for the user Set user privilege level Specify the secret for the user Limit the user's number of inbound links Set view name

password privilege secret user-maxlinks view

R1(config)#username dltec secret dltec123 R1(config)#do show run | include username username dltec secret 5 $1$pU/I$7xDFCpdFcw5cNnHI7Cpo30 R1(config)# R1(config)#line vty 0 15 R1(config-line)#login local R1(config-line)#exit R1(config)#

As duas opções mais utilizadas após o username são "secret" que cria uma senha criptografada em MD5 ou SHA, dependendo da versão de Cisco IOS, e a opção privilege que pode fazer com que o usuário já se logue em um outro modo privilegiado, por exemplo, o comando "username dltec privilege 15" faz com que o usuário dltec já se logue como usuário privilegiado. Algumas vezes essa configuração é necessárias para ferramentas de monitoração como CCP. Para fazer com que a line VTY, AUX ou console utilizem o banco de dados local de usuário ou senha basta entrar na line e inserir o comando "login local" como grifado no exemplo. 2.2 Ativando outros serviços nos roteadores - HTTP, HTTPS, SSH, SCP e (T)FTP No começo tópico eestudamos o uso de cadaagora um desses deativar rede que ser ativados nosdesse roteadores também em switches, vamosserviços ver como cadapodem um deles utilizando a autenticação local, com excessão do SCP que precisa do AAA para sua ativação. Nas empresas a ativação dos serviços de rede em roteadores normalmente depende da política de segurança para os roteadores, por isso cuidado ao fazer alterações em ambientes de produção. Recomendamos como sempre você estudar utilizando um simulador e não implementar nos dispositivos da empresa onde você trabalha antes de passar pelos processos e trâmites de aprovação e mudanças que por ventura sua empresa tenha. Outra recomendação é que os seviços sejam implementados somente para hosts vindo da Intranet, caso um funcionário necessite acessar recursos a partir da Internet o ideal é o uso de VPNs para acesso seguro aos recursos sem risco de exposição na Internet. 2.2.1 Serviços de HTTP e HTTPS

A ativação do HTTP e HTTPS é bem simples e você pode usar autenticação local ou através de AAA para ambos os protocolos. Nesse exemplo vamos utilizar o login local através do banco de usuários criados no próprio roteador com o comando "username". Router(config)# ! Ativando o serviço de HTTP Router(config)# ip http server Router(config)#! Ativando o serviço de HTTPS R1(config)#ip http secure-server % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R1(config)# *May 12 22:35:26.137: %PKI-4-NOAUTOSAVE: Configuration was modified. "write memory" to save new certificate Router(config)#! Definindo a autenticação com usuário/senha locais


  

 






  




Issue

Página 299  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br Router(config)# ip http authentication local Router(config)#! Criando um usuário Router(config)# username privilege secret

Note que ao digitar o comando para ativação do HTTPS uma chave de criptografia RSA de 1024 bits será criada automaticamente e o IOS recomenda salvar a configuração para gravar essa chave. Uma dica é para que você possa acessar quaisquer opções via HTTP/HTTPS utilize o usuário com nível de privilégio 15 (EXEC) que é opcional e está marcado em azul no comando. Caso o privilégio não seja difinido o usuário terá nível 1 (usuário sem privilégios). Você pode fechar mais ainda a segurança do acesso remoto via Web utilizando apenas HTTPS, o qual é um protocolo seguro, e fazendo uma restrição via Access Class para que apenas as redes de gerenciamento permitidas possa ter acesso via porta TCP 443, veja exemplo abaixo onde somente a rede 10.0.0.0/24 terá acesso Web. R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#ip http access-class ? <1-99> Access list number R1(config)#ip http access-class 1 R1(config)#

Para acessar o roteador via HTTP utilize qualquer browser e digite "http://IP-do-Router" e via HTTPS é só digitar "https://" e depois o IP do roteador. Você pode via HTTP/HTTPS dar comandos, tanto de configuração com show, fazer testes de conectividade, monitorar o roteador e muito mais.

É possível também alterar o número das portas utilizadas pelo HTTP e HTTPS com os comandos abaixo, com isso ao invés de escutar nas portas padrões TCP 80 e 443 o administrador de redes pode dificultar a vida dos "curiosos" alterando esses valores. No exemplo vamos alterar a porta HTTP para 8080 e HTTPS para 4443 respectivamente. DlteC-FW-GW(config)#ip http port ? 80 Default port number <1024-65535> Port number range DlteC-FW-GW(config)#ip http port 8080 DlteC-FW-GW(config)#ip http secure-port ? 443 Default secure port <1025-65535> Secure port number range DlteC-FW-GW(config)#ip http secure-port 4443


  

 






  




Página 300  



 


2.2.2 Serviço de SSH

Apesar de ser conteúdo do CCNA vamos repetir aqui os passos para ativação do SSH, o qual pode ser acessado via um cliente como o Putty. O SSH precisa ser ativado, criada a chave de criptografia, e depois habilitado nas lines VTY. Para autenticação será necessário aqui também criar um usuário e senha, o qual pode ser o mesmo para todos os serviços, além disso, em sequência precisamos alterar o hostname padrão, definir um nome de domínio, criar a chave de criptografia com 1024 bits, definir o timeout (60s) e número de tentativas para autenticação (2). Router(config)#hostname R1 R1(config)#username cisco secret cisco123 R1(config)#ip domain-name rtp.cisco.com R1(config)#crypto key generate rsa modulus 1024 % You already have RSA keys defined named R1.rtp.cisco.com. % They will be replaced. % The key modulus size is 1024 bits % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R1(config)#ip ssh time-out 60 R1(config)#ip ssh authentication-retries 2 R1(config)#

Agora podemos habilitar o SSH na line VTY. Podemos deixar só o SSH ou permitir que o roteador aceite SSH e Telnet, qual escolher depende do exercício (em caso de exame) ou política de segurança da empresa. R1(config)#line vty 0 15 R1(config-line)#transport input SSH R1(config-line)#transport input ? all All protocols mop DEC MOP Remote Console Protocol none No protocols pad X.3 PAD rlogin Unix rlogin protocol ssh TCP/IP SSH protocol telnet TCP/IP Telnet protocol udptn UDPTN async via UDP protocol v120 Async over ISDN R1(config-line)#transport input telnet ssh R1(config-line)#

Na linha marcada em cinza permitimos apenas o SSH, já na linha marcada em azul permitimos que o usuário conecte-se a linha VTY com Telnet ou SSH.


  

 






  




Página 301  



 


2.2.3 Serviço de TFTP

Normalmente utilizamos o TFTP para transferir os arquivos do roteador para um servidor TFTP externo e vice versa como um cliente TFTP através do comando "copy", porém você pode ativar o serviço de FTP no roteador e compartilhar arquivos de configuração ou imagens de IOS. Para isso você deve procurar na Flash o arquivo que você deseja compartilhar e definir com o comando "tftp server" em modo de configuração global esse arquivo, veja exemplo abaixo onde vamos compartilhar via TFTP o Cisco IOS do roteador para possibilitar cópia router-a-router sem a necessidade de um TFTP Server configurado na rede. DlteC#show flash: -#- --length-- -----date/time------ path 1 50825880 Dec 26 2013 15:51:00 c2801-adventerprisek9-mz.124-24.T8.bin ### saídas omitidas ### 31854592 bytes available (93954048 bytes used) DlteC#conf t Enter configuration commands, one per line. End with CNTL/Z. DlteC(config)#tftp-server ? archive: Allow URL file TFTP load requests flash: Allow URL file TFTP load requests null: Allow URL file TFTP load requests nvram: Allow URL file TFTP load requests system: Allow URL file TFTP load requests tmpsys: Allow URL file TFTP load requests xmodem: Allow URL file TFTP load requests ymodem:

Allow URL file TFTP load requests

DlteC(config)#tftp-server flash:c2801-adventerprisek9-mz.124-24.T8.bin ? <1-99> IP access list of requesting hosts <1300-1999> IP expanded access list of requesting hosts alias file alias DlteC(config)#tftp-server DlteC(config)#

flash:c2801-adventerprisek9-mz.124-24.T8.bin

Com o show flash podemos ver o arquivo que queremos compartilhar, depois entramos em modo de configuração global para com o comando "tftp server" mais a localização do arquivo disponibilizá-lo via serviço de TFTP. Para melhorar a segurança você pode ainda vincular no final um número de ACL para limitar acesso de usuários não permitidos na cópia dos arquivos dos roteadores, pois o TFTP não tem autenticação e com esse comando qualquer usuário com um cliente TFTP poderia copiar o Cisco IOS do roteador local.


  

 






  




Página 302  



 


2.2.4 Serviço de FTP

O FTP é uma opção mais segura para copiar e enviar arquivos armazenados agora em um servidor que possui autenticação e acesso mais simples a partir de um computador. Veja os passos de configuração abaixo. DlteC#conf t Enter configuration commands, one per line. DlteC(config)#ip ftp username cisco DlteC(config)#ip ftp password cisco123

End with CNTL/Z.

DlteC(config)#no passive DlteC(config)#ip ip ftpftp source-interface FastEthernet0/1.10

O usuário e a senha são os de acesso ao servidor FTP, já o comando "no ip ftp passive" é o padrão que aceita os dois tipos de servidores FTP. Com o comando "ip ftp source-interface" você pode definir o IP da interface que será coloca como srcem nos pacotes IP. Para realizar a cópia de um arquivo do servidor para o router utilize o comando "copy ftp://IPservidor/pasta flash:". Já para salvar um arquivo no servidor FTP utilize "copy flash: ftp://IPservidor/pasta". Veja exemplo abaixo onde vamos fazer um backup do Cisco IOS no servidor FTP com IP 192.168.1.8. DlteC#copy flash:c2801-adventerprisek9-mz.124-24.T8.bin ftp://192.168.1.12 Address or name of remote host [192.168.1.12]? Destination filename [c2801-adventerprisek9-mz.124-24.T8.bin]? Writing c2801-adventerprisek9-mz.124-24.T8.bin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 50825880 bytes copied in 83.104 secs (611594 bytes/sec) DlteC#

Abaixo segue tela com o arquivo copiado dentro do servidor TFTP.


  

 






  




Página 303  



 


2.2.5 Serviço de SCP

Para ativar o serviço de SCP como servidor em um roteador Cisco precisamos seguir seis passos básicos e ativar o AAA, o qual veremos no próximo tópico desse capítulo. Ele permite a cópia segura de arquivos através do Secure Shell. Abaixo seguem os comandos gerais de ativação. 1. enable 2. configure terminal 3. aaa new-model 4. {default | list-name} method1[method2...] 5. aaa aaaauthentication authorization login {network | exec | commands level | reverse-access | configuration} {default | list-name} [method1 [method2...]] 6. username name [privilege level]{password encryption-type encrypted-password} 7. ip scp server enable Veja um exemplo de configuração abaixo onde a configuração do AAA tanto para autenticação como para autorização foi realizada via banco de dados local. R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#aaa new-model R1(config)#aaa authentication login default local R1(config)#aaa authorization exec default local R1(config)#username dltec privilege 15 secret dltec123 R1(config)#! Certifique-se antes que o SSH está ativado e funcionando R1(config)#ip scp server enable R1(config)#

Para utilizar a cópia segura via SCP utilize o comando "copy" com a opção "scp://" na srcem ou destino, conforme a necessidade de troca de arquivos entre os roteadores, veja exemplo abaixo. DlteC#copy flash:syncinfo.xml scp://192.168.1.86 Address or name of remote host [192.168.1.86]? Destination username [dltec]? Destination filename [syncinfo.xml]? Writing syncinfo.xml Password: ! 69 bytes copied in 3.916 secs (18 bytes/sec) DlteC#

Vamos analisar agora a flash do roteador que está atuando como SCP server. R1#show disk0: -#- --length-- -----date/time------ path 1 2

24439 May 13 2015 15:13:28 dltec-confg 69 May 13 2015 15:16:14 syncinfo.xml

133890048 bytes available (28672 bytes used) R1#

Você pode utilizar o comando "copy [flash:CiscoIOS.bin ou running-config] scp://ip-scp-server" para transmitir arquivos de forma segura mesmo que se roteador não tenha um servidor SCP ativo, pois ele já atua por padrão como cliente SCP.


  

 






  




Página 304  



 


2.2.6 Arquivos de Core Dump

Um arquivo de "core dump" contém informações sobre processos que são finalizados antes do previsto e causam um "crash" no roteador, normalmente seguido de um reload expontâneo. Esses arquivos são utilizados pela Cisco para analisar o que causou (root cause) o problema, que pode ser desde uma falha no código do sistema operacional Cisco IOS até bug's. Existem quatro maneiras de se gerar e armazenar um core dump: 1. Via FTP 2. Via Remote Copy Protocol (RCP) 3. 4. Via Via Flash TFTP Por padrão ele vem desabilitado, porém inserimos uma configuração básica como exemplo para que o arquivo de dump seja enviado via FTP: DlteC(config)#ip ftp username dltec ! Define usuário e senha do FTP DlteC(config)#ip ftp password dltec123 ! que irá quardar o DUMP DlteC(config)#exception protocol ftp ! Define o protocolo FTP DlteC(config)#exception dump 192.168.1.12 ! Endereço do servidor FTP DlteC(config)#end DlteC#show exception 192.168.1.12 DlteC#

2.2.7 Verificando as portas conectadas

Você pode verificar os serviços que estão sendo acessados com os comandos "show tcp brief" e "show udp". Veja exemplo abaixo. DlteC#show udp Proto Remote 17 195.154.150.68 17 192.168.1.199 17 192.168.1.26 17 192.168.1.253 17 --listen-17(v6) --listen-17 0.0.0.0 17 192.168.1.84 17 --listen-17 --listen-17(v6) --listen-17(v6) --listen-17(v6) --listen-17 --listen-17(v6) --listen-17 --listen--

Port 5070 49 162 162

Local 192.168.10.2 192.168.1.1 192.168.1.1 192.168.1.1 10.10.10.10 --any-0 10.10.10.10 68 10.10.10.10 10.10.10.10 10.10.10.10 FE80::1 FE80::1 FE80::1 10.10.10.10 FE80::1 10.10.10.10

17(v6) --listen-17 192.168.1.253 DlteC#

FE80::1 514 192.168.1.1

DlteC#show tcp brief TCB Local Address 67D9B9DC 192.168.1.1.23 69A2421C 192.168.2.1.2000 676C3F30 192.168.1.1.33597 69A23BE0 192.168.2.1.2000 69A235A4 192.168.2.1.2000 DlteC#

  

 



4500 49772

In Out Stat TTY OutputIF 0 0 211 0 0 0 21 0 0 0 0 0 0 0 0 0 0 0 1001 0 0 0 20001 0 0 0 11 0 0 0 2211 0 0 0 1011 0 0 0 1011 0 0 0 20001 0 0 0 20011 0 0 0 20011 0 0 0 1011 0 0 0 20011 0 0 0 1011 0 0 0

0 20011 0 400211

Foreign Address 192.168.1.84.58578 192.168.2.22.17536 192.168.1.86.22 192.168.2.20.41372 192.168.2.21.29437


Port 5060 49 54186 59534 123 123 2517 67 162 53328 161 162 63965 500 500 4500




  

0

(state) ESTAB ESTAB CLOSED ESTAB ESTAB


0



Página 305  



 


2.3 Cisco IOS AAA - Local database, TACACS+ e RADIUS O AAA (Authentication, Authorization, and Accounting) oferece uma forma para a autenticação de usuários em servidores ou dispositivos de conectividade (router, switch, etc), além de controlar o nível de acesso destes usuários para os recursos desejados e gravar os comandos realizados para futuras auditorias. Veja imagem abaixo com um esquema do processo de autenticação via servidor externo AAA.

Para que isto seja possível, o AAA participa em três etapas durante este processo: 1. Autenticação de usuários: Com o AAA, é possível centralizar o gerenciamento de todas as contas de usuários e respectivas senhas, facilitando bastante o trabalho do administrador da rede. O administrador da rede poderá especificar diversos mecanismos para a autenticação de usuários, entre eles RADIUS, TACACS+ ou Kerberos e, para que isto ocorra, a ordem de execução destes componentes deverá ser informada e devidamente associada para uma interface ou mais interfaces do equipamento de rede. Por exemplo, um usuário que necessita configurar uma rota em um roteador Cisco poderá informar o seu username e password para o acesso ao equipamento. 2. Autorização para a execução de comandos: Após a autenticação do usuário, o AAA precisa informar ao roteador sobre os comandos que o referido usuário poderá executar no terminal. É possível limitar a quantidade de comandos disponíveis para a execução das seguintes formas: por usuário, perfil ou grupo de usuários. 3. Auditar os acessos ao equipamento: O AAA enviará dados sobre cada comando executado pelo usuário durante uma sessão com o roteador. Com este recurso, poderemos identificar e controlar todas as atividades de configuração e monitoramento efetuadas no roteador. Por exemplo, o administrador de rede pode analisar o que o usuário dltecuser fez durante sua sessão e quando ele executou os comandos. Mais em roteadores e switcheseCisco o AAA pode utilizar um banco de dados local especificamente ou servidor externo para autenticação autorização, porém normalmente o que é configurado na prática é o AAA com servidores externos TACACS+ ou RADIUS e o banco de dados local é utilizado como "fallback", ou seja, caso haja um problema com a comunicação entre o roteador e o servidor ele pode utilizar um usuário do banco de dados local para fazer o login, por exemplo.


  

 






  




Página 306  



 


2.3.1 Protocolos TACAS+ e RADIUS

O protocolo RADIUS (Remote Authentication Dial-In User Service) hoje faz parte dos padrões da IETF e pode funcionar juntamente com outros serviços. O RADIUS tem uma porta para autenticação/autorização (UDP 1645 ou UDP 1812) e outra para contabilidade (accounting UDP 1646 ou UDP 1813). O processo de autenticação do RADIUS utiliza um servidor que tem contato com o cliente, um servidor RADIUS e um banco de dados onde os dados dos usuários são armazenados. A autenticação é feita por meio de uma mensagem que o cliente RADIUS envia para o servidor RADIUS login ee senha. o servidor recebe eleEm valida o cliente verifica ocontendo login, senha outros Quando parâmetros que vêm coma mensagem, a mensagem. caso de umae autenticação válida, o servidor envia ao cliente uma mensagem permitindo o acesso bem como as ações permitidas pelo nível de acesso. Na figura a seguir você pode verificar as etapas de autenticação para acesso remoto em um roteador utilizando o RADIUS.

O protocolo TACACS+ é proprietário da cisco sendo suportado pela grande maioria dos roteadores da cisco. É uma melhoramento do protocolo aberto TACACS. O TACACS+ também é um protocolo que veio após o RADIUS e portanto apresenta algumas vantagens em relação a este. O TACACS+ usa conexões TCP (mais segura) enquanto que o RADIUS faz transporte via UDP (menos seguro). Do ponto de vista da segurança a diferença entre os protocolos de transporte utilizados é fundamental. O RADIUS precisa trabalhar com um número maior de variáveis para suprir a falta de serviços do UDP. Como TACACS+ usa TCP, que é orientado a conexão, esses detalhes não são preocupação do protocolo TACACS+. Usando TCP é mais fácil descobrir quando um servidor está off-line e quando ele está simplesmente lento. O TACACS+ e criptografa todo Com o corpo pacote eé faz a separação entre autenticação autorização contabilização. essa do separação possível criar soluções de autorizaçãoe separadas. O TACACS+ utiliza o protocolo TCP na porta 49 para transmitir suas informações de maneira segura. Além disso, o TACACS+ tem suporte multiprotocolo. Na figura a seguir você pode verificar o mesmo processo para acesso remoto em um roteador utilizando agora o TACACS+ como protocolo de autenticação.


  

 






  




Página 307  



 


Portanto, ambos TACACS + e RADIUS são protocolos de autenticação, porém cada um suporta diferentes recursos e funcionalidades. Escolher entre o TACACS + ou RADIUS depende das necessidades da organização. Por exemplo, um grande provedor de acesso selecionar RADIUS porqueJásuporta um billing detalhado (contabilidade) necessárias parapode o faturamento dos usuários. uma organização com vários grupos de usuários pode preferir utilizar o TACACS +, porque possibilita a implementação de políticas de autorização que pode ser aplicada por usuário ou por grupo. Veja na tabela a seguir um resumo da comparação entre o TACACS+ e o RADIUS.


  

 






  




Página 308  



 


2.3.2 Exemplo de configuração de autenticação com servidor TACACS+

Apesar de não ser foco do CCNP ROUTE você vai notar que a configuração é realtivamente simples. Para configurar a autenticação baseada em servidores com TACACS+ ou RADIUS o processo é semelhante, basta seguir os 4 passos básicos abaixo: 1. Habilitar o AAA (aaa new-model) 2. Especificar o endereço IP do servidor ACS ou do servidor de autenticação externo 3. Configurar a chave secreta 4. Configurar a autenticação para usar um servidor RADIUS ou TACACS + (aqui podemos configurar a redundância para autenticação) Vamos mostrar um exemplo de configuração conforme figura a seguir onde existem dois servidores: 1. Servidor TACACS+ (ACS) com IP 172.16.41.151 2. Servidor RADIUS (ACS) com IP 172.16.41.186

A primeira opção para login será o TACACS+, a segunda o RADIUS e a terceira o usuário local case-sensitive. Veja a configuração abaixo. R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#username dltec secret dltec123 R2(config)#aaa new-model R2(config)#tacacs-server host 172.16.41.151 single-connection R2(config)#tacacs-server key CHAVE-TACACS R2(config)#radius-server host 172.16.41.186 R2(config)#radius-server key CHAVE-RADIUS R2(config)#aaa authentication login ADMIN group tacacs+ group radius local-case R2(config)#line vty 0 15 R2(config-line)#login authentication ADMIN R2(config-line)#

Portanto para o TACACS+ o comando “tacacs-server host” define o IP do servidor ACS que está suportando o serviço do TACACS. O subcomando single-connection colocado no final evita que a sessão seja fechada e aberta toda vez que haja um novo acesso, ficando uma


  

 






  




Página 309  



 


conexão aberta sempre para melhorar a performance da conexão. Já o comando “tacacsserver key” define a senha para acesso ao servidor. O mesmo princípio serve para o RADIUS, porém para o RADIUS não existe o subcomando “single-connection”, pois ele trabalha com UDP que não é orientado a conexão. O comando para definir o método de autenticação foi o mesmo utilizado para o AAA local, sendo que o início do comando é o “aaa authentication login ADMIN”, logo após definidos os métodos: 1. Primeiro via TACACS+ com o group tacacs+ 2. Segundo via RADIUS com o group radius 3. Terceiro via usuário/senha locais com o local-case (distingue letras maiúsculas e minúsculas no usuário) que é o fallback caso o TACACS+ e o RADIUS fiquem indisponíveis para que o administrador consiga logar com um usuário local. Com a configuração realizada o usuário que tentar se logar no roteador primeiro vai ser encaminha para um servidor TACACS+ com endereço 172.16.41.151, caso esse servidor esteja indisponível o roteador tentará com o Servidor RADIUS (ACS) com IP 172.16.41.186 e caso esse servidor também esteja "fora do ar" ele tentará buscar correspondência no banco de dados local que são os comandos "username" como fallback. O comando "login authentication ADMIN" aplicado na line VTY vincula a lista de métodos de autenticação criada a autenticação do Telnet/SSH feita via VTY "amarrando" todo processo de autenticação com o AAA. Em Cisco IOSs mais novos você pode receber a mensagem "This cli will be deprecated soon. Use new abaixo serverdo cli", isso porque existe uma nova forma de configurar os servidores, veja exemplo TACACS+ no novo padrão. tacacs server AUTH address ipv4 172.16.41.151 key CHAVE-TACACS

Lembre-se mais uma vez que mostramos um exemplo de configuração como adendo, porém a prova irá cobrar o conceito de AAA, TACACS+ e RADIUS.


  

 






  




Página 310  



 


3 Segurança em Roteadores - ACLs e uRPF Sobre segurança em roteadores as duas novidades que foram introduzidas no CCNP ROUTE são as ACLs Temporizadas (time-based) e o "Unicast reverse path forwarding" (uRPF). Os demais assuntos são todos estudados nas versões atuais do CCNA, CCENT e ICND-2, por isso vamos focar nas novidades e a revisão das ACLs padrão e estendida será feita através de exemplos práticos para segurança da infraestrutura e seguindo o padrão da documentação oficial para a prova 300-101. 3.1 Unicast Reverse Path Forwarding - uRPF O uRPF permite que o roteador analise a srcem do pacote e decida se encaminha ou descarta o pacote com base no método definido. Esta funcionalidade permite limitar ataques com base em Spoofed Addresses (pacotes IP com endereço ou destino de srcem falso), pois se o pacote recebido não chegar pelo melhor caminho de acordo com a FIB do roteador ele será descartado por padrão. Veja imagem abaixo com que reprensenta o uRPF.

Lembre-se que o roteador não se importa com a srcem para rotear um pacote, pois ele analisa apenas o destino. Com o uRPF evitamos o uso de ACLs e ganhamos em desempenho, pois o processo é feito em conjunto com o CEF. Para examinar o endereço de srcem dos pacotes IP é preciso ativar na interface de entrada o recurso (feature) de Reverse Path Forwarding (uRPF) utilizando o comando "ip verify unicast source reachable-via { rx | any } [allow-default] [allow-self-ping] [NumACL]". Para utilizar esse recurso o CEF deverá estar ativo nas interfaces.


  

 






  




Página 311  



 


Os pacotes podem ser examinados pelo uRPF de 3 maneiras: 





Strict Mode: Usando o parâmetro rx o router verifica através da FIB (Forward information base) se a interface de saída será a mesma por onde os pacotes foram recebidos. Caso crontrário os pacotes são descartados. Loose Mode: Usando o parâmetro any o router verifica de existe alguma rota explícita que seja possível usar para chegar ao IP de srcem analisando a tabela de roteamento. VRF Mode: No modo VRF (conhecido como uRPF versão 3 ou uRPFv3 ) o roteador trabalha de forma análoga ao "Loose Mode", porém verificando o endereço IP na FIB

específica de cada VRF. O uRPF ignora a rota padrão quando efetua a análise, por isso se o pacote tem srcem alcaçável somente através de uma rota padrão ele será descartado por padrão. Para incluir a default route na análise deve ser incluido o parâmetro "allow-default". O parêmtro "allow-self-ping" permite o ping para o próprio roteador, porém a Cisco não recomenda essa opção por questões de segurança. A última opção " Num-ACL" permite que você crie uma ACL para permitir ou negar o tráfego que foi rejeitado pelo uRPF. Um dos cuidados a serem tomados é com fluxos assimétricos, por exemplo, a empresa tem dois links e o usuário envia o tráfego pelo link A e recebe o retorno pelo link B. Nesse caso o "Strict Mode" bloquearia o tráfego porque o retorno está em um caminho diferente. Nesses casos o usfo do "Loose Mode" é mais aconselhável. 3.1.1 Ativando e Verificando o uRPF

Vamos ativar o uRPF na topologia abaixo nas interfaces g1/0 e f0/0 do roteador R1.

R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int f0/0 R1(config-if)#ip verify unicast source reachable-via any R1(config-if)#int g1/0 R1(config-if)#ip verify unicast source reachable-via any R1(config-if)#

Com os comandos adicionados se o IP de srcem que chegar no roteador R1 não estiverem em sua FIB deverão ser bloqueados pelo uRPF, vamos ver a FIB e a tabela de roteamento IP.


  

 






  




Página 312  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1#sho ip route ### Saída omitidas ### Gateway of last resort is 192.168.1.1 to network 0.0.0.0 S* C L C L

0.0.0.0/0 [254/0] via 192.168.1.1 10.0.0.0/8 is variably subnetted , 2 subnets, 2 masks 10.1.0.0/30 is directly connected, GigabitEthernet1/0 10.1.0.1/32 is directly connected, GigabitEthernet1/0 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.1.0/24 is directly connected, FastEthernet0/0 192.168.1.86/32 is directly connected, FastEthernet0/0

R1#show ip cef Prefix 0.0.0.0/0 0.0.0.0/8 0.0.0.0/32 10.1.0.0/30 10.1.0.0/32 10.1.0.1/32 10.1.0.2/32 10.1.0.3/32 127.0.0.0/8 192.168.1.0/24 192.168.1.0/32 192.168.1.1/32 192.168.1.80/32 192.168.1.86/32 192.168.1.255/32 224.0.0.0/4 224.0.0.0/24 240.0.0.0/4 255.255.255.255/32 R1#

Next Hop 192.168.1.1 drop receive attached receive receive attached receive drop attached receive attached attached receive

Interface FastEthernet0/0

receive drop receive drop receive

FastEthernet0/0

GigabitEthernet1/0 GigabitEthernet1/0 GigabitEthernet1/0 GigabitEthernet1/0 GigabitEthernet1/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0 FastEthernet0/0

Vamos fazer um teste pingando do host Kali para o endereço 10.1.0.1 do roteador R1. Esse teste deve dar certo!


  

 






  




Página 313  



 


Agora vamos utilizar um comando para fazer o a falsificação do IP e voltar a pingar a interface fast 0/0 de R1.

Com o comando show ip interface fast 0/0 (interface de entrada dos pacotes falsificados) podemos ver a contagem de endereços bloqueados pelo uRPF. Foram no total 178.285 descartes de pings feitos com IPs falsificados que o uRPF pegou nesse teste. R1#sho ip interface f0/0 FastEthernet0/0 is up, line protocol is up Internet address is 192.168.1.86/24 Broadcast address is 255.255.255.255 ### Saídas Omitidas ### WCCP Redirect exclude is disabled IP verify source reachable-via ANY 178285 verification drops 0 suppressed verification drops 0 verification drop-rate R1#

O comando "show cef interface fast 0/0" possibilita que você veja também se o uRPF está ativo na interface. Veja saída abaixo. R1#show cef interface f0/0 FastEthernet0/0 is up (if_number 3) Corresponding hwidb fast_if_number 3 Corresponding hwidb firstsw->if_number 3 Internet address is 192.168.1.86/24 ICMP redirects are always sent Per packet load-sharing is disabled IP unicast RPF check is enabled Input features: uRPF IP policy routing is disabled BGP based policy accounting on input is disabled BGP based policy accounting on output is disabled IPv6 CEF switching enabled ### Saídas Omitidas ### Slot Slot unit 0 VC -1 IP MTU 1500 R1#


  

 






  




Página 314  



 


3.2 Time-based ACLs Criar ACLs baseadas em períodos (time-based) é uma ferramenta importante para um administrador de redes, pois as empresas atualmente enfrentam o problema do uso das redes sociais e Internet pelos funcionários durante o horário de trabalho. Com uma ACL time-based o administrador pode liberar acesso a Internet apenas a partir de um determinado período do dia, limitando as horas de acesso a Internet, por exemplo. Usamos como exemplo o acesso a Internet, mas poderíamos limitar por horário o acesso a quaisquer serviços. Para configurar uma ACL temporizada devemos seguir 3 etapas: 1. Definir um nome a ser atribuido a um determinado período Router(config)#time-range nome_do_timerange

2. Definir um intervalo em que as ACLs serão aplicadas. Router(config-time-range)# periodic dia_da_semana hh:mm to [dia_da_semana] hh:mm

Valem nomes de dias da semana em inglês e a hora no formato hh:mm. O parâmetro dia_da_semana pode ser: 

  

Um dia específico da semana: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday ou Sunday Daily (todo dia) Weekdays (segunda a sexta) Weekend (sábado e domingo)

Outra forma, seria definir um tempo absoluto definindo apenas a data de inicio e data de fim: Router(config-time-range)# absolute [data_de_inicio] [data_de_fim]

3. Criar uma ACL e aplicar as regras configuradas. Note que o sucesso das time based ACLs depende mais do nosso conhecimento de regras de ACLs já discutidas anteriormente. Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-mask] [operator operand] destination-addr [destination-mask] [operator operand] [established] [log | log-input] [established] [time-range name_of_time_range]

Depois de criada a ACL aplique em uma interface na direção correta. 3.2.1 Exemplo Prático

Vamos a um exemplo prático onde o administrador de rede quer limitar o horário de acesso a Internet pelos funcionários apenas durante a 1 hora de almoço, entre 12:30h e 13:30h, e no intervalo entre dois turnos, o qual vai das 17h às 20h.


  

 






  




Página 315  



 


Veja as configurações abaixo. R1(config)# time-range Internet-livre R1(config-time-range)# periodic weekdays 12:30 to 13:30 R1(config-time-range)# periodic weekdays 17:00 to 20:00 R1(config-time-range)# exit R1(config)# access-list 110 permit ip 192.168.1.0 0.0.0.255 any time-range Internet-livre R1(config)# access-list 110 deny ip any any R1(config)# interface FastEthernet 0/1 R1(config-if)# ip access-group 110 in R1(config-if)# exit

3.3 ACLs de Infraestrutura Uma ACL de Infraestrutura ou "Infrastructure ACL" tem a função de proteger os dispositivos de rede em geral e normalmente é aplicada nos pontos de entrada da rede, ou seja, nos roteadores de borda da Internet de um sistema autônomo (Edge Network). São listas de acesso IPv4 e IPv6 (se houver IPv6 implementado) que visam bloquear (deny) acesso de fora aos dispositivos que fazem parte da infraestrutura da rede, por exemplo, bloquear acesso às interfaces dos roteadores, assim como bloquear fragmentos de pacotes, ataque de spoofing, endereços privativos (RFC 1918 e 3330). Ao mesmo tempo essas ACLs devem permitir tráfego de trânsito, por exemplo, pacotes que são destinados a servidores e hosts internos permitidos, assim como permitir formação de vizinhança BGP nos próprios roteadores de borda e tráfego de gerenciamento (SSH, SNMP, ping, etc.). Podemos dividir de forma abrangente o tráfego de um roteador em duas categorias, a primeira é aquele destinado ao próprio roteador, o qual o processador terá que tratar diretamente, e o segundo que é o tráfego que passa pelo roteador, que podemos chamar de tráfego de trânsito. A maioria das vezes o tráfego simplesmente passa ou é encaminhado pelo roteador, ou seja, em sua maioria é tráfego de trânsito. Porém existe um porcentagem do tráfego que o próprio roteador terá que tratar, por exemplo, protocolos de roteamento, acesso remoto via Telnet ou SSH e gerenciamento de rede via SNMP. Além disso, protocolos como o ICMP também são processados pela CPU do roteador. O tráfego excessivo pode causar uso excessivo da CPU, resultando em perda de pacote e até a indisponibilidade total do roteador, caracterizando um ataque negação de serviço (denial-ofservice - DoS), por isso a liberação de ping, por exemplo, deve ser feita de maneira correta para evitar que um simples flooding de ICMP possa colocar o roteador em risco. Por isso filtrando tráfego destinado aos roteadores de infraestrutura na borda da rede muitos dos riscos a esses dispositivos são mitigados, pois os ataques são bloqueados no roteador de borda. Não confunda o que vamos fazer aqui com técnicas de filtragem genéricas, pois a proteção da infra com ACL está restrita aos protocolos e srcens dos equipamentos de infraestrutura.


  

 






  




Página 316  



 


Veja um exemplo de ACL de infraestrutura que será vinculada a interface serial 0/0 que está conectada a Internet. ip access-list extended INFRA ! remark Bloqueio de fragmentos deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments ! remark Bloquear RFC 1918 e registrar tentativas de spoofing deny ip 10.0.0.0 0.255.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log ! remark Permitindo BGP com o peer específico permit tcp host < bgp-peer-vizinho > host < bgp-peer-intern o > eq bgp permit tcp host < bgp-peer-vizinho > eq bgp host < bgp-peer-interno > remark Permitindo gerenciamento via SSH HTTPS SNMP e Ping permit tcp < IPs-de-gerenciamento > any eq 22 permit tcp < IPs-de-gerenciamento > any eq 443 permit tcp < IPs-de-gerenciamento > any eq 161 permit icmp < IPs-de-gerenciamento > any echo ! remark Bloquear trafego para redes internas de Infraestrutura deny ip any < endereçamento-interno-de-infra > ! remark Permitir trafego de transito permit ip any any exit ! ! Aplicar a ACL na interface de borda ou ! saída de Internet ! interface Serial0/0 ip access-group INFRA in

A ACL estendida criada inicia bloqueando os fragmentos TCP, UDP, ICMP e IP, assim como endereços privativos da RFC 1918 com a opção de "log" incluída para monitorar as tentativas de spoofing. Na sequência vem as permissões do protocolo de roteamento BGP e protocolos/ferramentas de gerenciamento de redes (SSH, HTTPS, SNMP e ping) sempre específicos para os vizinhos ou redes de gerenciamento. Na sequência bloqueamos o acesso aos IPs internos de infraestrutura, os quais são as redes e endereços de interfaces utilizadas switchespode e servidores que devem ser acessados apenas pela rede interna.nos Por roteadores, isso esse comando ser subdividido em vários dependendo de cada rede e sua estrutura de endereçamento. Por último vem a liberação do restante do tráfego de trânsito e a aplicação da ACL estendida na interface de borda com a Internet. Dica prática: ativar o "log" em uma ACL permite que você tenha uma visão do tráfego que está sendo bloqueado ou permitido na rede, porém ele pode fazer com que a CPU seja mais utilizada e acabe aumentando seu uso de maneira negativa, principalmente porque o log é feito via "process switching". A análise das entradas da ACL (access control entries - ACEs) e a Apostila/E-B     

  

 






  




Página 317  



 


geração de logs para transmissão via CLI e/ou Syslog são dois fatores que afetam o desempenho do roteador, pois ambos são "process-switched" e quando ativamos o "log" na ACL ele são simultaneamente ativados. No tópico específico de Logs vamos mostrar um exemplo para melhorar o desempenho caso haje necessidade de uso desse tipo de recurso. 3.4 Filtragem de pacotes IPv6 Lembre-se que um endereço IPv6 tem 128 bits e é escrito em hexadecimal, não mais em decimal pontuado, portanto as redes de srcem e destino nas ACLs serão diferentes. Já os protocolos de camadas taisé como TCP e UDP continuam os mesmos, para bloquear acesso aosuperiores, HTTP no IPv6 só selecionar na ACL o protocolo TCP portapor 80.exemplo, As ACLs IPv6 podem basicamente filtrar os seguintes itens:   







Endereços e/ou redes de srcem e destino. Portas TCP e/ou UDP de srcem e destino. Filtrar pacotes com cabeçalhos de extensão com base na informação do “next header” (próximo cabeçalho) ou então que contenha simplesmente a opção “Next header”. O deny implícito também está presente no final da ACL, porém com a exceção de pacotes de neighbor solicitation (NS) e neighbor advertisement (NA), pois eles são implicitamente habilitados. Se você quiser bloquear tudo no final de uma ACL IPv6 você precisará incluir regras explícitas com deny para o NS e NA. Se uma ACL que não foi criada ou apagada em modo de configuração global for aplicada a uma interface nada ocorre, assim como estudamos para o IPv4. ACLs do tipo reflexivas e time-based access lists são suportadas pelo IPv6. O comportamento é o mesmo que estudamos para o IPv6.

Note que a maior diferença é com o deny implícito que deixarequest), passar pacotes NS,solicitam utilizadoso para descobrir o MAC remoto em LANs (substituto do ARP e de RAdeque prefixo do roteador local para o processo de autoconfiguração (SLAAC – Stateless Address Auto Configuration). 3.4.1 Configurando uma ACL IPV6

Para configurar a ACL IPv6 utilizamos o mesmo princípio de criar as regras em modo de configuração global e depois aplicar a lista em uma interface, subinterface ou na VTY. Veja abaixo um exemplo de navegação nas opções de criação das listas. R1(config)#ipv6 access-list ? WORD User selected string identifying this access list log-update Control access list log updates R1(config)#ipv6 access-list CCNP-DlteC R1(config-ipv6-acl)#? IPv6 Access List configuration commands: default Set a command to its defaults deny evaluate exit no permit remark sequence

Specify packets to reject Evaluate an access list Exit from access-list configuration mode Negate a command or set its defaults Specify packets to forward Access list entry comment Sequence number for this entry

R1(config-ipv6-acl)#deny ? <0-255> An IPv6 protocol number X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/


  

 






  




Página 318  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br ahp any esp host icmp ipv6 pcp sctp tcp udp

Authentication Header Protocol Any source prefix Encapsulation Security Payload A single source host Internet Control Message Protocol Any IPv6 Payload Compression Protocol Streams Control Transmission Protocol Transmission Control Protocol User Datagram Protocol

R1(config-ipv6-acl)#deny 2000::/64 ? X:X:X:X::X/<0-128> IPv6 destination prefix x:x::y/ any Any destination prefix host A single destination host R1(config-ipv6-acl)#deny 2000::/64 any R1(config-ipv6-acl)#permit any any

No exemplo acima foi criada a lista de acesso com o nome CCNP-DlteC, a qual não permite pacotes com a rede de srcem 2000::/64, porém todos os demais pacotes IPv6 são permitidos. Para aplicar a lista na interface utilizamos o comando “ipv6 traffic-filter” com o nome da lista e o sentido do tráfego a ser filtrado (in ou out  igual ao que estudamos para IPv4). Veja a aplicação da lista acima na interface fast 0/0 do roteador. R1(config-)#int f0/0 R1(config-if)#ipv6 traffic-filter CCNP-DlteC out R1(config-if)#

Para aplicar a ACL IPv6 à VTY precisamos criar a lista em modo de configuração global e vinculá-la à line com o comando “ipv6 access-class”. Veja exemplo abaixo. R1(config)#ipv6 access-list cisco R1(config-ipv6-acl)# permit tcp host 2001:100:0:4::30 any eq 22 R1(config-ipv6-acl)#! R1(config-ipv6-acl)#line vty 0 4 R1(config-line)# ipv6 access-class cisco in

Com essa configuração apenas o host 2001:100:0:4::30 poderá acessar o roteador via SSH, não podendo fazer acesso via Telnet. 3.4.2 Exemplo de ACL IPv6

Vamos aproveitar o exemplo de ACL estendida do IPv4 e realizar as configurações com IPv6. Agora você deve configurar o roteador R1, que tem a sub-rede 2000::/64 em sua LAN (Fast 1/0) que para está que entroncada com um Switch de acesso e possui várias sub-redes na mesma interface, a rede 2002::/64 seja bloqueada quando tentar acessar os serviços de FTP e TFTP em quaisquer micros e servidores dentro dessa sub-rede específica. Todas as demais sub-redes devem ser permitidas para todos os serviços. O primeiro passo é verificar as portas e protocolos dos serviços a serem bloqueados:  

FTP: portas 20 e 21 do TCP TFTP: porta 69 do UDP


  

 






  




Página 319  



 


Note que os pacotes serão srcinados na sub-rede 2002::/64 e chegarão na rede de destino 2000::/64, ou seja, os micros da sub-rede 2002::/64 estão em um roteador remoto.

R2(config)#Ipv6 access-list bloq-2002 R2(config-ipv6-acl)# deny tcp 2002::/64 2000::/64 eq ftp R2(config-ipv6-acl)# deny tcp 2002::/64 2000::/64 eq ftp-data R2(config-ipv6-acl)# deny udp 2002::/64 2000::/64 eq tftp R2(config-ipv6-acl)# permit ip any any R2(config-ipv6-acl)#exit R2(config)#Interface fast 1/0 R2(config-if)# ipv6 traffic-filter bloq-2002 out R2(config-if)#end R2#

Para verificar as ACLs de IPV6 utilize os comandos show running-config e show ipv6 accesslist. R2#show running-config | begin ipv6 access-lis ipv6 access-list bloq-2002 deny tcp 2002::/64 2000::/64 eq ftp deny tcp 2002::/64 2000::/64 eq ftp-data deny udp 2002::/64 2000::/64 eq tftp permit ipv6 any any ### Saídas Omitidas ### R2#show running-config interface f0/0 Building configuration... Current configuration : 106 bytes ! interface FastEthernet1/0 no ip address ipv6 enable ipv6 address 2000::1/64 duplex full ipv6 traffic-filter bloq-2002 out end R2# R2#show ipv6 access-list IPv6 access list bloq-2002 deny tcp 2002::/64 2000::/64 deny tcp 2002::/64 2000::/64 deny udp 2002::/64 2000::/64 permit ipv6 any any sequence R2#


  

 





eq ftp sequence 10 eq ftp-data sequence 20 eq tftp sequence 30 40


  




Página 320  



 


4 Gerenciando Dispositivos Cisco Por incrível que pareça, nesse último tópico vamos estudar, ou melhor, revisar assuntos que fazem parte do CCNA R&S mais especificamente do ICND-2, porém com um pouco mais de foco nas questões de "gerenciamento seguro" dos roteadores, pois muitos protocolos e ferramentas de gerenciamento podem expor os dispositivos de infraestrutura se aplicados de maneira incorreta. O CCNP ROUTE na revisão atual irá cobrar o SNMP (v2c e v3), mensagens de logging, NTP (v3 e v4) e Netflow (v5 e v9). 4.1 Ativando e Verificando o Logging Os logs do roteador são as mensagens que ele fornece em caso de problemas, como quedas de interface, ou quando um acesso é realizado ou um evento ocorre, normalmente são as mensagens que recebemos via console e que "atrapalham" quando estamos configurando o roteador. Os logs possuem diversos níveis de amplitude de mensagens (de 0 a 7) que são geradas para o servidor de syslog, conforme abaixo: 0 - Emergency  provavelmente o sistema está fora. 1 - Alert  uma ação imediata é necessária. 2 - Critical  um evento crítico ocorreu. 3 - Error  o roteador teve um erro. 4 - Warning  essa condição requer atenção, é um aviso. 5 - Notification  uma situação normal, porém relevante ocorreu.

     





6 -–Informational significa que um normal 7 Debugging (nível padrão nos evento roteadores e aconteceu switches Cisco) mensagem de um debugging.





a saída é uma

Resumindo, dos níveis de 0 até 4 temos eventos que realmente podem impactar a operação do equipamento em questão, já dos níveis 5 a 7 são eventos com menor relevância. Temos que decidir no dia a dia até onde monitorar para não “entupir” o servidor de mensagens que não poderão ser interpretadas ou simplesmente são inúteis. Quanto maior a amplitude ou o nível de depuração do log, mais mensagens serão enviadas ao servidor de syslog, portanto a análise de nível do log deve ser feita com cuidado para não gerar sobrecarga no equipamento. Para configurar a amplitude do log enviado a um servidor externo entre com o comando em modo de configuração global: router(config)#logging trap nível

O nível pode ser o número ou o nome contido na lista acima. O nível 7 ou debug é o mais alto e o emergency o mais baixo, ou seja, menos rico em detalhes. Abaixo segue um exemplo alterando o nível do log para informacional: Router(config)#logging trap informational Router(config)# ! ou Router(config)#logging trap 6

Com o comando acima o roteador enviará ao syslog mensagens de nível 6 até zero, se configurássemos como nível 4 o roteador enviaria mensagens de 4 a zero. A mesma configuração pode ser feita para o armazenamento em buffer (logging buffered [0-7]) ou console (logging console [0-7]).


  

 






  




Página 321  



 


Lembre-se que essas mensagens são armazenadas nos roteadores e switches mesmo que não configuremos um servidor, pois o syslog é utilizado internamente também para: 







O logging buffered  armazenamento interno em memória RAM das mensagens nos roteadores e switches, portanto é apagado se reinicializarmos os equipamentos. Para desabilitar permanentemente o padrão de envio das mensagens de log para o buffer na memória RAM utilize o comando “no logging buffered” em modo de configuração global. Enviada mensagem para console (logging console)  ativada por padrão, são as mensagens que console enquanto estamos monitorando localmente os dispositivos. Paraaparecem desabilitarna permanentemente o padrão de envio das mensagens de log para o console utilize o comando “no logging console” em modo de configuração global. Na VTY podemos monitorar essas mensagens com o “terminal monitor”  por padrão as mensagens de syslog não são enviadas quando estamos conectados através de SSH ou Telnet, temos que ativar o recebimento das mensagens. Para desativar permanentemente as mensagens via terminal utilize o comando " no logging monitor" em modo de configuração global. Através de um servidor de syslog com o comando “logging ip-do-servidor”.

Se ativamos a monitoração das mensagens em uma sessão de SSH ou Telnet e queremos desabilita-la podemos utilizar o comando “terminal no monitor”. O tamanho do histórico do log gravado (logging history) no buffer por padrão é de 4096 bytes e pode ser alterado com o comando "logging buffered", veja exemplo abaixo onde vamos alterar o valor padrão para 16384 (4 vezes o padrão - best practice Cisco). DlteC-FW-GW(config)#logging <0-7> Loggingbuffered severity ?level <4096-2147483647> Logging buffer size alerts Immediate action needed (severity=1) critical Critical conditions (severity=2) debugging Debugging messages (severity=7) discriminator Establish MD-Buffer association emergencies System is unusable (severity=0) errors Error conditions (severity=3) filtered Enable filtered logging informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4) xml Enable logging in XML to XML logging buffer DlteC-FW-GW(config)#logging buffered 16384

Esse tamanho afeta a quantidade de mensagens armazenadas no roteador, porém quanto maior mais memória RAM será O valor pode poissibilitar melhores análises em casos como,necessária. por exemplo, ataques de ser DoSaumentado e DDoS ou para troubleshootings em geral.


  

 






  




Página 322  



 


4.1.1 Serviço de Syslog

O Syslog é um padrão criado pela IETF para a transmissão de mensagens de log em redes IP. O termo é geralmente usado para identificar tanto o protocolo de rede quanto para a aplicação ou biblioteca de envio de mensagens no protocolo syslog, o qual fica armazenado em um servidor de Syslog que pode ser instalado em qualquer computador.

O protocolo syslog é muito simples: o remetente envia uma pequena mensagem de texto (com menos de 1024 bytes) para o destinatário (também chamado "syslogd", "serviço syslog" ou "servidor syslog"). Tais mensagens podem ser enviadas tanto por UDP quanto por TCP. O protocolo syslog é tipicamente usado no gerenciamento de equipamentos em rede para auditoria de segurança de sistemas ou análises de problemas. Por ser suportado por uma grande variedade de dispositivos em diversas plataformas, o protocolo pode ser usado para integrar diferentes sistemas em um só repositório de dados. Nos roteadores e switches Cisco, conforme já estudamos, para habilitar o Sysylog basta utilizar o comando em modo de configuração globlal: “Router(config)#logging ip_do_servidor”, abaixo segue um exemplo no qual o servidor de syslog tem o IP 10.0.0.10: Router#config term Router(config)#logging 10.0.0.10


  

 






  




Página 323  



 


4.1.2 Verificando as mensagens de log

Para verificar as mensagens geradas pelos dispositivos e armazenadas no buffer de registros podemos utilizar o comando “show logging”. Veja saída do comando em um roteador com a configuração padrão. R1# show logging Syslog logging: enabled (0 messages dropped, overruns, xml disabled, filtering disabled) No Active Message Discriminator.

2 messages rate-limited,0 flushes, 0

No Inactive Message Discriminator. Console logging: level debugging, 10 messages logged, xml disabled, filtering disabled Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled Buffer logging: level debugging, 10 messages logged, xml disabled,filtering disabled Logging Exception size (8192 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled No active filter modules. ESM: 0 messages dropped Trap logging: level informational, 13 message lines logged

As mensagens são mostradas por padrão conforme abaixo: DlteC#conf t Enter configuration commands, one per line. DlteC(config)#exit

End with CNTL/Z.

DlteC# 070101: Sep 24 2013 03:04:25.389 BR: %SYS-5-CONFIG_I: Configured from console by dltec on vty0 (187.112.176.128) DlteC# 

   

Um timestamp (marcação de data e hora que o registro ocorreu): Sep 24 2013 03:04:25.389 BR O recurso no roteador que gerou o registro (facility): %SYS Nível de severidade (severity level): 5 Um mnemônico da mensagem: CONFIG_I Descrição breve da mensagem (description): Configured from console by dltec on vty0 (187.112.176.128)

Podemos mudar o formato de exibição do log de data e hora para um número de sequência com os comandos abaixo: DlteC(config)#no service timestamps DlteC(config)#service sequence-numbers DlteC(config)#exit DlteC# 070102: %SYS-5-CONFIG_I: (187.112.176.128) DlteC#

Configured

from

console

by

dltec

on

vty0

Veja a diferença da mensagem com a nova configuração através de números de sequência.     

Número de sequência (sequence number): 070102 Facility (recurso): %SYS Severity level (nível de severidade): 5 Mnemônico: Config_I Descrição: Configured from console by console Apostila/E-B

    

  

 






  




Página 324  



 


Existem outras opções que você pode configurar no comando “Service timestamp”, por exemplo, utilizando “Service timestamp log datetime msec” você define que as mensagens de data e hora sejam mostradas com os milisegundos na mensagem (03:04:25.389). Esse comando é útil se for necessário um nível de análise mais aprofundado, por exemplo, em casos de ataques de DoS ou DDoS, onde várias mensagens podem ser geradas em curtos intervalos de tempo devido ao ataque de negação de serviço. 4.1.3 Utilizando Debugs

Quando utilizamos um comando debug temos que lembrar que essas mensagens serão também enviadas para a console (padrão), terminal ou para o servidor de syslog, conforme configuração de logging que realizarmos no roteador. Essas mensagens consomem CPU e podem chegar no limite a causar o travamento do roteador, por isso seu uso deve ser muito bem estudado em ambientes de produção onde a quantidade de pacotes por segundo (PPS) pode ser alta, dando uma alta taxa de "macthes" e por consequência gerando muitas mensagens de debug. Normalmente ao ser ativado um debug as mensagens de depuração são enviadas para os destinos configurados e ficam ativas até a entrada do comando "undebug all", "no debug all" ou "no debug opção-escolhida-específica". Lembre-se que os dois primeiros comandos desativam TODOS os debugs e se você quer desativar um debug específico é necessário entrar com o "no debug" seguido do mesmo comando que você ativou. Algumas opções de debug permitem o uso de ACLs para limitar o match de pacotes ou segmentos, dependendo do filtro utilizado, reduzindo assim também a sobrecarga na CPU durante a análise. Um exemplo típico é o "debug ip packet", o qual permite analisar os pacotes que são processados pelo roteador. Veja exemplo abaixo onde vamos fazer uma ACL para filtrar apenas pacotes vindos do host 192.168.1.97 sejam pegos pelo debug ip packet. DlteC-FW-GW(config)# DlteC-FW-GW(config)#access-list 117 permit ip host 192.168.1.97 any DlteC-FW-GW(config)#access-list 117 permit ip any host 192.168.1.97 DlteC-FW-GW(config)#exit DlteC-FW-GW#debug ip packet ? <1-199> Access list <1300-2699> Access list (expanded range) detail Print more debugging detail DlteC-FW-GW#debug ip packet 117 IP packet debugging is on for access list 117 DlteC-FW-GW#

4.1.4 Utilizando Conditional Debugs

Outra forma de utilizar o comando de depuração "debug" é através do "Conditional Debug", o qual permite filtrar a saída de debugging de um certo comando aplicado conforme condições espeficificadas no comando "debug condition", veja as opções abaixo. R1#debug condition ? application Application called called number calling calling glbp interface group interface interface


  

 






  




Página 325  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br ip mac-address match-list standby username vcid voice-port xconnect

IP address MAC address apply the match-list interface group username VC ID voice-port number Xconnect conditional debugging on segment pair

Por exemplo, queremos analisar os pacotes OSPF recebidos apenas em uma interface específica do roteador. Nesse caso entramos com o comando "debug condition interface giga1/0" e depois o comando "debug ip ospf packets". Com isso o roteador não irá mostrar as demais linhas de debug referentes a pacotes recebido por outras interfaces diferentes da g1/0, siga o exemplo abaixo iniciando com o comando para estabelecer a condição e na sequência para verificar a condição "show debugging condition". R1#debug condition interface gigabitEthernet 1/0 Condition 1 set R1#show debugging condition Condition 1: interface Gi1/0 (1 flags triggered) Flags: Gi1/0

Com a condição estabelecida vamos ativar o debug dos pacotes do OSPF. Note que somente pacotes vindos da giga1/0 serão mostrados. R1#debug ip ospf packet OSPF packet debugging is on R1# *May 14 01:17:49.545: OSPF: rcv. aid:0.0.0.0 chk:D193 aut:0 R1# *May 14 01:17:59.121: OSPF: rcv. aid:0.0.0.0 chk:D193 aut:0

v:2 t:1 l:48 rid:2.2.2.2 auk: from GigabitEthernet1/0 v:2 t:1 l:48 rid:2.2.2.2 auk: from GigabitEthernet1/0

Agora vamos remover TODAS as condição com o comando "no debug condition all" e veja que pacotes de outras interfaces serão mostrados. Dica: ao desativar um debug condicional o roteador pergunta se você quer remover as condições, responda sim para confirmar (marcado em amarelo). R1#no debug condition all Removing all conditions may cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with the removal of all conditions? [yes/no]: y *May 14 01:18:17.913: OSPF: rcv. aid:0.0.0.0 chk:D193 aut:0 1 conditions have been removed R1# *May 14 01:18:20.905: OSPF: rcv. aid:0.0.0.0 chk:E598 aut:0

v:2 t:1 l:48 rid:2.2.2.2 auk: from GigabitEthernet1/0

v:2 t:1 l:48 rid:2.2.2.2 auk: from Serial2/0

Por último, não existe vizinho conectado a interface fast 0/0 e vamos colocar uma condição para ver somente pacotes recebidos por ela. Note que nada será mostrado. No final vamos desabilitar o debug condicional especificamente para a interface fast 0/0.


  

 






  




Página 326  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1#debug condition interface fast0/0 Condition 1 set R1#show debugging condition Condition 1: interface Fa0/0 (1 flags triggered) Flags: Fa0/0 R1# R1# R1#no debug condition interface fastEthernet 0/0 This condition is the last interface condition set. Removing all conditions may cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed

Aqui no CCNP ROUTE ainda vale a mesma recomendação de cuidado na ativação de debugs para não sobrecarregar a CPU do roteador com o processamento das mensagens. Nesse quesito o debug condicional é menos agressivo que o debug puro convencional, porém mesmo assim requer cuidados na aplicação. 4.1.5 Melhorando o Log de ACLs e ACEs

Como citado no tópico de ACLs de Infra o registro de logs nas entradas (ACEs) são processados via "process switching" e podem sobrecarregar o CPU do roteador. Abaixo vamos ilustrar um exemplo de configuração para melhorar o desempenho da CPU e evitar transtornos caso seja necessário o uso do recurso. No exemplo vamos utilizar os comando "ip access-list logging interval" e "logging ratelimit" seguindo as best practices para log desse tipo de informação que a Cisco recomenda. O comando "ip access-list logging interval 10" limita logs induzidos através de process switching para um pacote a cada 10 millisegundos (100 pacotes por segundo). Já o comando "logging rate-limit 100 except 4" limita a geração de mensagens para 100 por segundo a não ser que sejam mensagens de nível 4 (warnings) a 0 (emergencies), pois essas são mais importantes e devem ser mostradas. Veja os comandos e explicações abaixo, onde vamos aproveitar e mostrar outros comandos estudados também nesse tópico. DlteC#conf t Enter configuration commands, one per line. End with CNTL/Z. DlteC(config)#! DlteC(config)#!-- Configura os timestamps das mensagens de syslog com data, hora, DlteC(config)#!-- millisegundos e a time zone configurada. DlteC(config)#! DlteC(config)#service timestamps log datetime msec show-timezone localtime DlteC(config)#! DlteC(config)#!-- Ativa o logging para todos os destinos. DlteC(config)#! DlteC(config)#logging on DlteC(config)#! DlteC(config)#!-- Opcionalmente desativa o logging para a Console e Terminal, DlteC(config)#!-- pois ambos utilizam muita CPU (CPU Intensive). DlteC(config)#! DlteC(config)#no logging console DlteC(config)#no logging monitor DlteC(config)#! DlteC(config)#!-- Configura a severidade do logging, tamanho do buffer size e


  

 






  




Página 327  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br DlteC(config)#!-- taxa limite de mensagens - 100 por segundo. DlteC(config)#! DlteC(config)#logging buffered informational DlteC(config)#logging buffered 16386 DlteC(config)#logging rate-limit 100 except 4 DlteC(config)#! DlteC(config)#!-- Endereço do servidor de Syslog. DlteC(config)#! DlteC(config)#logging 192.168.1.10 DlteC(config)#! DlteC(config)#!-- Intervalo entre os pacotes que são process-switched. DlteC(config)#! DlteC(config)#ip access-list logging interval 10 DlteC(config)#end DlteC#

4.2 Entendendo e Ativando o NTP O protocolo NTP (Network Time Protocol) é utilizado para assegurar que todos os dispositivos da Infraestrutura de Redes (telefones, roteadores, switches, servidores, etc.) estejam com as informações de data/hora sincronizadas. Manter seus dispositivos sincronizados traz uma série de vantagens, dentre elas: 

 

Permite exibir a informação correta de data/hora para todos os e dispositivos da infraestrutura. Atribui corretamente a data/hora nas mensagens do do sistema e syslog. Sincroniza as mensagens de log nos roteadores e switches.

Curiosidade: quando você reseta um roteador ou switch Cisco a maioria deles irá exibir a configuração default de data (01 de Março de 1993). Para configurar a data/hora em roteador/switch você tem duas opções:  

Manualmente, com o comando clock set em modo EXEC privilegiado Automaticamente, com o protocolo NTP

Utilizando o protocolo NTP você terá uma informação de data/hora mais precisa e também irá garantir que todos os dispositivos fiquem sincronizados, ou seja, com a mesma informação de data/hora. Os servidores NTP formam uma topologia hierárquica, dividida em camadas ou estratos (em inglês: strata) numerados de 0 (zero) a 16 (dezesseis). O estrato 0 (stratum 0) na verdade não faz parte da rede de servidores NTP, mas representa a referência primária de tempo, que é geralmente um receptor do Sistema de Posicionamento Global (GPS) ou um relógio atômico. O estrato 16 indica que um determinado servidor está inoperante. O estrato 0, ou relógio de referência, fornece o tempo correto para o estrato 1, que por sua vez fornece o tempo para o estrato 2 e assim por diante. O NTP é então, simultaneamente, servidor (fornece o tempo) e cliente (consulta o tempo), formando uma topologia em árvore. Na Internet você pode encontrar diversos servidores públicos estratos 2 ou 3 (e até mesmo alguns estrato 1) para utilizar. Uma lista dos servidores NTP disponíveis na Internet pode ser encontrada no endereço abaixo. link para lista de servidores NTP: http://support.ntp.org/bin/view/Servers/WebHome


  

 






  




Página 328  



 


A forma mais simples de habilitar o NTP em um roteador Cisco é utilizar o comando “ntp server a.st1.ntp.br” informa o hostname ou endereço IP do servidor NTP utilizado. No exemplo abaixo utilizamos um servidor NTP stratum 1 localizado aqui no Brasil. Esse tipo de configuração é chamada de estática (NTP static client mode). dltec#configure terminal dltec(config)#ntp server a.st1.ntp.br dltec(config)#clock timezone BR-3 -3 dltec(config)#clock summer-time BR-2 date Oct 14 2015 0:00 Feb 17 2016 0:00 dltec(config)#ntp update-calendar dltec(config)#end dltec#

O comando "clock timezone" ajusta o fuso-horário do dispositivo baseado no UTC (Universal Time Coordinated - Greenwich Mean Time), em nosso exemplo utilizamos o fuso-horário padrão do Brasil e chamamos de BR-3, com -3 horas em relação ao UTC (Universal Time Coordinated). Logo após o comando "clock summer-time" é o ajuste para o horário de verão com uma hora a menos que o horário definido anteriormente, por isso colocamos o nome de BR-2 e depois definimos as datas onde ele vai valer. Nesse exemplo o horário de verão vai de 14 de outubro de 2015 até 17 de fevereiro de 2016. Por último temos o comando "ntp update-calendar" que faz o roteador atualizar periódicamente seu calendário com as informações do NTP. Obs: caso você não configure o timezone, o seu dispositivo irá exibir a hora tendo como referência o fuso-horário universal (UTC). Também poderíamos utilizar o primeiro comando para configurar o servidor NTP estático na forma ntp server 200.160.7.186, onde 200.160.7.186 e o endereço IP para o host a.st1.ntp.br. Para utilizar o nome de domínio ao invés de um IP deve haver um servidor DNS configurado e também o comando "ip domain-lookup" ativado para que uma resolução DNS seja realizada no início das configurações.


  

 






  




Página 329  



 


Para verificar o funcionamento básico do NTP utilize os comandos mostrados nos exemplos abaixo. dltec#sh ntp associations address ref clock st when poll reach delay offset disp *~200.160.7.186 .ONBR. 1 11 64 37 14.240 -1.468 439.05 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

O * indica que o roteador está sincronizado com o servidor NTP. Você pode configurar vários servidores NTP de redundância, no entanto o roteadores irá sincronizar apenas por uma fonte de cada vez. dltec#sh ntp status Clock is synchronized, stratum 2, reference is 200.160.7.186 nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**24 reference time is D2B6C6D7.27B172D4 (11:16:55.155 BR Tue Jan 10 2012) clock offset is -1.4685 msec, root delay is 14.24 msec root dispersion is 946.75 msec, peer dispersion is 5.79 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000227 s/s system poll interval is 64, last update was 412 sec ago. dltec#sh clock 11:23:19.000 BR Tue Jan 10 2012

Dica: no comando “show ntp associations” a coluna “st” indica o stratum do servidor NTP utilizado, no nosso exemplo mostra st 1, pois o servidor que utilizamos é stratum 1. Já no comandoComo "showestamos ntp status" temos a informação pois esse é oseremos stratumstratum do nosso sistema. nos referenciando com umstratum servidor2,stratum 1, nós 2. 4.2.1 Versões do NTP

O NTP representa a informação de tempo com 64 bits, 32 bits para os segundos e mais 32 bits para as frações de segundos. A versão vigente do NTP é a versão 4 (NTPv4 - RFC 5905), porém o NTPv4 é compatível com o NTPv3. Você pode definir a versão do NTP com o comando abaixo. R1(config)#ntp server a.st1.ntp.br version ? <2-4> NTP version number R1(config)#ntp server a.st1.ntp.br version 4 Translating "a.st1.ntp.br"...domain server (192.168.10.1) [OK]

Utilize o comando "show ntp associations detail" para verificar a versão do NTP. O NTP envia seus dados utilizando datagramas UPD e com o NTPv4 podemos sincronizar hosts IPv4 e IPv6, além disso ele possui mais recursos de segurança que asdeversões e 3, permitidos tais como autenticação e possibilidade de utilizar ACL para limitar acesso hosts 2não diretamente no comando do NTP.


  

 






  




Página 330  



 


4.2.2 Tipos de Configuração do NTP

O NTP pode ser configurado de diversas maneiras para suportar diferentes necessidades, sendo que as mais comuns são: 







NTP broadcast client mode: Nesse modo o roteador é configurado para "escutar" passivamente como cliente por broadcasts de um servidor NTP local, evitando a necessidade de configuração de um servidor estático específico. NTP static client mode: Nesse modo o roteador é configurado para escutar mensagens NTP como cliente de um servidor específico configurado estaticamente conforme exemplo no: início tópico. NTP master mode Nessedomodo o roteador é configurado como um servidor NTP e encaminha broadcasts NTP através da rede para outros dispositivos. NTP peer associations: Nesse modo o roteador pode formar associoções (NTP peer association) com outros roteadores, podendo se sincronizar com outro sistema ou permitindo que outros sistemas se sincrizem com suas informações.

Existem outras configurações específicas sobre data e hora do NTP, algumas já até configuradas, que veremos a seguir, tais como autenticação, horário de verão e time zone. A configuração do "broadcast client mode" é feita em modo de configuração de interface com o comando "ntp broadcast client". Veja exemplo abaixo. R1(config)#int fastethernet 0/0 R1(config-if)#ntp broadcast client R1(config-if)#exit

A configuração de cliente estático (static client mode) já utilizamos anteriormente com o comando "ntp server a.b.c.d", onde a.b.c.d é o endereço IP do servidor NTP. A configuração mestre/escravo (Master Mode) é quando utilizamos um roteador da própria rede para sincronizar com um servidor NTP externo e esse roteador da rede servir como servidor NTP internamente. Isso é muito comum em telefonia IP quando utilizamos o CUCME (Callmanager Express), pois o roteador CME será utilizado como referência NTP para os telefones IP. A configuração do cliente/escravo é a estática que estudamos anteriormente e do servidor mestre é feita com o comando "ntp master" e definimos o número do estrato NTP. Se for utilizar o clock interno do roteador Master como referência de sincronismo pode utilizar o valor "1", porém se houver um sincronismo com servidor NTP externo utilize preferencialmente o valor "5" (recomendação de best practice). Veja exemplo de configuração abaixo, onde R1 será o Master e R2 o escravo (Slave), além disso, note que R1 está sincronizando seu relógio com um servidor NTP externo (a.st1.ntp.br). R1-ntp_server#conf t Enter configuration commands, one per line. End with CNTL/Z. R1-ntp_server(config)#ntp server a.st1.ntp.br R1-ntp_server(config)#ntp master 5 R1-ntp_server(config)#exit R1-ntp_server# R2-ntp_client#conf t Enter configuration commands, one per line. End with CNTL/Z. R2-ntp_client(config)#ntp server 192.168.1.92 R2-ntp_client(config)#exit R2-ntp_client#


  

 






  




Página 331  



 


A configuração com "peer associations" é normalmente realizada em topologias maiores, como as em três camadas, onde podemos sincronizar o Core, por exemplo, com uma fonte externa e depois a distribuição com o Core e o acesso sincronizamos com a distribuição. Veja exemplo abaixo onde o servidor NTP será sincronizado com o Core. Configuração no Core router (192.168.1.10 - servidor NTP 200.200.200.10): ntp server 200.200.200.10 ntp master 5

Configuração no Distribution router (192.168.10.1): ntp peer 192.168.1.10

Configuração nos Access routers: ntp peer 192.168.10.1

Nesse exemplo, os computadores e telefones IP podem ser sincronizados com os roteadores de acesso diretamente, evitando que os datagramas UDP do NTP cruzem toda a rede até o Core ou até o servidor NTP. Os comandos de verificação são os mesmos estudados no início desse tópico. 4.2.3 Autenticação do NTP

Existem diversas formas de ataque ao NTP, uma delas bem simples é o atacante mandar uma informação de tempo errada para os dispositivos de rede, assim além de alterar o tempo das mensagens de log gravadas no timestamp, o atacante poderia fazer com que uma time-based ACL liberasse acesso a determinado recurso quando ele deveria ser bloqueado naquele horário real. Com a alteração nos timestamps o administrador de redes vai ter dificuldades de analisar o horário real do ataque também. Para mitigar esse tipo de risco, onde um falso servidor NTP (chamado de rogue NTP Device) passar informação de tempo falsa para os roteadores podemos implementar a autenticação do NTP. Para ativar a autenticação devemos seguir três passos em modo de configuração global: 1. Ativar a autenticação do NTP com o comando "ntp authenticate". 2. Definir as chaves de autenticação (authentication keys) utilizando MD5 com o comando "ntp authentication-key num-chave md5 senha-md5". 3. Definir a chave que será utilizada (trusted key) utilizando o mesmo número de chave definido no comando anterior com o comando "ntp trusted-key num-chave" tanto no mestre como nos escravos. Para vincular uma senha a um cliente que será escravo no comando "ntp server" após o endereço do Master insira a opção "key num-chave", por exemplo, o servidor Master tem IP 10.10.10.10 e foi utilizada a chave 1 para autenticação MD5: "ntp server 10.10.10.10 key 1". Abaixo segue um exemplo de configuração Master/Slave com autenticação para reforçar a segurança do NTP. Vamos iniciar pela configuração do roteador Master. Para autenticação vamos utilizar a chave 1 com senha MD5: "senhasecreta". R1# conf term Enter configuration commands, one per line. End with CNTL/Z. R1(config)# ntp authentication-key 1 md5 senhasecreta R1(config)# ntp authenticate R1(config)# ntp trusted-key 1 R1(config)# ntp master 5


  

 






  




Página 332  



 


Agora segue a configuração do escravo, onde repetimos os três primeiros comandos e no final, no comando ntp server, incluímos o IP do roteador definido como NTP master e a chave de autenticação. R2# conf term Enter configuration commands, one per line. End with CNTL/Z. R2(config)# ntp authentication-key 1 md5 senhasecreta R2(config)# ntp authenticate R2(config)# ntp trusted-key 1 R2(config)# ntp server 192.168.1.86 key 1

A chave de autenticação e a senha MD5 devem ser as mesmas do mestre na configuração dos escravos. No escravo o comando "ntp server" o vincula ao mestre com a chave de autenticação 1. Os mesmos comandos shows mostrados anteriormente podem ser utilizados na verificação do NTP. 4.3 Entendendo e Ativando o SNMP O protocolo SNMP ou Simple Network Management Protocol é utilizado para gerenciar redes TCP/IP complexas. Com o SNMP, os adminis tradores podem gerenciar e configurar elementos de rede de um servidor localizado centralmente em vez de ter que executar o software de gerenciamento de rede. Também é possível usar o SNMP para monitorar o desempenho da rede, detectar problemas de rede e acompanhar quem usa a rede e como ela é usada. O SNMP trabalha por padrão com o protocolo UDP na porta 161.

Uma rede gerida pelo protocolo SNMP é formada por três componentes chaves: 1. Agentes SNMP (SNMP Agent): os próprios roteadores e switches. Apostila/E-B     

  

 






  




Página 333  



 


2. MIB (Management Information Base): base de dados padronizada que é lida por um gerente SNMP. 3. Gerentes SNMP ou SNMP Manager: Sistemas de Gestão de Redes ou NMS (Network Management Systems), por exemplo, o pacote de software da Cisco chamado Cisco Prime. Um Dispositivo Gerenciado é um nó de rede que possui um agente SNMP instalado e se encontra numa rede gerenciada. Estes dispositivos coletam e armazenam informações de gestão e mantêm estas informações disponíveis para sistemas NMS através do protocolo SNMP. Dispositivos geridos, também às vezes denominados de dispositivos de rede, podem ser roteadores, servidores de acesso, impressoras, computadores, servidores de rede, switches, dispositivos de armazenamento, dentre outros. Um Agente é um módulo de software de gestão de rede que fica armazenado num Dispositivo Gerenciado. Um agente tem o conhecimento das informações de gestão locais e traduz estas informações para um formato compatível com o protocolo SNMP e padronizados em bancos de dados chamados MIB (Management Information Base). Um sistema NMS é um gerente SNMP responsável pelas aplicações que monitoram e controlam os Agentes SNMP. Normalmente é instalado em um (ou mais que um) servidor de rede dedicado a estas operações de gestão, que recebe informações (pacotes SNMP) de todos os dispositivos geridos daquela rede, por exemplo, o Whatsup Gold, Cisco Prime e o HP Openview. Trazendo para a realidade dos roteadores e switches, eles são os dispositivos gerenciados, os quais possuem uma MIB, que é um banco de dados que armazena de forma padronizada informações de hardware, software e parâmetros operacionais. Através de um sistema de gerenciamento (gerente SNMP) podemos ler essas informações e apresentá-las de forma mais intuitiva para que um analista de suporte, por exemplo, tenha informação de quanta CPU está sendo utilizada pelo roteador naquele momento através de um comando SNMP Get.

Esse tipo de operação pode ser automatizado em sistemas de gerência para geração de avisos, por exemplo, pode na de tela 5 emde5 minutos checar que o usoa de CPU pelo roteador e se chegar a 50%o gerenciador gerar um aviso gerenciamento CPU passou desse limite configurado (threshold ou limiar). Além do GET temos a mensagem SNMP SET, a qual configura uma variável em um dispositivo gerenciado ou então dispara uma ação nesse dispositivo. Outro tipo de mensagem que o SNMP pode gerar é um TRAP. Esse tipo de mensagem é gerada espontaneamente pelo dispositivo para informar que um problema inesperado ocorreu. Os traps são mensagens SNMP que descrevem uma variável da MIB, porém geradas pelo próprio dispositivo, sem a solicitação do NMS, o qual pode tomar uma ação diferente nesse caso, por Apostila/E-B     

  

 






  




Página 334  



 


exemplo, enviando uma mensagem para um destinatário de e-mail e soar um alarme para a equipe de monitoração.

O SNMP possui três versões principais: 1 (SNMPv1), 2c (SNMPv2c) e 3 (SNMPv3). A versão 1 é extremamente antiga e raramente encontrada atualmente, as versões mais utilizadas atualmente são a 2c e 3. A diferença entre as duas últimas é que a versão 2 não possui muitos recursos de segurança, o que foi contemplado para a felicidade de muitos administradores de rede na versão 3 do SNMP. A versão 2 é gerenciada através de nomes de comunidade, existindo uma para leitura e outra para leitura e escrita. Já a versão 3 possui recursos como autenticação, garantia da integridade das mensagens e criptografia. 4.3.1 Configurando o SNMP versão 2C

Vamos iniciar aprendendo os principais comandos relacionados ao SNMP versão 2c. Tanto nessa versão como na versão 1 do SNMP são utilizadas comunidades (community strings) para definir o acesso às MIBs e qual o nível podemos ter a essas informações através de dois tipos de comunidades. Read-only (RO): permite acesso de leitura às variáveis da MIB e opção mais utilizada com a Version 2c devido a falta de recursos de segurança adicionais dessa versão de SNMP. Read-write (RW): permite acesso de leitura e escrita a quaisquer objetos da MIB sem nenhuma verificação extra. 



Portanto, com um nome ou string definimos o acesso e que tipo de acesso podemos fazer à MIB dos dispositivos com SNMPv2c ativado. Para configurá-lo utilizamos os passos abaixo, sendo que somente o passo 1 é obrigatório, os demais são opcionais: 1. 2. 3. 4.

Configurar a community string e o nível de acesso com o comando “s nmp-server community comunidade RO|RW” em modo de configuração global. Descrever (documentar) a localização do dispositivo com o comando “snmp-server location”. Documentar o contato responsável pelo dispositivo com o comando “snmp-server contact”. Restringir o acesso SNMP apenas ao servidor ou host que possui o sistema NMS utilizando uma ACL no comando “snmp-server community nome-da-comunidade num-ou-nome-da-acl”.

Veja exemplo de configuração abaixo onde o host de gerenciamento tem IP 192.168.1.15 e a comunidade a ser configurada apenas como leitura tem o nome dltecRO12345 e de leitura e escrita como dltecRW12345. Vamos também limitar o acesso à comunidade exclusivamente ao host de gerenciamento através de uma access-list padrão.


  

 






  




Página 335  



 

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br R1(config)#access-list R1(config)#snmp-server R1(config)#snmp-server R1(config)#snmp-server R1(config)#snmp-server R1(config)#end R1#

1 permit host 192.168.1.15 community dltecRO12345 RO 1 community dltecRW123435 RW 1 location Curitiba/PR/Brasil contact Marcelo Nascimento – 41 3045-7810

A acess-list é a única maneira de proteger o SNMP caso descubram as community strings de leitura e escrita, sem ela quasiquer gerentes SNMP que souberem as community strings poderão acessar as informações dos roteadores e até alterar parâmetros se tiverem acesso de escrita (community string de RW). Para o envio de TRAPs (mensagens de problemas geradas pelos roteadores e switches) primeiro precisamos definir o IP do servidor e depois habilitar o envio das mensagens, veja exemplo abaixo para a versão 2c. R1(config)#snmp-server host 192.168.1.14 version 2c dltec12345 R1(config)#snmp-server enable traps

4.3.2 SNMP versão 3

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





Integridade das mensagens: através de um algoritmo de hash pode ser verificado se o conteúdo da mensagem não foi alterado em trânsito, seja por problemas na rede ou ataque. Autenticação: ajuda a validar se a srcem que está enviando informações realmente tem a permissão para tal. Criptografia : protege os dados eventualmente capturados em trânsito dificultando a leitura das informações.

Com isso, a configuração do SNMPv3 tem três opções a mais que estudamos para a versão anterior: 





noAuthNoPriv  opção no comando noauth e utiliza um usuário e senha para autenticação, porém sem criptografia. Fica semelhante ao SNMPv2c (sem compatibilidade), porém o nome do usuário acaba sendo o equivalente ao community string para verificar a autenticidade. authNoPriv  usa a opção auth no comando e implementa Message Digest 5 (MD5) ou Secure Hash Algorithm (SHA) para autenticação, porém ainda sem criptografia. authPriv  opção priv no comando, implementa autenticação e integridade com Message Digest 5 (MD5) ou Secure Hash Algorithm (SHA) e criptografia através do DES ou DES-56.

Para configurar o SNMPv3 precisamos escolher um gerente, seja ele qual for. Para esse exemplo utilizamos o LoriotProSoftware free edition que você pode baixar no link a seguir: - http://www.loriotpro.com/Download/DownloadV7_EN.php Normalmente os gerentes ou NMSs precisarão do engine ID do roteador que é gerado automaticamente, você pode descobrir com o comando "show snmp engineID". DlteC#show snmp engineID Local SNMP engineID: 800000090300001E130B1AEE Remote Engine ID IP-addr Port DlteC#


  

 






  




Página 336  



 


No primeiro exemplo vamos configurar o SNMPv3 sem autenticação ou criptografia com um usuário chamado "dltecsnmpv3". Veja as configurações abaixo. snmp-server engineID local 800000090300001E130B1AEE ! Esse é o snmpV3 engine ID que obtivemos no comando anterior ! snmp-server group DlteCnoAuth v3 noauth ! Criando um grupo chamado DlteCnoAuth ! snmp-server user DlteCnoAuth dltecsnmpv3 v3 ! Vinculando o usuário dltecsnmpv3 ao grupo DlteCnoAuth ! Esse usuário tem privilégio de leitura apenas ! snmp-server group DlteCnoAuth v3 noauth write view1 ! Adicionando uma view com privilégio de escrita (write) ! chamada view1 ao grupo DlteCnoAuth ! snmp-server view view1 system included ! Adicionando uma MIB a view, sendo que nesse exemplo inclui ! syslocation, syscontact, etc.. ! ! Para receber notificações ou traps utilize o comando abaixo ! snmp-server host 192.168.1.87 version 3 noauth dltecsnmpv3 ! ! O roteador SNMPv3 vai enviar notificações para o servidor ! 192.168.1.87 com o usuário dltecsnmpv3 sem autenticação ou criptografia

Agora vamos ver outro exemplo com autenticação através de HMAC-MD5-96. Para isso vamos usar a opção auth na criação dos grupos e utilizar a view criada anteriormente (omitida), acompanhe abaixo. snmp-server engineID local 800000090300001E130B1AEE ! Configura o engine ID como no exemplo anterior. ! snmp-server group DlteCAuth v3 auth ! Cria o grupo DlteCAuth com autenticação (opção auth) ! snmp-server user dltecuserauth DlteCAuth v3 auth md5 dltec123 ! Cria o usuário dltecuserauth vinculado ao grupo DlteCAuth ! com autenticação md5 e senha dltec123 ! snmp-server host 192.168.1.87 version 3 auth dltecuserauth ! Configuração do envio de notificações no usuário criado no exemplo para o servidor ! SNMPv3 de endereço 192.168.1.87 Nesse link você da encontra essas dos configurações e também como configurar o servidor que citamos no início configurações dois exemplos: - http://www.loriotpro.com/ServiceAndSupport/How_to/howto_snmpv3_cisco_EN.php


  

 






  




Página 337  



 


4.4 Entendendo e Configurando o NetFlow O NetFlow é uma tecnologia implementada no IOS da Cisco que considera os pacotes como parte de um fluxo ao invés de simplesmente contá-los. Um fluxo tem um princípio, meio e fim, como uma conexão TCP feita para acesso a uma página de Internet, por exemplo. Quando pacotes de dados são agrupados como fluxos os administradores são capazes de entender as aplicações que estão utilizando a rede de forma mais abrangente. Isto naturalmente permite um gerenciamento mais preciso e melhorar a qualidade de serviço como um todo. Os administradores também são capazes comsituações o NetFlowque depodem identificar áreas de problemas e tomarem uma ação preventiva em diversas gerarasproblemas para os serviços de rede. Na figura a seguir temos um exemplo de monitoração realizada através do NetFlow sobre um determinado fluxo entre o os Hosts A e B (contagem de pacotes, bytes, etc.) para determinada aplicação. Essas informações coletadas são passadas para um servidor externo chamado “NetFlow Collector”, onde podem ser tratadas e exibidas de diversas formas para o administrador de redes e seu time de monitoração de redes.

As opções de monitoração que o NetFlow permite são bastante vastas e os principais usos que você deve encontrar para ele nas empresas são:   

   

   

Gerenciamento de tráfego para gerar análises de linha de base (baseline analysis). Monitorar o uso da rede ou serviços para fins de cobrança de usuários de rede. Planejamento de capacidade (Capacity Planning): o Auxiliar no projeto e análise de crescimento da rede. o Identificar necessidades de redesenho da rede e inserção de novos dispositivos. o Auxiliar na definição de necessidades de aumento de banda em links da Intranet e Internet. Monitoração da rede durante a operação normal (banda e análise de tráfego). Monitoramento de aplicativos e rastreamento da migração de aplicativos. Validação de QoS. Auxiliar no projeto de segurança de rede em geral através de monitoração e análise do comportamento dos fluxos. Monitoração e prevenção de Denial of Service (DoS) e Distributed DoS (DDoS). Identificação de Worms e Malwares. Análise de tráfego de VPN e comportamento do acesso remoto. Calcular o custo total da propriedade de aplicativos.


  

 






  




Página 338  



 


O NetFlow também é completamente transparente para os usuários finais e não precisa ser suportado em todos os dispositivos para funcionar. 4.4.1 O que é um Fluxo para o NetFlow?

É importante entender que um fluxo é unidirecional e para cada sessão haverá sempre dois fluxos (ida e volta). Por exemplo, um web-browser acessando uma página na Internet tem o fluxo em direção ao servidor, requisitando a página, e do servidor em direção ao host respondendo à requisição e enviando os dados da página solicitada. Portanto, analisa IP fluxos IP ao invés de sete contar bytesde nas interfaces. Um fluxo é composto oporNetFlow vários pacotes contendo pelo menos campos identificação: 1. 2. 3. 4. 5. 6. 7.

Um endereço IP de srcem comum. Um endereço IP de destino comum. Uma porta de srcem comum. Uma porta de destino comum. Mesmo protocolo de camada 3. Mesmo tipo de serviço (ToS). Mesma interface lógica de entrada.

Os primeiros quatro campos são utilizados pelo NetFlow para identificar um fluxo que pode ser familiar. Os endereços IP de srcem e destino, assim como as portas de srcem e destino identificam a conexão entre a aplicação de srcem e destino. O protocolo de camada-3 (Layer 3) identifica o tipo de cabeçalho que o NetFlow terá que analisar. Além disso, o campo ToS no cabeçalho do IPv4 traz informações sobre como os dispositivos devem aplicar regras de qualidade de serviço para aquele fluxo (QoS – regras para o fluxo de pacotes naquele link). Baseado nesses parâmetros o IOS é então capaz de identificar o fluxo e coletar as informações necessárias para o monitoramento. Estas informações são armazenadas no cache NetFlow e podem ser transferidas a um coletor (NetFlow Collector) para serem analisadas detalhadamente. 4.4.2 Configurando o NetFlow

Para configurar o NetFlow básico primeiro temos que iniciar a captura dos dados em uma determinada interface com o comando “ip flow”, veja exemplo de configuração abaixo. R1(config)#interface Gig0/0 R1(config-if)#ip flow ingress R1(config-if)#ip flow egress R1(config-if)#exit

A opção ingress diz ao roteador para monitorar pacotes entrantes na interface, já a opção egress diz ao dispositivo para monitorar pacotes que estão saindo da interface. Esses comandos podem ser aplicados à diversas interfaces simultaneamente. A segunda etapa da configuração é definir como os dados serão exportados para o NetFlow Collector utilizando o comando ip flow-export em modo de configuração global. Veja exemplo de configuração abaixo. R1(config)#ip flow-export destination 192.168.1.15 99 R1(config)#ip flow-export version 9 R1(config)#ip flow-export source loopback 0 R1(config)#


  

 






  




Página 339  



 


Portanto utilizamos três comandos para definir a comunicação com o coletor de dados do NetFlow: 1. O endereço do coletor de NetFlow e a porta UDP utilizada com o comando “ip flowexport destination end-IP-do-coletor porta-UDP”. 2. A versão do NetFlow no comando “ip flow-export version versão”. Existem diversas versões de NetFlow sendo que as mais comuns são 1, 5, 7, 8 e 9, porém a 9 é a mais recente. 3. A interface de srcem que será utilizada como endereço de srcem para os pacotes que serão enviados ao coletor com o comando “ip flow-export source interface númeroda-interf ”. 4.4.3 Verificando e utilizando o NetFlow

Podemos utilizar três comandos para verificar as configurações, os dados coletados pelo NetFlow e o estado da exportação dos dados para o coletor, seguem abaixo os comandos: 

 

Show ip cahe flow: verifica os dados coletados e várias estatísticas dos fluxos analisados. Show ip flow interface: verifica as interfaces que o NetFlow está ativado. Show ip flow export: verifica como está sendo executada a exportação e dados de configuração dos pacotes a serem enviados ao coletor.

Uma vez ativado com o comando “ip flow” dentro da interface, o NetFlow começa a coletar informações e armazená-las para envio posterior ao coletor (se configurado). Para verificar esses dados utilizamos o comando “show ip cache flow”, veja exemplo abaixo. DlteC#show ip cache flow IP packet size distribution (122533 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .444 .219 .013 .007 .001 .005 .003 .004 .002 .003 .001 .002 .001 .001 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .002 .002 .006 .028 .245 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 278544 bytes 276 active, 3820 inactive, 4160 added 69388 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 34056 bytes 0 active, 1024 inactive, 0 added, 0 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-WWW TCP-other UDP-NTP UDP-other ICMP Total: SrcIf Fa0/0 Fa0/0 Fa0/0

1079 2388 52 364 1 3884

0.0 0.0 0.0 0.0 0.0 0.0

SrcIPaddress 184.85.128.170 184.85.128.170 50.19.253.34


  

 





33 34 9 1 1 30

DstIf Fa0/1.10 Fa0/1.10 Fa0/1.10

858 254 76 139 32 433

DstIPaddress 192.168.10.2 192.168.10.2 192.168.10.2


0.0 0.0 0.0 0.0 0.0 0.0

  

5.3 3.4 8.9 0.0 0.0 3.7 Pr 06 06 06

SrcP 0050 0050 0050




8.6 10.9 15.5 15.4 15.0 10.8 DstP B6AC B6AD E5FE

Pkts 3 1 3

Página 340  



 


Note que o primeiro campo destacado após o comando show mostra a quantidade de pacotes monitorados (122533 total packets). Mais abaixo, destacado em azul temos um fluxo que está sendo monitorado pelo NetFlow através da interface Fast0/0 (SrcIf), com IP de srcem 23.57.145.224, destino 192.168.10.2 (este destino está na porta fast0/1.10 – DstIf). No campo Pr temos que o protocolo trocado é do tipo “6”, ou seja, TCP com porta de srcem 0x50 (SrcP) e de destino 0xb6ac (DstP), ambos os valores em Hexadecimal, portanto 0x50 em decimal é 80 e 0xb6ac é 46764, portanto esse é um fluxo de retorno de um acesso que o computador interno 192.168.10.2 fez à página de Internet com endereço 23.57.145.224. Para ver fast0/0 as interfaces ativas no NetFlow utilizamos o comando abaixo. Note que apenas a interface está com os comandos “ip flow” ativados. DlteC#show ip flow interface FastEthernet0/0 ip flow ingress ip flow egress DlteC#

Por último, podemos verificar o estado da configuração da exportação dos dados coletados para o servidor ou host com um coletor ativado com o comando a seguir, onde temos um roteador sem os comandos de exportação definidos. DlteC#show ip flow export Flow export v1 is disabled for main cache Version 1 flow records 0 flows exported in 0 udp datagrams 0 flows failed due to lack of export packet 0 export packets were sent up to process level 0 export 0 export 0 export 0 export DlteC#

packets packets packets packets

were were were were

dropped dropped dropped dropped

due due due due

to to to to

no fib adjacency issues fragmentation failures encapsulation fixup failures

Portanto a saída do comando diz que a versão utilizada por padrão é a 1 e está desativada. Agora vamos aplicar a configuração mostrada no exemplo do tópico anterior e verificar as mudanças. DlteC(config)#ip flow-export destination 192.168.1.253 99 DlteC(config)#ip flow-export version 5 DlteC(config)#ip flow-export source fast0/1.10 DlteC(config)#end DlteC#show ip flow export Flow export v5 is enabled for main cache Export source and destination details : VRF ID : Default Source(1) 192.168.1.1 (FastEthernet0/1.10) Destination(1) 192.168.1.253 (99) Version 5 flow records 3859 flows exported in 134 udp datagrams 0 flows failed due to lack of export packet 33 export packets were sent up to process level 0 export packets were dropped due to no fib 0 export packets were dropped due to adjacency issues 0 export packets were dropped due to fragmentation failures 0 export packets were dropped due to encapsulation fixup failures DlteC#


  

 






  




Página 341  



 


O comando mostra que a versão 5 foi configurada e o IP de srcem é o configurado na interface fast0/1.1 (192.168.1.1) e o destino é o configurado no comando ip flow-export destination (192.168.1.253). Você pode encontrar uma diferença no comando "show ip flow export" em versões de IOS mais antigas, como na 12.3, por exemplo. Veja exemplo abaixo: Router# show ip flow export Flow export v5 is enabled for main cache Exporting flows to 10.51.12.4 (9991) 10.1.97.50 (9111) Exporting using source IP address 10.1.97.17 Version 5 flow records 11 flows exported in 8 udp datagrams 0 flows failed due to lack of export packet 0 export packets were sent up to process level 0 export packets were dropped due to no fib 0 export packets were dropped due to adjacency issues 0 export packets were dropped due to fragmentation failures 0 export packets were dropped due to encapsulation fixup failures 0 export packets were dropped enqueuing for the RP 0 export packets were dropped due to IPC rate limiting 0 export packets were dropped due to output drops

Note que existem algumas diferenças, onde se houver incremento na última linha representa que a fila de saída (send queue) está cheia e as informações do Netflow não estão sendo exportadas porque os pacotes não estão sendo enviados. Para que coletor os dados coletados NetFlow exibidos de forma simples é preciso utilizar software que permita pelo a geração de sejam gráficos e relatórios conforme a necessidade de um análise de cada empresa. Essas aplicações podem ser gratuitas (freeware) ou pagas e podem ter vários relatórios pré-configurados ou que podem ser criados/otimizados pelo administrador de redes. As informações mais comuns que podemos obter nesse tipo de aplicação são: “Top talkers” ou os hosts que mais usam banda na rede. “Top listeners” ou os serviços mais solicitados na rede. Websites mais visitados. Downloaded mais realizado. Sistemas com pouca largura de banda disponível, etc.     

No link a seguir existe uma lista de softwares gratuitos para o NetFlow divulgada pela própria Cisco, você pode baixar e utilizar nos seus estudos. http://www.cisco.com/en/US/prod/iosswrel/ps6537/ps6555/ps6601/networking_solutions_prod ucts_genericcontent0900aecd805ff72b.html Veja abaixo exemplo de tela do software disponibilizado pela Solar Winds gratuitamente que permite monitoração SNMP e ser NetFlow chamado Real Time . Essa ferramenta é simples, gratuita e permite instalada no Windows 7 ouNetflow 8. NessaAnaliser versão gratuita ela suporta a versão 5 do NetFlow.


  

 






  




Página 342  



 


O NetFlow versão 9 inclui Multiprotocol Label Switching (MPLS) labels e endereços IPv6, assim como portas TCP e UDP utilizadas em fluxos estabelecidos pelo protocolo IPv6. Os recursos de SNMP e NetFlow não são suportados pelo Packet Tracer, caso você deseje praticar precisrá utilizar o GNS3 ou laboratório real com Cisco IOS que suporte esses recursos.


  

 






  




Página 343  



 


4.4.4 Flexible NetFlow

O Flexible NetFlow melhora o NetFlow srcinal adicionando a capacidade de personalizar os parâmetros de análise de tráfego para necessidades específicas, facilitando a criação de configurações mais complexas para a análise de dados de tráfego e de exportação através da utilização de componentes de configuração reutilizáveis (templates). O Flexible NetFlow consiste em diversos componentes que podem ser utilizados em conjunto para fazer a análise de tráfego e exportar dados. Seus componentes são: 

 



Records : utilizado osoflow o cachê que será utilizado para armazemar os dadoscom sobre fluxomonitors analisadopara pelodefinir monitor. Flow Monitors: aplicado nas interfaces para monitorar o tráfego. Flow Exporters: utilizados para exportar os dados que estão gravados no cachê do roteador para um servidor com um coletor instalado. Flow Samplers: utilizado para limitar o número de pacotes que serão utilizados nos testes e não sobrecarregar as interfaces do roteador.

Um registro de fluxo (flow record) permite a criação de várias configurações para análise de tráfego e exportação de dados em um determinado dispositivos de redes com poucos comandos, como se fosse um template de testes. Cada monitor de fluxo ou flow monitor pode ter uma única combinação de flow record, flow exporter e tipo de cachê. Se você altera, por exemplo, o IP de destino de um flow exporter ele é alterado em todos os flow monitors que utilizam aquele flow exporter, facilitando as mudanças de configuração. Um mesmo flow monitor pode ser utilizado em diferentes flow samplers para tirar amostras do mesmo tipo de rede com diferentes cargas de tráfego e interfaces.


  

 






  




Página 344  



 


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


  

 






  




Página 345  



 


Sobre o E-book/Apostila O conteúdo desse documento é uma adaptação da matéria online de leitura do curso. O presente material traz conteúdo teórico do curso online, porém temos que deixar claro que não é um curso e sim uma adaptação do nosso material online para e-book/apostila . Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com professores) e vídeo aulas não fazem parte desse e-book, pois são exclusivos para alunos devidamente matriculados em nosso site oficial.

Para maiores informações sobre nossos treinamento visite o site:

>>> http://www.dltec.com.br <<<


  

 






  




Página 346  



 

Apostila Curso CCNP Route 300-101_v3-m

Recommend Documents