---
title: "A conta invisível de rodar SDN no kernel do Linux antes de apelar para silício dedicado"
author: "Pedro Dalben"
date: "2026-10-10T11:03:50Z"
category: "DevOps & Cloud"
reading_time: "6 min"
canonical: "https://pedrodalben.com.br/blog/a-conta-invisivel-de-rodar-sdn-no-kernel-do-linux-antes-de-apelar-para-silicio-dedicado"
---

# A conta invisível de rodar SDN no kernel do Linux antes de apelar para silício dedicado

> Implementar redes virtuais com VXLAN e ferramentas nativas do Linux reduz custos, mas transfere o preço do roteamento para a CPU do hipervisor.

**Autor:** Pedro Dalben (CTO no Integrar Plus)  
**Publicado em:** 10 de October de 2026  
**URL Canônica Oficial:** [https://pedrodalben.com.br/blog/a-conta-invisivel-de-rodar-sdn-no-kernel-do-linux-antes-de-apelar-para-silicio-dedicado](https://pedrodalben.com.br/blog/a-conta-invisivel-de-rodar-sdn-no-kernel-do-linux-antes-de-apelar-para-silicio-dedicado)  

---


Toda vez que um provedor de infraestrutura decide expor as entranhas da sua pilha de rede, a reação da comunidade se divide em dois extremos previsíveis. De um lado, engenheiros acostumados com ambientes corporativos torcem o nariz e apontam que empilhar bridges, namespaces, VXLAN e regras de filtragem no próprio kernel do host é uma heresia que destrói a latência. Do outro, defensores do software livre comemoram que dá para construir uma nuvem inteira sem pagar pedágio para caixas proprietárias de fabricantes tradicionais.

A discussão técnica recente sobre a pilha de rede da Hetzner Cloud escancarou esse choque de realidade. O modelo deles segue a filosofia de empurrar os pontos terminais de túneis (os chamados VTEPs) diretamente para os hipervisores em vez de delegar essa carga aos switches físicos do topo do rack. Para quem opera servidores dedicados ou frotas de VPS para rodar aplicações web, a escolha entre abstração pura em software ou aceleração em hardware nunca é puramente ideológica. Ela define exatamente onde a sua aplicação vai engasgar quando a carga subir.

O argumento dos críticos mais severos tem fundamento técnico real. Quando você coloca a terminação da VXLAN no kernel do hipervisor usando módulos padrão do Linux, cada pacote que sai de uma máquina virtual percorre um caminho longo. O pacote sai do espaço de usuário do guest, cruza o kernel do guest, passa pela interface virtual conectada ao host, sofre encapsulamento no kernel do host e só então atinge a placa de rede física. Se a agregação de links estiver com algoritmos de balanceamento mal ajustados ou se o escalonamento de interrupções de CPU falhar, esse trajeto gera entrega de pacotes fora de ordem, sobrecarga severa de processamento e queda vertiginosa na taxa de transferência útil.

Por outro lado, quem defende a simplicidade dessa arquitetura argumenta que BGP com EVPN e VXLAN rodando direto no Linux virou padrão moderno da indústria por um motivo simples: inspecionabilidade. Se um túnel falha, você não precisa de um console obscuro nem de um firmware fechado para entender o problema. Ferramentas comuns como comandos de manipulação de rotas, filtros de pacotes e analisadores de tráfego mostram exatamente o que está acontecendo em cada interface virtual.

Eu discordo da visão de que rodar SDN puramente no kernel seja um erro de projeto amador. Essa postura ignora o modelo econômico da computação acessível. Se todo provedor precisasse equipar cada servidor com SmartNICs caras ou switches com suporte avançado a tabelas gigantescas de roteamento por hardware, o preço de uma instância básica dispararia. O uso de componentes nativos do Linux viabilizou a existência de nuvens com custo muito inferior aos gigantes tradicionais.

No entanto, também não compro o otimismo cego de quem acha que o Linux padrão resolve qualquer volume de rede sem cobrar pedágio. O problema começa quando você tenta rodar tráfego pesado de banco de dados ou sincronização intensa de arquivos sobre essas redes privadas virtuais. 

Em cargas típicas de sistemas web, a maior parte do tempo do processador é gasta em regras de negócio no servidor de aplicação. O tráfego de rede é composto por conexões HTTP moderadas e consultas pontuais a instâncias do PostgreSQL. Nesse cenário, o overhead de encapsular pacotes em software é irrelevante. A CPU do servidor físico tem folga para processar as interrupções de rede sem atrapalhar as máquinas virtuais vizinhas.

O colapso dessa abordagem ocorre sob duas condições específicas: pacotes pequenos por segundo em altíssimo volume e transferências de grande volume que esbarram em configurações de MTU.

Quando você adiciona o cabeçalho de uma VXLAN sobre um pacote Ethernet, cinquenta bytes extras entram na equação. Se a rede virtual mantém a unidade máxima de transmissão em 1500 bytes sem que a interface física subjacente suporte quadros maiores (jumbo frames), o pacote é fragmentado. Em transferências contínuas de backup ou replicação de bancos, a fragmentação no nível de software faz a utilização de CPU disparar e a velocidade efetiva desabar para patamares ridículos, mesmo em conexões com gigabits de largura de banda nominal.

```text
Caminho do pacote em SDN no host:
Guest VM (App -> Kernel -> VirtIO)
       ↓
Host OS (TAP -> Linux Bridge -> VXLAN Encapsulation -> Netfilter)
       ↓
Physical NIC (Driver -> Anel de TX -> Cabo)
```

Além disso, o custo de interrupções por segundo escala com a quantidade de pacotes, não com o total de gigabytes trafegados. Um fluxo constante de milhares de consultas curtas por segundo a um banco relacional gera uma tempestade de transições de contexto no hipervisor. É nesse ponto que a falta de aceleração de hardware dói. Placas com descarregamento de encapsulamento conseguem empacotar e desempacotar frames diretamente nos buffers da controladora, liberando os núcleos da máquina física para a computação real.

Existe uma lição prática direta para quem administra servidores próprios ou contrata provedores focados em custo-benefício:

Primeiro, nunca trate a rede privada de um provedor econômico como se fosse um barramento de memória local. Se você planeja mover dumps pesados de bancos de dados ou tráfego de replicação física entre instâncias, verifique se a MTU da interface virtual está ajustada para acomodar o encapsulamento sem fragmentação. Configurar a interface interna para 1450 bytes costuma evitar desastres silenciosos quando o host não suporta jumbo frames externos.

Segundo, separe mentalmente tráfego de controle de tráfego de dados massivos. Usar a rede privada em software para conectar a aplicação ao banco de dados funciona muito bem até determinado teto de conexões. Ultrapassado esse teto, se o volume de transações por segundo exigir latências consistentes na casa dos microssegundos, o Linux em software no hipervisor vai demonstrar seus limites de jitter.

Terceiro, entenda que a ausência de recursos complexos de rede muitas vezes é uma vantagem operacional. Pilhas baseadas em ferramentas padrão do ecossistema Linux falham de maneiras previsíveis. Quando uma falha de DNS ou uma tabela de vizinhança quebra, o diagnóstico depende de conceitos consolidados de redes Unix, não de contratos de suporte corporativo que demoram dias para analisar um relatório de diagnóstico.

A decisão de construir redes virtuais com o que o sistema operacional já oferece nativamente não é perfeita nem definitiva. Ela representa um compromisso deliberado entre preço baixo e eficiência bruta de pacotes por segundo. Saber onde essa linha é cruzada é a diferença entre manter um ambiente estável e barato ou culpar injustamente o banco de dados por uma lentidão que nasceu na fila de processamento do hipervisor.

## Fontes

- [https://www.hetzner.com/blog/the-hetzner-cloud-network-stack-history-and-technical-overview/](https://www.hetzner.com/blog/the-hetzner-cloud-network-stack-history-and-technical-overview/)