Uma rede quase nunca roda um único protocolo de roteamento. As filiais usam um, o data center usa outro, o cuida da conexão com a internet e as rotas estáticas cobrem o que falta. Na redistribuição, o roteador que fica na fronteira pega as rotas que aprendeu de um jeito e as anuncia de outro. A Cisco lista os motivos mais comuns: "Organizations can deploy different protocols for varied purposes, such as BGP for internet routes and for internal networks" e, nas fusões de empresas, "Networks with disparate protocols need to interoperate during integration" (Cisco, redistribuição de protocolos de roteamento). Na mesma página, logo em seguida, vêm os riscos, e o primeiro deles é "Routing Loops: Misconfigurations can lead to loops, degrading network performance" (como acima).

O que o padrão exige de um roteador

A 1812 (junho de 1995), que define os requisitos para roteadores IPv4, transforma essa troca numa obrigação e põe os riscos dela na conta do roteador: "Routers MUST be able to exchange routing information between separate IP interior routing protocols, if independent IP routing processes can run in the same router. Routers MUST provide some mechanism for avoiding routing loops when routers are configured for bi-directional exchange of routing information between two separate interior routing processes. Routers MUST provide some priority mechanism for choosing routes from independent routing processes" (RFC 1812, seção 7.6). Esse mecanismo de prioridade é o que os fabricantes chamam de administrative distance (distância administrativa) ou route preference, assunto do artigo sobre rotas estáticas e longest match.

O mesmo documento define o comportamento padrão: "Routers MUST NOT by default redistribute routing data they do not themselves use, trust or otherwise consider valid" (RFC 1812, seção 7.1.1). A implementação da Cisco segue ao pé da letra a primeira parte dessa regra: "The rules for redistribution on a Cisco router dictate that the redistributed route be present in the routing table. It is not sufficient that the route be present in the routing topology or database" (Cisco, como acima). O roteador redistribui o que instalou na tabela, e sob o protocolo que instalou a rota. No exemplo da Cisco, uma rota estática redistribuída no Enhanced Interior Gateway Routing Protocol () não segue adiante quando o EIGRP é redistribuído no Routing Information Protocol () no mesmo roteador, porque a rota que está na tabela é a estática, e a "static route is not redistributed into RIP because it never got entered into the EIGRP routing table" (como acima).

Toda rota redistribuída precisa de uma métrica nova

Uma rota que passa de um protocolo para outro não tem como manter a métrica, porque as unidades são diferentes. A RFC 1812 diz isso com todas as letras: "Different IGPs use different metrics, requiring some translation technique when introducing information from one protocol into another protocol with a different form of metric". Ela descreve duas técnicas. Na abordagem estática, ou de alcançabilidade (reachability), o simples fato de a rota existir num protocolo gera um anúncio no outro "with a given metric"; na abordagem de tradução, ou tabular, a métrica antiga é convertida "through use of either a function (such as adding a constant) or a table lookup" (RFC 1812, seção 7.6). A configuração da Cisco segue a primeira abordagem: quem configura informa o número, a chamada seed metric (a métrica inicial da rota redistribuída), para cada redistribuição ou de uma vez para todas, com o comando default-metric. A Cisco diz a regra sem rodeios: "When routes are redistributed, you must define a metric for a protocol that the route that receives can understand", e os protocolos diferem no que exigem e no que assumem por padrão (Cisco, redistribuição de protocolos de roteamento):

Protocolo que recebeMétrica a informarO que é preciso saber
RIPHop count (o número de hops, ou passagens por roteador); 16 é inalcançávelUma métrica de 10 deixa a rota avançar só mais cinco hops
OSPFCusto20 para rotas redistribuídas, 1 para rotas vindas do BGP
EIGRPCinco valores: bandwidth, delay, reliability, load e maximum transmission unit ()Definir um default-metric é a prática recomendada
(Intermediate System to Intermediate System)De 1 a 63Não tem a opção default-metric; 0 se nenhuma métrica for informada

O RIP mostra o dilema na forma mais simples. "If you define a metric of 10 for redistributed routes, these routes are only advertised to routers up to 5 hops away, at which point the metric (hop count) exceeds 15"; já uma métrica de 1 deixa a rota chegar a qualquer lugar, mas "this can increase the possibility of routing loops if there are multiple redistribution points and if a router learns about the network with a better metric from the redistribution point than from the original source" (como acima). A métrica precisa ser "neither too high, which prevents the route from advertisement to all the routers, or too low, which leads to routing loops when there are multiple redistribution points" (como acima).

Os dois tipos de rota externa do OSPF

O OSPF marca as rotas redistribuídas como externas e atribui a elas um de dois tipos de métrica. "Type 1 external metrics are expressed in the same units as OSPF interface cost", e por isso a distância interna até o roteador que fez a redistribuição entra na soma; "Type 2 external metrics are an order of magnitude larger; any Type 2 metric is considered greater than the cost of any path internal to the AS", e, entre rotas do tipo 2, "The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router" (RFC 2328, seção 2.3). "Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always take precedence" (como acima). Na saída do exemplo da própria Cisco, uma rota redistribuída do EIGRP aparece no OSPF como O E2 10.10.1.0/24 [110/20]: tipo 2, administrative distance 110, métrica 20 (Cisco, redistribuição de protocolos de roteamento). Quando duas saídas redistribuem o mesmo prefixo como tipo 2 e com a mesma métrica, a métrica externa não consegue diferenciar uma da outra, e, pela RFC 2328, o desempate fica por conta da distância interna: "When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie" (como acima).

De onde vêm os loops

A RFC 1812 aponta a causa de fundo em duas frases: "Bi-directional exchange of routing information is dangerous without control mechanisms to limit feedback. This is the same problem that distance vector routing protocols must address with the split horizon technique and that addresses with the third-party rule" (seção 7.6). Uma rota que sai de um domínio por redistribuição num roteador pode voltar para esse mesmo domínio por outro roteador, agora com cara de rota que pertence ao segundo domínio. A Cisco atribui o mecanismo à própria regra de prioridade: "Administrative distances help with route selection among different routing protocols, but they can cause problems for redistribution. These problems can be in the form of routing loops, convergence problems, or inefficient routing" (Cisco, redistribuição de protocolos de roteamento).

Veja o caso clássico: dois roteadores redistribuindo entre um domínio RIP e um domínio OSPF, com os valores padrão que a Cisco publica. Os roteadores A e B ligam os dois domínios, e os dois redistribuem o RIP no OSPF. Uma rede N fica no domínio RIP.

  1. A aprende N pelo RIP, com administrative distance 120, instala a rota e a redistribui no OSPF como rota externa.
  2. B aprende N duas vezes: pelo RIP, com 120, e pelo OSPF, como a rota externa de A, com 110. Num roteador Cisco, a cópia do OSPF vence, porque 110 é menor, e B passa a mandar o tráfego para N através do domínio OSPF até A, em vez de mandá-lo para o domínio RIP, que está ali do lado.
  3. B não tem mais uma rota RIP para N na tabela e, por isso, para de redistribuir N; a rede passa a depender só de A, sem que ninguém tenha decidido isso.

Quem decide o resultado são os números, e eles mudam de um fabricante para outro. No Junos, a ordem é a contrária: RIP com 100 e rotas externas do OSPF com 150 (Juniper, valores de preferência de rota), e, nesse caso, B manteria a rota RIP. O mesmo projeto de rede pode se comportar de um jeito com os valores padrão de um fabricante e de outro jeito com os de outro, e era isso que a RFC 1812 queria dizer quando avisou que a preferência administrativa "can easily be misused to create routing loops" (RFC 1812, seção 5.2.4.4).

A redistribuição mútua, nos dois sentidos e em dois pontos, fecha o ciclo. Se A e B também redistribuem o OSPF no RIP, B anuncia N de volta para o domínio RIP como a rota OSPF que tem agora, com a métrica que tiver sido configurada; o exemplo da Cisco, em que os dois pontos de redistribuição são R2 e R5, avisa que um roteador do domínio original pode então "learn the network from R2 or R5 with a better metric than from the original source". Quando isso acontece, os roteadores RIP mandam o tráfego para N na direção de B, B manda esse tráfego pelo domínio OSPF até A, e A devolve o tráfego para o domínio RIP, onde ele pode dar mais uma volta. Mesmo sem loop, os caminhos ficam errados: no segundo exemplo da Cisco, um roteador "can end up preferring the less desirable path through R5 instead of going through R1 to reach the network" (Cisco, redistribuição de protocolos de roteamento).

As soluções que funcionam

A Cisco resume todas as soluções num único princípio: "You can avoid these problems if you never announce the information originally received from routing process X back into routing process X" (Cisco, redistribuição de protocolos de roteamento). A RFC 1812 lista os meios: os loops "can be avoided explicitly through use of tables or lists of permitted/denied routes or implicitly through use of a split horizon rule, a no-third-party rule, or a route tagging mechanism", e "Vendors are encouraged to use implicit techniques where possible to make administration easier for network operators" (seção 7.6).

Filtrar por prefixo. No primeiro exemplo da Cisco, o OSPF e o EIGRP se encontram em dois roteadores. Ali, o feedback (a volta da rota para o domínio de onde ela saiu) é cortado com uma distribute list em cada um dos dois, que impede o roteador de aprender de volta, pelo EIGRP, uma rede do domínio OSPF: "the routers are told that they must not learn network 192.168.1.0/24 through the EIGRP updates they receive on the specified interface. Therefore, the only knowledge these routers have for network 192.168.1.0/24 is through OSPF from R1" (Cisco, como acima). Funciona, mas a lista precisa ser mantida prefixo a prefixo, à medida que a rede muda.

Marcar as rotas com uma tag na fronteira e filtrar pela tag. O método que a Cisco chama de "preferable" usa "route-maps to set tags for various routes, allowing routing processes to redistribute based on these tags" (como acima). No exemplo, cada roteador que redistribui aplica a tag 77 nas rotas que leva do OSPF para o EIGRP e a tag 88 nas que leva do EIGRP para o OSPF, e se recusa a levar de volta para o EIGRP uma rota com tag 88, ou de volta para o OSPF uma rota com tag 77. Assim, uma rota cruza a fronteira uma vez e nunca mais volta, seja qual for o prefixo. Os protocolos foram feitos para carregar essas marcas: a Route Tag do RIP versão 2 existe "to provide a method of separating 'internal' RIP routes (routes for networks within the RIP routing domain) from 'external' RIP routes, which may have been imported from an EGP or another " (RFC 2453, seção 4.2), e toda rota externa do OSPF carrega "A 32-bit field attached to each external route. This is not used by the OSPF protocol itself" (RFC 2328, apêndice A.4.5), um campo que fica livre justamente para esse uso.

Redistribuir num sentido só e mandar uma rota padrão no sentido contrário. Quase todo feedback depende de uma rota passar nos dois sentidos. No exemplo da própria RFC 1812, um roteador que fica entre redes-folha (leaf networks) e um backbone simplesmente não redistribui nada do backbone nas redes-folha: "Since each of the leaf networks has only one path in and out, the router can simply send a default route to them. It advertises the leaf networks to the main network" (seção 7.5.2). Quando um domínio tem uma única saída, uma rota padrão é mais simples do que qualquer filtro.

Redistribuir só o necessário. "Unfiltered redistribution can inadvertently propagate incorrect or undesired routes" (Cisco, redistribuição de protocolos de roteamento), e um route map que faz match com uma lista de prefixos permite ao roteador "selectively redistribute a single static route", em vez de redistribuir todas (como acima). A sumarização, assunto do artigo sobre sumarização de rotas, diminui a quantidade de rotas que precisam passar de um lado para o outro.

Atenção à fronteira com o BGP. Nos roteadores Cisco, "By default, only EBGP-learned information is a candidate for redistribution into Interior Gateway Protocol (IGP) when the redistribute bgp command is issued"; as rotas de BGP interno precisam de um comando explícito, e "precautions must be taken in order to avoid loops within the Autonomous System when IBGP routes are redistributed into IGP" (como acima).

Como validar um projeto de redistribuição

Os fatos estão na tabela de roteamento. Na saída da Cisco, uma rota redistribuída no EIGRP aparece como D EX, com distância 170, e uma rota redistribuída no OSPF aparece como O E2, com 110; a visão detalhada de uma rota mostra a tag dela, como em "distance 170, metric 258816 Tag 77, type external" (Cisco, redistribuição de protocolos de roteamento). Três perguntas pegam os problemas de sempre antes que eles apareçam em produção. Em cada roteador que redistribui, qual protocolo a tabela usa para os prefixos do outro domínio? Alguma rota carrega a tag do domínio em que ela está agora? E o tráfego para um prefixo segue o mesmo caminho de antes quando um dos pontos de redistribuição cai? Um traceroute de cada lado, desligando um roteador de fronteira de cada vez, responde à última.

Para lembrar

  • A redistribuição anuncia num protocolo o que foi instalado por outro; o roteador repassa o que está na tabela de roteamento, não o que está na base de dados de um protocolo.
  • Toda rota redistribuída precisa de uma métrica que o protocolo de destino entenda, e essa escolha decide até onde a rota vai e como ela compete com as outras.
  • As rotas externas do OSPF são do tipo 1 (com o custo interno somado) ou do tipo 2 (só a métrica externa); o tipo 1 sempre ganha do tipo 2.
  • Dois pontos de redistribuição mais a administrative distance geram feedback: um roteador de fronteira pode preferir a rota que a outra fronteira exportou, em vez da rota original.
  • Para corrigir: tags que impedem a rota de voltar, filtros por prefixo, redistribuição num sentido só com rota padrão e só as rotas necessárias; para testar, derrube cada roteador de fronteira, um de cada vez.

Fontes