Le 14/08/2019 à 13:07, Sebastien Caps via FRsAG a écrit :
A devenir dingue cette histoire :)
je deviens effectivement dingue depuis plusieurs jours. J'ai même fait des montages plus complexe en couplant namespace, veth, bridge et OVS mais toujours le même résultat.
Je viens de trouver le problème. Cela provient des options de lancement de mes VM qemu
Je faisais : qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda alpine-lab1.img -net nic,macaddr=52:54:00:12:12:02 -net tap,script=no,ifname=lab1vm1 -vnc :1 -name lab1vm1 -localtime --daemonize
Maintenant, j'ai modifié pour respecter les nouvelles options : qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda alpine-lab1.img -device e1000,netdev=mynet3,mac=52:54:00:12:12:02 -netdev tap,script=no,ifname=lab1vm1,id=mynet3 -vnc :1 -name lab1vm2 -localtime --daemonize
La modification de -net nic,macaddr=52:54:00:12:12:02 -net tap,script=no,ifname=lab1vm1 en -device e1000,netdev=mynet3,mac=52:54:00:12:12:02 -netdev tap,script=no,ifname=lab1vm1,id=mynet3 résout le problème.
Pourquoi, j'en ai aucune idée. Si quelqu'un sait, cela m'intéresse. Pour info, QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15)
Possible de nous faire voir "ovs-vsctl show" ?
Seb
Le 14-08-2019 12:22, Florent Nolot a écrit :
au démarrage de la maquette, sur VM1, VM2 et VM3
ip neigh | arp -a -> vide
donc normal, je viens de démarrer les VM
Je stoppe de suite VM2 (poweroff) le ping depuis VM1 -> VM3 ne marche pas
En faisant un poweroff de la VM2, cela détruit les tap sur l'host (lab1dhcp lab1dhcpadm) donc pour simuler l'existance de la VM, je refais un
ip tuntap add lab1dhcp mode tap; ip link set up dev lab1dhcp ip tuntap add lab1dhcpadm mode tap; ip link set up dev lab1dhcpadm Le ping ne marche pas.
Je lance VM2 et le ping se met à marcher.
VM1 : ip neigh | arp -a -> MAC de VM3 VM2 : ip neigh | arp -a -> vide VM3 : ip neigh | arp -a -> MAC VM1
Si je shut eth0 et eth1 de VM2, le ping continue à marcher.
Je flush la table arp de VM1 et VM2. Le arp -an et le ip neigh | arp -an sont vide sur VM1 et VM3 MAIS le ping marche !
C'est donc bien sur le host qu'il se passe quelque chose !
Sur le host, iptables -F et iptables -F -t nat, ebtables (qui n'a pas d'impact sur les OVS il me semble) vide, politique par defaut accept
Le 14/08/2019 à 11:47, Sebastien Caps via FRsAG a écrit :
Bonjour,
Justement au niveau 2 tu as quoi dans ta table ARP quand la VM est éteinte ? ip neigh / arp -a
Seb
Le 14-08-2019 11:42, Florent Nolot a écrit :
Bonjour
justement, je n'ai pas de routage en place, pas de proxy arp et les trames de broadcast atteigne VM3 depuis VM1
Sur mon host :
toto@ubuntu:~$ ip route show default via 10.22.9.254 dev ens160 onlink 10.22.9.0/24 dev ens160 proto kernel scope link src 10.22.9.75
net.ipv4.ip_forward = 0 net.ipv4.conf.all.proxy_arp = 0
Sur les VM, je n'ai pas de route par défaut. Chaque VM est lancé ainsi
qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda alpine-lab1.img -net nic,macaddr=52:54:00:12:12:02 -net tap,script=no,ifname=lab1vm1 -vnc :2 -name lab1vm1 -localtime --daemonize
Ce que je n'explique pas, si je down eth0 eth1 de la VM2, les ping continue à marcher ! VM2 ne fait donc pas le routage. Visiblement, c'est le kernel du host qui relai les paquets. Mais pourquoi les tag vlan ne jouent pas leur rôle ?
Cordialement
Le 14/08/2019 à 04:44, VALOIS, Pascal a écrit :
bonjour,
Dans ton cas, je pense que tes vm1 2 et 3 ont chacune une route par défaut positionnée, et que l'équipement qui assure leur routage fait le lien entre les deux vlans.
en gros, au niveau 2 tu est bien isolé, mais comme tu es dans un contexte de ping et de routage ip, et non plus d'une transation pure ethernet (niveau 2), ben tu as un chemin qui existe entre des vms.
A ce niveau la, il faut ajouter des ACLS sur ton équipement de routage, pour filtrer le niveau 3 (comme le ferai un firewall)
Cordialement.
Le 13/08/2019 à 23:23, Florent Nolot a écrit :
Bonjour
J'ai un problème d'isolation entre des VM connectés à un OpenVSwitch et utilisant des VLAN. Les vlan ne jouent pas leur rôle de cloisement. Je copie ci-dessous le post stackoverflow que j'ai effectué, resté sans réponse à ce jour.
I have 3 VM (qemu with tap interface), 2 on vlan 10 and 1 on vlan 66 on the same lab1 OpenVSwitch. The first VM is connected via a tap interface on port lab1vm1. The second has 2 network interfaces connected on port lab1dhcp and lab1dhcpmaster and the third VM on port dhcpmaster.
| VM 1 | | VM2 | | VM3 | |10.10.10.3 | |10.8.6.1 10.10.10.13| | 10.10.10.2 |
| | | | | | | |
|lab1vm1 lab1dhcp lab1dhcpadm dhcpmaster OVS lab1| |tag 10 tag 10 tag 66 tag 66 |
The OpenVSwitch is configured as follow :
Bridge "lab1" Port "lab1vm1" tag: 10 Interface "lab1vm1" Port "lab1" tag: 10 Interface "lab1" type: internal Port "lab1dhcp" tag: 10 Interface "lab1dhcp" Port "lab1dhcpadm" tag: 66 Interface "lab1dhcpadm" Port dhcpmaster tag: 66 Interface dhcpmaster ovs_version: "2.9.2"
The problem: VM1 can ping VM3!
- If I power off VM2 or shutdown lab1dhcp or lab1dhcpadm
interface, the ping doesn't work.
- If I shutdown the two network interfaces of VM2, ping works !
Why VM2 relay ICMP packet from VM1 to VM3 ? The broadcast send by VM1 reach also VM3 ! for example, if I ask an address from dhcp client on VM1, VM3 receive the dhcp discover.
Merci pour votre aide.
Florent
Liste de diffusion du FRsAG http://www.frsag.org/ [1]
Links:
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/