Um roteador quase nunca tem uma resposta só. O destino de um pacote pode cair, ao mesmo tempo, dentro de um /24, de um /16, de um /8 e da rota padrão; e o mesmo /24 pode ser oferecido pelo , pelo e por uma rota estática que alguém digitou anos atrás. Três regras resolvem essa disputa, e a maior parte da confusão sobre roteamento vem de aplicá-las na ordem errada ou no momento errado: a métrica escolhe dentro de um protocolo, a administrative distance (distância administrativa) escolhe entre as fontes, e o longest prefix match (a regra do prefixo mais longo) escolhe, para cada pacote, entre as rotas que passaram pelas duas primeiras.

Dois momentos: quando a rota é instalada e quando ela é usada

A Cisco descreve três processos por trás da tabela de um roteador: os processos de roteamento, que rodam os protocolos; "The routing table itself, which accepts information from the routing processes and also replies to requests for information from the forwarding process"; e "The forwarding process, which requests information from the routing table to make a packet forwarding decision" (Cisco, seleção de rotas). Os dois primeiros montam a tabela; o terceiro usa essa tabela.

As três regras atuam em momentos diferentes. A métrica e a administrative distance decidem o que é instalado na RIB (routing information base, a base de informações de roteamento); o longest prefix match decide, pacote a pacote, qual das rotas instaladas vai ser usada, consultando a FIB (forwarding information base, a base de encaminhamento), que é montada a partir da RIB. A página da Cisco sobre administrative distance, revisada em julho de 2026, diz isso com todas as letras: "Longest prefix match is not part of route installation; it is applied later during packet forwarding", e " and routing metrics are not evaluated during forwarding" (Cisco, distância administrativa). A sequência de instalação descrita pela Cisco segue a ordem inversa à das seções deste artigo: primeiro, cada protocolo escolhe o seu melhor caminho pela própria métrica; depois, a tabela compara pela administrative distance os candidatos dos vários protocolos para o mesmo prefixo; e o vencedor só é instalado se o seu next hop (o próximo salto) puder ser alcançado.

O longest prefix match, como a norma descreve

A 1812 (junho de 1995), que define os requisitos para roteadores IPv4, descreve o lookup (a busca na tabela) como um filtro. Ele "starts out with a set of candidate routes that consists of the entire contents of the FIB" e depois aplica as "Pruning Rules", regras que vão descartando rotas até sobrar uma só; "If the set ever becomes empty, the packet is discarded because the destination is unreachable" (RFC 1812, seção 5.2.4.3). As regras "MUST be (conceptually) applied to the FIB in the order that they are presented":

  1. Basic match (a correspondência básica) mantém só as rotas cujo prefixo contém o destino. Para um pacote destinado a 10.144.2.5, essa regra "would discard a route to net 128.12.0.0/16 but would retain any routes to the network prefixes 10.0.0.0/8 and 10.144.0.0/16, and any default routes".
  2. Longest match fica, entre essas, só com as de prefixo mais longo. Com 10.144.2.0/24, 10.144.0.0/16 e 10.0.0.0/8 na tabela, "this rule would keep only the first (10.144.2.0/24) because its prefix length is longest".
  3. Weak TOS dá preferência às rotas feitas para o type of service (TOS, tipo de serviço) do pacote; a RFC deixa esta regra como opcional.
  4. Best metric compara o que sobrou, mas só entre rotas do mesmo domínio de roteamento.
  5. policy, a política do fabricante, que, como a própria RFC admite, é "sort of a catch-all to make up for the fact that the previously listed rules are often inadequate to choose from the possible routes".

De modo geral, a rota de host vence primeiro; depois vêm os prefixos de rede, que "are selected in order of decreasing prefix length"; e, por último, a rota padrão, que "is by definition the route whose prefix length is zero" (RFC 1812, como acima). Uma tabela deixa isso mais concreto. Imagine um roteador com 10.144.2.0/24, 10.144.0.0/16, 10.0.0.0/8 e a rota padrão 0.0.0.0/0:

DestinoRotas que incluem o destinoRota usada
10.144.2.5/24, /16, /8, padrão10.144.2.0/24
10.144.9.1/16, /8, padrão10.144.0.0/16
10.200.0.1/8, padrão10.0.0.0/8
198.51.100.7padrão0.0.0.0/0

Sem a rota padrão, o último pacote não teria nenhuma rota correspondente, e a RFC 1812 diz que, nesse caso, "the packet MUST be discarded and an appropriate error generated": uma mensagem de destination unreachable (destino inalcançável). A calculadora CIDR mostra a faixa de endereços que qualquer prefixo cobre.

Para o longest match, não importa de qual protocolo a rota veio. No exemplo da Cisco, três rotas de três protocolos são instaladas ao mesmo tempo: 192.168.32.0/26 do (Enhanced Interior Gateway Routing Protocol), 192.168.32.0/24 do (Routing Information Protocol) e 192.168.32.0/19 do OSPF. Isso é possível porque "each of these routes has a different prefix length (subnet mask), they are considered different destinations, and they can all be installed in the routing table". Um pacote para 192.168.32.1 segue o /26; um pacote para 192.168.32.100, que fica fora do /26, segue o /24 do RIP, mesmo que o RIP tenha a maior administrative distance das três. "Longer prefixes are always preferred over shorter ones when forwarding a packet" (Cisco, seleção de rotas).

Administrative distance: em qual fonte acreditar

Quando duas fontes oferecem exatamente o mesmo prefixo, o longest match não tem como escolher, e as métricas não podem ser comparadas: o custo do OSPF e o hop count do RIP são unidades diferentes. A RFC 1812 sugeriu uma resposta, como uma das formas de vendor policy: uma "administrative preference", com um valor "in the range [0..255], with zero being the most preferred and 254 being the least preferred", em que "255 is a special value that means that the route should never be used" (RFC 1812, seção 5.2.4.4).

A Cisco chama esse valor de administrative distance (AD): "AD is a value used to rank the trustworthiness of routing information sources", e "AD is used only when multiple routing sources advertise the same destination prefix". Esse valor nunca sai do roteador: "AD is a local value and is not advertised in routing updates" (Cisco, distância administrativa). A Juniper chama de route preference, "a value from 0 through 4,294,967,295", e acrescenta que "This concept is called administrative distance by some vendors" (Juniper, valores de preferência de rota). Os valores padrão variam mais do que a maioria das pessoas imagina:

Fonte da rota (AD)Junos OS (preference)
Diretamente conectada00
Estática15
OSPF11010 interna, 150 externa
(Intermediate System to Intermediate System)11515 ou 18 interna (level 1 ou 2), 160 ou 165 externa
RIP120100
BGP20 externa, 200 interna170
EIGRP90 interna, 170 externanão aparece na tabela

Na prática, é na linha do BGP que os dois divergem, e a própria Juniper aponta isso: "some vendors assign a distance of 110 to OSPF routes. This is higher than the EBGP distance of 20"; ou seja, um roteador desses prefere a rota de BGP externo à rota do OSPF para o mesmo prefixo, enquanto "In the same scenario, Junos OS chooses the OSPF route" (Juniper, como acima). Por isso, numa rede com equipamentos de vários fabricantes, roteadores diferentes podem fazer escolhas diferentes para o mesmo prefixo.

Mudar os valores padrão é possível, mas arriscado. Já em 1995, a RFC 1812 avisava que a administrative preference "is not safe in that it can easily be misused to create routing loops", porque nada verifica se os vizinhos foram configurados de forma coerente. O texto da Cisco de 2026 concorda: "An inconsistent AD design can cause asymmetric routing, suboptimal routing, routing loops, or traffic black holes", e "There are no general guidelines to assign administrative distances because each network has varied requirements" (Cisco, distância administrativa).

Nos equipamentos Cisco, cada rota na saída do show ip route traz os dois números: "the values in brackets use the format [administrative distance/metric]"; assim, [90/1] é uma rota com "an administrative distance of 90 and a protocol metric of 1" (como acima). No Linux, o ip route atribui a cada rota uma métrica, também chamada de preference, "an arbitrary 32bit number, where routes with lower values are preferred", e registra num campo de protocolo quem instalou a rota (ip-route(8)). O FortiGate acrescenta um segundo número, a priority (prioridade), que entra em jogo depois da distância; o artigo sobre roteamento no FortiGate e o explicador de seleção de rotas mostram como isso funciona, passo a passo.

A métrica: o desempate dentro de um protocolo

Dentro de um mesmo protocolo, quem decide é a métrica. A regra de best metric da RFC 1812 só se aplica "If route.domain is equal for the two routes", isto é, entre rotas do mesmo domínio de roteamento, e a Cisco diz a mesma coisa: "If there are multiple paths to the same destination from a single routing protocol, then the multiple paths would have the same administrative distance and the best path is selected based on the metrics" (Cisco, seleção de rotas). Cada protocolo mede de um jeito, e é justamente por isso que a administrative distance existe; a comparação dos protocolos dinâmicos mostra o que cada um leva em conta.

Quando as métricas empatam, o roteador pode manter várias rotas e dividir o tráfego entre elas. A especificação do OSPF diz que "When several equal-cost routes to a destination exist, traffic is distributed equally among them" (RFC 2328, seção 1.1), e a sequência de instalação da Cisco prevê que "multiple equal cost routes can be selected" onde há suporte a Equal-Cost Multi-Path (), o uso de vários caminhos de mesmo custo (Cisco, distância administrativa). A RFC 1812 é mais cautelosa: "a wise implementor who implements load-splitting will also provide a way for the network manager to disable it" (RFC 1812, seção 5.2.4.5).

Rotas estáticas

Segundo a norma, "Static routing provides a means of explicitly defining the next hop from a router for a particular destination" (RFC 1812, seção 7.4). A Cisco aponta os dois motivos mais comuns: as rotas estáticas "are often used when there is no dynamic route to the destination IP address, or to override the dynamically learned route" (Cisco, next hop em rotas estáticas). Com AD 1 na Cisco e preference 5 no Junos, uma rota estática ganha, por padrão, de qualquer protocolo dinâmico.

Next hop, interface de saída ou os dois

Uma rota estática pode indicar o endereço do next hop, a interface de saída ou as duas coisas, e essa escolha faz diferença. Uma rota que indica só uma interface diz ao roteador que todos os destinos cobertos por ela estão diretamente conectados; por isso, "a router performs Address Resolution Protocol () on the Ethernet for every destination the router finds through the default route", e, com muitos destinos, isso "can cause high processor use and a very large ARP cache (along with memory allocation failures)" (Cisco, next hop em rotas estáticas). Já uma rota que indica só o endereço do next hop precisa de um segundo lookup: "If the route uses a next-hop IP address, the router performs recursive lookup, also called route recursion, to resolve the outgoing interface", e "If the next hop cannot be resolved, the route is not installed in the routing table" (Cisco, distância administrativa). A recomendação da Cisco é informar as duas coisas: "Cisco highly recommends you specify the outbound interface and the next hop IP address when static routes are configured"; num link ponto a ponto, só a interface já basta (Cisco, next hop em rotas estáticas).

Floating static routes e o failover que não acontece

Uma rota estática com uma distância alta, configurada assim de propósito, funciona como backup. É a floating static route (rota estática flutuante): "A floating static route is configured with an administrative distance higher than the primary route, so it is used only when the primary route is removed from the routing table" (Cisco, distância administrativa). No exemplo da Cisco, uma rota do OSPF (110) ganha um backup com ip route 10.0.0.0 255.255.255.0 172.16.1.200 250: a rota estática fica fora da tabela enquanto o OSPF conhece o prefixo e aparece como [250/0] quando o OSPF perde esse prefixo. A RFC 1812 descrevia a mesma ideia usando métricas: uma rota estática primária por uma interface e uma secundária por outra, "with failover to the alternate path if the interface for the primary route fails" (RFC 1812, seção 7.4).

A armadilha está na recursão. Num segundo exemplo da Cisco, um roteador tem uma rota estática primária para uma via 10.10.10.2, por um link serial; uma floating static route com distância 250, pelo outro link; e uma rota estática para 10.0.0.0/8, sem relação com as outras duas. Quando o link primário é desligado com shutdown, o backup nunca aparece: a rota primária continua na tabela, "because static routes are recursive in nature", e o seu next hop "10.10.10.2 is successfully recursed to (to 192.168.10.2) through the static route 10.0.0.0/8, which is present in the routing table" (Cisco, next hop em rotas estáticas). O tráfego da LAN passa a seguir a rota 10.0.0.0/8, em direção ao link de internet, e o ping e o traceroute do host param de funcionar. A solução é indicar a interface de saída, porque uma rota amarrada a uma interface é "inserted into the routing table only when the interface is active" (como acima): assim, a rota primária sai da tabela junto com o seu link, e a floating route pode tomar o lugar dela. Toda floating route merece um teste em que o caminho primário caia de verdade.

Rotas que, de propósito, não levam a lugar nenhum

Algumas rotas estáticas existem para descartar tráfego. O Linux tem três tipos delas: a rota unreachable, em que "Packets are discarded and the ICMP message host unreachable is generated"; a rota blackhole, em que "Packets are discarded silently"; e a rota prohibit, que responde com "communication administratively prohibited" (ip-route(8)). A mesma página traz um aviso para quem cria rotas à mão: se nenhum protocolo for indicado, "ip assumes protocol boot (i.e. it assumes the route was added by someone who doesn't understand what they are doing)", e, sobre as rotas boot, ela diz: "If a routing daemon starts, it will purge all of them". Uma rota que deve permanecer recebe a marcação proto static, que a página descreve como "installed by the administrator to override dynamic routing". No ip route, a rota padrão se escreve default, a forma abreviada que a página usa para 0/0 no IPv4 e ::/0 no IPv6.

A decisão completa, num único exemplo

Agora, junte as três regras num roteador só. O OSPF oferece 10.1.0.0/16 com distância 110, uma floating static route cobre o mesmo /16 com 250, o RIP oferece 10.1.5.0/24 com 120, e uma rota padrão estática aponta para a internet.

  • Instalação: para 10.1.0.0/16, o OSPF (110) ganha da floating static route (250), que fica fora da tabela; o /24 do RIP e a rota padrão não têm concorrentes para os seus prefixos e são instalados.
  • Um pacote para 10.1.5.9: ele cai dentro do /24, do /16 e da rota padrão; o /24 é o mais longo, então o pacote vai pelo caminho do RIP, seja qual for a distância do RIP.
  • Um pacote para 10.1.9.9: ele cai dentro do /16 e da rota padrão; segue o OSPF.
  • O OSPF perde o /16: a floating static route é instalada, desde que o seu next hop seja resolvido, e 10.1.9.9 passa a seguir essa rota; 10.1.5.9 não é afetado.

Para lembrar

  • Dois momentos: a métrica e a administrative distance decidem o que é instalado; o longest prefix match decide qual rota instalada cada pacote usa.
  • A administrative distance só compara fontes para o mesmo prefixo, nunca passa por cima de um match mais longo, vale só dentro do roteador e tem valores padrão diferentes na Cisco e no Junos.
  • Uma rota estática com next hop só é instalada se esse next hop for resolvido, e continua instalada enquanto houver alguma rota que chegue até ele.
  • Uma floating static route é um backup definido pela distância; teste derrubando o caminho primário, e indique a interface de saída para que a rota primária consiga de fato sair da tabela.
  • Sem rota padrão, um pacote que não bate com nenhuma rota é descartado, com uma mensagem ICMP de unreachable.

Fontes