![Interpretando a coluna 'métrica' na tabela de roteamento](https://rvso.com/image/1518704/Interpretando%20a%20coluna%20'm%C3%A9trica'%20na%20tabela%20de%20roteamento.png)
Estou um pouco confuso sobre a saída que vejo na minha tabela de roteamento, principalmente na coluna 'métrica':
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
172.16.35.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
192.168.0.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
192.168.82.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
De acordo com a página de manual, a métrica indica a 'distância' até o alvo. Fiquei um pouco confuso sobre o que exatamente era "alvo". Presumi que fosse meu roteador (ele vai para o gateway 0.0.0.0, que depois vai para meu roteador em 192.168.0.1). Portanto, eu esperava que a métrica fosse um único salto para o meu roteador. No entanto, são 9! Por que esse número é tão alto?
Responder1
De acordo com a página de manual, a métrica indica a 'distância' até o alvo.
Eu esperava que a métrica fosse um único salto para o meu roteador. No entanto, são 9! Por que esse número é tão alto?
O metric
campo tem vários significados diferentes:
O campo Métrica indica o custo de uma rota. Se existirem múltiplas rotas para um determinado ID de rede de destino, a métrica será usada para decidir qual rota será tomada. A rota com a métrica mais baixa é a rota preferida. Alguns algoritmos de roteamento armazenam apenas uma única rota para qualquer ID de rede na tabela de roteamento, mesmo quando existem várias rotas. Neste caso, a métrica é utilizada pelo roteador para decidir qual rota armazenar na tabela de roteamento.
As métricas podem indicar diferentes maneiras de expressar uma preferência de rota:
Contagem de saltos.
Uma métrica comum. Indica o número de roteadores (saltos) no caminho para o ID da rede.
Atraso.
Uma medida de tempo necessária para que o pacote alcance o ID da rede. O atraso é usado para indicar a velocidade do caminho – os links de redes locais (LAN) têm um atraso baixo, os links de redes de longa distância (WAN) têm um atraso alto – ou uma condição congestionada de um caminho.
Taxa de transferência.
A quantidade efetiva de dados que podem ser enviados ao longo do caminho por segundo. A taxa de transferência não é necessariamente um reflexo da taxa de bits do link, pois um link Ethernet muito ocupado pode ter uma taxa de transferência menor do que um link WAN de 64 Kbps não utilizado.
Confiabilidade.
Uma medida da constância do caminho. Alguns tipos de links são mais propensos a falhas de link do que outros. Por exemplo, com links WAN, as linhas alugadas são mais confiáveis do que as linhas dial-up.
Responder2
Vou comentar sobre isso porque a resposta existente é tecnicamente correta no sentido descritivo, mas falta detalhes e valores concretos importantes úteis para fins de depuração e engenharia, alguns dos quais eu tive que testar para o Windows 10 21H2, embora isso deva aplicam-se a quase todas as versões do Windows, menos alguns padrões internos específicos do Windows que foram alterados nas versões mais recentes do Windows (mais sobre isso mais tarde).
Uma pequena nota: Outros sistemas operacionais, incluindo muitos sistemas operacionais incorporados em dispositivos (roteadores/switches/IoT/etc), geralmente usam uma única métrica (em comparação com diferentes métricas somadas de gateway e interface, como o Windows), mas a regra básica da métrica de rota mais baixa sempre vence é consistente em todos os lugares que eu já vi.
Para novatos:O objetivo dos valores métricos automáticos é, em teoria, tentar garantir que a "melhor" rota seja escolhida com a maior freqüência possível, sem configuração extra, quando houver mais de 2 rotas para um destino. A razão pela qual a definição da página de manual mostrada na outra resposta é tão vaga/ampla é que você pode estruturar os valores escolhidos como quiser, para que qualquer SO/engenheiro/dev/sistema possa escolher os valores que desejar, tentando garantir que sua definição de A "melhor" rota/link geralmente vence (ou seja, é o valor mais baixo). Dito isto, na maioria das aplicações normais, o "melhor" é quase sempre determinado pela atribuição de valores baseados na velocidade bruta do link em intervalos para acomodar conexões que variam regularmente na velocidade do link (principalmente links sem fio).
Não sei e não testei para ver se a métrica da interface é atualizada de forma consistente/periódica em um link sem fio à medida que a velocidade do link cruza diferentes faixas, mas imagino que haja alguma histerese/aderência ou seja apenas definido no link para evitar que ele potencialmente troque a prioridade muito rapidamente, se houver, com outro link (geralmente uma conexão com fio na mesma máquina, como um laptop).
Métricas básicas de roteamento no Windows
Uma rota é selecionada na tabela de roteamento (verificada na linha de comando com "route print") e é a soma dosmétrica de interfaceemétrica de gateway. "Rotas ativas" mostra as métricas funcionais somadas.
Para ver esses valores separados sem verificar o painel de controle você pode usar Run->"netsh int ipv4 show add"
Essas duas métricas podem ser editadas nas propriedades da placa de rede->Avançado->"IPv4" ou "IPv6" dependendo de qual conjunto de rotas/tráfego você está lidando (Execute->"ncpa.cpl" para ir direto para lá -- Fazernãouse o aplicativo de configurações de formulário sobre função). Você pode ver as métricas separadas em "Gateways padrão" e "Métrica de interface".
Valores de métricas automáticas no Windows (varia de acordo com a versão)
Métrica de interface:
Poressepágina onipresente da Microsoft, existem tabelas internas usadas para definir a métrica da interface dependendo da velocidade do link. No momento, eles listam, em ordem, valores pré-XP-SP2 (presumo), valores do XP SP2 até o Windows 8.1 e, em seguida, valores do Windows 10+ para links sem fio e links com fio (tabelas separadas). As versões de servidor são quase certamente idênticas às versões equivalentes para o consumidor, como acontece com muitas coisas ocultas.
- Exemplo: link com fio Ethernet padrão de 1 Gbit, Win10 -> 4ª tabela (conforme acima), "Maior ou igual a 200 Mb e menor que 2 Gb" é uma métrica automática de interface de 25.
Métrica de gateway:
A métrica do gateway pode ser um pouco mais complicada, pois os padrões não são aparentes ou aparentemente documentados em uma pesquisa rápida. Aqui é definido se o link usa um IP dinâmico ou estático. Pode haver outras condições, mas essas duas são tudo que encontrei.
Nos testes, descobri que o padrãoestáticoa métrica é 256 e o padrãodinâmico/DHCPmétrica é 0. Como eles são adicionados à métrica de interface acima e você pode ver nas tabelas vinculadas acima que 256 é maior/pior do que qualquer métrica de interface automática, isso informaum link endereçado dinamicamente sempre terá prioridade sobre qualquer link endereçado estaticamente se todos os padrões/configurações automáticas forem usados.
Considerações Básicas na Prática
Por exemplo: para alguém que administra um servidor ou outro dispositivo Windows com um IP estático que não deseja um roteador não autorizado/de teste/segundo roteador em, digamos, uma segunda NIC para puxar repentinamente o tráfego do dispositivo através do referido roteador (possivelmente tomando o servidor off-line), defina à força as métricas do gateway e da interface baixas o suficiente para que nenhuma outra atribuição automática possa substituí-las. Talvez use 1 e 10 respectivamente ou apenas 1 e 1 se quiser que essa rota/NIC seja sempre usada, sem exceção. Apenas documente que você fez isso, pois definir algumas coisas para valores extremos pode ocasionalmente causar problemas no futuro.
Possíveis peculiaridades/bugs
Antes de iniciar este pequeno projeto de documentação, configurei uma NIC secundáriainterfacemétrica para 100 para lidar com um laboratório de rede que eu havia configurado e depois de talvez uma ou duas semanas, com uso normal no meio, voltei e encontrei a interfacePorta de entradaa métrica também foi definida como 100... não tenho certeza de como isso aconteceu ou se foi um bug secundário, mas rapidamente configurei-o para estático e vice-versa (usava DHCP, então não havia gateway nas propriedades da NIC para definir) corrigi-lo e o problema não voltou.