# GTM topology longest-match scorer > Topology decisions computed the way BIG-IP DNS computes them: the Longest Match sort with per-record rationale, the scoring walk with shadowing shown, highest score wins, ties round-robin. - Tool: https://ronutz.com/en/tools/f5-topology-longest-match - Family: Networking --- # GTM topology longest-match scorer The folklore says longest match wins. The documentation says something sharper: Longest Match is a sort of the record list, and the scores decide. This tool computes the whole thing the way BIG-IP DNS (formerly GTM - Global Traffic Manager) does. Paste `gtm topology` records (as tmsh prints them: `gtm topology ldns: server: { score N }`, with `not` negation supported on either side), optional `gtm region` stanzas (positive members; nested regions resolve), one `source` line declaring the LDNS attributes to evaluate (`ip=`, `country=`, `continent=`, `isp=`, `region=`), and optionally a `candidates` line naming the destinations to score (otherwise the pool and datacenter destinations in the records become the candidates). The output shows the records in Longest Match sorted order, each with its rank rationale: the negation bucket (plain entries above server-side negations, above LDNS-side negations, above wildcards, per K10721), the type ladder (subnets by longest mask, then datacenter and pool, region, ISP, country, continent), and the weight. Types the sources do not rank are placed after the verified ladder and flagged, never guessed. Then the scoring walk: each candidate receives its score from the first record in the sorted list that matches it, and later records for that candidate are marked shadowed. The candidate with the highest score wins; equal top scores round-robin. Which is why a wildcard carrying weight 100 really does beat a /32 carrying weight 5, and the tool shows exactly where that happens. Without a `source` line, the sorted list renders on its own. Everything runs locally; nothing you paste leaves the page. ## 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 - [BIG-IP DNS Load Balancing: the Wide IP, the Pool, and the Three-Step Chain](https://ronutz.com/en/learn/gtm-load-balancing-methods.md): A GSLB answer is decided twice: the wide IP picks a pool, then the pool picks a member through a preferred, alternate and fallback chain. The chain carries the rules people trip over: the alternate can only be static, the fallback ignores availability on purpose, and None cascades all the way to a BIND aggregate. - [GTM Topology Records: Longest Match Is a Sort, Not the Pick](https://ronutz.com/en/learn/gtm-topology-records-and-longest-match.md): Topology load balancing scores candidates from an ordered record list, and the ordering is what Longest Match actually does. The first record to match a candidate scores it, later records are shadowed, and the highest score wins, which is why a heavy wildcard really can beat a light /32.