Atualmente estou construindo uma nova versão do meu roteador DIY, executo o Ubuntu 22.04 LTS com uma instalação mínima e executo firewalldem cima dele - e o hardware mais recente que executo tem uma 'mistura' de diferentes velocidades de porta - 10G, 2,5G e gigabit no mínimo.
Tenho dois problemas aqui e espero resolvê-los configurando um switch virtual entre todas as minhas portas.
Minhas construções 'tradicionais' conectam todas as portas - e pelo que entendi, uma ponte só funcionará tão rápido quanto a porta mais lenta em uso. Estou resolvendo isso criando uma ponte por velocidade de interface. Isso é confuso e, para servidores DHCP, significa uma sub-rede por velocidade de link que preciso suportar.
Prefiro executar uma sub-rede, e meu servidor DHCP parece um pouco temperamental com várias sub-redes. Seria desejável reduzir a complexidade no gerenciamento de DHCP e outros serviços e nivelar minha rede. Não preciso de várias sub-redes na minha instalação básica.
Minha configuração do Netplan para minha caixa de teste é assim - mas acho que algumas das portas de 10 giga são na verdade portas de 1 giga (modelos diferentes têm portas diferentes e esqueci que o modelo que recebi era uma mistura). Se assim for, eu teria que dividir as portas gigabit para outra ponte
# This is the network config written by 'subiquity'
network:
ethernets:
#10G ports Jumbo frames give slightly better speed
eno1:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:X1
set-name: SFP4
mtu: "9000"
# Top Left SFP cage
eno2:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:X2
set-name: SFP2
mtu: "9000"
# Bottom Left SFP cage
eno3:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:X3
set-name: SFP3
mtu: "9000"
# Top Right SFP cage
eno4:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:X4
set-name: SFP1
mtu: "9000"
# Bottom Right SFP cage
#2.5 gig ports follow physical labels
enp4s0:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:Xa
set-name: LAN1
enp5s0:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:Xb
set-name: LAN2
enp6s0:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:Xc
set-name: LAN3
enp7s0:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:Xd
set-name: LAN4
#wan port
enp8s0:
dhcp4: true
match:
macaddress: 20:7c:14:f3:XX:Xe
set-name: WAN
#bridges - Apparently bridges are only as fast as the slowest port,
#and I can only host one subnet a bridge. Will be splitting up 10G and 2.5G ports
bridges:
SFPBR:
dhcp4: no
addresses: [10.0.0.1/24]
interfaces:
- eno1
- eno2
- eno3
- eno4
LANBR:
dhcp4: no
addresses: [10.0.1.1/24]
interfaces:
- enp4s0
- enp5s0
- enp6s0
- enp7s0
O que eu gostaria de fazer é substituir SFPBR e LANBR por um único switch virtual (e praticamente uma única interface virtual) e expor um único IP/interface para conversar com o 'switch'. Na verdade, gosto do Netplan, então, idealmente, gostaria de segui-lo para configuração, se possível.
Como eu faria isso?
Geralmente esse não é o caso das pontes.
Sua descrição parece falar sobre as antigas pontes Ethernet físicas de décadas atrás, antes da invenção da comutação (ou hubs de velocidade dupla), que tinham essa limitação devido à forma como funcionavam fisicamente . Bridge não é isso no Netplan – o termo refere-se apenas à funcionalidade geral de encaminhamento de quadros Ethernet (por endereços MAC aprendidos), não às especificidades e limitações de como isso é feito.
(Na verdade, se bem me lembro, nem foram as "pontes" que tiveram esse problema - as pontes eram o que se usaria para resolver o problema, fazendo com que a ponte avançasse entre duas Ethernet de taxas diferentes. Mas Não estou muito claro sobre a terminologia que quase me antecede.)
Uma ponte Netplan (ou mais precisamente uma ponte Linux) é literalmente uma "troca de software virtual". É chamado de "ponte" em vez de "switch" porque chamá-lo de "switch" geralmente implicaria algum tipo de aceleração de hardware, enquanto na maioria dos casos ele realmente apenas faz o encaminhamento via CPU. (Se você tiver, por exemplo, uma NIC multiporta e os drivers a suportarem, uma ponte Linux tentará ativar o descarregamento de hardware, mas isso não mudaria muito as coisas.)
Assim, mesmo que os portos sejam interligados, continua a ser verdade que cada porto tem a sua própria ligação ponto-a-ponto, que funciona à velocidade que necessita, independentemente dos outros portos que também têm as suas próprias tarifas; a ponte recebe quadros da porta A, armazena-os em buffer e os envia pela porta B. Você pode ter uma porta 10G conectada a uma porta 10M e elas funcionarão "como esperado".
Dito isto, posso ver alguns problemas surgindo:
Se o hardware fosse de fato um par de NICs multiportas para as quais o Linux suporta descarregamento de switch de hardware, eles poderiam estar fazendo a ponte no hardware em sua configuração atual, mas forçados a fazer o encaminhamento de 10G na CPU quando unidos em uma única ponte. Pelo seu comentário sobre "quadros jumbo", parece que esse não é o caso.
Todas as portas conectadas a uma única sub-rede – seja em software (CPU) ou hardware, seja em uma 'ponte' ou em um 'switch' - realmente deveriam ter MTU idênticos, caso contrário as coisas só se tornarão mais complexas.