O grande tema da linha BIG-IP 21.x é que o TMOS agora trata o tráfego de IA como um protocolo que ele entende de fato, e não como HTTP opaco. O protocolo em questão é o , Model Context Protocol: a convenção baseada em JSON-RPC 2.0 que permite a um cliente descobrir e chamar ferramentas (tools) em servidores MCP, transportada em Streamable HTTP ou, por compatibilidade, em HTTP com Server-Sent Events. Essa combinação de sessões longas, respostas em streaming e tool calls com efeitos colaterais reais é exatamente o tipo de tráfego que um load balancer comum trata mal e que um (web application firewall, o firewall de aplicações web) comum não consegue ler. As versões 21.x atacam o problema em duas etapas.

21.0: o BIG-IP passa a falar MCP

O BIG-IP 21.0.0 trouxe o suporte a MCP no nível dos profiles (perfis). Segundo a referência de profiles do LTM da F5, para tratar MCP direito o virtual server precisa de um profile HTTP e de profiles JSON e (server-sent events): juntos, eles permitem que o TMM faça o parsing da estrutura das mensagens JSON-RPC, lide com os dois transportes e aplique inspeção e otimização no nível do protocolo, em vez de só repassar bytes às cegas. Os profiles definem limites de tamanho para as partes da mensagem, e o JSON e o SSE trazem, cada um, seus próprios eventos e comandos de iRules; ou seja, o 21.0 já permitia fazer o parsing, a manipulação e o gerenciamento de tráfego dos fluxos MCP.

A persistência, porém, ainda era manual. As sessões MCP passam a ter estado (stateful) quando o servidor emite um Mcp-Session-Id, e, a partir daí, o cliente precisa apresentar esse ID em todas as requisições; se uma requisição no meio da sessão cai no membro errado do pool, o servidor MCP stateful que a recebe não tem o contexto da conversa. A própria documentação do 21.0 e o passo a passo com OpenShift que a F5 publicou resolviam isso com uma iRule de persistência Universal (UIE) baseada no header (cabeçalho) Mcp-Session-Id: detectar os endpoints MCP, ler o token, fixar a sessão no membro. Funcionava, e era exatamente o tipo de código de integração feito à mão (glue code) que, com o tempo, um recurso da própria plataforma deveria substituir.

Além do trabalho no protocolo, o 21.0 acrescentou integrações com armazenamento S3 voltadas a cargas de trabalho de IA, ou seja, o lado do data plane de pipelines de (retrieval-augmented generation, a geração aumentada por recuperação), embeddings, fine-tuning, inferência em lote e distribuição de artefatos de modelo. Assim, o mesmo equipamento que fica na frente dos endpoints MCP também pode ficar no caminho do armazenamento, com o tráfego de saída controlado.

21.1: persistência nativa com o profile aimcp

O BIG-IP 21.1.0 troca a iRule por um tipo de persistência de verdade. O LTM ganha um profile de persistência MCP, que vem com o nome aimcp, e as release notes da F5 descrevem o mecanismo com precisão: o TMM entrega ao cliente um valor de Mcp-Session-ID encapsulado e criptografado, o que garante ao mesmo tempo a continuidade da sessão e a segurança. O material de lançamento da F5 diz que o comportamento é muito parecido com o da persistência por cookie: depois que o servidor MCP emite um ID de sessão, o tráfego seguinte que traz esse ID vai para o mesmo membro do pool. Vale parar um pouco no detalhe do encapsulamento. O valor que fica com o cliente não é o identificador de sessão original do backend; o TMM o criptografa e o encapsula, então o token que passa pelo cliente não pode ser simplesmente reaproveitado (replay) contra outro membro, nem revela os nomes usados no backend. Quem conhece o jeito como a persistência por cookie do BIG-IP codifica, e opcionalmente criptografa, o cookie do membro do pool vai reconhecer aqui a mesma filosofia, aplicada a um protocolo de IA. O explicador de métodos de persistência mostra o aimcp ao lado dos métodos clássicos.

O 21.1 também traz suporte experimental ao A2A, o protocolo Agent2Agent, com balanceamento de carga do tráfego A2A e logging e visibilidade via iRules. É um sinal de para onde essa linha de produto vai: não só clientes conversando com servidores de ferramentas, mas agentes conversando com agentes pelo mesmo data plane.

21.1: o WAF passa a conhecer o modelo de ameaças

A outra metade da versão é de proteção. No 21.1, o Advanced WAF ganha inspeção do protocolo MCP com um template de política de segurança dedicado, o MCP Protection Policy, voltado às classes de ataque catalogadas no MCP Top 10: tool poisoning, exposição de segredos, injeção de prompt e de ferramenta, e outras do mesmo tipo. O conjunto de recursos é o de um WAF que realmente conhece tráfego MCP: detecção de injeção de prompt e de ferramenta nos payloads JSON-RPC, proteção contra (server-side request forgery, a falsificação de requisições pelo lado do servidor) nas chamadas de saída que a execução de uma ferramenta pode disparar, mascaramento com Data Guard para que segredos e padrões sensíveis não saiam nas respostas, e validação de (JSON Web Token) dos tokens que autenticam os clientes MCP. O template tem o seu próprio tipo de resposta com página de bloqueio e, ao aplicar a política, expõe o ID de sessão MCP nos headers da resposta e o ID da requisição MCP no corpo da resposta, o que torna viável ligar um bloqueio à tool call específica que o causou. Como é um template de política, tudo sobre a forma como ele aplica as regras pode ser lido como em qualquer política ASM; o explicador de políticas declarativas vale sem mudança nenhuma.

Uma ressalva, que vem direto da documentação da versão, merece ir em negrito nas suas notas de projeto: respostas em streaming SSE não passam pela inspeção do lado da resposta. As proteções do lado da requisição (a detecção de injeção, as verificações de SSRF e a validação de JWT) veem tudo; mas uma resposta transmitida como Server-Sent Events não fica retida para a limpeza de resposta no estilo do Data Guard. Se o seu modelo de ameaças inclui a exfiltração de segredos na saída do modelo, o caminho de streaming precisa de um controle compensatório, porque ali o WAF deixa claro que não faz esse papel.

O MCP 2026-07-28 acabou com a sessão

Seção acrescentada em 2026-10-03. Tudo o que está acima descreve o MCP como ele era quando o BIG-IP 21.0 e o 21.1 foram lançados: o servidor podia emitir um Mcp-Session-Id, e o cliente tinha de apresentá-lo em todas as requisições. O protocolo mudou. A revisão atual do Model Context Protocol é a 2026-07-28, e o changelog dela começa removendo as sessões no nível do protocolo e o header Mcp-Session-Id do transporte Streamable HTTP: "Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments". Ou seja, o servidor que precisa guardar estado entre uma chamada e outra passa a usar handles explícitos, criados por ele mesmo e enviados como argumentos comuns das ferramentas. A mesma revisão remove o handshake initialize (agora toda requisição leva a versão do protocolo em _meta), acrescenta a chamada server/discover, remove ping e logging/setLevel, deixa de permitir a retomada de streams SSE e reclassifica o antigo transporte HTTP+SSE como Deprecated. O batching do JSON-RPC já tinha saído na revisão 2025-06-18.

Para um load balancer, a consequência é direta. A página do transporte deixa claro o que um servidor que só fala a 2026-07-28 faz com o mecanismo antigo: o header Mcp-Session-Id que vier na requisição é ignorado, e a especificação completa: "and do not mint or echo session IDs", ou seja, o servidor não cria nem devolve IDs de sessão; e um GET ou DELETE de HTTP no endpoint MCP recebe 405 Method Not Allowed. Assim, o profile de persistência aimcp, que a referência de profiles do 21.1 da F5 (atualizada em 2026-07-07) descreve como "appending persistence information to the value of the mcp-session-id cookie as it passes through the BIG-IP system", só tem um identificador de sessão para usar enquanto os servidores atrás dele falarem as revisões que tinham esse identificador: da 2025-03-26 à 2025-11-25, que a própria especificação lista como as revisões do Streamable HTTP que "could assign a session via the Mcp-Session-Id header". Diante de um servidor que já migrou para a 2026-07-28, não existe identificador para o profile encapsular, e a continuidade da sessão vira problema do servidor, que a mantém nos seus próprios handles.

Em troca, o que a nova revisão oferece a um intermediário é melhor do que um cookie de sessão. O Streamable HTTP agora copia alguns campos do corpo para headers HTTP "so that intermediaries (load balancers, gateways, observability tooling) can route and inspect requests without parsing the body": MCP-Protocol-Version em todo POST, Mcp-Method em todas as requisições, Mcp-Name em tools/call, resources/read e prompts/get (o nome da ferramenta ou a URI do recurso, codificado em no formato =?base64?...?= quando o valor não pode ir direto num header), e Mcp-Param-{Name} para qualquer parâmetro de ferramenta que o servidor marque com x-mcp-header no seu schema de entrada. Um servidor que processa o corpo deve rejeitar a requisição cujos headers não batem com ele, com HTTP 400 e o erro JSON-RPC -32020 HeaderMismatch, justamente por causa do risco de "a load balancer routing on the header value while the MCP server executes based on the body value". Por isso, uma política de LTM ou uma iRule pode direcionar ou recusar o tráfego com base no método e no nome da ferramenta, sem precisar de profile JSON nenhum. A especificação acrescenta uma regra para quem fizer isso: o intermediário que roteia ou aplica rate limiting com base nesses headers "SHOULD verify that the MCP-Protocol-Version header indicates a version that requires" que os headers sejam validados contra o corpo, e deve rejeitar a requisição, em vez de confiar nos headers, quando a versão for mais antiga ou quando o header não vier.

Mais duas observações sobre o transporte interessam a quem projeta com BIG-IP. A especificação pede que os servidores enviem X-Accel-Buffering: no nas respostas SSE, para que os proxies reversos não façam buffer do stream, e incentiva uma linha de comentário SSE periódica como keep-alive em streams de longa duração. As duas regras tratam de intermediários, e um full proxy é exatamente isso. Nada disso muda a ressalva sobre o WAF feita acima: uma resposta transmitida como Server-Sent Events continua sem passar pela inspeção do lado da resposta.

Antes de ativar

Três verificações, em ordem. Primeira, a plataforma: o 21.x só roda em rSeries, VELOS e Virtual Edition, então um parque de iSeries fica no 17.x e totalmente fora deste conjunto de recursos. Segunda, os profiles: tanto o profile de persistência MCP quanto o template do WAF pressupõem que o virtual server já fala MCP, ou seja, que já tem os profiles HTTP, JSON e SSE; então adicione esses profiles primeiro e confirme que os limites de tamanho comportam os seus payloads. Terceira, as sessões: se você trouxe a iRule de persistência da época do 21.0, desative-a quando associar o aimcp, em vez de deixar as duas rodando; cada token de sessão deve ter um único dono. Quarta, desde 2026-10-03: descubra qual revisão do MCP os servidores falam. Servidores nas revisões de 2025-03-26 a 2025-11-25 emitem o identificador de sessão que o aimcp encapsula; um servidor na 2026-07-28 ignora esse identificador e nunca cria um, então, se o backend ainda precisar de persistência, planeje-a em torno dos headers Mcp-Param-* que o servidor decidir expor, e verifique o MCP-Protocol-Version antes de confiar em qualquer header espelhado. A visão geral do 21.x coloca tudo isso no contexto mais amplo da versão.

Fontes

O MCP Protocol Protection, a persistência de sessão MCP e as configurações de perfil acima estão documentados pela F5 em dois conjuntos de notas de versão e na referência de perfis do próprio recurso. A seção sobre a 2026-07-28 cita a própria página de versionamento, o changelog e a página do transporte Streamable HTTP da especificação do Model Context Protocol, tudo lido em 2026-10-03.