Resumo

  • Uma palestra da NANOG 98 descreve a migração gradual de portas TCP para uma nuvem, enquanto o site antigo continuava anunciando o IP do serviço.
  • O apresentador relata 3 mil portas transferidas em seis meses, dois retornos por problemas na aplicação e nenhuma transação perdida; a RFC 8955 não padroniza a ação redirect-nh mostrada.

Um plano pode chamar a migração de gradual; uma sessão de pagamento só quer que o próximo pacote chegue ao mesmo serviço. Na NANOG 98, o arquiteto de infraestrutura Hervé Hildenbrand apresentou um serviço cujos clientes usavam um IP fixo no software e TCP bruto. Não havia DNS para alterar, proxy que a aplicação tolerasse ou firmware de cliente que pudesse ser atualizado. Mover o /32 inteiro de uma vez levaria mais de 3 mil portas TCP juntas; anunciá-lo em dois locais poderia dividir sessões ativas.

A solução descrita na sessão da NANOG foi manter o tráfego comum no local antigo e redirecionar apenas combinações escolhidas de endereço de destino, protocolo e porta. Os slides mostram regras de BGP FlowSpec mudando o próximo salto para uma âncora Anycast em uma nova nuvem, com MPLS entre os locais. Uma porta migra quando está pronta; as outras ficam. No final, o /32 passa a ser anunciado pela nova borda, é retirado da antiga e as regras de redirecionamento FlowSpec são removidas.

É uma aplicação engenhosa de uma ferramenta mais conhecida por filtrar tráfego. Mas “FlowSpec” descreve a forma de combinar critérios e distribuí-los pelo BGP, não um comando universal de encaminhamento. A RFC 8955 permite regras por prefixo de destino, protocolo e portas. Também determina que o endereço do próximo salto no NLRI FlowSpec seja ignorado. O redirecionamento padronizado envia o tráfego para uma VRF selecionada por route target. Os slides de Hildenbrand mostram outra ação, redirect-nh, em direção a um endereço Anycast. A RFC permite ações adicionais padronizadas separadamente ou específicas de implementação; o uso de FlowSpec não torna automaticamente portável essa reescrita. Os slides não identificam a implementação nem mostram sua codificação no fio.

As proteções fazem parte do caso. O material descreve regras declaradas em Git/Terraform, uma esteira de CI/CD que valida endereços de destino, faixas de portas e próximos saltos autorizados, além de filtros nos roteadores que rejeitam destinos não aprovados. Uma regra errada pode afetar o tráfego na velocidade do plano de encaminhamento. Validar antes da injeção e filtrar no equipamento reduz o risco de uma migração específica virar um problema no backbone inteiro.

Os slides relatam 3 mil portas TCP migradas em seis meses, convergência abaixo de um segundo, dois retornos atribuídos a problemas na aplicação e nenhuma perda de transação. São números do caso apresentado, não um registro de serviço auditado de forma independente. O endereço 192.0.2.50 nos diagramas pertence ao TEST-NET-1, reservado para documentação pela RFC 5737; 10.100.0.254 pertence ao espaço privado da RFC 1918. A apresentação não revela o cliente nem endereços reais.

O resultado útil não é “FlowSpec migra um serviço”. A equipe dividiu uma identidade compartilhada — o IP — em decisões operacionais menores, cada uma com critério específico, destino autorizado e reversão possível. Assim, problemas da aplicação podiam ser tratados sem transformar cada correção em uma troca total de rede. Os detalhes do caso vêm dos slides de Hervé Hildenbrand na NANOG 98.