Redistribuindo entre protocolos com classes e sem classes: EIGRP ou OSPF no RIP ou IGRP

Opções de download

PDF (88.8 KB)
Ver no Adobe Reader em vários dispositivos
ePub (74.8 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (75.2 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:10 de Agosto de 2005

ID do documento:13721

Sobre a tradução

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Índice

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Convenções

OSPF tem uma máscara maior que RIP

Solução

RIP tem uma máscara maior que OSPF

Solução

Conclusão

Informações Relacionadas

Introdução

Este documento explica dois problemas comuns com rotas de distribuição entre RIP e OSPF ou IGRP e EIGRP. O RIP e o IGRP não anunciarão rotas fora de uma interface se essas rotas estiverem na mesma rede principal, mas tiverem uma máscara diferente da dessa interface. Para obter mais informações sobre atualizações de RIP e IGRP, consulte Comportamento de RIP e IGRP durante o envio e a recepção de atualizações.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

OSPF tem uma máscara maior que RIP

No diagrama da rede para este problema, o roteador GW-2 está redistribuindo entre o RASGO e o OSPF. O domínio de OSPF tem uma máscara diferente (mais longa neste caso) do que o domínio do RASGO, e estão na mesma rede principal. Consequentemente, o RASGO não anunciará as rotas aprendidas do OSPF e redistribuídas no RASGO.

Solução

A máscara de sub-rede do domínio de OSPF é difícil de mudar tão pelo contrário, adiciona uma rota estática no roteador GW-2 que aponta ao domínio de OSPF com uma máscara de 255.255.255.0, mas com um salto seguinte do null0. Em seguida, redistribua as rotas estáticas no RIP. Está aqui a configuração para realizar esta tarefa:

ip route 128.103.35.0 255.255.255.0 null0
 router rip 
 redistribute static
 default metric 1

Isto permite que 128.103.35.0 seja anunciado através do RASGO para fora a relação E2/0 do roteador GW-2. Contudo, o roteador GW-2 ainda tem umas rotas mais específicas aprendidas do OSPF em sua tabela de roteamento, assim que as melhores decisões de roteamento são feitas.

RIP tem uma máscara maior que OSPF

No diagrama da rede para este problema, o domínio do RASGO tem uma máscara de 255.255.255.248 e o domínio de OSPF tem uma máscara de 255.255.255.240. O RASGO não anunciará as rotas aprendidas do OSPF e redistribuídas no RASGO.

Solução

Podemos adicionar, ao Roteador GW-2, uma rota estática que aponte para o domínio OSPF com uma máscara 255.255.255.248. Contudo, porque esta é uma máscara mais específica do que a máscara original OSPF, o salto seguinte deve ser um salto seguinte ou uma relação real. Também, necessitamos de múltiplas rotas estáticas a fim de cobrir todos os endereços no domínio do OSPF. As rotas estáticas desta via são redistribuídas no RIP.

No código abaixo, as primeiras duas rotas estáticas cobrem a escala 128.103.35.32 255.255.255.240 no domínio de OSPF. A segunda das duas rotas estáticas abrange a faixa 128.103.35.16 255.255.255.240 no domínio OSPF. E as últimas quatro rotas cobrem o intervalo 128.130.35.64 255.255.255.240, as quais são conhecidas via duas interfaces no domínio OSPF.

ip route 128.103.35.32 255.255.255.248 E0/0 
ip route 128.103.35.40 255.255.255.248 E0/0

ip route 128.103.35.16 255.255.255.248 E1/0
ip route 128.103.35.24 255.255.255.248 E1/0

ip route 128.103.35.64 255.255.255.248 128.103.35.34
ip route 128.103.35.64 255.255.255.248 128.103.35.18
ip route 128.103.35.72 255.255.255.248 128.103.35.34
ip route 128.103.35.72 255.255.255.248 128.103.35.18
router rip
redistribute static
default metric 1

Conclusão

As soluções apresentadas neste documento igualmente trabalham quando você usa o EIGRP em vez do OSPF, e IGRP em vez do RASGO. Este problema não deve acontecer se as máscaras de ambos os protocolos são as mesmas ou se todos os protocolos você usam a máscara de sub-rede de comprimento variável do apoio (VLS). Este reparo é considerado somente uma correção de programa para cobrir a limitação do RASGO e IGRP (VLS). Para obter mais informações sobre do RASGO e da limitação do IGRP VLS, refira porque o apoio VLS NÃO RASGUE e IGRP?.