# Explicador do fluxo de decisão GSLB > A decisão em duas camadas do BIG-IP DNS, explicada: seleção de pool no wide IP, depois a cadeia preferred, alternate e fallback dentro do pool, com a gramática validada e as regras do manual verificadas. - Tool: https://ronutz.com/pt-BR/tools/f5-gslb-decision-flow - Family: Redes --- # Explicador do fluxo de decisão GSLB Cole estrofes `gtm wideip` e `gtm pool` (como `tmsh list gtm wideip a ` e `tmsh list gtm pool a ` as imprimem) e a decisão em duas camadas do BIG-IP DNS (antigo GTM - Global Traffic Manager) é renderizada como realmente executa. A camada wide-IP mostra o método de seleção de pool (`pool-lb-mode`, padrão round-robin) com os pools anexados, seus valores de order e ratio, e as configurações do wide IP que moldam as respostas: persistence, last-resort-pool, comportamento de failure-rcode e a verbosidade do log de decisão que permite assistir esse mesmo fluxo nos logs. A camada de pool renderiza a cadeia de três passos: preferred (`load-balancing-mode`), alternate (`alternate-mode`), fallback (`fallback-mode`), cada passo carregando a semântica do fabricante para a camada e o método. Os padrões são aplicados e rotulados quando um atributo está ausente: round-robin, round-robin, return-to-dns. Abaixo, observações determinísticas verificam a configuração contra a gramática documentada e as regras do manual de Load Balancing: métodos fora da lista de tokens admitidos por camada, a propriedade ignora-disponibilidade da camada de fallback declarada em toda cadeia resolvida, a fiação do Fallback IP (o método sem endereço, ou um endereço que nenhuma camada usa), o escopo do dynamic-ratio, coeficientes de QoS zerados, ratios de membros que nenhuma camada consome, a regra de pareamento do Global Availability e o aviso de topologia-nas-duas-camadas que pede o fallback de cada pool em None. Um nome de método explica aquele método, incluindo quais camadas o admitem e de onde vem seu sinal de decisão (sondagem do caminho LDNS, estatísticas do servidor, ou nenhum). A palavra `methods` lista os dois catálogos. Tudo roda localmente; nada do que você cola sai da página. ## Standards and references - [F5 TMSH Reference: gtm pool a (load-balancing-mode, alternate-mode, fallback-mode, dynamic-ratio, qos-* coefficients)](https://clouddocs.f5.com/cli/tmsh-reference/v15/modules/gtm/gtm_pool_a.html) - the three-tier mode grammars with per-token descriptions, the chain defaults, the dynamic-ratio applicability set, and the pool options the observations cross-check - [F5 TMSH Reference: gtm wideip a (pool-lb-mode, persistence, last-resort-pool, decision-log verbosity)](https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/gtm/gtm_wideip_a.html) - the wide-IP pool-selection grammar and semantics, including the v13 reference's version-dependent random token - [BIG-IP DNS: Load Balancing - About load balancing and resource availability (and the Topology chapter's both-tiers warning)](https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-dns-load-balancing/about-load-balancing-and-resource-availability.html) - the chain semantics: alternate is static-only, fallback ignores availability, the None cascade and the BIND aggregate, the dynamic-ratio proportional example, and the topology-at-both-tiers fallback rule ## Related reading - [Como o iQuery Conecta o BIG-IP DNS ao Resto da Rede](https://ronutz.com/pt-BR/learn/how-iquery-connects-bigip-dns.md): O iQuery é o protocolo XML que o BIG-IP DNS usa para saber se os objetos que ele resolve estão realmente no ar. Este artigo percorre a malha: gtmd e big3d, as conexões de longa duração na TCP 4353, a confiança por certificado SSL que o bigip_add estabelece, o que o iqdump mostra e a razão clássica de um virtual server estar verde no LTM mas vermelho no DNS. - [DNS como motor de política: multi-RPZ no BIG-IP 21.1](https://ronutz.com/pt-BR/learn/bigip-dns-multi-rpz.md): Response Policy Zones transformam um resolvedor em ponto de aplicação de política, e o BIG-IP DNS 21.1 transforma um feed em muitos: até 65.535 zonas RPZ por cache DNS, avaliadas por precedência configurável, transferidas com segurança via TSIG HMAC-SHA-512, e armadas com o conjunto completo de ações RPZ, de NXDOMAIN e CNAME de jardim murado a PASSTHRU, DROP e TCP-only. Respostas A por FQDN substituem o único IP global de jardim murado, e os gatilhos vão além do QNAME para IP do cliente e IP da resposta. - [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. - [Uma consulta, seis atendentes: a ordem de processamento do BIG-IP DNS](https://ronutz.com/pt-BR/learn/bigip-dns-request-processing-order.md): Uma consulta DNS que chega a um listener do BIG-IP pode ser respondida por iRules, pelo processamento DNSSEC, por um wide IP de GSLB, pelo DNS Express, por um cache DNS, pelo BIND local ou por um pool de servidores DNS reais. A F5 documenta uma precedência estrita entre eles, e a maioria das surpresas no BIG-IP DNS, do registro que responde quando você esperava GSLB ao Rapid Response silenciando o BIND, se resolve lendo essa ordem corretamente.