# Pontuador longest-match de topologia GTM > Decisões de topologia computadas como o BIG-IP DNS computa: a ordenação Longest Match com justificativa por registro, a caminhada de pontuação com sombreamento exibido, maior pontuação vence, empates em round robin. - Tool: https://ronutz.com/pt-BR/tools/f5-topology-longest-match - Family: Redes --- # Pontuador longest-match de topologia GTM O folclore diz que a correspondência mais longa vence. A documentação diz algo mais afiado: Longest Match é uma ordenação da lista de registros, e as pontuações decidem. Esta ferramenta computa tudo do jeito que o BIG-IP DNS (antigo GTM - Global Traffic Manager) computa. Cole registros `gtm topology` (como o tmsh os imprime: `gtm topology ldns: server: { score N }`, com negação `not` suportada em ambos os lados), estrofes `gtm region` opcionais (membros positivos; regiões aninhadas resolvem), uma linha `source` declarando os atributos do LDNS a avaliar (`ip=`, `country=`, `continent=`, `isp=`, `region=`), e opcionalmente uma linha `candidates` nomeando os destinos a pontuar (caso contrário os destinos pool e datacenter dos registros viram os candidatos). A saída mostra os registros na ordem do Longest Match, cada um com sua justificativa de posição: o balde de negação (entradas simples acima de negações do lado servidor, acima de negações do lado LDNS, acima de curingas, conforme o K10721), a escada de tipos (subnets pela máscara mais longa, depois datacenter e pool, region, ISP, país, continente) e o peso. Tipos que as fontes não classificam são colocados depois da escada verificada e sinalizados, nunca adivinhados. Depois, a caminhada de pontuação: cada candidato recebe sua pontuação do primeiro registro da lista ordenada que o corresponde, e registros posteriores para aquele candidato são marcados como sombreados. O candidato com a maior pontuação vence; pontuações máximas iguais fazem round robin. E é por isso que um curinga carregando peso 100 realmente vence um /32 carregando peso 5, e a ferramenta mostra exatamente onde isso acontece. Sem uma linha `source`, a lista ordenada é exibida sozinha. Tudo roda localmente; nada do que você cola sai da página. ## Standards and references - [BIG-IP GTM: Load Balancing - Using Topology Load Balancing (record anatomy, the sort keys, scoring the candidates, the both-tiers fallback rule)](https://techdocs.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm-lb-configuring-11-5-0/1.html) - Longest Match as a sort by source statement, destination statement and weight; subnets ranked by mask specificity; weight is called score in tmsh; scores assigned to pools or pool members from the ordered list - [F5 K10721: Overview of the Longest Match algorithm](https://my.f5.com/manage/s/article/K10721) - the sorting rules this engine implements: longest netmask first, the type ladder demonstrated in the worked examples, negation buckets (server-side above LDNS-side above wildcards), wildcards last, and weights governing when Longest Match is disabled ## Related reading - [Load Balancing no BIG-IP DNS: o Wide IP, o Pool e a Cadeia de Três Passos](https://ronutz.com/pt-BR/learn/gtm-load-balancing-methods.md): Uma resposta GSLB é decidida duas vezes: o wide IP escolhe um pool, e o pool escolhe um membro através de uma cadeia preferred, alternate e fallback. A cadeia carrega as regras em que as pessoas tropeçam: o alternate só pode ser estático, o fallback ignora disponibilidade de propósito, e None cascateia até um agregado via BIND. - [Registros de Topologia do GTM: Longest Match É uma Ordenação, Não a Escolha](https://ronutz.com/pt-BR/learn/gtm-topology-records-and-longest-match.md): O balanceamento por topologia pontua candidatos a partir de uma lista ordenada de registros, e a ordenação é o que o Longest Match de fato faz. O primeiro registro a corresponder a um candidato o pontua, os posteriores ficam sombreados, e a maior pontuação vence, e é por isso que um curinga pesado realmente pode vencer um /32 leve.