Ccna 4.0 - Rpc - 07 Ripv2

Alternar idioma para English | Pesquisa | Glossário

Índice do curso:

CCNA Exploration - Protocolos e conceitos de roteamento7 RIPv27.0 Introdução do capítulo7.0.1 Introdução do capítulo

Página 1:O RIP Versão 2 (RIPv2) é definido na RFC 1723. É o primeiro protocolo de roteamento classless discutido neste curso. A figura coloca o RIPv2 em sua perspectiva apropriada com outros protocolos de roteamento. Embora o RIPv2 seja um protocolo de roteamento adequado para alguns ambientes, ele perdeu a popularidade quando comparado a outros protocolos de roteamento como o protocolo EIGRP, OSPF, e IS-IS, que oferecem mais recursos e que são mais escaláveis.

Embora ele possa ser menos popular do que outros protocolos de roteamento, ambas as versões de RIP ainda são apropriadas em algumas situações. Embora falte ao RIP os recursos de muitos dos protocolos mais novos, sua absoluta simplicidade e uso difundido em diversos sistemas operacionais o torna um candidato ideal para redes menores e homogêneas, onde o suporte a diversos fornecedores é necessário - principalmente dentro de ambientes UNIX.

Como você precisará entender o RIPv2 - mesmo se não utilizá-lo - este capítulo se concentrará nas diferenças entre um protocolo de roteamento classful (RIPv1) e um protocolo de roteamento classless (RIPv2) em vez de abordar apenas os detalhes do RIPv2. A limitação principal do RIPv1 é que ele é um protocolo de roteamento classful. Como você sabe, os protocolos de roteamento classful não incluem a máscara de sub-rede com o endereço de rede em atualizações de roteamento, o que pode causar problemas com redes ou sub-redes descontíguas que utilizam Mascaramento de Sub-rede de Tamanho Variável (VLSM, Variable-Length Subnet Masking). Como o RIPv2 é um protocolo de roteamento classless, são incluídas máscaras de sub-rede nas atualizações de roteamento, tornando o RIPv2 mais compatível com ambientes de roteamento modernos.

O RIPv2 é, de fato, mais um aprimoramento dos recursos e extensões do RIPv1 do que um protocolo completamente novo. Algumas destas características aprimoradas incluem:

� Endereços do próximo salto incluídos nas atualizações de roteamento � Uso de endereços de multicast nas atualizações enviadas � Opção de autenticação disponível

Como o RIPv1, o RIPv2 é um protocolo de roteamento do vetor de distância. Ambas as versões de RIP compartilham as seguintes características e limitações:

� Uso de holddown e outros temporizadores para ajudar a impedir loops de roteamento. � Uso de split horizon ou split horizon com poison reverse para ajudar também a evitar loops de

roteamento. � Uso de atualizações disparadas (triggered updates) quando há uma mudança na topologia

para uma convergência mais rápida. � Limite máximo de contagem de 15 saltos, com a contagem de saltos de 16 significando uma

rede inalcançável.

7 RIPv2 Selecionar

Página 1 de 19Tema acessível CISCO

08/07/2011http://curriculum.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCServlet...

Exibir meio visual

7.1 Limitações de RIPv17.1.1 Topologia do laboratório

Página 1:A figura mostra a topologia e o esquema de endereçamento utilizados neste capítulo. Este cenário é semelhante ao domínio de roteamento com três roteadores que foi utilizado no fim do Capítulo 5, "RIPv1." Lembre-se de que ambos os roteadores R1 e R3 possuem sub-redes que fazem parte da rede classful principal 172.30.0.0/16 (classe B). Lembre-se também de que ambos os roteadores R1 e R3 estão conectados a R2 utilizando sub-redes da rede classful principal 209.165.200.0/24 (classe C). Esta topologia não é contígua e não converge porque 172.30.0.0/16 está dividida pela 209.165.200.0/24.

Clique em R1, R2 e R3 para ver a configuração inicial para cada roteador.

Rota de sumarização

A topologia mostra que R2 possui uma rota de sumarização estática para a rede 192.168.0.0/16. A configuração desta rota de sumarização será exibida posteriormente nesta seção.

O conceito e a configuração de rotas de sumarizadas estáticas foram discutidos no Capítulo 2, "Roteamento estático". Nós podemos acrescentar informações da rota estática nas atualizações de protocolo de roteamento. Isto é chamado de redistribuição e também será discutido posteriormente nesta seção. Por enquanto, entenda que esta rota de sumarização causará problemas com RIPv1 porque 192.168.0.0/16 não é um endereço classful principal e inclui todas as /24 versões de 192.168.0.0/16, conforme mostrado na topologia.

Finalmente, observe que os roteadores R1 e R3 contêm redes de VLSM e estão compartilhando espaço de endereço da rede classful principal 172.30.0.0/16. A seguir, observaremos o esquema de endereçamento de VLSM.Exibir meio visual

Página 2:VLSM

Reveja o esquema de endereçamento de VLSM na figura. Como mostrado no gráfico da parte superior, R1 e R3 tiveram a rede 172.30.0.0/16 dividida em /24 sub-redes. Quatro destas /24 sub-redes são atribuídas: duas para R1 (172.30.1.0/24 e 172.30.2.0/24) e duas para R3 (172.30.100.0/24 e 172.30.110.0/24).

No gráfico da parte inferior, nós subdividimos a rede 172.30.200.0/24 e a dividimos em sub-redes novamente, utilizando os primeiros quatro bits para sub-redes e os últimos quatro bits para hosts. O resultado é uma máscara 255.255.255.240 ou /28. A sub-rede 1 e a sub-rede 2 são atribuídas a R3. Isto significa que a sub-rede 172.30.200.0/24 já não pode ser utilizada apesar de as /28 sub-redes restantes poderem ser utilizadas.Exibir meio visual

Página 3:



Endereços privados da RFC 1918

Você já deve estar familiarizado com a RFC 1918 e o raciocínio relacionado ao endereçamento privado. Todos os exemplos no currículo utilizam endereços IP privados para o exemplo de endereçamento interior.

Os endereços referentes à RFC 1918 são mostrados na tabela. Mas quando o tráfego IP é roteado através dos links de WAN por um ISP, ou quando usuários internos precisam acessar sites externos, um endereço IP público deve ser utilizado.

Exemplos de endereços IP da Cisco

Você pode ter notado que os links de WAN entre R1, R2 e R3 estão utilizando endereços IP públicos. Embora estes endereços IP não sejam endereços privados de acordo com a RFC 1918, a Cisco adquiriu alguns espaços de endereço público para serem utilizados como exemplos.

Os endereços mostrados na figura são todos os endereços IP públicos válidos que podem ser roteados na Internet. A Cisco reservou estes endereços para propósitos educacionais. Portanto, este curso e futuros cursos utilizarão estes endereços quando houver uma necessidade de utilizar endereços públicos.

Na figura, R1, R2 e R3 estão conectados utilizando o espaço de endereçamento público da Cisco de 209.165.200.224/27. Como os links de WAN precisam somente de dois endereços, a 209.165.200.224/27 é dividida em sub-rede com uma máscara de /30. Na topologia, a sub-rede 1 é atribuída ao link de WAN entre R1 e R2. A sub-rede 2 é atribuída ao link de WAN entre R2 e R3.Exibir meio visual

Página 4:Interfaces de loopback

Note que R3 está utilizando interfaces de loopback (Lo0, Lo1 e Lo2). Uma interface de loopback é uma interface somente de software que é utilizada para emular uma interface física. Como outras interfaces, pode-se atribuir a ela um endereço IP. As interfaces de loopback também são utilizadas por outros protocolos de roteamento, tais como OSPF, para propósitos diferentes. Estes usos serão discutidos no Capítulo 11 OSPF.

Em um ambiente de laboratório, as interfaces de loopback são úteis para criar redes adicionais sem ter que adicionar mais interfaces físicas no roteador. Uma interface de loopback pode sofrer ping e a sub-rede pode ser anunciada em atualizações de roteamento. Portanto, as interfaces de loopback são ideais para simular diversas redes conectadas ao mesmo roteador. Em nosso exemplo, o R3 não precisa de quatro interfaces de rede local para demonstrar várias sub-redes e VLSM. Em vez disso, nós utilizamos as interfaces de loopback.

Links

"Internet Assigned Numbers Authority (IANA),” http://www.iana.org/

"Configurando Interfaces Lógicas," http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.htmlExibir meio visual



7.1.2 Limitações da topologia de RIPv1

Página 1:Rotas estáticas e interfaces nulas

Para configurar a rota de super-rede estática em R2, utiliza-se o seguinte comando:

R2(config)#ip route 192.168.0.0 255.255.0.0 Null0

Lembre-se de que a sumarização de rota permite uma única entrada de rota de alto nível para representar muitas rotas de nível menor, reduzindo assim o tamanho das tabelas de roteamento. A rota estática em R2 utiliza uma máscara /16 para sumarizar todas as 256 redes entre 192.168.0.0/24 e 192.168.255.0/24.

O espaço de endereço representado pela rota de sumarização estática 192.168.0.0/16 não existe verdadeiramente. Para simular esta rota estática, nós utilizamos uma interface nula (null interface) como a interface de saída. Você não precisa digitar nenhum comando para criar ou configurar a interface nula. Ela está sempre ativa, mas não encaminha ou recebe tráfego. O tráfego enviado à interface nula é descartado. Para nossos propósitos, a interface nula servirá como a interface de saída para nossa rota estática. Lembre-se do Capítulo 2, "Roteamento estático", que uma rota estática deve ter uma interface de saída ativa antes de ser instalada na tabela de roteamento. Utilizar a interface nula permitirá que R2 anuncie a rota estática através do RIP embora as redes que pertencem à rede sumarizadas 192.168.0.0/16 não existam de fato.

Redistribuição de rota

O segundo comando que precisa ser digitado é o comando redistribute static:

R2(config-router)#redistribute static

A redistribuição envolve levar as rotas de uma origem de roteamento para outra. Em nossa topologia de exemplo, desejamos que o processo RIP em R2 redistribua nossa rota estática (192.168.0.0/16) importando a rota para RIP e a enviando, então, para R1 e R3, utilizando o processo RIP. Nós veremos se isto realmente está acontecendo e, se não, por quê.

Links

"Configurando Interfaces Lógicas," http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.htmlExibir meio visual

Página 2:Verificando e testando a conectividade

Para testar se a topologia possui conectividade completa ou não, nós verificamos primeiro se ambos os links seriais em R2 estão ativos utilizando show ip interface brief, conforme mostrado na figura para Links de R2. Se um link estiver inativo, o campo de Status ou o campo de Protocolo (ou ambos os campos) exibirão down (inativo) na saída do comando. Se um link estiver ativo, ambos os campos exibirão up (ativo), conforme mostrado aqui. R2 possui conectividade direta com R1 e R3 através dos links seriais.

Mas R2 pode executar ping nas redes locais em R1 e R3? Há algum problema de conectividade com um protocolo de roteamento classful e com as sub-redes descontíguas de 172.30.0.0? Testemos as



comunicações entre os roteadores que utilizam ping.

Clique em Pings de R2 na figura.

Esta saída mostra R2 tentando executar ping na interface de 172.30.1.1 em R1 e na interface de 172.30.100.1 em R3. Sempre que R2 executar ping em qualquer sub-rede de 172.30.0.0 em R1 ou R3, somente por volta de 50% das mensagens de ICMP serão bem-sucedidas.


Esta saída do comando mostra que R1 pode executar ping em 10.1.0.1, mas é malsucedido ao tentar executar ping na interface de 172.30.100.1 em R3.


Esta saída do comando mostra que R3 pode executar ping em 10.1.0.1, mas é malsucedido ao tentar executar ping na interface de 172.30.1.1 em R1.

Como você pode ver, há um problema óbvio ao tentar comunicar-se com as sub-redes descontíguas de 172.30.0.0. Nas seções seguintes nós examinaremos as tabelas de roteamento e atualizações de roteamento para investigar mais a fundo este problema e tentar resolvê-lo.Exibir meio visual

Página 3:Utilize a Atividade do Packet Tracer para praticar suas habilidades de configuração de roteador, inclusive configurações de RIPv1.

Clique no ícone do Packet Tracer para obter mais detalhes.Exibir meio visual

7.1.3 RIPv1: Redes descontíguas

Página 1:Você já sabe que o RIPv1 é um protocolo de roteamento classful. Como você pode ver no formato de mensagem de RIPv1, ela não inclui as máscaras de sub-rede em suas atualizações de roteamento. Portanto, RIPv1 não pode suportar redes descontíguas, VLSM ou super-redes de Roteamento entre Domínios com Endereços Classless (CIDR, Classless Inter-Domain Routing). No entanto, pode haver espaço para expandir o formato de mensagem de RIPv1 para incluir a máscara de sub-rede de forma que nós possamos ter realmente uma configuração de rede descontígua? Como você alteraria o formato desta mensagem na figura para incluir a máscara de sub-rede?Exibir meio visual

Página 2:Como a máscara de sub-rede não está incluída na atualização, RIPv1 e outros protocolos de roteamento classful devem sumarizar as redes a limites de rede principal. Como você pode ver na figura, RIPv1 em ambos os roteadores R1 e R3 irá sumarizar suas sub-redes de 172.30.0.0 para o endereço de rede classful principal de 172.30.0.0 ao enviar atualizações de roteamento para R2. Da perspectiva de R2, ambas as atualizações possuem um custo igual de 1 salto para alcançar a rede 172.30.0.0/16. Como você verá, R2 instala ambos os caminhos na tabela de roteamento.



Exibir meio visual

Página 3:Examinando as tabelas de roteamento

Como você viu, R2 obtém resultados inconsistentes ao tentar executar ping em um endereço em uma das sub-redes de 172.30.0.0.

Clique em Rotas de R2 na figura.

Note que R2 possui duas rotas para a rede 172.30.0.0/16 com custos iguais. Isto porque R1 e R3 estão enviando para R2 uma atualização de RIPv1 para a rede classful 172.30.0.0/16 com uma métrica de 1 salto. Como R1 e R3 sumarizaram automaticamente as sub-redes individuais, a tabela de roteamento de R2 contém somente o endereço classful principal de 172.30.0.0/16.

Nós podemos examinar o conteúdo das atualizações de roteamento conforme as atualizações são enviadas e recebidas com o comando debug ip rip.

Clique em Depur. de R2 1 na figura.

A saída deste comando mostra que R2 está recebendo duas rotas de custos iguais de 172.30.0.0 com uma métrica de 1 salto. R2 está recebendo uma rota na Serial 0/0/0 de R1 e a outra rota na Serial 0/0/1 de R3. Observe que a máscara de sub-rede não está incluída junto ao endereço de rede na atualização.

E quanto a R1 e R3? Eles estão recebendo cada umas das sub-redes de 172.30.0.0?


Aqui nós vemos que R1 possui suas próprias rotas para 172.30.0.0: 172.30.2.0/24 e 172.30.1.0/24. Mas R1 não envia para R2 essas sub-redes. R3 possui uma tabela de roteamento semelhante. R1 e R3 são roteadores de borda e estão enviando somente a rede 172.30.0.0 sumarizada para R2 em suas atualizações de roteamento de RIPv1. Como resultado, R2 sabe somente sobre a rede classful 172.30.0.0/16 e não tem ciência de nenhuma sub-rede de 172.30.0.0.

Clique em Depur. de R2 2 na figura.

Observe que, na saída do comando debug ip rip para R2, não está incluída a rede 172.30.0.0 em suas atualizações para R1 ou R3. Por que não? Porque a regra de split horizon é aplicada. R2 obteve informações sobre 172.30.0.0/16 em ambas as interfaces Serial 0/0/0 e Serial 0/0/1. Como R2 obteve informações sobre 172.30.0.0 nestas interfaces, ele não inclui aquela rede nas atualizações que envia para estas mesmas interfaces.Exibir meio visual

7.1.4 RIPv1: Sem suporte de VLSM

Página 1:Como RIPv1 não envia a máscara de sub-rede nas atualizações de roteamento, ele não pode suportar VLSM. O roteador R3 é configurado com sub-redes VLSM, das quais todas são membros da rede de classe B 172.30.0.0/16:



� 172.30.100.0/24 (FastEthernet 0/0) � 172.30.110.0/24 (Loopback 0) � 172.30.200.16/28 (Loopback 1) � 172.30.200.32/28 (Loopback 2)

Como vimos nas atualizações de 172.30.0.0/16 para R2 por R1 e R3, o RIPv1 sumariza as sub-redes ao limite de classful ou utiliza a máscara de sub-rede da interface de saída para determinar para quais sub-redes deve anunciar.

Clique na Topologia na figura.

Para demonstrar como o RIPv1 utiliza a máscara de sub-rede da interface de saída, R4 é adicionado à topologia conectada a R3 através da interface FastEthernet0/0 na rede 172.30.100.0/24.

Clique em Saída do comando do roteador na figura.

Observe o debug ip rip na figura. Observe que a única sub-rede de 172.30.0.0 que é enviada ao roteador R4 é 172.30.110.0. Você verá também que R3 está enviando a rede classful principal 172.30.0.0 inteira para a Serial 0/0/1.

Por que RIPv1 em R3 não está incluindo as outras sub-redes, 172.30.200.16/28 e 172.30.200.32/28, nas atualizações para R4? Essas sub-redes não possuem a mesma máscara de sub-rede que a FastEthernet 0/0. Esse é o motivo pelo qual todas as sub-redes devem utilizar a mesma máscara de sub-rede quando um protocolo de roteamento classful é implementado na rede.

Uma explicação mais detalhada

R3 precisa determinar quais sub-redes de 172.30.0.0 devem ser incluídas nas atualizações partindo de sua interface FastEthernet 0/0 com o endereço IP 172.30.100.1/24. Ele somente incluíra essas rotas de 172.30.0.0 em sua tabela de roteamento com a mesma máscara da interface de saída. Considerando que a interface é 172.30.100.1 com uma máscara /24, ele incluirá somente as sub-redes 172.30.0.0 com uma máscara /24. A única que atende esta condição é 172.30.110.0.

As outras sub-redes de 172.30.0.0, 172.30.200.16/28 e 172.30.200.32/28 não são incluídas porque as máscaras /28 não correspondem à máscara /24 da interface de saída. O roteador destino, R4, pode aplicar somente sua própria máscara de interface /24 aos anúncios de rota de RIPv1 com sub-redes 172.30.0.0. R4 aplicaria a máscara errada /24 a estas sub-redes com máscaras /28.Exibir meio visual

7.1.5 RIPv1: Sem suporte de CIDR

Página 1:A rota estática de 192.168.0.0/16

Até o momento, grande parte destas informações devem ser familiares a você pelo Capítulo 5, "RIPv1." Porém, há um problema que nós ainda não abordamos.

Clique em Roteamento de R2 na figura.

Nós configuramos uma rota estática para a rede 192.168.0.0/16 em R2 e instruímos RIP a incluir aquela rota em suas atualizações utilizando o comando redistribute static, como mostrado na figura. Esta rota estática é uma sumarização das sub-redes de 192.168.0.0/24 entre 192.168.0.0/24 e 192.168.255.0/24.





Nós podemos ver que a rota estática está incluída na tabela de roteamento de R2.


Observando a tabela de roteamento para R1, notamos que R1 não está recebendo esta rota de 192.168.0.0/16 em suas atualizações RIP de R2, embora pudéssemos esperar que o fizesse.

Clique em Depuração de R2 na figura.

Utilizando debug ip rip em R2, observamos que RIPv1 não inclui a rota 192.168.0.0/16 em suas atualizações de RIP para R1 ou R3. Você pode imaginar por que esta rota não é incluída? Observe a rota 192.168.0.0/16. Qual é a classe da rota? Classe A, B ou C? Qual é a máscara utilizada na rota estática? Ela corresponde à classe? A máscara na rota estática é menor do que a máscara classful?

Nós configuramos a rota estática 192.168.0.0 com uma máscara /16. Ela tem menos bits do que a máscara classful de classe C /24. Como a máscara não corresponde à classe ou a uma sub-rede da classe, RIPv1 não incluirá esta rota em suas atualizações para outros roteadores.

RIPv1 e outros protocolos de roteamento classful não podem suportar rotas de CIDR que são rotas sumarizadas com uma máscara de sub-rede menor do que a máscara classful da rota. RIPv1 ignora estas super-redes na tabela de roteamento e não as inclui nas atualizações para outros roteadores. Isto acontece porque o roteador destino só pode aplicar a maior máscara classful para a atualização e não a máscara /16 mais curta.

Nota: Se a rota estática de 192.168.0.0 fosse configurada com uma máscara /24 ou maior, esta rota seria incluída nas atualizações RIP. Os roteadores destino aplicariam a máscara classful /24 para esta atualização.Exibir meio visual

Página 2:Utilize a Atividade do Packet Tracer no modo de Simulação para verificar se as atualizações não são enviadas através dos limites de rede classful com RIPv1. No modo Tempo real, verifique a não convergência com show ip route, ping e debug ip rip.


7.2 Configurando o RIPv27.2.1 Habilitando e verificando o RIPv2

Página 1:Comparando os formatos de mensagem de RIPv1 e RIPv2

O RIPv2 está definido na RFC 1723. Como a versão 1, o RIPv2 é encapsulado em um segmento de UDP utilizando a porta 520 e pode carregar até 25 rotas. Embora o RIPv2 possua o mesmo formato de mensagem básico que o RIPv1, são adicionadas duas extensões significativas.



A primeira extensão no formato de mensagem de RIPv2 é o campo de máscara de sub-rede, que permite incluir uma máscara de 32 bits na entrada de rota RIP. Como resultado, o roteador destino já não depende da máscara de sub-rede da interface de entrada ou da máscara classful ao determinar a máscara de sub-rede para uma rota.

A segunda extensão significativa para o formato de mensagem de RIPv2 é a adição do endereço do próximo salto. O endereço do próximo salto é utilizado para identificar um endereço do próximo salto melhor – caso exista – do que o endereço do roteador de origem. Se o campo for definido como todos os zeros (0.0.0.0), o endereço do roteador origem será o melhor endereço do próximo salto. Informações detalhadas sobre como o endereço do próximo salto é utilizado estão além do escopo deste curso. Entretanto, um exemplo pode ser encontrado na RFC 1722 ou em TCP/IP de

Roteamento Volume 1 de Jeff Doyle.

Links

"RFC 1723: RIP Versão 2," http://www.ietf.org/rfc/rfc1723.txtExibir meio visual

Página 2:Versão 2

Por padrão, quando um processo de RIP é configurado em um roteador Cisco, isso significa que ele está executando o RIPv1. Entretanto, embora o roteador somente envie mensagens de RIPv1, ele pode interpretar mensagens de RIPv1 e de RIPv2. Um roteador com RIPv1 irá somente ignorar os campos de RIPv2 na entrada de rota.

Clique em RIPv1 de R2 na figura.

O comando show ip protocols verifica se R2 está configurado para RIPv1, mas recebe mensagens de RIP para ambas as versões.

Clique em Configs de RIPv2 na figura.

Observe que o comando version 2 é utilizado para modificar o RIP para utilizar a versão 2. Este comando deve ser configurado em todos os roteadores no domínio de roteamento. O processo de RIP incluirá agora a máscara de sub-rede em todas as atualizações, fazendo de RIPv2 um protocolo de roteamento classless.

Clique em RIPv2 de R2 na figura.

Como você pode ver na saída do comando, quando um roteador é configurado para a versão 2, somente as mensagens de RIPv2 são enviadas e recebidas.

Clique em Reverter para RIPv1 na figura.

O comportamento padrão de RIPv1 pode ser restaurado utilizando o comando no version no modo de configuração do roteador. Porém, o comando version 1 também pode ser utilizado de forma que somente as mensagens de RIPv1 sejam enviadas e recebidas.Exibir meio visual



7.2.2 Sumarização automática e RIPv2

Página 1:Examinando as tabelas de roteamento

Como RIPv2 é um protocolo de roteamento classless, espera-se que você veja as sub-redes individuais de 172.30.0.0 nas tabelas de roteamento. Porém, quando examinarmos a tabela de roteamento para R2 na figura, ainda veremos a rota de 172.30.0.0/16 sumarizada com os mesmos dois caminhos de custos iguais. Os roteadores R1 e R3 ainda não incluem as sub-redes de 172.30.0.0 do outro roteador.


A única diferença até o momento entre RIPv1 e RIPV2 é que R1 e R3 possuem, cada um, uma rota para a super-rede 192.168.0.0/16. Esta era a rota estática configurada em R2 e redistribuída por RIP.

Clique em Depuração de R1 1 na figura.

Então, o que está acontecendo? Para examinar quais rotas de RIPv2 estão sendo enviadas e recebidas, nós utilizaremos o comando debug ip rip. A figura mostra a saída do comando debug ip rip para R1. Note que RIPv2 está enviando o endereço de rede e a máscara de sub-rede:

RIP: sending v2 update to 224.0.0.9 via Serial0/0 (209.165.200.230)172.30.0.0/16 via 0.0.0.0, metric 1, tag 0

Observe, entretanto, que a rota enviada é o endereço sumarizado de rede classful, 172.30.0.0/16, e não as sub-redes 172.30.1.0/24 e 172.30.2.0/24 individuais.

Clique em Sumarização automática na figura.

Por padrão, RIPv2 sumariza automaticamente as redes a limites de rede principal, assim como o RIPv1. Ambos os roteadores R1 e R3 ainda estão sumarizando suas sub-redes de 172.30.0.0 ao endereço classe B 172.30.0.0 ao enviar atualizações para fora de suas interfaces nas redes 209.165.200.228 e 209.165.200.232, respectivamente. O comando show ip protocols mostra que "automatic summarization is in effect." (“sumarização automática está em funcionamento”).

Clique em Depuração de R1 2 na figura.

A única alteração resultante do comando version 2 é que R2 está incluindo agora a rede 192.168.0.0/16 em suas atualizações. Isto porque o RIPv2 inclui a máscara 255.255.0.0 com o endereço de rede 192.168.0.0 na atualização. R1 e R3 receberão agora esta rota estática redistribuída por RIPv2 e as inserirão em suas tabelas de roteamento.

Nota: Lembre-se: a rota 192.168.0.0/16 não pôde ser distribuída com RIPv1 porque a máscara de sub-rede era menor que a máscara classful. Como a máscara não é incluída nas atualizações de RIPv1, não havia nenhum modo do roteador utilizando RIPv1 determinar qual máscara deveria ser. Portanto, a atualização nunca foi enviada.Exibir meio visual

7.2.3 Desabilitando a sumarização automática em RIPv2

Página 1:Como você pode ver na figura, para modificar o comportamento de RIPv2 padrão de sumarização



automática, utilize o comando no auto-summary no modo de configuração do roteador. Este comando não é válido com RIPv1. Embora o IOS Cisco permita que você configure o no auto-summary para RIPv1, o comando não tem efeito algum. Você também deve configurar a versão 2 antes de o IOS Cisco alterar o modo de envio das atualizações de RIP.

Quando a sumarização automática foi desabilitada, o RIPv2 já não sumariza redes para o seu endereço classful em roteadores de borda. O RIPv2 incluirá agora todas as sub-redes e suas máscaras apropriadas em suas atualizações de roteamento. O comando show ip protocols pode ser utilizado para verificar se "automatic network summarization is not in effect." (“sumarização automática de rede não está em funcionamento”).Exibir meio visual

7.2.4 Verificando as atualizações de RIPv2

Página 1:Agora que nós estamos utilizando o protocolo de roteamento classless RIPv2 e que também desabilitamos a sumarização automática, o que deveremos ver nas tabelas de roteamento?

Na figura, a tabela de roteamento para R2 agora contém as sub-redes individuais para 172.30.0.0/16. Observe que não há mais uma rota de sumarização única com dois caminhos de custos iguais. Cada sub-rede e máscara tem sua própria entrada específica, juntamente com a interface de saída e endereço do próximo salto para alcançar aquela sub-rede.


A tabela de roteamento para R1 contém todas as sub-redes para 172.30.0.0/16, inclusive as sub-redes de R3.


A tabela de roteamento para R3 contém todas as sub-redes para 172.30.0.0/16, incluindo as sub-redes de R1. Esta rede convergiu.


Nós podemos verificar se o protocolo de roteamento classless RIPv2 está de fato enviando e recebendo as informações de máscara de sub-rede nas atualizações de roteamento utilizando o comando debug ip rip. Note que cada entrada de rota inclui agora a notação de corte para a máscara de sub-rede.

Nós também podemos ver se uma atualização em uma interface tem sua métrica aumentada antes de ela ser enviada para outra interface. Por exemplo, a atualização que foi recebida na Serial 0/0/1 para a rede 172.30.100.0/24 com 1 salto é enviada para outras interfaces, tais como a Serial 0/0/0, com uma métrica de 2, ou 2 saltos.

RIP: received v2 update from 209.165.200.234 on Serial0/0/1172.30.100.0/24 via 0.0.0.0 in 1 hopsRIP: sending v2 update to 224.0.0.9 via Serial0/0/0 (209.165.200.229)172.30.100.0/24 via 0.0.0.0, metric 2, tag 0

Observe também que as atualizações são enviadas com o uso do endereço de multicast 224.0.0.9. O RIPv1 envia atualizações como um broadcast 255.255.255.255. Existem diversas vantagens de utilizar um endereço de multicast. Detalhes sobre endereçamento multicast estão além do escopo



deste curso; porém, em geral multicasts podem consumir menos largura de banda na rede. Além disso, atualizações de multicast exigem menos processamento por dispositivos que não são habilitados para RIP. Sob RIPv2, qualquer dispositivo que não estiver configurado para RIP descartará o quadro na camada de enlace de dados. Com atualizações de broadcast sob configurações de RIPv1, todos os dispositivos em uma rede de broadcast como a Ethernet devem processar uma atualização RIP por todo o caminho até a camada de transporte, onde o dispositivo detecta finalmente que o pacote é destinado para um processo que não existe.Exibir meio visual

Página 2:Utilize a Atividade do Packet Tracer para configurar RIPv2, desabilitar a sumarização automática e verificar suas configurações.


7.3 VLSM e CIDR7.3.1 RIPv2 e VLSM

Página 1:Como os protocolos de roteamento classless como o RIPv2 podem considerar tanto o endereço de rede quanto a máscara de sub-rede, eles não precisam sumarizar estas redes aos seus endereços classful a limites de rede principal. Portanto, os protocolos de roteamento classless suportam VLSM. Os roteadores que utilizam o RIPv2 já não precisam utilizar a máscara da interface de entrada para determinar a máscara de sub-rede no anúncio da rota. A rede e a máscara são explicitamente incluídas em todas as atualizações de roteamento.

Em redes que utilizam um esquema de endereçamento de VLSM, um protocolo de roteamento classless é essencial para propagar todas as redes junto com suas máscaras de sub-rede corretas. Observando a saída do comando debug ip rip para R3 na figura, nós podemos ver que RIPv2 inclui as redes e suas máscaras de sub-rede em suas atualizações de roteamento.

Observe também na figura que nós adicionamos mais uma vez o roteador R4 na topologia. Lembre-se: com RIPv1, R3 enviaria somente para R4 as rotas 172.30.0.0 que tiveram a mesma máscara que a interface de saída FastEthernet 0/0. Como a interface é 172.30.100.1 com uma máscara /24, RIPv1 somente incluiu as sub-redes 172.30.0.0 com uma máscara /24. A única rota que atendeu esta condição foi 172.30.110.0.

Porém, com RIPv2, R3 pode incluir agora todas as sub-redes de 172.30.0.0 em suas atualizações do roteamento para R4, como mostrado na saída do comando de depuração na figura. Isto porque o RIPv2 pode incluir a máscara de sub-rede adequada com o endereço de rede na atualização.Exibir meio visual

7.3.2 RIPv2 e CIDR

Página 1:Uma das metas do Roteamento Entre Domínios com Endereços Classless (CIDR, Classless Inter-Domain Routing), conforme estabelecido pela RFC 1519, é "fornecer um mecanismo para a agregação de informações de roteamento". Esta meta inclui o conceito de criar super-redes. Uma



super-rede é um bloco de redes classful contíguas que é tratado como uma única rede. No roteador R2, nós configuramos uma super-rede - uma rota estática para uma única rede que é utilizada para representar diversas redes ou sub-redes.

Super-redes possuem máscaras que são menores do que a máscara classful (neste caso /16, em vez da classful /24). Para a super-rede ser incluída em uma atualização de roteamento, o protocolo de roteamento deve ter a capacidade de considerar aquela máscara. Em outras palavras, ela deve ser um protocolo de roteamento classless, como RIPv2.

A rota estática em R2 inclui uma máscara que é menor que a máscara classful:


Em um ambiente classful, o endereço de rede 192.168.0.0 seria associado à máscara de classe C /24 ou 255.255.255.0. Nas redes de hoje, nós não associamos mais os endereços de rede a máscaras classful . Neste exemplo, a rede 192.168.0.0 possui uma máscara /16 ou 255.255.0.0. Esta rota pode representar uma série de redes 192.168.0.0/24 ou qualquer número de intervalos de endereços diferentes. O único modo de esta rota ser incluída em uma atualização de roteamento dinâmico é utilizando um protocolo de roteamento classless que inclua a máscara /16.


Utilizando o comando debug ip rip, podemos ver que esta super-rede de CIDR é incluída na atualização de roteamento enviada por R2. A sumarização automática não precisa ser desabilitada em RIPv2 ou em qualquer protocolo de roteamento classless para que as super-redes sejam incluídas nas atualizações.


A tabela de roteamento para R1 mostra que ele recebeu a rota de super-rede de R2.Exibir meio visual

7.4 Verificação, identificação e solução de problemas de RIPv27.4.1 Comandos de verificação, identificação e solução de problemas

Página 1:Existem diversas maneiras para verificar, identificar e solucionar problemas de RIPv2. Muitos dos mesmos comandos utilizados para RIPv2 podem ser utilizados para verificar, identificar e solucionar problemas de outros protocolos de roteamento.

É melhor sempre começar com o básico:

1. Certifique-se de que todos os links (interfaces) estejam ativos e em funcionamento.

2. Verifique o cabeamento.

3. Certifique-se de que você tem o endereço IP e máscara de sub-rede corretos em cada interface.

4. Remova os comandos de configuração que não sejam mais necessários ou que tenham sido substituídos por outros comandos.

Clique em show ip route na figura.



Este é o primeiro comando a ser utilizado para verificar a convergência de rede. Conforme você examina a tabela de roteamento, é importante procurar as rotas que você espera que estejam nela e também as que não deveriam estar.

Clique em show ip interface brief na figura.

Se estiver faltando uma rede na tabela de roteamento, geralmente é porque uma interface está inativa ou configurada incorretamente. Os comando show ip interface brief verifica rapidamente o status de todas as interfaces.

Clique em show ip protocols na figura.

O comando show ip protocols verifica diversos itens críticos, inclusive se o RIP está habilitado, a versão do RIP, o status da sumarização automática e as redes que foram incluídas nos comandos network. As Fontes de Informações de Roteamento listadas na parte inferior da saída do comando são os vizinhos de RIP dos quais este roteador está atualmente recebendo atualizações.

Clique em debug ip rip na figura.

Conforme demonstrado ao longo do capítulo, o comando debug ip rip é um excelente comando para examinar o conteúdo das atualizações de roteamento que são enviadas e recebidas por um roteador. Muitas vezes, uma rota pode ser recebida por um roteador mas não ser adicionada à tabela de roteamento. Uma razão para isto pode ser que uma rota estática também está configurada para a mesma rede que está sendo anunciada. Por padrão, uma rota estática possui uma distância administrativa inferior do que qualquer protocolo de roteamento dinâmico e levará vantagem para ser acrescentada na tabela de roteamento.

Clique em ping na figura.

Um modo fácil de verificar a conectividade de ida-e-volta é com o comando ping. Se conectividade fim-a-fim não for bem-sucedida, comece executando ping nas interfaces locais. Caso obtenha sucesso, execute ping nas interfaces de roteador nas redes diretamente conectadas. Se isso também obtiver sucesso, continue executando ping nas interfaces em cada roteador sucessivo. Quando o comando ping for malsucedido, examine ambos os roteadores e todos os roteadores intermediários para determinar onde e por que o ping está falhando.

Clique em show running-config na figura.

O comando show running-config pode ser utilizado para verificar todos os comandos configurados atualmente. Normalmente, outros comandos são mais eficientes e fornecem mais informações do que uma simples listagem de configurações atuais. Porém, o comando show running-config é útil para determinar se algo óbvio foi esquecido ou mal configurado.Exibir meio visual

7.4.2 Problemas comuns do RIPv2

Página 1:Ao identificar e solucionar problemas específicos para RIPv2, existem várias áreas a serem examinadas.

Versão

Um bom ponto de partida para começar a identificar e solucionar problemas na rede que está



executando o RIP é verificar se a versão 2 está configurada em todos os roteadores. Embora o RIPv1 e o RIPv2 sejam compatíveis, o RIPv1 não suporta sub-redes descontíguas, VLSM ou rotas de super-rede CIDR. É melhor sempre utilizar o mesmo protocolo de roteamento em todos os roteadores a menos que haja uma razão específica para não fazê-lo.

Comandos network

Outra fonte de problemas pode ser comandos network rede incorretos ou perdidos. Lembre-se de que um comando network faz duas coisas:

� Permite que o protocolo de roteamento envie e receba atualizações nas interfaces locais que pertençam àquela rede.

� Inclui aquela rede em suas atualizações de roteamento para seus roteadores vizinhos.

Um comando network incorreto ou que estiver faltando resultará na perda ou não envio de atualizações de roteamento em uma interface.

Sumarização automática

Se houver necessidade ou expectativa para enviar sub-redes específicas e não apenas rotas sumarizadas, verifique se a sumarização automática foi desabilitada.Exibir meio visual

7.4.3 Autenticação

Página 1:A maioria dos protocolos de roteamento envia suas atualizações de roteamento e outras informações de roteamento utilizando o IP (em pacotes IP). IS-IS é a exceção notável e é discutido em cursos CCNP. Uma preocupação de segurança de qualquer protocolo de roteamento é a possibilidade de aceitar atualizações de roteamento inválidas. A origem destas atualizações de roteamento inválidas pode ser um invasor tentando atrapalhar o funcionamento da rede ou tentando capturar pacotes enganando o roteador enviando suas atualizações ao destino errado. Outra fonte de atualizações inválidas pode ser um roteador mal configurado. Ou talvez um host esteja conectado à rede executando o protocolo de roteamento da rede local sem o conhecimento de seu usuário.

Por exemplo, na figura, R1 está propagando uma rota padrão a todos os outros roteadores neste domínio de roteamento. Porém, alguém adicionou o roteador R4 erroneamente à rede, o qual também está propagando uma rota padrão. Alguns dos roteadores podem encaminhar tráfego padrão para R4 em vez de encaminhar para o roteador gateway real, R1. Estes pacotes podem entrar em um “buraco negro” e nunca mais serem vistos.

Qualquer que seja a razão, é uma boa prática autenticar as informações de roteamento transmitidas entre os roteadores. RIPv2, EIGRP, OSPF, IS-IS e BGP podem ser configurados para autenticar suas informações de roteamento. Esta prática assegura que os roteadores somente aceitem informações de roteamento de outros roteadores que foram configurados com a mesma senha ou informações de autenticação. Nota: A autenticação não criptografa a tabela de roteamento.

Nota: Como o RIP abriu caminho para protocolos de roteamento mais populares, não são discutidas neste capítulo as características detalhadas de configuração para autenticação em RIPv2. Em vez disso, a configuração de protocolos de roteamento para utilizar autenticação será discutida em um curso posterior com outras questões de segurança.Exibir meio visual



Utilize a Atividade de Packet Tracer para ver como as atualizações de roteamento não intencionais podem corromper a tabela de roteamento.


7.5 Laboratórios de configuração RIPv27.5.1 Configuração RIPv2 básica

Página 1:Neste laboratório, você trabalhará com uma rede descontígua que é dividida em sub-redes utilizando o VLSM. Conforme visto ao longo deste capítulo e do Capítulo 5, "RIP versão 1", ele pode ser um problema quando o protocolo de roteamento utilizado não incluir informações suficientes para distinguir as sub-redes individuais. Para resolver este problema, você configurará o RIPv2 como o protocolo de roteamento classless para fornecer informações de máscara de sub-rede nas atualizações de roteamento.

Clique no ícone de laboratório para obter mais detalhes.Exibir meio visual

Página 2:Utilize a Atividade do Packet Tracer para repetir uma simulação de Laboratório 7.5.1. Lembre-se, entretanto, de que o Packet Tracer não substitui um exercício prático em laboratório com equipamentos reais.

Um resumo das instruções é fornecido na atividade. Use o PDF do laboratório para obter mais detalhes.


7.5.2 Configuração RIPv2 avançada

Página 1:Nesta atividade de laboratório, você recebe um endereço de rede que deve ser dividido em sub-redes utilizando o VLSM para concluir o endereçamento da rede. Uma combinação entre roteamentos de RIP versão 2 e estático será obrigatória para que os hosts em redes que não estejam diretamente conectadas possam se comunicar entre si e com a Internet.


Página 2:Utilize a Atividade do Packet Tracer para repetir uma simulação de Laboratório 7.5.2. Lembre-se,



entretanto, de que o Packet Tracer não substitui um exercício prático em laboratório com equipamentos reais.



7.5.3 Identificação e solução de problemas de RIPv2

Página 1:Neste laboratório, você começa carregando scripts de configuração em todos os roteadores. Esses scripts contêm erros que impedirão a comunicação fim-a-fim através da rede. Após carregar os scripts corrompidos, identifique e solucione os problemas de cada roteador para determinar os erros de configuração e, em seguida, utilize os comandos apropriados para corrigir as configurações. Quando todos os erros de configuração forem corrigidos, todos os hosts na rede devem poder comunicar-se uns com os outros.


Página 2:Utilize a Atividade do Packet Tracer para repetir uma simulação de Laboratório 7.5.3. Lembre-se, entretanto, de que o Packet Tracer não substitui um exercício prático em laboratório com equipamentos reais.



7.6 Resumo do capítulo7.6.1 Resumo e revisão

Página 1:Resumo

RIPv2 é o protocolo de roteamento do vetor de distância classless que é definido na RFC 1723. Como o RIPv2 é um protocolo de roteamento classless, ele inclui a máscara de sub-rede com os endereços de rede nas atualizações de roteamento. Assim como ocorre com outros protocolos de roteamento classless, o RIPv2 suporta super-redes CIDR, VLSM e redes descontíguas.

Nós vimos que os protocolos de roteamento classful como o RIPv1 não podem suportar redes descontíguas porque eles sumarizam automaticamente a limites de rede principal. Um roteador que recebe atualizações de roteamento de vários roteadores que anunciam a mesma rota de sumarização classful não pode determinar quais sub-redes pertencem a qual rota de sumarização. Esta incapacidade leva a resultados inesperados, por exemplo, pacotes enviados a rotas erradas.



A versão padrão de RIP é a versão 1. O comando version 2 é utilizado para modificar o RIP para RIPv2.

Semelhante ao RIPv1, o RIPv2 sumariza automaticamente aos limites de rede principal. Entretanto, com RIPv2, a sumarização automática pode ser desabilitada com o comando no auto-summary. A sumarização automática deve ser desabilitada para suportar redes descontíguas. O RIPv2 também suporta super-redes CIDR e VLSM porque a máscara de sub-rede específica é incluída com o endereço de rede em toda atualização de roteamento. Você pode utilizar o comando debug ip rippara exibir a atualização RIP que envia a máscara de sub-rede com o endereço de rede como parte da entrada de rota.

O comando show ip protocols mostrará que o RIP está enviando e recebendo agora as atualizações da versão 2 e se a sumarização automática está sendo aplicada ou não.Exibir meio visual

Página 2:Exibir meio visual

Página 3:A Atividade avançada de integração das habilidades no Packet Tracer integra todo o conhecimento e as habilidades que você adquiriu nos capítulos anteriores deste curso e nos cursos anteriores. As habilidades relacionadas à discussão sobre RIPv2 também estão incluídas. Nesta atividade, você cria uma rede do zero.

Começando com um espaço de endereçamento e requisitos de rede, você deve implementar um projeto de rede que satisfaça às especificações para, então, implementar uma configuração de roteamento de RIPv2 efetiva com o roteamento padrão integrado. Instruções detalhadas são fornecidas na atividade.

Instruções de integração das habilidades no Packet Tracer (PDF)


Página 4:Para saber mais

RFC 1723 RIP versão 2

RFCs (Request for Comments) é uma série de documentos enviados à IETF (Internet Engineering Task Force) para propor um padrão de Internet ou comunicar novos conceitos, informações ou até mesmo diversão. RFC 1723 é o RFC para o RIP versão 2.

As RFCs podem ser acessadas em vários sites, inclusive o www.ietf.org. Leia tudo ou partes do RFC 1726 para obter mais informações sobre este protocolo de roteamento classless.

Packet Tracer



Utilize o Packet Tracer para criar duas redes classful descontíguas. Cada rede descontígua deve ter vários roteadores e sub-redes, um utilizando VLSM. Entre os dois grupos de redes descontíguas, adicione outro roteador que vincule as duas redes descontíguas. Certifique-se de utilizar uma rede principal diferente entre este roteador e cada uma das duas redes descontíguas.

Utilize este cenário para examinar os problemas com RIPv1 e como RIPv2 pode ser utilizado para resolver estes problemas de roteamento.Exibir meio visual

7.7 Teste do capítulo7.7.1 Teste do capítulo

Página 1:Exibir meio visual

Ir para a próximaIr para a anteriorIr para a parte superior

All contents copyright © 2007-2009 Cisco Systems, Inc. | Translated by the Cisco Learning Institute. Sobre



Ccna 4.0 - Rpc - 07 Ripv2

Documents

Transcript of Ccna 4.0 - Rpc - 07 Ripv2