O que é GENEVE?

Minha primeira experiência com um túnel de sobreposição aconteceu em 2003, quando eu trabalhava em um projeto para criar um proxy transparente baseado no Squid e no Cisco WCCP (protocolo de comunicação de cache da Web). Parte da configuração entre o roteador Cisco e o proxy Squid precisava usar túneis GRE (Encapsulamento Genérico de Roteamento) para comunicação. Naquela época, eu não entendia bem a necessidade de protocolos de túneis. No entanto, agora sei da importância deles porque VLANs em grandes nuvens de multilocação são corrompidas.

As VLANs foram desenvolvidas para segmentar o tráfego de rede em redes menores e menos complexas. A desvantagem é que elas têm apenas um campo fixo de 12 bits, o que significa que você só pode ter cerca de 4.000 VLANs em uma topologia de rede. No final dos anos 1990 e início dos anos 2000, esses segmentos eram mais do que suficientes para acomodar a rede. No entanto, com a chegada da era da nuvem e os ambientes de multilocação, surgiu a necessidade de muito mais túneis de rede individuais.

Para lidar com esse problema, vários fornecedores propuseram diversas soluções: VXLAN (LAN virtual extensível), NVGRE (virtualização de rede usando encapsulamento genérico de roteamento) e STT (tunelamento de transporte sem estado). As três soluções encapsulam os dados de aplicações em um novo campo de cabeçalho fixo maior. Esse tamanho de cabeçalho é de 24 bits para VXLAN e NVGRE, este último é usado principalmente pela Microsoft, enquanto o STT tem um tamanho de cabeçalho de 64 bits. Nenhum desses métodos de encapsulamento de túnel exige alteração na infraestrutura de rede do hardware, embora alguns fornecedores ofereçam hardware que pode ajudar a melhorar a eficiência da solução. As soluções não são compatíveis entre si.

No entanto, nem tudo está perdido na era atual das grandes nuvens de multilocação. Um novo padrão de virtualização de rede surgiu: GENEVE (Encapsulamento Genérico de Virtualização de Rede), que promete solucionar as limitações percebidas das especificações anteriores e oferecer suporte a todos os recursos de VXLAN, NVGRE e STT. Muitos acreditam que o GENEVE poderia substituir completamente esses formatos anteriores.

O objetivo declarado do GENEVE é definir somente um formato de dados de encapsulamento. Ao contrário dos formatos anteriores, ele não inclui informações ou especificações para o control plane. Os autores afirmam que:

"Há uma clara vantagem em definir um único formato de dados: a maioria dos protocolos é apenas superficialmente diferente e não há muita vantagem em duplicar os esforços. No entanto, o mesmo não pode ser dito dos control planes, diversos em aspectos fundamentais. O argumento a favor da padronização também fica menos claro, considerando a grande variedade de requisitos, objetivos e cenários de implantação."

Para alcançar esses objetivos, os autores do GENEVE concordaram que o formato dos dados deveria ser o mais flexível e extensível possível. Embora os campos atuais de identificador de túnel de 24 bits em VXLAN e NVGRE e de 64 bits em STT sejam mais do que suficientes para especificar todas as redes virtuais que serão necessárias, eles esperam que futuros desenvolvedores queiram subdividir esse campo para transportar informações diferentes do identificador de rede virtual. Eles comparam os possíveis usos desse campo com as informações de estado do sistema atualmente trocadas em servidores virtualizados ou entre line cards em um switch de chassi. Também observam que não é possível especificar um tamanho fixo de campo que seja suficiente para todos os usos futuros possíveis. Além disso, os autores do GENEVE se baseiam em muitos outros protocolos que demonstraram ter uma vida longa. Protocolos como BGP (Border Gateway Protocol), LLDP (Link Layer Discovery Protocol), IS-IS (Intermediate System - Intermediate System) e muitos outros já existem há várias décadas e continuam tão populares quanto antes.

A razão é simples: eles são extensíveis. Eles evoluem ao longo do tempo com novos recursos, não pela revisão dos protocolos base, mas pela adição de novos recursos opcionais.

Os pacotes encapsulados do GENEVE foram projetados para serem transmitidos mediante um equipamento de rede padrão. Os pacotes são enviados de um endpoint de túnel para um ou mais endpoints de túnel usando endereçamento unicast, ou multicast. A aplicação cliente e o host no qual ela está sendo executada não são modificados de forma alguma. As aplicações geram pacotes IP idênticos como se estivessem se comunicando por meio de switches e roteadores de hardware. O endereço IP de destino incluído no pacote é significativo apenas na rede virtual do locatário da nuvem. O endpoint do túnel encapsulará o pacote IP do usuário final no cabeçalho do GENEVE, adicionando o identificador do túnel que especifica a rede virtual do locatário seguido de qualquer opção. O cabeçalho consiste em campos especificando que é um pacote do GENEVE, o comprimento total das opções, se houver, o identificador do túnel e a série de opções. Em seguida, o pacote concluído é transmitido ao endpoint de destino em um pacote UDP padrão compatível com IPv4 e IPv6. O endpoint do túnel receptor retira o cabeçalho, interpreta todas as opções incluídas e direciona o pacote do usuário final para seu destino na rede virtual indicada pelo identificador do túnel.

A especificação do GENEVE oferece recomendações sobre maneiras de alcançar uma operação eficiente, evitando a fragmentação e aproveitando as vantagens dos recursos de descarregamento de hardware NIC e ECMP (Equal-cost multi-path, multicaminho de custo igual). A especificação também oferece opções sobre como oferecer suporte a serviços diferenciados e notificação explícita de congestionamento. Os autores esperam que não haverá problemas quando o GENEVE e um ou mais dos outros métodos de encapsulamento estiverem em uso no mesmo sistema. Os endpoints do túnel do GENEVE só se comunicarão entre si, e os pacotes serão processados pela infraestrutura de rede de forma idêntica a qualquer outro pacote UDP. O formato de dados é compatível com todos os recursos de VXLAN, NVGRE e STT. Portanto, no futuro, o uso dos três formatos anteriores poderá ser recusado. Como não é especificado um protocolo de control plane, os autores esperam que ele seja compatível com qualquer protocolo em uso com os outros métodos de encapsulamento. Um dos principais benefícios em relação a outros métodos de encapsulamento é o formato de opção flexível do GENEVE e o uso da IANA (Autoridade para Atribuição de Números da Internet) para designar classes de opção. Os desenvolvedores podem incluir muitas ou poucas opções dinamicamente sem se limitar a 24 bits nem incorrer na sobrecarga de um campo de 64 bits quando apenas uma fração desse tamanho for necessária.

A transição para o GENEVE não será imediata. Os outros métodos de encapsulamento estão em uso há algum tempo e vários métodos podem operar dentro do mesmo sistema. No entanto, o GENEVE está sendo adotado como o protocolo de tunelamento padrão para a OVN (Open Virtual Network), que, por sua vez, está sendo promovida como uma implementação do OVS (OpenvSwitch) em versões futuras do OpenStack.

A experiência com grandes nuvens de multilocação continua a crescer, e nenhum método de encapsulamento deve se tornar o único padrão aceito. No entanto, o GENEVE, com seu formato de opções flexíveis e suporte para todos os recursos dos outros métodos, será um forte candidato para ampla adoção.

Benjamin Schmaus é Red Hat Cloud TAM na região central de NA. Ele trabalha com Linux desde 1998 e deu suporte a ambientes de negócios em diversos setores: varejo, defesa, software, financeiro, ensino superior e ensino básico. Mais recentemente, seu foco foi capacitar nossos clientes a implantar, operar e oferecer suporte ao Red Hat OpenStack Platform e ao Red Hat Ceph Storage.

Um Gerente Técnico de Contas (TAM) da Red Hat é um especialista em soluções que trabalha junto às organizações de TI para planejar implantações estratégicas bem-sucedidas e ajudá-las a maximizar o desempenho e crescimento. O TAM faz parte da organização Customer Experience and Engagement de nível mundial da Red Hat e oferece recomendações e orientações proativas para ajudar você a identificar e resolver possíveis problemas antes que eles ocorram. Em caso de problemas, o TAM reconhece o problema e emprega os melhores recursos para a resolução acontecer o quanto antes, e sua empresa não precisar parar.