Este documento descreve como configurar mapas de rotas que são aplicados com o comando redistribute de protocolos de roteamento dinâmico.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Embora o suporte a mapa de rota tenha sido introduzido originalmente no Cisco IOS Software, o comando route-map permanece válido e amplamente utilizado no Cisco IOS XE. Os conceitos gerais de mapa de rotas, como avaliação de sequência ordenada, cláusulas permit e deny, instruções match e ações set também se aplicam ao Cisco IOS XE. A sintaxe de comando e o suporte a recursos podem variar por plataforma, versão de software, protocolo de roteamento e família de endereços. Alguns comandos match e set suportados em um contexto de redistribuição podem não ser suportados ou se comportar de forma diferente em outro contexto. Sempre valide a sintaxe de comando exata em relação à versão de destino e à documentação da plataforma antes da implantação.
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 a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Esta seção fornece uma visão geral dos mapas de rotas usados no software Cisco IOS.
Os mapas de rotas e as listas de controle de acesso (ACLs) compartilham algum comportamento comum. Ambos são mecanismos de política que avaliam entradas em uma ordem definida e retornam um resultado de permissão ou negação.
As características comuns incluem:
Avaliação ordenada:
As ACLs e os mapas de rotas são processados sequencialmente, do menor número de sequência para o maior. A avaliação pára quando a primeira entrada correspondente é encontrada e a ação associada a essa entrada é aplicada.
Lógica de permissão e negação:
As ACLs e os mapas de rota usam instruções permit e deny. No entanto, o significado de permitir e negar depende de como a ACL ou o mapa de rota é aplicado. Por exemplo, o efeito de um mapa de rota usado para redistribuição é diferente do efeito de um mapa de rota usado para o Roteamento Baseado em Políticas (PBR - Policy-Based Routing) ou política BGP.
Comportamento dependente do contexto:
As ACLs e os mapas de rota são ferramentas de política genéricas. O comportamento deles depende da característica que faz referência a eles. O mesmo mapa de rota pode ter efeitos diferentes quando usado para redistribuição, política de rota BGP, PBR ou outro recurso.
Os mapas de rotas e as ACLs também têm diferenças importantes:
As ACLs fornecem correspondência básica de permissão ou negação:
Uma ACL retorna principalmente um resultado sim ou não. No contexto de redistribuição de rota, uma ACL ou lista de prefixos pode ser usada como critério de correspondência para identificar quais rotas são elegíveis para redistribuição.
Os mapas de rotas podem corresponder e modificar informações de roteamento:
Um mapa de rota pode fazer referência a ACLs, listas de prefixos ou outros critérios de correspondência. Além de permitir ou negar rotas, os mapas de rota podem modificar atributos de rota suportados com comandos set. Por exemplo, um mapa de rota usado durante a redistribuição pode definir uma métrica de rota, tag, tipo de métrica ou outros atributos suportados, dependendo dos protocolos de roteamento de origem e de destino.
Os mapas de rotas suportam critérios de correspondência mais avançados:
Os mapas de rota podem corresponder a atributos de roteamento que as ACLs não podem avaliar diretamente. Por exemplo, um mapa de rota pode corresponder a tipo de rota, tag de rota, métrica, próximo salto, origem de rota ou outros atributos específicos do protocolo quando essas condições de correspondência são suportadas no contexto de redistribuição.
O comportamento do fim da política depende do aplicativo:
As ACLs incluem um deny implícito no final. O comportamento do mapa de rota também depende de como o mapa de rota é usado. Para redistribuição, se uma rota não corresponder a nenhuma cláusula do mapa de rota, a rota não será redistribuída. Essa funcionalidade é semelhante a uma negação implícita no final do mapa de rota.
As cláusulas de mapa de rota vazias têm significado especial:
Uma cláusula de mapa de rota sem uma instrução de correspondência corresponde a todas as rotas restantes que atingem essa cláusula. Na redistribuição, uma cláusula de permissão vazia permite a redistribuição de todas as rotas restantes, enquanto uma cláusula de negação vazia bloqueia a redistribuição de todas as rotas restantes.
O comando dynamic routing protocol redistribute geralmente suporta o uso de um mapa de rota para controlar quais rotas são redistribuídas e como os atributos de rota são modificados durante a redistribuição. Quando a filtragem for necessária com base no prefixo ou na máscara, configure uma ACL ou uma lista de prefixos e faça referência a ela a partir de um mapa de rotas com uma instrução de correspondência.
Use um mapa de rota no processo de redistribuição quando precisar modificar informações de rota, como métrica, tag, tipo de métrica ou outros atributos suportados, ou quando precisar corresponder recursos além de uma simples seleção de prefixo ou máscara. Para filtragem baseada em prefixo simples, uma ACL ou lista de prefixos ainda pode ser usada, no entanto, ela é normalmente referenciada dentro do mapa de rota que é aplicado ao comando redistribute.
Na redistribuição, o mapa de rotas é aplicado às informações de roteamento selecionadas no processo de roteamento de origem antes que essas informações sejam injetadas no processo de roteamento de destino. Ele não se aplica diretamente ao tráfego de pacotes de entrada ou de saída. Seu efeito é limitado a controlar e modificar rotas redistribuídas.
Este é um mapa de rota típico do OSPF (Open Shortest Path First) para o EIGRP (Enhanced Interior Gateway Routing Protocol), aplicado com um comando redistribute:
!
router eigrp 1
default-metric 20000 2000 255 1 1500
redistribute ospf 1 route-map ospf-to-eigrp
!
!
ip prefix-list pfx seq 5 permit 10.0.0.0/8 le 32
!
route-map ospf-to-eigrp deny 10
match tag 6
match route-type external type-2
!
route-map ospf-to-eigrp permit 20
match ip address prefix-list pfx
set metric 40000 1000 255 1 1500
!
route-map ospf-to-eigrp permit 30
set tag 8
!
Observações importantes:
As cláusulas do mapa de rotas são numeradas. Neste exemplo, as cláusulas têm números de sequência 10, 20 e 30. Os números de sequência permitem:
A Cisco recomenda a numeração de cláusulas em intervalos de 10 para reservar números de sequência para alterações futuras, se necessário.
Os mapas de rotas podem ter cláusulas permit e deny. Em route-map ospf-to-eigrp, há uma cláusula deny com o número de sequência 10 e duas cláusulas permit com os números de sequência 20 e 30. A cláusula deny rejeita rotas correspondentes da redistribuição. Por conseguinte, aplicam-se as seguintes regras:
Cada cláusula do mapa de rota pode conter dois tipos de comandos:
Para cada rota redistribuída, o roteador avalia primeiro os comandos match em uma cláusula de mapa de rota. Se os critérios de correspondência forem bem-sucedidos, a rota será redistribuída ou rejeitada conforme ditado pela cláusula permit ou deny. Se a rota for permitida, seus atributos poderão ser modificados pelos comandos set. Se os critérios de correspondência falharem, a cláusula não será aplicável à rota e o software Cisco IOS avaliará a rota em relação à próxima cláusula no mapa de rota. A varredura do mapa de rota continua até que seja encontrada uma cláusula cujos comandos de correspondência correspondam à rota ou até que o final do mapa de rota seja alcançado.
Um comando match ou set pode ser omitido ou repetido em cada cláusula, com estas considerações:
Não configure um comando set em uma cláusula deny route-map porque a cláusula deny impede a redistribuição da rota. Não há informações de rota redistribuída para modificar.
Uma cláusula de mapa de rota sem um comando match ou set ainda executa uma ação. Uma cláusula de permissão vazia permite a redistribuição das rotas restantes sem modificação. Uma cláusula deny vazia impede a redistribuição das rotas restantes. Esse também é o comportamento padrão se um mapa de rota for completamente verificado e nenhuma correspondência explícita for encontrada.
Com base nas informações nesta seção, o exemplo de mapa de rota OSPF para EIGRP anterior faz o seguinte:
Neste exemplo, a topologia consiste em três roteadores conectados em um arranjo linear: R3 ↔ R1 ↔ R2. O roteador R1 atua como o roteador de redistribuição entre R3 e R2, sem conexão direta entre R3 e R2. Cada roteador é conectado usando interfaces GigabitEthernet, fornecendo conectividade ponto a ponto de alta velocidade entre os dispositivos adjacentes.
R3#show ip route 10.20.20.20
Routing entry for 10.20.20.20/32
Known via "eigrp 1", distance 170, metric 320256, precedence routine (0), type external
Redistributing via eigrp 1
Last update from 192.168.1.1 on GigabitEthernet1, 00:01:02 ago
Routing Descriptor Blocks:
* 192.168.1.1, from 192.168.1.1, 00:01:02 ago, via GigabitEthernet1
Route metric is 320256, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 40000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
R3#show ip route 172.16.1.0
Routing entry for 172.16.1.0/24
Known via "eigrp 1", distance 170, metric 640256
Tag 8, precedence routine (0), type external
Redistributing via eigrp 1
Last update from 192.168.1.1 on GigabitEthernet1, 00:01:56 ago
Routing Descriptor Blocks:
* 192.168.1.1, from 192.168.1.1, 00:01:56 ago, via GigabitEthernet1
Route metric is 640256, traffic share count is 1
Total delay is 20010 microseconds, minimum bandwidth is 20000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 Route tag 8
R3#
Execute o comando show ip route <prefix> em R3 para confirmar como cada rota redistribuída foi processada pelo mapa de rota. A rota 10.20.20.20/32 corresponde à sequência de mapa de rota 20 porque é permitida pela lista de prefixos pfx. Como resultado, a rota é redistribuída no EIGRP com a métrica configurada explicitamente na sequência 20 com o comando set metric 40000 1000 255 1 1500.
Essas características são refletidas na saída da rota:
Além disso, a rota 172.16.1.0/24 não corresponde à sequência 10 ou à sequência 20, portanto, alcança a sequência de mapa de rota 30. Como a sequência 30 não tem nenhuma instrução de correspondência, ela corresponde a todas as rotas restantes e aplica a marca de definição 8 que é refletida na saída da rota:
Essas saídas confirmam os processos de mapa de rota das rotas na ordem: a sequência 20 aplica a métrica EIGRP explícita aos prefixos correspondidos pela lista de prefixos, enquanto a sequência 30 permite as rotas redistribuídas restantes e as marca com a marca 8.
Embora os links físicos entre R3, R1 e R2 sejam interfaces GigabitEthernet com DLY 10 usec, as rotas EIGRP redistribuídas também transportam o atraso de propagação configurado durante a redistribuição. Nos comandos set metric e default-metric, o valor de atraso do EIGRP é inserido em dezenas de microssegundos. Portanto, um atraso configurado de 1000 torna-se 10000 microssegundos e um atraso configurado de 2000 torna-se 20000 microssegundos. Quando R3 aprende as rotas de R1, adiciona o atraso da interface GigabitEthernet local de 10 microssegundos, o que resulta em atrasos totais de 10010 microssegundos e 20010 microssegundos, respectivamente.
Esta seção inclui estes tópicos:
Configurar Correspondência Sem Suporte e Comandos Set nos Mapas de Rota
Natureza de dois protocolos da redistribuição do mapa de rota
Os mapas de rotas são mecanismos genéricos que você pode usar em muitos contextos de configuração, incluindo o comando redistribute descrito anteriormente. Você pode configurar e executar o comando match length em um mapa de rota usado para o Roteamento Baseado em Políticas (PBR - Policy-Based Routing) para especificar que uma ação específica é tomada quando pacotes de um comprimento específico são encaminhados. No entanto, o comando match length não é aplicável em mapas de rota usados para redistribuição de rota.
Você pode configurar e executar os comandos match e set em um mapa de rotas que não são suportados, ou que não têm efeito no contexto em que o mapa de rotas é aplicado. Um exemplo é executar o comando match length em um mapa de rota aplicado à redistribuição. Na redistribuição, o mapa de rotas é aplicado às rotas instaladas na tabela de roteamento pelo protocolo de origem especificado no comando redistribute. Portanto, quando o roteador processa o mapa de rotas, ele interpreta somente os comandos que são significativos no contexto de redistribuição. Neste exemplo, o comando match length não tem efeito sobre a redistribuição. O comando permanece na configuração do mapa de rota e aparece na configuração em execução, no entanto, a redistribuição da rota não é afetada pela presença ou não do comando.
Embora o roteador possa permitir que diferentes tipos de comandos match e set sejam configurados em um mapa de rota, esses comandos devem ser apropriados para o contexto de recurso ou protocolo em que o mapa de rota é usado. Caso contrário, a configuração pode se tornar confusa ou produzir resultados indesejados.
Não use comandos que não tenham efeito em um contexto de mapa de rota específico, mesmo que eles pareçam inofensivos, pelas seguintes razões:
Caution: A sintaxe set metric +<value> e set metric -<value> não é suportada por todos os protocolos de roteamento. Em plataformas ou protocolos que não suportam a forma + ou -, o sinal pode ser ignorado e o comando interpretado como set metric <value>. Isso pode resultar na atribuição de uma métrica não intencional durante a redistribuição, afetando potencialmente a seleção de rota e o tráfego de rede. Sempre verifique o suporte à plataforma e ao protocolo antes de usar a sintaxe de métrica incremental ou decrescente.
Note: Consulte Suporte ao Mapa de Rota do EIGRP para obter informações adicionais.
Por exemplo, considere este mapa de rota:
! route-map ospf-to-ospf permit 10 set metric +2 !
Esta configuração parece redistribuir todas as rotas de um processo OSPF para outro, enquanto aumenta a métrica de todas as rotas em dois. Ele define a métrica de todas as rotas como sendo a mesma, igual a 2. Isso é inesperado na configuração do roteador.
R2#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, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
C 10.20.20.20 is directly connected, Loopback0
O E2 10.30.30.30 [110/2] via 172.16.1.1, 00:00:26, GigabitEthernet1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet1
L 172.16.1.2/32 is directly connected, GigabitEthernet1
O E2 192.168.1.0/24 [110/2] via 172.16.1.1, 00:00:26, GigabitEthernet1
R2#show ip route 10.30.30.30
Routing entry for 10.30.30.30/32
Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:38 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:38 ago, via GigabitEthernet1
Route metric is 2, traffic share count is 1
R2#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:01:34 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:01:34 ago, via GigabitEthernet1
Route metric is 2, traffic share count is 1
Este mapa de rota fornece um efeito contraintuitivo:
!
route-map ospf-to-ospf permit 10
set metric -367
!
Em vez de diminuir a métrica das rotas redistribuídas, essa configuração na verdade define a métrica como 367 (um valor positivo, porque uma métrica negativa não é possível quando set metric é interpretado sem o sinal).
R2#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, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
C 10.20.20.20 is directly connected, Loopback0
O E2 10.30.30.30 [110/367] via 172.16.1.1, 00:00:06, GigabitEthernet1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet1
L 172.16.1.2/32 is directly connected, GigabitEthernet1
O E2 192.168.1.0/24 [110/367] via 172.16.1.1, 00:00:06, GigabitEthernet1
R2#show ip route 10.30.30.30
Routing entry for 10.30.30.30/32
Known via "ospf 1", distance 110, metric 367, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:17 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:17 ago, via GigabitEthernet1
Route metric is 367, traffic share count is 1
R2#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "ospf 1", distance 110, metric 367, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:31 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:31 ago, via GigabitEthernet1
Route metric is 367, traffic share count is 1
Os mapas de rotas aplicados ao trabalho de redistribuição com dois protocolos de roteamento:
Cada protocolo de roteamento suporta seu próprio conjunto de atributos de rota. Por esse motivo, os comandos match e set em um mapa de rota de redistribuição são avaliados em relação a diferentes protocolos:
A seção Tabelas de Suporte a Comandos lista os comandos suportados. Eles são categorizados como comandos match e set para mostrar como os mapas de rota de redistribuição operam nos protocolos de roteamento de origem e de destino.
Esta seção descreve os comandos que são suportados nos mapas de rota anexados no comando redistribute. Há sete protocolos de roteamento que permitem redistribuir as rotas; no entanto, há apenas cinco onde ocorre a redistribuição. As rotas conectadas e estáticas não são protocolos de roteamento dinâmico e só podem fornecer informações a serem redistribuídas em outros protocolos.
O Intermediate System-to-Intermediate System (IS-IS) e o BGP podem propagar informações sobre rotas do Connectionless Network Service (CLNS) junto com rotas IP. Para ser completo, as tabelas nesta seção também mencionam comandos relacionados ao CLNS, que podem ser usados em mapas de rota de redistribuição para esses protocolos.
Você pode usar o Routing Information Protocol (RIP), OSPF, IS-IS e BGP para propagar rotas IPv6; os mapas de rota de redistribuição para esses protocolos podem conter comandos específicos de IPv6. Os comandos match ip e set ip são específicos para redistribuição de prefixos IPv4. Os comandos match ipv6 e set ipv6 são específicos para redistribuição de prefixos IPv6. Você pode usar os comandos match clns e set clns somente se usar um mapa de rota para redistribuir rotas CLNS de ou para o protocolo de roteamento.
As Tabelas 1 e 2 usam estas convenções:
Os comandos suportados são marcados com Sim.
Comandos sem suporte são marcados com um traço (—).
Os comandos sem suporte conhecidos por executar uma ação (provavelmente uma ação indesejada) são marcados com No.
Tabela 1 - Comandos do mapa de rotas para corresponder as rotas instaladas nas tabelas de roteamento por protocolos
| Comando |
Suporte à redistribuição |
||||||
| Conectado |
Estático |
RIP |
EIGRP |
OSPF |
IS-IS |
BGP |
|
| match clns address |
— |
Yes |
— |
— |
— |
Yes |
Yes |
| match clns next-hop |
— |
Yes |
— |
— |
— |
Yes |
— |
| combinar interface |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
— |
| combinar endereço ip |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| match ip address prefix-list |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| combinar ip next-hop |
— |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| match ip next-hop prefix-list |
— |
No |
No |
No |
No |
No |
No |
| combinar ip route-source |
— |
— |
Yes |
Yes |
Yes |
— |
Yes |
| match ip route-source prefix-list |
— |
— |
No |
No |
No |
— |
No |
| match ipv6 address [prefix-list] |
Yes |
Yes |
Yes |
— |
Yes |
Yes |
Yes |
| match ipv6 next-hop [prefix-list] |
— |
Yes |
Yes |
— |
— |
— |
Yes |
| match ipv6 route-source [prefix-list] |
— |
— |
Yes |
— |
— |
— |
Yes |
| combinar metrica |
— |
— |
Yes |
Yes |
Yes |
Yes |
Yes |
| match policy-list |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| match route-type external |
— |
— |
— |
Yes |
Yes |
Yes |
Yes |
| match route-type internal |
— |
— |
— |
Yes |
Yes |
— |
Yes |
| match route-type local |
— |
— |
— |
— |
— |
— |
Yes |
| match route-type nssa-external |
— |
— |
— |
— |
Yes |
— |
— |
| match route-type {level-1|level-2} |
— |
— |
— |
— |
— |
Yes |
— |
| combinar tag |
— |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Tabela 2 - Comandos que Modificam Atributos de Rota Durante a Redistribuição no Protocolo de Destino
| Comando |
Suporte à redistribuição |
||||
| RIP |
EIGRP |
OSPF |
IS-IS |
BGP |
|
| set as-path tag |
— |
— |
— |
— |
Yes |
| definir comunidade |
— |
— |
— |
— |
Yes |
| set ip next-hop |
— |
— |
— |
— |
Yes |
| set ip next-hop peer-address |
— |
— |
— |
— |
No |
| set ipv6 next-hop |
— |
— |
— |
— |
Yes |
| set level {backbone|stub-area} |
— |
— |
No |
— |
— |
| set level {level-1|level-2|level-1-2} |
— |
— |
— |
Yes |
— |
| defomor a preferência local |
— |
— |
— |
— |
Yes |
| definir métrica |
Yes |
— |
Yes |
Yes |
Yes |
| set metric +/- |
No |
— |
No |
No |
No |
| set metric eigrp-metric |
— |
Yes |
— |
— |
— |
| set metric +/- eigrp-metric |
— |
No |
— |
— |
— |
| set metric-type internal |
— |
— |
— |
Yes |
— |
| set metric-type external |
— |
— |
— |
Yes |
— |
| set metric-type {type-1|type-2} |
— |
— |
Yes |
— |
— |
| set nlri |
— |
— |
— |
— |
Yes |
| definir a origem |
— |
— |
— |
— |
Yes |
| definir a etiqueta |
Yes |
Yes |
Yes |
— |
— |
| definir o peso |
— |
— |
— |
— |
Yes |
Os mapas de rotas são ferramentas poderosas e flexíveis para controlar a redistribuição de rotas. Eles fornecem controle granular sobre como as informações de roteamento são trocadas entre os protocolos de roteamento durante a redistribuição. Ao implementar a redistribuição mútua, use tags de rota e políticas de filtragem explícitas para evitar que as rotas redistribuídas sejam reintroduzidas em seu protocolo de roteamento de origem. Se isso não for feito, poderão ocorrer loops de roteamento, buracos de tráfego ou caminhos de encaminhamento não ideais. Como a redistribuição entre vários protocolos de roteamento pode aumentar significativamente a complexidade do roteamento, as redes devem ser cuidadosamente projetadas, implementadas e validadas antes da implantação de políticas de redistribuição avançadas.
| Revisão | Data de publicação | Comentários |
|---|---|---|
4.0 |
29-Jul-2026
|
Título, ortografia, gramática e linhas horizontais inseridas atualizadas para separar seções/legibilidade. |
3.0 |
27-Nov-2023
|
Recertificação |
2.0 |
10-Nov-2022
|
Formatação atualizada e recertificação. |
1.0 |
25-Feb-2004
|
Versão inicial |