# Rotas estáticas, longest prefix match e administrative distance: como o roteador escolhe entre várias respostas

> Um roteador muitas vezes tem várias respostas para o mesmo pacote, e três regras decidem entre elas, em dois momentos diferentes: a métrica escolhe o melhor caminho dentro de um protocolo, a administrative distance escolhe em qual fonte acreditar quando duas oferecem o mesmo prefixo, e o longest prefix match escolhe, pacote a pacote, a mais específica das rotas instaladas. Com rotas estáticas, floating static routes como backup, next hops recursivos e o failover que não acontece e não avisa, tudo lido na RFC 1812 e na documentação dos próprios fabricantes.

Source: https://ronutz.com/pt-BR/learn/static-routes-and-longest-match  
Updated: 2026-10-07  
Related tools: https://ronutz.com/pt-BR/tools/cidr, https://ronutz.com/pt-BR/tools/fortigate-route-selection-explainer

---

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 OSPF, pelo BGP 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](https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8651-21.html)). 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 "AD and routing metrics are not evaluated during forwarding" ([Cisco, distância administrativa](https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html)). 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 RFC 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](https://www.rfc-editor.org/rfc/rfc1812#section-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. **Vendor 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:

| Destino | Rotas que incluem o destino | Rota usada |
|---|---|---|
| 10.144.2.5 | /24, /16, /8, padrão | 10.144.2.0/24 |
| 10.144.9.1 | /16, /8, padrão | 10.144.0.0/16 |
| 10.200.0.1 | /8, padrão | 10.0.0.0/8 |
| 198.51.100.7 | padrão | 0.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 ICMP error generated": uma mensagem de destination unreachable (destino inalcançável). A [calculadora CIDR](https://ronutz.com/pt-BR/tools/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 EIGRP (Enhanced Interior Gateway Routing Protocol), 192.168.32.0/24 do RIP (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](https://www.rfc-editor.org/rfc/rfc1812#section-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](https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/local-preference.html)). Os valores padrão variam mais do que a maioria das pessoas imagina:

| Fonte da rota | Cisco IOS (AD) | Junos OS (preference) |
|---|---|---|
| Diretamente conectada | 0 | 0 |
| Estática | 1 | 5 |
| OSPF | 110 | 10 interna, 150 externa |
| IS-IS (Intermediate System to Intermediate System) | 115 | 15 ou 18 interna (level 1 ou 2), 160 ou 165 externa |
| RIP | 120 | 100 |
| BGP | 20 externa, 200 interna | 170 |
| EIGRP | 90 interna, 170 externa | nã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)](https://man7.org/linux/man-pages/man8/ip-route.8.html)). O FortiGate acrescenta um segundo número, a priority (prioridade), que entra em jogo depois da distância; o [artigo sobre roteamento no FortiGate](https://ronutz.com/pt-BR/learn/fortigate-routing-and-sdwan-selection) e o [explicador de seleção de rotas](https://ronutz.com/pt-BR/tools/fortigate-route-selection-explainer) 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](https://ronutz.com/pt-BR/learn/dynamic-routing-compared) 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](https://www.rfc-editor.org/rfc/rfc2328#section-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 (ECMP), 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](https://www.rfc-editor.org/rfc/rfc1812#section-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](https://www.rfc-editor.org/rfc/rfc1812#section-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](https://www.cisco.com/c/en/us/support/docs/dial-access/floating-static-route/118263-technote-nexthop-00.html)). 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 Ethernet diz ao roteador que todos os destinos cobertos por ela estão diretamente conectados; por isso, "a router performs Address Resolution Protocol (ARP) 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 LAN 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

- [RFC 1812, Requirements for IP Version 4 Routers, junho de 1995: seções 5.2.4.3 a 5.2.4.5 (as regras de poda, a preferência administrativa, a divisão de carga) e 7.4 (roteamento estático) (lida em 2026-10-07)](https://www.rfc-editor.org/rfc/rfc1812)
- [RFC 2328, OSPF Version 2, abril de 1998: rotas de custo igual (lida em 2026-10-07)](https://www.rfc-editor.org/rfc/rfc2328)
- [Cisco, Understand Administrative Distance, documento 15986, revisão de 20 de julho de 2026: sequência de instalação, recursão, valores padrão, rotas estáticas flutuantes (lida em 2026-10-07)](https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html)
- [Cisco, Configure Route Selection for Routers, documento 8651, 17 de janeiro de 2024: os três processos, comprimentos de prefixo como destinos diferentes (lida em 2026-10-07)](https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8651-21.html)
- [Cisco, Configure a Next Hop IP Address for Static Routes, documento 118263, 10 de julho de 2023: rotas só com interface, a rota flutuante que nunca é instalada (lida em 2026-10-07)](https://www.cisco.com/c/en/us/support/docs/dial-access/floating-static-route/118263-technote-nexthop-00.html)
- [Juniper Networks, Junos OS, Understanding Route Preference Values (Administrative Distance): preferências padrão (lida em 2026-10-07)](https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/local-preference.html)
- [Linux, ip-route(8), página de manual do iproute2, cópia do man7.org de 4 de agosto de 2026: métrica, tipos de rota, campo de protocolo (lida em 2026-10-07)](https://man7.org/linux/man-pages/man8/ip-route.8.html)