A rede do BIG-IP é uma cadeia rígida de dependências: as interfaces físicas na base, depois os trunks, depois as Virtual Local Area Networks (VLANs), depois os self-IPs e, por fim, as rotas. Cada camada se apoia na de baixo; o status se propaga em cascata, de cada camada para as que dependem dela, e as decisões de tráfego percorrem a cadeia no sentido inverso. O blueprint pede que você explique essas relações, com o status e as estatísticas de cada uma, e isso favorece quem percorre a cadeia com método.

Interfaces e trunks

Uma interface é uma porta física, com velocidade, duplex e um status up ou down que aparece em show net interface, junto com os contadores; é a primeira parada quando você suspeita de drops (descartes) ou de erros. Um trunk agrega interfaces num único link lógico, normalmente negociado com o Link Aggregation Control Protocol (), para ganhar banda e para sobreviver à falha de um membro. Explicar para que serve um trunk é simples: dois cabos até o switch funcionam como um link só, mais rápido e mais resistente, e o show net trunk informa quantos membros estão funcionando. Um trunk rodando com menos membros do que o configurado está degradado, mas up, e esse é um estado que merece um alarme.

VLANs: tagged ou untagged

Uma recebe interfaces ou trunks, e cada associação é tagged ou untagged. Untagged significa que os frames (quadros) saem da porta sem tag e que a porta pertence a uma única VLAN: é o comportamento de uma porta de acesso. Tagged significa que os frames levam o identificador de VLAN do 802.1Q, o que permite que uma mesma interface ou um mesmo trunk carregue várias VLANs: é o padrão normal num trunk que vai para um switch. A regra que separa um caso do outro na prova: untagged associa uma VLAN à porta, tagged multiplexa várias, e as duas pontas do cabo precisam estar de acordo, senão o tráfego vai parar, sem nenhum aviso, no domínio de broadcast errado.

Self-IPs: os endereços do próprio equipamento

Um self-IP dá ao BIG-IP um endereço numa VLAN: é o endereço de origem dos monitores, o endereço que os peers de config sync e de failover alcançam e o que os servidores usam como gateway. Os self-IPs flutuantes (floating) pertencem a um traffic group e mudam de equipamento no failover; os estáticos ficam sempre no mesmo equipamento. Todo self-IP tem a configuração de port lockdown, explicada em acesso de gerenciamento. A dependência fica assim: sem VLAN, não há self-IP; se a VLAN cai porque a última interface dela morreu, o self-IP fica inalcançável.

Rotas e a decisão de saída

Que VLAN, que rota e que endereço de saída o tráfego usa é uma decisão de roteamento: o destino é comparado com a tabela de roteamento (uma por route domain), e a rota escolhida aponta um gateway alcançável em alguma VLAN, através de algum self-IP. No tráfego que o equipamento origina ou encaminha para os servidores, o endereço de origem é o self-IP da VLAN de saída, a menos que o Secure Network Address Translation () o reescreva, assunto de SNAT e tráfego de retorno.

O status em cascata

A cadeia também é um modelo de falha. Interface caída: o trunk fica degradado ou cai; uma VLAN que perdeu a última interface que a carregava leva os self-IPs junto; as rotas que passam por esses self-IPs deixam de resolver; os monitores que usam esses self-IPs como origem ficam mudos e marcam como down servidores que estão saudáveis. Compare primeiro o status das interfaces e depois vá subindo pela cadeia: as dependências entre interfaces, trunks, VLANs e self-IPs, exatamente na ordem do blueprint.

Esta série, em ordem

Este artigo abre a série Fundamentos do BIG-IP, da interface ao pool member. Ele monta a cadeia de dependências, da interface ao self-IP, em que todo o resto se apoia; as partes primeiro completam o equipamento (segmentação, acesso de gerenciamento, os serviços de que ele depende), depois acompanham uma conexão na ordem em que o BIG-IP a trata e terminam mostrando como a plataforma distribui esse trabalho entre os núcleos e se divide em guests.

  1. Route domains: segmentação em camada 3 dentro de um único BIG-IP. Uma tabela de roteamento separada, com um ID, para que tenants com espaços de endereçamento sobrepostos dividam o mesmo equipamento: a notação com o sinal de porcentagem e o isolamento estrito (strict isolation).
  2. Acesso de gerenciamento no BIG-IP: management IP, port lockdown e listas de acesso. As duas portas de entrada de um BIG-IP: o endereço de gerenciamento e o que o port lockdown realmente libera num self-IP.
  3. Os serviços de sistema por trás de um BIG-IP saudável: DNS, NTP, SNMP, syslog. DNS, , e syslog remoto: quatro configurações pequenas que, quando dão errado, causam um estrago desproporcional.
  4. Como funciona um virtual server do BIG-IP. A porta da frente: o endereço e a porta em que ele escuta, a pilha de profiles, a persistência, o pool member e a tradução do endereço de origem.
  5. Tipos de virtual server do BIG-IP, e o que cada um realmente faz. Do full proxy, que termina a conexão e abre uma nova, ao forwarder que encaminha pacote a pacote: o que cada tipo faz de verdade.
  6. Profiles em um virtual server. Profiles de protocolo, de aplicação, de SSL e de persistência empilhados para formar o comportamento de um virtual server, e como funciona a herança entre eles.
  7. Pools e métodos de balanceamento no BIG-IP. O pool de members de backend e a divisão entre métodos estáticos e métodos dinâmicos, que reagem à carga.
  8. Métodos de balanceamento do BIG-IP, e o que cada um pondera. Os métodos documentados em dois eixos: se reagem ou não ao estado em tempo real e o que exatamente eles levam em conta.
  9. Para onde vão as requisições? Simulação da distribuição do BIG-IP LTM. Da regra ao resultado: por que o Ratio é um ciclo completo e como o priority group activation deixa members ociosos.
  10. Como os monitores de saúde do LTM decidem ativo ou inativo. Send string e receive string, interval e timeout, e onde o monitor é associado: em quanto tempo uma falha é percebida.
  11. Métodos de persistência do BIG-IP e em que cada um se baseia. Cookie, endereço de origem, sessão SSL ou um valor extraído por iRule: em que cada método se baseia e onde cada um quebra.
  12. SNAT e o problema do tráfego de retorno. Por que a resposta do member precisa voltar pelo BIG-IP, e como o SNAT garante isso.
  13. OneConnect: reuso é um problema de agrupamento, e o SNAT reescreve os grupos. Conexões ociosas do lado do servidor entregues à próxima requisição elegível, a source mask que define o que é elegível e o que o SNAT faz com os grupos.
  14. Perfis de protocolo: TCP vivo, TCP congelado e os dois caminhos rápidos. Os profiles TCP que continuam evoluindo, o trio legado congelado e os dois fast paths que trocam o full proxy por velocidade.
  15. CMP: os núcleos que você pagou, e as linhas de iRule que os devolvem. Um TMM por núcleo, o virtual server rebaixado que roda tudo num único núcleo e o static:: como solução.
  16. vCMP: hosts, guests e como os recursos são fatiados. Uma plataforma fatiada em guests independentes: o modelo de host e guest, o ciclo de vida e como o número de núcleos define a memória.