Bridge de Rede é um dispositivo (físico ou virtual) que opera na camada 2 do modelo OSI (Data Link) e conecta dois ou mais segmentos de rede encaminhando quadros Ethernet com base no endereço MAC de destino. No universo Linux, virtualização e containers, a bridge deixou de ser um equipamento físico e passou a ser uma abstração de software essencial para conectar VMs, containers e sub-redes lógicas à rede física.
TL;DR
- O que é: dispositivo camada 2 (OSI) que encaminha quadros Ethernet aprendendo MAC addresses e associando cada MAC a uma porta.
- Por que importa: é a base de KVM/QEMU, Docker, Kubernetes CNI e VMware vSwitch — sem bridge, VMs e containers não conseguem falar com a rede física.
- Quando usar: sempre que precisar conectar máquinas virtuais ou containers à mesma sub-rede de hosts físicos, ou segmentar redes por VLAN em servidores Linux.
Como funciona uma Bridge de Rede?
Bridge é um forwarder de camada 2 que aprende endereços MAC dinamicamente e encaminha quadros seletivamente entre portas.
Ao receber um quadro Ethernet, a bridge inspeciona o MAC de origem e o registra em sua tabela de encaminhamento (FDB — Forwarding Database), associando-o à porta de entrada. Em seguida, consulta o MAC de destino: se conhecido, envia o quadro somente pela porta correspondente; se desconhecido, broadcast ou multicast, faz flooding para todas as portas exceto a de origem. Segundo a Linux Kernel Documentation (2024), o aging time padrão de entradas na FDB no bridge do kernel Linux é 300 segundos.
Esse comportamento posiciona a bridge na camada 2 (Data Link) do modelo OSI, definida pelo padrão IEEE 802.1D. Diferente de roteadores (camada 3), bridges não modificam headers IP nem decrementam TTL — apenas encaminham frames intactos, o que torna sua operação transparente para protocolos superiores.
Bridge vs Switch vs Router vs Hub
Entender a diferença entre esses quatro dispositivos evita erros graves de arquitetura de rede. Segundo Cisco (2023), a distinção principal está na camada OSI em que cada equipamento opera:
| Dispositivo | Camada OSI | Aprende MAC? | Granularidade | Uso típico |
|---|---|---|---|---|
| Hub | Camada 1 (Física) | Não | Repete para todas as portas | Obsoleto — redes legadas |
| Bridge | Camada 2 (Data Link) | Sim | 2 a poucas portas (software/hardware) | Virtualização, Docker, Linux |
| Switch | Camada 2 (às vezes L3) | Sim | Dezenas a centenas de portas (ASIC) | LAN corporativa, datacenter |
| Router | Camada 3 (Rede) | Não (usa IP) | Encaminhamento por rota IP | Interconexão de sub-redes, WAN |
Na prática, um switch moderno é uma bridge multiporta implementada em ASIC (Application-Specific Integrated Circuit), capaz de encaminhamento em wire-speed. Já a bridge de software do Linux é mais lenta, mas flexível — pode ter VLAN awareness, integração com netfilter e uso em cenários dinâmicos como containers.
Bridge no Linux: brctl e bridge (iproute2)
Bridge no Linux é um módulo do kernel (bridge.ko) gerenciado historicamente por brctl e hoje por bridge do pacote iproute2.
Segundo a Red Hat (2024), o comando ‘brctl’ foi marcado como legado desde o RHEL 7 e substituído por ‘ip link’ e ‘bridge’ do iproute2, que suportam recursos modernos como VLAN filtering e MDB (Multicast Database). Ainda assim, muitos tutoriais e scripts em produção usam brctl.
Exemplos de comandos essenciais:
- Criar bridge: ‘ip link add name br0 type bridge’ (moderno) ou ‘brctl addbr br0’ (legado)
- Adicionar interface: ‘ip link set eth0 master br0’ ou ‘brctl addif br0 eth0’
- Ativar bridge: ‘ip link set br0 up’
- Ver forwarding table: ‘bridge fdb show’ ou ‘brctl showmacs br0’
- Habilitar VLAN awareness: ‘ip link set br0 type bridge vlan_filtering 1’
Distribuições modernas como Ubuntu 22.04+ usam Netplan para configuração declarativa de bridges via YAML, enquanto RHEL/CentOS/Rocky adotam NetworkManager com ‘nmcli con add type bridge’.
Bridge em virtualização (KVM/QEMU/libvirt)
Em hypervisors baseados em KVM/QEMU, a bridge é o método mais comum para dar acesso direto à rede física para máquinas virtuais. Segundo a documentação do libvirt (2024), o modo ‘bridged networking’ faz cada VM aparecer como um host independente na LAN, obtendo IP via DHCP do roteador físico como se fosse uma máquina bare-metal.
O fluxo típico envolve:
- Criar uma bridge br0 no host e adicionar a interface física (eth0/enp0s3) como slave
- Definir a rede da VM no XML do libvirt apontando para a bridge br0
- QEMU cria um dispositivo TAP (vnetX) e o conecta à bridge
- A VM enxerga sua interface como uma NIC física conectada ao switch
Alternativas incluem Open vSwitch (OVS), uma bridge programável com suporte a OpenFlow, e o modo macvtap, que evita a bridge tradicional criando pseudo-interfaces atreladas ao MAC do host. VMware ESXi usa conceito equivalente com vSwitch e Distributed vSwitch.
Bridge no Docker
Segundo a Docker Documentation (2024), o driver de rede padrão do Docker é o bridge, que cria automaticamente uma bridge Linux chamada ‘docker0’ no host durante a instalação. Cada container recebe uma interface veth conectada a essa bridge, com IP privado (geralmente 172.17.0.0/16).
Características do driver bridge do Docker:
- Isolamento: containers na mesma bridge se comunicam por IP, mas ficam isolados de containers em outras bridges
- Port mapping: exposição de serviços ao host via regras iptables/nftables geradas pelo Docker (docker-proxy ou DNAT)
- DNS interno: em user-defined bridges (criadas com ‘docker network create’), containers se resolvem por nome via DNS embutido
- NAT saída: tráfego dos containers para a Internet passa por MASQUERADE no host
Para produção, muitos preferem drivers como overlay (Swarm/Kubernetes) ou macvlan (que atribui MAC único a cada container, sem NAT), mas o bridge continua sendo o default para uso local e desenvolvimento.
Bridge com VLAN Tagging (802.1Q)
Bridges Linux modernas suportam o padrão IEEE 802.1Q para VLAN tagging, permitindo segmentar tráfego lógico em uma mesma bridge física. Isso é essencial quando o servidor recebe múltiplas VLANs via trunk do switch de núcleo.
Segundo IEEE 802.1Q (padrão atualizado 2022), o header VLAN adiciona 4 bytes ao quadro Ethernet, incluindo um VID (VLAN ID) de 12 bits (0-4094). No Linux, você habilita VLAN awareness na bridge e associa portas a VLANs específicas:
- ‘ip link set br0 type bridge vlan_filtering 1’ — habilita filtragem
- ‘bridge vlan add dev eth0 vid 10 pvid untagged’ — porta access na VLAN 10
- ‘bridge vlan add dev eth1 vid 10 tagged’ — porta trunk com tag VLAN 10
- ‘bridge vlan show’ — inspecionar configuração
Exemplos práticos B2B brasileiros
Caso 1 — Provedor de hospedagem WordPress em São Paulo: um servidor dedicado Dell PowerEdge com Proxmox VE hospeda 40 VMs de clientes. Cada VM precisa aparecer como um servidor real na LAN /24 do datacenter, com IP público próprio. A equipe configura vmbr0 como bridge conectada à NIC eno1, e cada VM recebe uma interface virtio conectada à bridge, com IPs alocados pelo painel do provedor.
Caso 2 — Startup de fintech usando Kubernetes: um cluster on-premises em Porto Alegre usa CNI Flannel com backend host-gw, que cria uma bridge cni0 em cada nó e distribui rotas entre nós. Pods do mesmo namespace se comunicam via bridge local, e a comunicação inter-nó ocorre por roteamento direto sem encapsulamento, ganhando 15-20% de throughput comparado a VXLAN.
Caso 3 — Laboratório de desenvolvimento em agência digital: desenvolvedores usam Vagrant + libvirt para simular ambientes de cliente, com múltiplas VMs (LAMP, Redis, Nginx) conectadas a uma bridge isolada ‘labbr0’ sem NAT, permitindo testar comunicação inter-serviço em rede plana antes de fazer deploy em cloud.
Spanning Tree Protocol (STP) em Bridges
Quando múltiplas bridges são interconectadas, loops físicos podem causar tempestades de broadcast. O Spanning Tree Protocol (STP), definido em IEEE 802.1D, elege uma root bridge e bloqueia portas redundantes formando uma topologia lógica em árvore, sem loops.
Segundo IEEE (2024), o Rapid STP (RSTP, 802.1w) reduziu o tempo de convergência de 30-50 segundos do STP clássico para 1-3 segundos, tornando-se padrão de facto. Conceitos importantes:
- BPDU (Bridge Protocol Data Unit): mensagens trocadas entre bridges para eleger root e calcular caminho
- Root bridge: a bridge com menor bridge ID (prioridade + MAC)
- Custo: baseado em largura de banda (10 Gbps = custo 2, 1 Gbps = custo 4)
- TCN (Topology Change Notification): notifica mudanças de topologia para flush da FDB
No Linux, habilitar STP na bridge é simples: ‘ip link set br0 type bridge stp_state 1’ ou ‘brctl stp br0 on’.
Ferramentas para monitorar Bridges
Diagnosticar problemas em bridges requer inspecionar tabelas, quadros e contadores. Ferramentas essenciais:
- bridge fdb show: exibe a tabela de encaminhamento (MAC + porta + VLAN)
- bridge link show: lista interfaces slave da bridge
- brctl showmacs br0: equivalente legado da FDB
- tcpdump -i br0: captura tráfego passando pela bridge (só quadros forwarded, não os de entrada)
- tshark: análise avançada com filtros por VLAN, MAC, protocolo
- ip -s link show br0: contadores de pacotes, bytes, erros e drops
- ethtool -S eth0: estatísticas por interface slave
Erros comuns em Bridge de Rede
- Loop de camada 2 sem STP: conectar duas bridges por dois cabos sem habilitar STP causa broadcast storm que satura a rede em segundos. Sempre habilite STP em bridges com potencial de loop.
- MTU inconsistente entre bridge e interfaces: se a bridge tem MTU 1500 e uma interface slave tem MTU 9000 (jumbo frames), pacotes grandes são descartados silenciosamente. Padronize MTU em toda a bridge.
- Promiscuous mode desligado em NICs de VM: em ambientes com múltiplos MACs por interface (VMs, containers), a NIC física precisa estar em modo promíscuo para aceitar frames destinados a MACs desconhecidos, senão a bridge nunca vê o tráfego.
- Esquecer de habilitar IP forwarding: ao usar bridge para roteamento entre sub-redes, ‘net.ipv4.ip_forward=1’ precisa estar ativo, senão o kernel descarta pacotes que precisariam ser roteados.
- MAC learning ilimitado: em bridges com muitas VMs criadas dinamicamente, a FDB pode crescer indefinidamente. Configure ‘bridge link set dev eth0 fdb_max 512’ para limitar por porta e evitar exhaustion.
Como criar uma Bridge no Linux — passo a passo
- Instalar iproute2 e bridge-utils: ‘apt install iproute2 bridge-utils’ (Debian/Ubuntu) ou ‘dnf install iproute NetworkManager’ (RHEL/Rocky).
- Criar a bridge: ‘ip link add name br0 type bridge’ — cria interface br0 do tipo bridge.
- Adicionar interface física como slave: ‘ip link set eth0 master br0’ — vincula eth0 à bridge.
- Remover IP da interface física: ‘ip addr flush dev eth0’ — o IP passa para a bridge, não para a NIC.
- Atribuir IP à bridge: ‘ip addr add 192.168.1.10/24 dev br0’ e ‘ip route add default via 192.168.1.1’.
- Ativar bridge e interfaces: ‘ip link set br0 up’ e ‘ip link set eth0 up’.
- Persistir configuração: em Ubuntu, editar /etc/netplan/00-installer-config.yaml com bridges: br0 e aplicar com ‘netplan apply’. Em RHEL, usar ‘nmcli con add type bridge con-name br0 ifname br0’.
Bridge e a Shiftmind
A Shiftmind atua há mais de 12 anos gerenciando infraestrutura Linux, virtualização e redes para clientes B2B, com expertise profunda em configuração de bridges para KVM, Docker e ambientes multi-tenant. Nossos servidores dedicados são configurados com bridges otimizadas para hospedagem de múltiplas VMs isoladas, garantindo performance e segurança de rede.
Para clientes WordPress, oferecemos hospedagem WordPress em infraestrutura containerizada com Docker, isolando cada site em sua própria rede bridge e evitando cross-contamination. O time de suporte e manutenção WordPress monitora ativamente bridges, FDB overflow e loops de camada 2 nos servidores gerenciados.
Complementamos com proteção antivírus para websites integrada ao nível de rede e serviço completo de criação de sites WordPress hospedados em ambiente otimizado.
Perguntas frequentes sobre Bridge de Rede
Qual a diferença entre bridge e switch?
Ambos operam na camada 2 e encaminham quadros por MAC, mas o switch é uma bridge multiporta implementada em hardware ASIC, com dezenas a centenas de portas e throughput wire-speed. Bridges tradicionalmente tinham 2 portas em hardware, mas hoje o termo se refere principalmente a bridges de software no Linux (br0, docker0), usadas em virtualização e containers. Funcionalmente idênticos: switches são bridges otimizadas para alta densidade de portas.
Bridge funciona em qual camada do modelo OSI?
Bridge opera na camada 2 (Data Link) do modelo OSI, também conhecida como camada de enlace. Ela processa quadros Ethernet identificando dispositivos por endereço MAC (48 bits), sem tocar em headers IP ou portas TCP/UDP. Isso a torna transparente para camadas superiores — protocolos como IP, TCP, HTTPS funcionam normalmente sem saber que uma bridge está no caminho. O padrão que define bridges é o IEEE 802.1D.
Preciso de STP em bridges de virtualização?
Depende da topologia. Se sua bridge conecta apenas VMs e uma única interface física uplink, não há risco de loop e STP é desnecessário (pode até ser desabilitado para acelerar boot de VMs). Se a bridge tem múltiplos uplinks para redundância, ou se conecta a outros hosts físicos em topologia com potencial de loop, STP é obrigatório para evitar broadcast storms. Segundo Cisco, RSTP (Rapid STP) converge em 1-3 segundos.
Docker usa bridge por padrão?
Sim. Segundo a Docker Documentation, o driver de rede padrão é o ‘bridge’, que cria automaticamente a interface docker0 no host durante a instalação. Cada container recebe uma interface veth conectada a docker0, com IP privado da faixa 172.17.0.0/16. Para produção com múltiplos hosts, drivers como overlay (Swarm) ou macvlan são preferidos. Você pode criar bridges customizadas com ‘docker network create –driver bridge minha-rede’ para isolar aplicações.
Bridge Linux suporta VLAN?
Sim, bridges modernas do kernel Linux suportam VLAN tagging 802.1Q nativamente desde o kernel 3.8. Basta habilitar ‘vlan_filtering’ na bridge e associar VIDs a portas específicas com o comando ‘bridge vlan add’. Isso permite que um único host Linux atue como switch trunk-aware, recebendo múltiplas VLANs via uma NIC física e distribuindo tráfego para VMs em VLANs distintas — arquitetura comum em datacenters densos e ambientes multi-tenant.
Bridge é mais lenta que roteamento IP?
Em geral, sim, mas depende do cenário. Bridges Linux fazem processamento por quadro em software (netfilter bridge hooks), enquanto roteamento IP pode aproveitar fast-path do kernel e offload de NICs. Segundo benchmarks da Red Hat (2023), roteamento com XDP pode chegar a 10+ Mpps enquanto bridge tradicional fica em 1-2 Mpps. Para cargas altas em containers, drivers macvlan ou ipvlan (que evitam a bridge) oferecem melhor performance.
Termos relacionados
- Bond (Network Bonding) — agregação de múltiplas interfaces físicas em uma lógica, frequentemente combinada com bridges
- Bandwidth (Largura de Banda) — capacidade de transmissão que impacta desempenho da bridge
- ARP (Address Resolution Protocol) — protocolo que traduz IP em MAC, essencial para o funcionamento de bridges
- BGP (Border Gateway Protocol) — protocolo de roteamento externo, complementar em cenários com bridges e roteamento híbrido
- API Gateway — camada de entrada em arquiteturas de microserviços que frequentemente rodam em containers Docker com bridges
Conclusão
Bridge de Rede é uma abstração fundamental da camada 2 que sustenta virtualização moderna, containers e redes segmentadas em servidores Linux. Dominar sua configuração, entender STP, VLAN awareness e as diferenças em relação a switches e routers é requisito básico para qualquer profissional que administre infraestrutura de servidores ou desenvolva com Docker e Kubernetes. Erros como loops sem STP, MTU inconsistente e MAC learning ilimitado podem paralisar redes inteiras — prevenir é sempre mais barato que remediar.
Última atualização: Setembro/2026
Precisa de infraestrutura Linux com bridges e virtualização configuradas por especialistas? A Shiftmind oferece servidores dedicados, hospedagem gerenciada e suporte técnico com mais de uma década de experiência em redes corporativas. Fale com nosso time.
