Rota Redistribuição – Parte 1

ccie r/s ccnp r/s Set 25, 2018

Introdução à Rota Redistribuição

Até lá é um protocolo de roteamento para a todos governar, é necessário ter vários protocolos de roteamento coexistir pacificamente na mesma rede. Talvez a empresa a execute o OSPF, e a empresa B execute o EIGRP, e as duas empresas se fundem. Até que a equipe de TI recém-combinada concorde com um protocolo de roteamento padrão para usar (se o fizerem), as rotas conhecidas pelo OSPF precisam ser anunciadas na parte da rede que executa o EIGRP e vice-versa.

esse cenário é possível graças à redistribuição de rotas, e esse é o foco desta postagem do blog. Outras razões pelas quais você pode precisar realizar a redistribuição de rotas incluem: diferentes partes da rede de sua própria empresa estão sob controle administrativo diferente; você deseja anunciar rotas para seu provedor de serviços via BGP; ou talvez você queira se conectar com a rede de um parceiro de negócios. Considere a seguinte topologia básica.

no Show topologia simples acima, estamos querendo OSPF e EIGRP para anunciar as rotas que conhecem uns aos outros. Esse conceito é chamado de redistribuição de rota mútua. Como o roteador R2 possui uma interface no sistema autônomo OSPF (AS) e uma interface no EIGRP AS, Ele assume a responsabilidade de realizar a redistribuição de rota.

métricas de sementes

o principal desafio que encontramos ao redistribuir rotas entre diferentes protocolos de roteamento são as diferentes abordagens que os protocolos de roteamento usam para medir suas métricas. Por exemplo, o OSPF usa uma métrica de custo, que é baseada na largura de banda, enquanto o EIGRP usa uma métrica baseada na largura de banda e atraso, por padrão, mas também pode considerar confiabilidade e/ou carga (e até mesmo usar um valor de unidade de transmissão máxima (MTU) como um disjuntor). O problema não é tão simples quanto converter moedas entre dois países, porque nesse cenário, há uma proporção que descreve a relação das duas moedas. No entanto, com a redistribuição de rotas, essa relação não existe. Então, o que fazemos?

nós, como administradores, podemos configurar a métrica atribuída às rotas que vêm de um AS, que estão sendo redistribuídas para outro AS. Se não nos preocuparmos em Configurar manualmente uma métrica a ser usada para redistribuição de rota, uma métrica de semente será usada. A tabela a seguir mostra as métricas de semente usadas por vários protocolos de roteamento.

o Protocolo de Roteamento

a Semente Métrica

RIP

Infinity

EIGRP

Infinity

OSPF

20 (ou 1 quando redistribuindo rotas BGP)

BGP

Utiliza o IGP valor de métrica

com Base no quadro acima, podemos ver que, por padrão, uma rota redistribuído para o OSPF será atribuído um métrica de 20, a menos que a rota esteja sendo redistribuída para o OSPF do BGP, caso em que a rota seria atribuída um valor métrico de 1. Curiosamente, tanto o RIP quanto o EIGRP têm métricas de semente padrão de infinito, o que significa que qualquer rota redistribuída nesses protocolos de roteamento será considerada inacessível, por padrão e, portanto, não anunciada para nenhum outro roteador. O BGP, no entanto, redistribui uma rota aprendida a partir de um protocolo de gateway interno (IGP) usando a métrica original dessa rota.

Configuração Básica de Exemplo

Certamente, há muito mais a considerar sobre a rota de redistribuição, tais como loops de roteamento que pode ocorrer quando temos mais de um roteador interligando nossos sistemas autônomos, ou como podemos filtrar seletivamente rotas específicas de ser redistribuído, mas nós vamos chegar a todos os que nas próximas postagens do blog. Por enquanto, vamos entender como executar uma configuração básica de redistribuição de rota. Considere a topologia anterior, desta vez com informações de rede e interface adicionadas:

nesta topologia, o roteador R2 é a aprendizagem de rotas de R1 via OSPF e de R3 através de EIGRP, como mostra a seguinte saída do comando show ip route emitido em R2:

no Entanto, nem o roteador R1, nem roteador R3 aprendeu as rotas, porque roteador R2 ainda não está realizando a rota de redistribuição. Isso é evidenciado na saída do comando show ip route emitido em R1 e R3.:

Vamos agora adicionar uma rota de redistribuição de configuração para o roteador R2. Para reforçar a afirmação anterior de que a métrica de semente para rotas redistribuídas no EIGRP é infinita, inicialmente não configuraremos nenhuma métrica e deixaremos as métricas de semente entrarem em vigor.

o comando redistribute foi emitido no modo de configuração do roteador para cada protocolo de roteamento, e nenhuma métrica foi especificada. Também é interessante observar o que, quando inserimos o comando redistribuir eigrp 1 acima, não incluímos a palavra-chave sub-redes no comando, o que faz com que as redes classful e classfuless sejam redistribuídas para o OSPF. No entanto, como visto na saída abaixo, as sub-redes de palavras-chave foi adicionada automaticamente para nós:

Enquanto este comportamento de ter as sub-redes de palavras-chave adicionados automaticamente é visto em versões recentes do Cisco IOS, algumas versões mais antigas do Cisco IOS não incluir automaticamente as sub-redes de palavras-chave, e você pode precisar manualmente adicionar ao seu redistribuir comando.Vamos agora dar uma olhada nas tabelas de roteamento IP nos roteadores R1 e R3 para ver quais rotas eles aprenderam (e não aprenderam).

a saída acima nos mostra que o roteador R2 redistribuiu com sucesso as rotas conhecidas pelo EIGRP no OSPF, que foram aprendidas pelo roteador R1. Observe que as rotas redistribuídas conhecidas pelo roteador R1 têm uma métrica de 20, que é a métrica de semente do OSPF. No entanto, o roteador R3 não aprendeu nenhuma nova rota, porque quando o roteador R2 redistribuiu rotas para o EIGRP, ele usou a métrica de semente do EIGRP do infinito (significando inacessível). Como resultado, essas rotas não foram anunciadas para o roteador R3.

para resolver esse problema, precisamos atribuir uma métrica às rotas que estão sendo redistribuídas no EIGRP. Existem três maneiras principais de atribuir uma métrica não padrão às rotas que estão sendo redistribuídas em um protocolo de roteamento.

  1. defina uma métrica padrão para todos os protocolos de roteamento sendo redistribuídos em um protocolo de roteamento específico.
  2. defina uma métrica como parte do comando redistribuir.
  3. defina uma métrica usando um mapa de rotas.

para ilustrar a primeira opção, vamos configurar a métrica para atribuir a todas as rotas que estão sendo redistribuídas no EIGRP.

a ajuda sensível ao contexto foi usada no exemplo acima para mostrar cada componente da métrica que está sendo atribuída às rotas que estão sendo redistribuídas no EIGRP. No entanto, o comando final foi Padrão-métrica 1000000 1 255 1 1500. Se estivéssemos definindo uma métrica padrão para OSPF, poderíamos ter usado um comando como default-metric 30, para atribuir um custo OSPF de 30 às rotas que estão sendo redistribuídas para OSPF. No entanto, neste exemplo, especificamos apenas uma métrica padrão para EIGRP. Vamos agora verificar a tabela de roteamento IP no roteador R3 para ver se as rotas OSPF foram anunciadas com sucesso no EIGRP.

Sucesso! O roteador R3 aprendeu rotas originadas no OSPF AS. Sabemos que as rotas vieram originalmente de fora do EIGRP devido ao código EX que aparece em cada uma dessas rotas.

a segunda opção para definir a métrica em rotas redistribuídas foi atribuir a métrica como parte do comando redistribuir, que vamos especificar métricas diferentes para diferentes protocolos de roteamento sendo redistribuídos em um processo de roteamento. Para ilustrar essa abordagem, Vamos remover a métrica padrão anterior e redistribuir comandos do roteador R2 e inserir um comando redistribuir que especifique a métrica a ser atribuída.

Se agora revisitar o roteador R3, podemos obter o mesmo resultado que antes:

A terceira opção para definir a métrica de redistribuído rotas foi a utilização de um route-map. Os mapas de rotas são super poderosos e podem ser usados para uma variedade de Configurações. Essencialmente, eles podem corresponder ao tráfego específico e definir um ou mais parâmetros (por exemplo, um endereço IP de próximo salto) para esse tráfego. Em nosso contexto, porém, vamos usar um mapa de rotas para especificar um valor métrico e, em seguida, aplicaremos o mapa de rotas a um comando de redistribuição. O exemplo a seguir, mostra como podemos remover a nossa anterior redistribuir o comando do roteador R2, criar um route-map, e, em seguida, introduza um novo redistribuir o comando que faz referência a nosso route-map:

No exemplo acima, após a remoção de nossos existente redistribuir comando, criamos um route-map chamado SET-MÉTRICA-DEMO. Este era um mapa de rotas muito básico que não precisava corresponder a nenhum tráfego. Foi simplesmente usado para definir uma métrica. No entanto, em uma próxima postagem do blog, veremos que um mapa de rotas pode ser usado para nos dar mais controle sobre nossa redistribuição de rotas. Em nosso exemplo atual, o mapa de rotas foi então aplicado ao nosso novo comando redistribute. Novamente, isso nos dá o mesmo resultado a partir da perspectiva do roteador R3 da tabela de roteamento IP:

OSPF E1 vs. E2 Rotas

Antes de encerrar este primeiro post do blog em nossa Rota de Redistribuição da série, vamos mais uma vez examinar a tabela de roteamento IP no roteador R1:

observe que cada uma das rotas redistribuídas no OSPF aparece na tabela de roteamento IP do roteador R1 com um Código E2. No entanto, há também a opção de ter um Código E1, ambos os quais indicam que a rota se originou de fora do OSPF do roteador AS. Então, qual é a diferença entre esses dois códigos?

um código de E2 indica que uma rota carrega uma métrica que foi atribuída pelo roteador que executa a redistribuição, que é conhecida como um roteador de limite de Sistema Autônomo (ASBR). Isso significa que não importa quantos roteadores adicionais dentro do OSPF tenhamos que cruzar para voltar ao ASBR, a métrica permanece a mesma de quando o ASBR o redistribuiu. Quando redistribuímos rotas para o OSPF, essas rotas, por padrão, são essas rotas externas do tipo 2 (E2).

um código de E1 indica que a métrica de uma rota é composta pelo custo original atribuído pelo ASBR mais o custo necessário para alcançar o ASBR. Isso sugere que uma rota E1 é geralmente mais precisa e, de fato, é. Embora, ter um código de E1 não nos ofereça nenhuma vantagem em uma topologia simples como temos, onde o roteador R1 tem apenas um caminho para alcançar o ASBR (ou seja, R2) e onde há apenas uma maneira de as rotas EIGRP serem injetadas em nosso OSPF AS (ou seja, via roteador R2).

se quisermos redistribuir rotas E1 em OSPF em vez de rotas E2, isso pode ser realizado com o comando redistribuir. No exemplo a seguir, removemos nosso comando redistribute existente para o processo de roteamento OSPF no roteador R2 e, em seguida, reaplicamos o comando redistribute especificando que queremos métricas externas do tipo 1 (e1) aplicadas a rotas redistribuídas.

Vamos confira a tabela de roteamento IP no roteador R1 para ver se as coisas mudaram e com este novo redistribuir comando emitido no roteador R2.

na saída acima, observe que as rotas redistribuídas para o OSPF têm um código de E1, em vez do código padrão de E2. Além disso, observe que isso faz com que a métrica dessas rotas seja um pouco maior. Especificamente, o roteador R2 redistribuiu rotas aprendidas com EIGRP para o OSPF usando a métrica de sementes do OSPF de 20. No entanto, há um custo OSPF de 1 Para ir do roteador R1 ao roteador R2. Portanto, como as rotas redistribuídas foram configuradas como rotas E1, o custo dessas rotas da perspectiva do roteador R1 é o custo originalmente atribuído pelo roteador R1, que era 20, mais o custo para R1 chegar a R2, que é 1, para um custo total de 21.

resumo

nesta postagem do blog, consideramos a necessidade de redistribuição de rota e analisamos uma configuração básica. Discutimos o impacto da métrica de semente de um protocolo de roteamento (que pode ser infinita) ao executar a redistribuição de rota e vimos três maneiras de atribuir administrativamente uma métrica a rotas redistribuídas. Por fim, contrastamos as rotas externas tipo 1 (E1) e externas tipo 2 (E2) da OSPF. Em uma próxima postagem do blog, vamos aproveitar essa topologia e considerar como podemos filtrar seletivamente as rotas que estão sendo redistribuídas. Então, em Mais UMA postagem no blog, consideraremos questões de design em torno de topologias com vários pontos de redistribuição entre dois sistemas autônomos.Espero que tenham gostado deste primeiro vislumbre do mundo da redistribuição de rotas. Se você fez, por favor, ajude a espalhar a palavra compartilhando este post com outras pessoas. Aqui está o link pode partilhar:

https://www.kwtrain.com/blog/route-redistribution-part-1

Até a próxima vez,

Kevin Wallace, CCIEx2 (R/S e Colaboração) #7945

Deixe uma resposta

O seu endereço de email não será publicado.