Para contextualizar, estou configurando um cluster Proxmox de 3 nós para uso pessoal e configurando 2 redes mesh diferentes em 4 interfaces (2 interfaces por nó para cada rede mesh). Dessa forma, cada nó tem uma conexão direta com todos os outros nós. Para fazer a rede funcionar, dependo de rotas estáticas em cada interface, configuradas da seguinte forma:
auto lo
iface lo inet loopback
iface enp5s0f0 inet manual
iface enp5s0f1 inet manual
auto eno1
iface eno1 inet static
address 10.83.86.10/24
up ip route add 10.83.86.11/32 dev eno1
down ip route del 10.83.86.11/32
auto eno2
iface eno2 inet static
address 10.83.86.10/24
up ip route add 10.83.86.12/32 dev eno2
down ip route del 10.83.86.12/32
auto eno3
iface eno3 inet static
address 10.83.67.10/24
up ip route add 10.83.67.11/32 dev eno3
down ip route del 10.83.67.11/32
auto eno4
iface eno4 inet static
address 10.83.67.10/24
up ip route add 10.83.67.12/32 dev eno4
down ip route del 10.83.67.12/32
auto vmbr0
iface vmbr0 inet static
address 192.168.0.20/24
gateway 192.168.0.1
bridge-ports enp5s0f0
bridge-stp off
bridge-fd 0
source /etc/network/interfaces.d/*
Os endereços IP diferem entre os nós, mas fora isso a configuração é a mesma. Interfaces eno1e eno2fazem parte da 10.83.86.0rede, e eno3e eno4fazem parte da 10.83.67.0rede.
Surge o problema de não saber como expor essas redes a VMs e contêineres em execução no Proxmox. Por exemplo, quero ser capaz de balancear a carga e criar um túnel de proxy na interface da web do Proxmox, que estou planejando expor apenas na rede mesh. Outro exemplo é que preciso de determinadas cargas de trabalho para poder acessar a rede pública do Ceph, como o driver CSI do Ceph Kubernetes.
Pelo que entendi, o Proxmox requer uma ponte Linux para virtualização de placas de rede virtuais. Tentei reescrever minha configuração de interface como:
auto eno1
iface eno1 inet manual
up ip route add 10.83.86.11/32 dev eno1
down ip route del 10.83.86.11/32
auto eno2
iface eno2 inet manual
up ip route add 10.83.86.12/32 dev eno2
down ip route del 10.83.86.12/32
auto vmbr1
iface vmbr1 inet static
address 10.83.86.10/24
bridge-ports eno1 eno2
bridge-stp off
bridge-fd 0
Mas essa configuração apenas... interrompe a rede entre nós quando eu recarrego com ifreload -a. Eu não entendo completamente o porquê.
Responder1
As rotas pertencem a interfaces IP, não a portas de ponte. As portas da sua ponte não devem conter literalmente nada. Todas as rotas estão associadas a interfaces que possuem endereços IP.
Considere se você tivesse isso:
auto eno1
iface eno1 inet static
address 10.83.86.10/24
up ip route add 10.83.86.11/32 dev eno1
down ip route del 10.83.86.11/32
então fica assim:
iface eno1 inet manual
auto vmbr1
iface vmbr1 inet static
address 10.83.86.10/24
up ip route add 10.83.86.11/32 dev vmbr1
down ip route del 10.83.86.11/32
bridge-ports eno1
bridge-stp off
bridge-fd 0
Observe como todas as coisas relacionadas ao IP simplesmente passaram da NIC física para a ponte. A NIC se torna uma interface somente L2, pense nela como uma porta de switch. Os switches não possuem endereços IP em cada interface, nem as interfaces em ponte deveriam.
Você pode conectar vários NICs físicos como fez, especificando todos eles em bridge-ports. Nenhuma das portas terá configuração IP. Somente a ponte pode tê-lo.
Não consigo entender o que você vai conseguir tendo cada endereço/32 de interface individual e rota individual. Não sei por que você quer isso, mas essa configuração de rede parece um tanto estranha.
No entanto, se você quiser manter a estrutura de rede (camada 3) como na sua pergunta, será necessário criar uma ponte dedicada para cada endereço IP e colocar a respectiva VM nessa ponte.
Se tudo isso for apenas para comunicação host-VM, você não precisará trazer nenhuma NIC física para essas pontes. Sair vmbrXsemqualquerportas de ponte, mas configure endereços IP. Você poderá colocar VMs nessa ponte "vazia" e elas se comunicarão entre si e com o host. As NICs físicas só precisam fazer parte da ponte se você precisar conectar este segmento de rede virtual com a rede física na camada 2 (por exemplo, Ethernet).