Em no episódio anterior eu descrevi a estrutura de automação de rede. Segundo o feedback de alguns, até mesmo essa primeira abordagem ao problema já esclareceu algumas questões. E isso me deixa muito feliz, porque nosso objetivo neste ciclo não é rechear o Ansible com scripts em Python, mas construir um sistema.

Essa mesma estrutura define a ordem em que lidaremos com a questão.
E a virtualização da rede, que se concentra neste episódio, não se encaixa muito na temática do ADSM, onde analisamos automação.

Mas vamos olhá-la sob uma nova perspectiva.

Já há muito tempo que uma única rede é utilizada por vários serviços. No caso de um operador de telecomunicações, isso inclui 2G, 3G, LTE, banda larga e B2B, por exemplo. No caso de um data center: conectividade para diferentes clientes, Internet, armazenamento em bloco, armazenamento de objetos.

E todos os serviços exigem isolamento uns dos outros. Assim surgiram as redes sobrepostas.

E todos os serviços não querem esperar que uma pessoa os configure manualmente. Assim surgiram os orquestradores e SDN.

A primeira abordagem para automação sistemática da rede, ou melhor, de sua parte, já foi tentada há muito tempo e implementada em diversos lugares: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

É com isso que vamos trabalhar hoje.

Conteúdo

Razões
Terminologia
Underlay — rede física
Overlay — rede virtual
- Overlay com ToR
- Overlay com o host
- Tomando como exemplo o Tungsten Fabric
  - Comunicação dentro de uma única máquina física
  - Comunicação entre VMs localizadas em diferentes máquinas físicas
  - Saída para o mundo exterior
FAQ
Conclusão
Links Úteis

Razões

E já que estamos falando sobre isso, vale a pena mencionar as premissas para a virtualização da rede. Na verdade, esse processo não começou ontem.

Provavelmente, você já ouviu várias vezes que a rede sempre foi a parte mais inerte de qualquer sistema. E isso é verdade em todos os sentidos. A rede é a base sobre a qual tudo se apoia, e realizar alterações nela é bastante difícil — os serviços não toleram quando a rede cai. Muitas vezes, a retirada de um único nó pode derrubar muitas aplicações e afetar muitos clientes. Em parte, é por isso que a equipe de rede pode resistir a quaisquer mudanças — porque agora funciona de alguma forma (podemos até não saber como), mas agora precisamos configurar algo novo, e não se sabe como isso afetará a rede.

Para não esperar que os provedores de rede configurem o VLAN e para não precisar definir todos os serviços em cada nó da rede, as pessoas inventaram o uso de sobreposições — redes sobrepostas — das quais existe uma grande variedade: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etc.

Sua atratividade reside em duas coisas simples:

Ajustam-se apenas os nós finais — os nós de trânsito não precisam ser tocados. Isso acelera significativamente o processo e, às vezes, permite até mesmo excluir o departamento de infraestrutura de rede do processo de introdução de novos serviços.
A carga está oculta profundamente dentro dos cabeçalhos — os nós de trânsito não precisam saber nada sobre ela, sobre a endereçamento nos hosts, as rotas da rede sobreposta. Isso significa que é necessário armazenar menos informações nas tabelas, o que permite o uso de dispositivos mais simples e baratos.

Neste número não tão completo, não pretendo discutir todas as tecnologias possíveis, mas sim descrever a estrutura do funcionamento das redes sobrepostas em Data Centers.

Toda a série descreverá um data center composto por fileiras de racks idênticos, nos quais está instalado o mesmo equipamento de servidor.

Nesses equipamentos, são iniciadas máquinas virtuais / contêineres / serverless que implementam serviços.

Terminologia

No ciclo servidor eu chamarei de programa que implementa a parte do servidor da comunicação cliente-servidor.

As máquinas físicas nos racks chamaremos de servidores não .

A máquina física é um computador x86 instalado em um rack. O termo mais comumente utilizado é host. Portanto, vamos chamá-la de "máquina" ou host.

Hipervisor é um aplicativo executado em uma máquina física que emula os recursos físicos nos quais as Máquinas Virtuais são iniciadas. Às vezes, na literatura e na rede, a palavra "hipervisor" é usada como sinônimo de "host".

Máquina virtual é um sistema operacional que é executado em uma máquina física sobre o hipervisor. Para nós, dentro do escopo deste ciclo, não é tão importante se é realmente uma máquina virtual ou apenas um contêiner. Vamos chamar isso de "MV«

Inquilino é um conceito amplo que eu definirei neste artigo como um serviço separado ou um cliente separado.

Multi-inquilino ou multi-tenant — o uso do mesmo aplicativo por diferentes clientes / serviços. Nesse caso, a segregação dos clientes entre si é alcançada graças à arquitetura do aplicativo, e não a instâncias separadamente executadas.

ToR — Switch Top of the Rack — switch instalado no rack, ao qual estão conectadas todas as máquinas físicas.

Além da topologia ToR, diferentes provedores praticam End of Row (EoR) ou Middle of Row (embora este último seja uma raridade desprezível e nunca encontrei as siglas MoR).

Rede subjacente ou rede subjacente ou underlay — infraestrutura física de rede: switches, roteadores, cabos.

Rede sobreposta ou rede sobreposta ou overlay — rede virtual de túneis que opera sobre a física.

Fábrica L3 ou Fábrica IP — uma invenção impressionante da humanidade, permitindo que nas entrevistas não se repita STP e não se aprenda TRILL. Um conceito no qual toda a rede até o nível de acesso é exclusivamente L3, sem VLAN e, portanto, enormes domínios de broadcast estendidos. O porquê do termo "fábrica" será esclarecido na próxima parte.

SDN — Rede Definida por Software. Dificilmente precisa de apresentação. Uma abordagem para gerenciar a rede em que as alterações na rede são feitas não por uma pessoa, mas por um programa. Geralmente significa deslocar o Control Plane para fora dos dispositivos de rede finais para um controlador.

NFV — Virtualização de Funções de Rede — virtualização de dispositivos de rede, sugerindo que parte das funções da rede pode ser executada na forma de máquinas virtuais ou contêineres para acelerar a implementação de novos serviços, organização de Service Chaining e escalabilidade horizontal mais simples.

VNF — Função Virtual de Rede. Um dispositivo virtual específico: roteador, switch, firewall, NAT, IPS/IDS, etc.

Estou intencionalmente simplificando a descrição para uma implementação específica, para não confundir muito o leitor. Para uma leitura mais ponderada, remeto à seção Links. Além disso, Roma Gorge, que critica este artigo por imprecisões, promete escrever uma edição separada sobre as tecnologias de virtualização de servidores e redes, mais aprofundada e atenta aos detalhes.

A maioria das redes hoje pode ser claramente dividida em duas partes:

Underlay — rede física com configuração estável.
Overlay — abstração sobre o Underlay para isolamento de locatários.

Isso é verdade tanto para o caso de DC (que iremos abordar neste artigo), quanto para ISP (que não iremos abordar, pois já foi mencionado em SDN). Com redes corporativas, é claro que a situação é um pouco diferente.

Imagem com foco na rede:

Underlay

Underlay é uma rede física: switches de hardware e cabos. Os dispositivos no underlay sabem como chegar às máquinas físicas.

Baseia-se em protocolos e tecnologias padrão. Não menos importante, porque dispositivos de hardware ainda operam com software proprietário, o que impede a programação de chips e a implementação de seus próprios protocolos, necessitando assim da compatibilidade com outros fornecedores e da padronização.

Já uma empresa como o Google pode se permitir desenvolver seus próprios switches e se afastar dos protocolos comuns. Mas a LAN_DC não é o Google.

Underlay muda relativamente pouco, pois sua função é fornecer conectividade IP básica entre máquinas físicas. O underlay nada sabe sobre os serviços, clientes ou inquilinos que são executados sobre ele — ele apenas precisa entregar pacotes de uma máquina para outra.
Um exemplo de Underlay pode ser:

IPv4+OSPF
IPv6+ISIS+BGP+L3VPN
L2+TRILL
L2+STP

A rede underlay é configurada de maneira clássica: CLI/GUIs/NETCONF.

Manual, por scripts, ferramentas proprietárias.

Mais detalhes sobre o underlay serão abordados no próximo artigo da série.

Overlay

Overlay é uma rede virtual de túneis estendida sobre o underlay, permitindo que VMs de um único cliente se comuniquem entre si, ao mesmo tempo que garantem isolamento de outros clientes.

Os dados do cliente são encapsulados em cabeçalhos de tunelamento para transmissão através da rede compartilhada.

Assim, VMs de um cliente (de um único serviço) podem se comunicar entre si via Overlay, mesmo sem perceber o caminho real que o pacote percorre.

Um exemplo de Overlay pode ser, como mencionei anteriormente:

túnel GRE
VXLAN
EVPN
L3VPN
GENEVE

A rede overlay é normalmente configurada e gerenciada através de um controlador central. A partir dele, a configuração, o Control Plane e o Data Plane são entregues aos dispositivos que cuidam do roteamento e encapsulamento do tráfego do cliente. Um pouco mais abaixo vamos entender isso através de exemplos.

Sim, isso é SDN em sua essência.

Existem duas abordagens fundamentalmente diferentes para a organização de uma rede Overlay:

Overlay com ToR
Overlay com o host

Overlay com ToR

Overlay pode começar no switch de acesso (ToR), que está no rack, como ocorre, por exemplo, no caso de uma fábrica VXLAN.

Este é um mecanismo testado ao longo do tempo em redes de ISP e todos os fornecedores de equipamentos de rede o suportam.

No entanto, nesse caso, o switch ToR deve ser capaz de separar diferentes serviços, e o administrador de rede deve, de certa forma, colaborar com os administradores de máquinas virtuais e fazer alterações (mesmo que automaticamente) na configuração dos dispositivos.

Aqui vou direcionar o leitor para o artigo sobre VxLAN no Habr nosso velho amigo @bormoglotx.
Nesta apresentação com a ENOG são descritas detalhadamente as abordagens para a construção de uma rede de DC com uma fábrica EVPN VXLAN.

E para uma imersão mais completa na realidade, você pode ler o livro da Cisco A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Nota que VXLAN é apenas um método de encapsulamento e a terminação dos túneis pode ocorrer não no ToR, mas no host, como acontece no caso do OpenStack, por exemplo.
No entanto, uma fábrica VXLAN, onde o overlay começa no ToR, é um dos designs estabelecidos para a rede overlay.

Overlay com o host

Outra abordagem é iniciar e terminar túneis nos hosts finais.
Neste caso, a rede (Underlay) permanece o mais simples e estática possível.
E o host realiza todas as encapsulações necessárias.

Para isso, é imprescindível executar um aplicativo especial nos hosts, mas vale a pena.

Primeiro, iniciar um cliente em uma máquina Linux é mais fácil ou, digamos, — totalmente possível — enquanto no switch, é provável que você tenha que recorrer a soluções SDN proprietárias, o que vai contra a ideia de multi-vendor.

Em segundo lugar, o switch ToR neste caso pode ser mantido o mais simples possível, tanto em termos de Control Plane quanto de Data Plane. De fato — com o controlador SDN, ele não precisa se comunicar, e não precisa armazenar redes/ARP de todos os clientes conectados — basta conhecer o endereço IP da máquina física, o que facilita muito as tabelas de comutação/routing.

Na série ADSM, escolho a abordagem de overlay a partir do host — a partir de agora, falaremos apenas sobre isso e não voltaremos à fábrica VXLAN.

É mais fácil considerar exemplos. E como cobaia, vamos usar a plataforma SDN OpenSource OpenContrail, agora conhecida como Tungsten Fabric.

No final do artigo, apresentarei algumas reflexões sobre a analogia com OpenFlow e OpenvSwitch.

Tomando como exemplo o Tungsten Fabric

Em cada máquina física, existe vRouter — um roteador virtual que conhece as redes conectadas a ele e a quais clientes elas pertencem — essencialmente — um roteador PE. Para cada cliente, ele mantém uma tabela de roteamento isolada (leia-se VRF). E o vRouter, de fato, realiza o tunelamento Overlay.

Um pouco mais sobre o vRouter — no final do artigo.

Cada VM, localizada no hipervisor, se conecta ao vRouter desta máquina através de interface TAP.

TAP — Terminal Access Point — uma interface virtual no núcleo do Linux, que permite interações de rede.

Se houver várias redes atrás do vRouter, para cada uma delas é criada uma interface virtual, que recebe um endereço IP — esse será o endereço do gateway padrão.
Todas as redes de um cliente são colocadas em um VRF (uma tabela), as diferentes — em tabelas distintas.
Faço aqui uma ressalva de que nem tudo é tão simples, e encaminho o leitor curioso para o final do artigo..

Para que os vRouters possam se comunicar entre si, e, consequentemente, as VMs localizadas atrás deles, eles trocam informações de roteamento através do controlador SDN..

Para sair para o mundo externo, existe um ponto de saída da matriz — o gateway da rede virtual VNGW — Virtual Network GateWay (termo meu).

Agora vejamos exemplos de comunicações — e ficará claro.

Comunicação dentro de uma única máquina física

VM0 deseja enviar um pacote para a VM2. Suponhamos por enquanto que estas sejam VMs de um único cliente.

Data Plane

A VM-0 possui uma rota padrão para sua interface eth0. O pacote é enviado para lá.
Esta interface eth0 está, na verdade, conectada virtualmente ao roteador virtual vRouter através da interface TAP tap0.
O vRouter analisa em qual interface o pacote chegou, ou seja, a qual cliente (VRF) ele pertence, e compara o endereço do destinatário com a tabela de roteamento desse cliente.
Ao descobrir que o destinatário está na mesma máquina por outra porta, o vRouter simplesmente envia o pacote para ele sem cabeçalhos adicionais — para isso, já existe um registro ARP no vRouter.

Neste caso, o pacote não chega à rede física — ele foi roteado dentro do vRouter.

Control Plane

O hipervisor, ao iniciar uma máquina virtual, informa a ela:

Seu próprio endereço IP.
A rota padrão — através do endereço IP do vRouter nesta rede.

O hipervisor informa ao vRouter através de uma API especial:

Que é necessário criar uma interface virtual.
Qual Virtual Network ela (a VM) precisa criar.
A qual VRF vincular sua (VN).
O registro ARP estático para esta VM — qual interface possui seu endereço IP e a qual endereço MAC ele está associado.

E mais uma vez, o procedimento real de interação é simplificado em prol da compreensão do conceito.

Assim, todas as VMs de um cliente nesta máquina vRouter são vistas como redes diretamente conectadas e podem roteá-las entre si.

No entanto, VM0 e VM1 pertencem a clientes diferentes, portanto, estão em tabelas vRouter diferentes.

Se poderão se comunicar diretamente depende das configurações do vRouter e do design da rede.
Por exemplo, se as VMs de ambos os clientes usam endereços públicos, ou se o NAT ocorre no próprio vRouter, é possível realizar o roteamento direto no vRouter.

Na situação oposta, é possível a sobreposição de espaços de endereço — é necessário passar por um servidor NAT para obter um endereço público — isso se assemelha à saída para redes externas, conforme mencionado abaixo.

Comunicação entre VMs localizadas em diferentes máquinas físicas

Data Plane

O início é exatamente o mesmo: VM-0 envia um pacote para o destinatário VM-7 (172.17.3.2) usando seu padrão.
O vRouter o recebe e, desta vez, vê que o destinatário está em outra máquina e acessível através do túnel Tunnel0.
Primeiro, ele adiciona uma etiqueta MPLS, identificando a interface remota, para que do outro lado o vRouter possa determinar onde colocar este pacote sem ciclos adicionais.
O Tunnel0 tem origem 10.0.0.2 e destinatário: 10.0.1.2.
O vRouter adiciona cabeçalhos GRE (ou UDP) e um novo IP ao pacote original.
Na tabela de roteamento, o vRouter tem uma rota padrão através do endereço ToR1 10.0.0.1. E é para lá que ele o envia.
ToR1, como parte da rede Underlay, sabe (por exemplo, através do OSPF) como chegar a 10.0.1.2 e envia o pacote pela rota. Observe que aqui ocorre ECMP. Na ilustração, há dois next hops, e diferentes fluxos serão alocados a eles com base no hash. Em uma verdadeira fábrica, pode haver mais de 4 next hops.
Nesse processo, não é necessário saber o que está sob o cabeçalho IP externo. Ou seja, na verdade, sob o IP pode haver um empilhamento de IPv6 sobre MPLS sobre Ethernet sobre MPLS sobre GRE e assim por diante.
Assim, do lado receptor, o vRouter remove o GRE e pelo rótulo MPLS entende para qual interface este pacote deve ser enviado, desembrulha-o e o envia em sua forma original ao destinatário.

Control Plane

Ao iniciar a máquina, tudo o que foi descrito acima ocorre.

E mais o seguinte:

Para cada cliente, o vRouter atribui uma etiqueta MPLS. Esta é uma etiqueta de serviço L3VPN, pela qual os clientes serão separados dentro de uma única máquina física.
Na verdade, a etiqueta MPLS é sempre atribuída pelo vRouter, pois não se sabe de antemão se a máquina irá interagir apenas com outras máquinas atrás do mesmo vRouter, e isso provavelmente nem é o caso.
O vRouter estabelece uma conexão com o controlador SDN através do protocolo BGP (ou um semelhante — no caso do TF, é XMPP 0_o).
Através dessa sessão, o vRouter informa ao controlador SDN as rotas para as redes conectadas:
- Endereço da rede
- Método de encapsulação (MPLSoGRE, MPLSoUDP, VXLAN)
- Etiqueta MPLS do cliente
- Seu endereço IP como nexthop
O controlador SDN recebe essas rotas de todos os vRouters conectados e as reflete para outros. Ou seja, ele atua como um Route Reflector.

O mesmo acontece na direção oposta.

A Overlay pode mudar a qualquer minuto. É assim que isso acontece em nuvens públicas, quando os clientes frequentemente ligam e desligam suas máquinas virtuais.

O controlador central assume todas as complexidades de manter a configuração e controlar as tabelas de comutação/roteamento no vRouter.

Falando de forma geral, o controlador se conecta a todos os vRouters via BGP (ou um protocolo semelhante) e simplesmente transmite as informações de rota. O BGP, por exemplo, já tem Address-Family para transmitir o método de encapsulação. MPLS-in-GRE ou MPLS-in-UDP.

Nesse processo, a configuração da rede Underlay não muda de forma alguma, que por sinal é muito mais difícil de automatizar, e é mais fácil quebrá-la com um movimento desajeitado.

Saída para o mundo exterior

Em algum momento, a simulação deve terminar, e é necessário sair do mundo virtual para o real. E é necessário um gateway de telefone.

Existem duas abordagens:

Um roteador de hardware é instalado.
Um appliance que realiza funções de roteador é iniciado (sim, após o SDN, também encontramos o VNF). Vamos chamá-lo de gateway virtual.

A vantagem da segunda abordagem é a escalabilidade horizontal barata — se falta potência, inicia-se outra máquina virtual com um gateway. Em qualquer máquina física, sem a necessidade de procurar por racks livres, unidades, fornecimento de energia, comprar o hardware, transportá-lo, instalá-lo, conectar, configurar e depois ainda ter que trocar componentes com falhas.
No entanto, as desvantagens do gateway virtual são que a unidade do roteador físico é, sem dúvida, muito mais poderosa do que uma virtual com múltiplos núcleos, e seu software, ajustado à sua própria base de hardware, funciona de maneira significativamente mais estável (não). É difícil negar o fato de que o complexo de hardware e software simplesmente funciona, exigindo apenas configuração, enquanto a inicialização e manutenção do gateway virtual exigem engenheiros experientes.

De uma perna, o gateway olha para a rede virtual Overlay, como uma Máquina Virtual comum, e pode interagir com todas as outras VMs. Ao mesmo tempo, pode terminar redes de todos os clientes e, соответственно, realizar o roteamento entre elas.

Com a outra perna, o gateway observa a rede troncal e sabe como acessar a Internet.

Data Plane

Ou seja, o processo é assim:

VM-0, tendo o padrão ainda no vRouter, envia um pacote com um destinatário no mundo externo (185.147.83.177) para a interface eth0.
vRouter recebe esse pacote e faz uma busca do endereço de destino na tabela de roteamento — encontra a rota padrão pelo gateway VNGW1 através do Tunnel 1.
Ele também vê que este é um túnel GRE com SIP 10.0.0.2 e DIP 10.0.255.2, e além disso, primeiro precisa anexar o rótulo MPLS deste cliente, que o VNGW1 espera.
vRouter empacota o pacote original nos cabeçalhos MPLS, GRE e um novo IP e o envia para o endereço ToR1 10.0.0.1 por padrão.
A rede subjacente entrega o pacote ao gateway VNGW1.
O gateway VNGW1 remove os cabeçalhos de tunelamento GRE e MPLS, vê o endereço de destino, consulta sua tabela de roteamento e percebe que está indo para a Internet — ou seja, através do Full View ou Default. Realiza a tradução NAT, se necessário.
Do VNGW até o border pode haver uma rede IP comum, o que é pouco provável.
Pode ser uma rede MPLS clássica (IGP+LDP/R RSVP TE), pode ser a fábrica reversa com BGP LU ou um túnel GRE do VNGW até o border através da rede IP.
De qualquer forma, VNGW1 realiza as encapsulações necessárias e envia o pacote original em direção ao border.

O tráfego na direção oposta passa pelos mesmos passos na ordem inversa.

O border entrega o pacote até o VNGW1
Esse o desarma, observa o endereço do destinatário e vê que este está acessível através do túnel Tunnel1 (MPLSoGRE ou MPLSoUDP).
Consequentemente, anexa um rótulo MPLS, um cabeçalho GRE/UDP e um novo IP e envia para seu ToR3 10.0.255.1.
O endereço de destino do túnel é o IP do vRouter, atrás do qual está a VM alvo — 10.0.0.2.
A rede subjacente entrega o pacote ao vRouter necessário.
O vRouter alvo remove GRE/UDP, determina a interface pela etiqueta MPLS e envia o pacote IP puro para sua interface TAP, vinculada ao eth0 da VM.

Control Plane

VNGW1 estabelece uma vizinhança BGP com o controlador SDN, do qual recebe toda a informação de roteamento sobre os clientes: qual IP (vRouter) está associado a qual cliente e com qual etiqueta MPLS ele é identificado.

Da mesma forma, ele informa ao controlador SDN a rota padrão com a etiqueta desse cliente, apontando-se como o próximo salto. E então essa padrão chega aos vRouters.

No VNGW, normalmente ocorre a agregação de rotas ou a tradução NAT.

E na outra direção, na sessão com as bordas ou Route Reflectors, ele entrega exatamente essa rota agregada. E deles recebe a rota padrão, seja Full-View ou algo mais.

No que diz respeito à encapsulação e troca de tráfego, o VNGW não se difere do vRouter.
Se ampliarmos um pouco a área, podemos adicionar outros dispositivos de rede ao VNGW e aos vRouters, como firewalls, farms de limpeza ou enriquecimento de tráfego, IPS e assim por diante.

E com a criação sequencial de VRF e o anúncio correto das rotas, é possível forçar o tráfego a se mover como você gostaria, o que é chamado de Service Chaining.

Ou seja, também aqui o controlador SDN atua como Route Reflector entre VNGW, vRouters e outros dispositivos de rede.

Mas, de fato, o controlador ainda fornece informações sobre ACL e PBR (Policy Based Routing), forçando fluxos de tráfego individuais a seguir caminhos diferentes do que o roteiro determina.

FAQ

Por que você sempre faz a observação GRE/UDP?

Bem, na verdade, isso pode ser considerado específico para o Tungsten Fabric — pode-se completamente ignorar.

Mas se considerarmos, o próprio TF, mesmo quando era OpenContrail, suportava ambas as encapsulações: MPLS em GRE e MPLS em UDP.

O UDP é bom porque no Port de Origem no seu cabeçalho é muito fácil codificar uma função hash a partir dos IP+Proto+Port iniciais, permitindo balanceamento.

No caso do GRE, infelizmente, existem apenas os cabeçalhos IP e GRE externos, que são iguais para todo o tráfego encapsulado e não se fala em balanceamento — poucos podem olhar tão profundamente dentro do pacote.

Até algum tempo atrás, os roteadores, se conseguiam criar túneis dinâmicos, era apenas em MPLSoGRE, e só recentemente aprenderam a fazer isso em MPLSoUDP. Portanto, é necessário sempre fazer uma observação sobre a possibilidade de duas encapsulações diferentes.

Para ser justo, vale ressaltar que o TF suporta plenamente a conectividade L2 por meio de VXLAN.

Você prometeu traçar paralelos com o OpenFlow.
Realmente, isso se impõe. O vSwitch no mesmo OpenStack faz coisas bastante semelhantes, utilizando VXLAN, que, por sinal, também possui cabeçalho UDP.

No Data Plane, eles funcionam de maneira bastante semelhante, enquanto o Control Plane é bastante diferente. O Tungsten Fabric usa XMPP para entregar informações sobre rotas ao vRouter, enquanto no OpenStack, o OpenFlow é utilizado.

Você poderia falar um pouco mais sobre o vRouter?
Ele se divide em duas partes: vRouter Agent e vRouter Forwarder.

O primeiro é iniciado no espaço do usuário do sistema operacional host e se comunica com o controlador SDN, trocando informações sobre rotas, VRF e ACL.

O segundo implementa o Data Plane — normalmente no espaço do kernel, mas pode ser executado em SmartNICs — placas de rede com CPU e um chip de comutação programável separado, o que permite descarregar a carga da CPU da máquina host, tornando a rede mais rápida e previsível.

Outro cenário possível é que o vRouter seja um aplicativo DPDK no espaço do usuário.

O vRouter Agent aplica as configurações no vRouter Forwarder.

O que é uma Rede Virtual?
Mencionei no início do artigo sobre VRF, que cada inquilino está vinculado ao seu próprio VRF. E se isso foi suficiente para uma compreensão superficial do funcionamento da rede overlay, na próxima iteração, é necessário fazer esclarecimentos.

Normalmente, nas mecânicas de virtualização, a entidade Rede Virtual (pode-se considerar isso um nome próprio) é introduzida separadamente dos clientes/tenants/máquinas virtuais — uma entidade completamente independente. E essa Rede Virtual pode ser conectada a um tenant, a outro, a dois, a qualquer lugar. Assim, por exemplo, realiza-se o Service Chaining, quando o tráfego precisa passar por determinados nós em uma sequência específica, simplesmente criando e vinculando Redes Virtuais na ordem correta.

Portanto, não há um correspondente direto entre a Rede Virtual e o tenant.

Conclusão

Esta é uma descrição bastante superficial do funcionamento de uma rede virtual com overlay a partir do host e do controlador SDN. Mas qualquer que seja a plataforma de virtualização que você escolher hoje, ela funcionará de forma semelhante, seja VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ou Juniper Contrail. Elas diferem em tipos de encapsulamento e cabeçalhos, protocolos de entrega de informações aos dispositivos de rede finais, mas o princípio da rede overlay programável, que opera sobre uma rede subjacente relativamente simples e estática, permanece o mesmo.
Pode-se dizer que, atualmente, o SDN baseado em rede overlay venceu na área de criação de nuvens privadas. No entanto, isso não significa que o OpenFlow não tenha espaço no mundo moderno — ele é usado no OpenStack e no mesmo VMWare NSX, e, pelo que sei, é utilizado pelo Google para configurar a rede subjacente.

Um pouco abaixo, forneci links para materiais mais detalhados, caso queira estudar o assunto mais a fundo.

E quanto ao nosso Underlay?

Na verdade, nada. Ele não mudou ao longo do tempo. Tudo o que precisa fazer em caso de um overlay a partir do host é atualizar rotas e ARP conforme os vRouter/VNGW aparecem e desaparecem e transferir pacotes entre eles.

Vamos formular uma lista de requisitos para a rede Underlay.

Deve ser capaz de usar algum protocolo de roteamento, no nosso caso — BGP.
Deve ter banda larga, preferencialmente sem sobrecarga, para que pacotes não sejam perdidos devido a congestionamentos.
Suportar ECMP — uma parte essencial da fábrica.
Ser capaz de garantir QoS, incluindo coisas complexas, como ECN.
Suportar NETCONF — uma preparação para o futuro.

Dediquei muito pouco tempo ao funcionamento da própria rede Underlay aqui. Isso porque, nos próximos capítulos, será nela que nos concentraremos, enquanto o Overlay será tratado apenas de passagem.

É evidente que estou limitando a todos nós gravemente, usando como exemplo uma rede de DC construída sobre a fábrica de Clouza com roteamento IP puro e um overlay a partir do host.

No entanto, estou certo de que qualquer rede que tenha um design pode ser descrita em termos formais e automatizada. Eu só busco entender as abordagens de automação, e não confundir a todos resolvendo a tarefa de forma geral.

Dentro do ADMS, Román Gorge e eu planejamos publicar uma edição separada sobre a virtualização de capacidades computacionais e sua interação com a virtualização de rede. Fique conectado.

Links Úteis

Arquitetura Tungsten Fabric.
sobre:cloud. 6 horas sobre Yandex.Cloud, que também aborda a rede virtual no TF.
O que é Open vSwitch?
Introdução ao VxLAN.
RFC 7348. Rede Local Virtual eXtensível (VXLAN): Um Framework para Sobrepor Redes Virtualizadas de Camada 2 sobre Redes de Camada 3.
Abordagem Scaleway para a Fabrica VXLAN EVPN. Aqui, falamos sobre toda a rede do datacenter, incluindo Underlay, Overlay, abordagens de multi-homing e gerenciamento.

Obrigado

Roman Gorge — ex-apresentador do podcast linkmeup, e agora especialista em plataformas de nuvem. Agradecimentos pelos comentários e correções. E esperamos em breve seu artigo mais profundo sobre virtualização.
Alexander Shalimov — meu colega e especialista em desenvolvimento de redes virtuais. Agradecimentos pelos comentários e correções.
Valentin Sinitsyn — meu colega e especialista em Tungsten Fabric. Agradecimentos pelos comentários e correções.
Artem Chernobay — ilustrador do linkmeup. Agradecimentos pela contribuição.
Alexander Limonov. Pela meme "automato".

Fonte: habr.com