[QEMU/KVM] problème d'interface bridge

Support Debian
#1

Bonjour,

Je dispose de 2 serveurs chez Online et j’utilise leurs technologie RPN pour l’interconnexion de ces serveurs.
Suite à un changement de techno ESXi -> QEMU/KVM, je rencontre un souci de configuration des mes interfaces bridge pour le RPN.

Infrastructure ESXi ok :
Deux ESXi avec une VM mikrotik sur chacun. Chaques mikrotik dispose de 2 cartes réseau WAN + RPN (@mac de la carte physique). Récupération du dhcp fourni par le RPN et ping des ip RPN ok sur les mikrotik. j’ai pu monter un tunnel EoIP sans problème.

Infrastructure QEMU/KVM :
Mes deux serveurs sont en debian 9. une fois bridge-utils installés je créer un bridge sur mon interface eno2 (RPN) et j’active le dhcp; l’ip remonte et le ping fonctionne. J’en conclus donc que mon bridge est bon. Cependant une fois que je repasse mon bridge en manual (br0) et que je me mets sur une VM de test (mikrotik, debian ou windows) le dhcp du RPN remonte mais le ping ne fonctionne pas …

Auriez-vous quelques pistes ? j’ai déjà fait pas mal de recherches mais je n’ai rien trouver

Merci pour vos réponses.

#2

Un simple telnet sur un port fonctionne ?
L’ICMP est-il bien autorisé et de où à où se fait-il ?

#3

Merci pour ta réponse @Clochette

Le telnet n’aboutit pas et l’ICMP est bien autorisé sur la VM.

En fait si je reste sur la couche de l’OS, tous mes serveurs physiques ce ping entre eux par le RPN. les interfaces br0 (bridge des inertfaces eno2) sont monté en DHCP sur chacun des serveurs et fonctionnels.

Quand je passe juste une interface br0 sur un des serveurs physique en “manual” et que je démarre une VM avec ces paramètres réseau dans le xml :

  <interface type='bridge'>
  <mac address='@mac de la carte RPN'/>
  <source bridge='br0'/>
  <model type='virtio'/>

L’ip du dhcp du RPN remonte bien sur la VM mais impossible de sortir sur le réseau RPN et idem dans le sens inverse, les ping depuis des serveurs physiques avec une interface bridge en dhcp ce ping entre eux sauf celui que j’ai passé en manual (la VM devrait répondre).

Voici la conf de mon bridge :

# The secondary network interface
# auto eno2
iface eno2 inet manual

# Bridge RPN
auto br0
iface br0 inet manual
        bridge_ports eno2
        bridge_stp on
        bridge_fd 0
        bridge_maxwait 0
        post-up ifconfig eno2 mtu 9000
#4

Bonjour,

Apparemment tu utilises la libvirt avec éventuellement les outils virsh et/ou virt-manager. Et pas simplement qemu/kvm.

Et puisque le RPN ne semble t’autoriser qu’une seule adresse MAC par serveur, c’est qu’il s’agit de RPN version 1 et non pas de RPN-v2 .

Un bridge (un switch virtuel, donc) n’a pas d’adresse MAC, comme n’importe-quel autre switch Ethernet.

Par contre le bridge créé par les bridge-utilities crée une interface réseau “interne” appelé br0 dans ton cas. Et que cette interface est dotée d’une adresse MAC. Et qu’une adresse MAC est censée être unique au monde.

Pour le bridge crée par les bridge-utilities, l’adresse MAC utilisée par l’interface “interne” est la plus petite des adresses des interfaces réseau inclues dans le bridge.
En effet, les interfaces réseau inclues dans le bridge n’ont plus besoin de leur adresse MAC.

Donc, imaginons que l’adresse MAC de l’interface RPN soit celle utilisée par l’interface br0 et que tu crées une VM avec une interface dont l’adresse MAC est également celle de l’interface RPN comme dans ton exemple, la même adresse MAC sera donc utilisée deux fois et là, paf !

Cela ne répondra pas du tout à ton besoin sur le long terme mais la solution la plus simple à l’exemple que tu as donné en XML ci-dessus est d’assigner une adresse MAC à l’interface br0 en ajoutant une directive telle que hwaddress ether c6:89:bd:12:c7:84 dans le /etc/network/interfaces. Sur chacun de tes deux hyperviseurs, évidemment avec une MAC différente.
Je te conseille d’utiliser ce générateur d’adresse MAC si tu veux en prendre une au hasard.

–
AnonymousCoward

#5

Bonjour @AnonymousCoward,

Merci beaucoup pour ton analyse, qui s’avère être exacte du point de vue des outils utilisés. J’ai bien compris ton explication sur le principe de la double utilisation de l’adresse MAC.

Pour faire le test que tu m’indiques j’utilise un serveur physique sous Debian 9 avec le RPN directement sur l’interface eno2 en DHCP et sur mon hyperviseur voici la conf modifiée :

# The secondary network interface
# auto eno2
iface eno2 inet manual

# Bridge RPN
auto br0
iface br0 inet manual
        hwaddress ether 62:2d:a5:b8:42:7f
        bridge_ports eno2
        bridge_stp on
        bridge_fd 0
        bridge_maxwait 0
#       post-up ifconfig eno2 mtu 9000

Le résultat sur la VM de test est identique, le DHCP monte mais impossible de sortir sur le RPN. Il n’y aurait des modules à activer sur l’hyperviseur ? (je pense aux 3 options sur la configuration d’un vSwitch sur ESXi)

#6

Il peut y avoir plusieurs raisons à cela.

Un problème occasionnel est que les paquets passant le bridge traversent, par défaut, netfilter/iptables.
A tout hasard, ne pas hésiter à désactiver les options du genre bridge-nf-call-iptables .

Sinon, il est très pratique d’utiliser tcpdump pour regarder ce qui passe (ou ne passe pas) en indiquant qu’on écoute sur l’interface eno2 .

–
AnonymousCoward

#7

Mais les adresses MAC des interfaces servant de ports au pont n’en continuent pas moins d’exister : le pont les considère comme lui appartenant, et ne forwardera jamais une trame reçue destinée à une de ces adresses.