Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox
16 réponses
Fran=c3=a7ois Lafont
Bonjour Í tous,
J'ai une régression au niveau d'un bridge suite Í un upgrade de
ma Ubuntu Desktop de la version 20.04 vers la version 22.04.
Comme vous allez voir, il est question de VirtualBox mais j'ai
l'impression que ce n'est pas lui qui est en cause ici.
Lorsque j'étais encore sous Ubuntu 20.04, j'avais ceci qui
fonctionnait très bien sur mon desktop :
1. Une interface br-virt qui était créée comme ceci via un script :
ip link add br-virt type bridge
ip address add 10.111.222.1/24 dev br-virt
ip link set br-virt up
2. Et des VM sous VirtualBox (la version d'Oracle) qui avait la
configuration réseau suivante :
Attached to: Bridged Adapter
Name: br-virt
En clair, les VM étaient bridgées Í mon interface br-virt.
Et avec tout ça, lorsque je démarrais une VM qui avait une IP
dans le réseau 10.111.222.0/24, j'avais, de ma machine physique
(ma Desktop Ubuntu 20.04), un accès réseau Í ma VM. En gros ma
machine physique et les VM se trouvaient dans un réseau IP local
Í ma machine. Ça me semble quelque chose de plutÍ´t classique.
Mon souci, c'est que depuis que j'ai migré ma machine physique
en Ubuntu 22.04, tout ceci ne marche plus du tout, je ne pingue
plus mes VM. Alors bien sÍ»r, Virtualbox a lui aussi été mis Í
jour quand je suis passé en 22.04 mais j'ai l'impression que
ce n'est pas lui le souci (voir ci-dessous).
DéjÍ , pour info, quand j'étais sous Ubuntu 20.04 j'avais les
versions suivantes :
* le noyau: 5.4.0-122-generic
* Virtualbox: 6.1.36-152435~Ubuntu~focal
Et une fois que je suis passé sous Ubuntu 22.04 :
* le noyau: 5.15.0-46-generic
* Virtualbox: 6.1.36-152435~Ubuntu~jammy
(en fait c'est la même version du Virtualbox au final)
Les commandes pour créer mon bridge n'ont absolument pas
changé après la migration de la distribution, ce sont les mêmes
que ci-dessus. Au passage, j'ai une autre machine (un laptop)
avec globalement la même configuration que mon desktop mais qui
est toujours en Ubuntu 20.04 (pas encore migrée en 22.04) et je
constate une différence.
Avec le laptop toujours en 20.04, j'ai ceci :
---------------------------------------
$ ip -j l show dev br-virt | jq
[
{
"ifindex": 4,
"ifname": "br-virt",
"flags": [
"BROADCAST",
"MULTICAST",
"UP",
"LOWER_UP"
],
"mtu": 1500,
"qdisc": "noqueue",
"operstate": "UNKNOWN",
"linkmode": "DEFAULT",
"group": "default",
"txqlen": 1000,
"link_type": "ether",
"address": "06:f5:51:c3:81:1e",
"broadcast": "ff:ff:ff:ff:ff:ff"
}
]
$ ip -j a show dev br-virt | jq
[
{
"ifindex": 4,
"ifname": "br-virt",
"flags": [
"BROADCAST",
"MULTICAST",
"UP",
"LOWER_UP"
],
"mtu": 1500,
"qdisc": "noqueue",
"operstate": "UNKNOWN",
"group": "default",
"txqlen": 1000,
"link_type": "ether",
"address": "06:f5:51:c3:81:1e",
"broadcast": "ff:ff:ff:ff:ff:ff",
"addr_info": [
{
"family": "inet",
"local": "10.111.222.1",
"prefixlen": 24,
"scope": "global",
"label": "br-virt",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
},
{
"family": "inet6",
"local": "fe80::4f5:51ff:fec3:811e",
"prefixlen": 64,
"scope": "link",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
}
]
}
]
---------------------------------------
Alors que sur la Ubuntu migrée en 22.04, j'ai cela :
---------------------------------------
$ ip -j l show dev br-virt | jq
[
{
"ifindex": 17,
"ifname": "br-virt",
"flags": [
"NO-CARRIER",
"BROADCAST",
"MULTICAST",
"UP"
],
"mtu": 1500,
"qdisc": "noqueue",
"operstate": "DOWN",
"linkmode": "DEFAULT",
"group": "default",
"txqlen": 1000,
"link_type": "ether",
"address": "9a:aa:18:5f:0f:ee",
"broadcast": "ff:ff:ff:ff:ff:ff"
}
]
$ ip -j a show dev br-virt | jq
[
{
"ifindex": 17,
"ifname": "br-virt",
"flags": [
"NO-CARRIER",
"BROADCAST",
"MULTICAST",
"UP"
],
"mtu": 1500,
"qdisc": "noqueue",
"operstate": "DOWN",
"group": "default",
"txqlen": 1000,
"link_type": "ether",
"address": "9a:aa:18:5f:0f:ee",
"broadcast": "ff:ff:ff:ff:ff:ff",
"addr_info": [
{
"family": "inet",
"local": "10.111.222.1",
"prefixlen": 24,
"scope": "link",
"label": "br-virt",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
}
]
}
]
---------------------------------------
On peut constater que le flag NO-CARRIER est présent
sur la Ubuntu 22.04 et pas sur la 20.04. De plus, le
operstate est DOWN sur la 22.04 alors qu'il est indiqué
UNKNOWN sur la 20.04. Je ne sais pas si cette différence
est une piste... C'est étrange qu'exactement les mêmes
commandes de création d'un bridge ne produisent pas la
même sorite au final.
Je reviens sur ma Ubuntu 22.04 o͹ j'ai mon souci. J'ai
une VM bridgée sur br-virt et qui possède l'adresse IP
10.111.222.19/24 avec pour gateway 10.111.222.1 (l'IP
de br-virt elle-même). Sur cette VM, je tente un ping
vers l'IP de br-virt :
---------------------------------------
~# ping -n 10.111.222.1
PING 10.111.222.1 (10.111.222.1) 56(84) bytes of data.
From 10.111.222.19 icmp_seq=1 Destination Host Unreachable
From 10.111.222.19 icmp_seq=2 Destination Host Unreachable
From 10.111.222.19 icmp_seq=3 Destination Host Unreachable
From 10.111.222.19 icmp_seq=4 Destination Host Unreachable
...
---------------------------------------
Aucune réponse. Au même moment, sur la machine physique, je
tente un tcpdump sur l'interface br-virt :
Je constate que la requête ARP whos-has arrive bien Í destination de
l'interface br-virt, et que donc de ce point de vue Virtualbox fait
bien son travail. Mais mon interface br-virt ne répond jamais Í ces
requêtes ARP. Pourquoi ? 10.111.222.1 c'est pourtant son adresse Í
elle.
Ensuite, je tente juste une petite expérience. Sur la VM, puisque
le who-has ne fonctionne pas, je rentre moi-même dans le cache ARP
l'adresse MAC de br-virt. Sur la VM, je fais donc ceci :
---------------------------------------
# L'interface « WAN » de la VM s'appelle enp0s3.
~# ip neigh change 10.111.222.1 lladdr 9a:aa:18:5f:0f:ee dev enp0s3
---------------------------------------
Puis, toujours sur la VM, je retente un ping, et lÍ toujours aucune
réponse :
---------------------------------------
~# ping -n 10.111.222.1
PING 10.111.222.1 (10.111.222.1) 56(84) bytes of data.
... # rien ne s'affiche
---------------------------------------
Mais comme cette fois-ci, la VM connaͮt l'adresse MAC qui correspond
Í l'adresse 10.111.222.1, la requête "echo request" arrive bien Í
destination :
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-virt, link-type EN10MB (Ethernet), snapshot length
262144 bytes
18:48:01.526413 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 1, length 64
18:48:02.553072 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 2, length 64
18:48:03.577111 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 3, length 64
18:48:04.601017 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 4, length 64
18:48:05.625070 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 5, length 64
18:48:06.649096 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 6, length 64
18:48:07.673002 IP 10.111.222.19 > 10.111.222.1: ICMP echo request, id
49452, seq 7, length 64
...
---------------------------------------
LÍ aussi, on voit bien que les requêtes ICM arrivent bien Í l'interface
br-virt mais celle-ci ne répond jamais, alors que 10.111.222.1 est
pourtant bien une adresse de cette interface.
Du coup, j'ai l'impression que le souci n'est pas cÍ´té Virtualbox mais
plutÍ´t sur cÍ´té de la machine physique o͹ le noyau Linux ne gère plus
tout Í fait de la même manière une interface de type bridge entre
Ubuntu 20.04 (o͹ ça marchait) et Ubuntu 22.04. Mon interface br-virt
reste totalement silencieuse pour des requêtes qui proviennent de ma
VM. En revanche, sur la machine physique je peux bien pinguer l'IP
de br-virt, pas de souci. En revanche, de la machine physique, je ne
peux pas pinguer l'IP de la VM 10.111.222.19 (j'ai « Destination
Host Unreachable »).
Je reste suis un peu coincé. Si jamais vous avez des pistes Í me
proposer, ce serait sympa. :)
Le vendredi 19 aoÍ»t 2022 Í 01:17:12 UTC+2, Pascal Hambourg a écrit :
Oui, j'avais essayé mais sans succès : ------------------------------- # Création de br-virt: ip link add br-virt type bridge ip address add 10.111.222.1/24 dev br-virt ip link set br-virt up # Création d'une interface dummy pontée sur br-virt: ip link add dummy0 type dummy ip addr add 10.111.222.200/24 dev dummy0 ip link set dummy0 master br-virt
Sauf erreur de ma part, tu ne l'as pas activée (up).
En effet, tu as raison. Je me demande si je n'ai pas fait une coquille, j'ai dÍ» mettre "br-virt" au lieu de "dummy0", comme un con. Et le pire, c'est que c'est ça la solution Í mon problème ! :) Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0. Je fais donc juste : ip link add dummy0 type dummy ip link set dummy0 master br-virt ip link set dummy0 up Et au moment de cette derrière commande, dummy0 et surtout br-virt passent en état UP immédiatement. Et lÍ , je démarre la VM et paf ! J'arrive bien Í la pinguer cette fois. o/ Merci Í toi Pascal, parce que ça doit faire 4 jours que je bloque sur cette connerie. Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r). En conclusion, dans mon script il va falloir que je mette ceci : ip link add br-virt type bridge ip address add 10.111.222.1/24 dev br-virt ip link set br-virt up ip link add dummy0 type dummy ip link set dummy0 master br-virt ip link set dummy0 up Et j'aurai une interface dummy0 toute moche qui sert juste Í rien (enfin on se comprend).
Avis personnel : la sortie en format JSON, c'est ultra-lourd Í lire, je dois scroller pour tout lire alors que le format par défaut tient en 3 lignes.
Ok, je le saurai pour les prochaines fois, promis. ;)
Ah et sinon, ça n'a peut-être rien Í voir mais, quand je pinge l'IP de br-virt (10.111.222.1) directement sur ma machine physique :
(...)
ce qui fonctionne très bien dans ce cas, alors si je fais un "tcpdump icmp" sur l'interface br-virt, rien ne s'affiche :
Normal, le trafic émis Í destination de n'importe quelle adresse locale passe par l'interface de loopback.
Ah ok, je ne savais pas, c'est bon Í savoir. Merci beaucoup pour ton aide Pascal.
Le vendredi 19 aoÍ»t 2022 Í 01:17:12 UTC+2, Pascal Hambourg a écrit :
> Oui, j'avais essayé mais sans succès :
>
> -------------------------------
> # Création de br-virt:
> ip link add br-virt type bridge
> ip address add 10.111.222.1/24 dev br-virt
> ip link set br-virt up
>
> # Création d'une interface dummy pontée sur br-virt:
> ip link add dummy0 type dummy
> ip addr add 10.111.222.200/24 dev dummy0
> ip link set dummy0 master br-virt
Sauf erreur de ma part, tu ne l'as pas activée (up).
En effet, tu as raison. Je me demande si je n'ai pas fait une coquille, j'ai
dÍ» mettre "br-virt" au lieu de "dummy0", comme un con. Et le pire, c'est
que c'est ça la solution Í mon problème ! :)
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite,
il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0. Je
fais donc juste :
ip link add dummy0 type dummy
ip link set dummy0 master br-virt
ip link set dummy0 up
Et au moment de cette derrière commande, dummy0 et surtout br-virt passent
en état UP immédiatement. Et lÍ , je démarre la VM et paf ! J'arrive bien Í la pinguer
cette fois. o/
Merci Í toi Pascal, parce que ça doit faire 4 jours que je bloque sur cette connerie.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04
(noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la
moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans
le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin
si, juste Í faire en sorte que mon putain de bridge soit UP).
Si je pouvais trouver la référence/documentation qui fait mention de ce changement
de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit
documenté quelque part, ce qui est loin d'être sÍ»r).
En conclusion, dans mon script il va falloir que je mette ceci :
ip link add br-virt type bridge
ip address add 10.111.222.1/24 dev br-virt
ip link set br-virt up
ip link add dummy0 type dummy
ip link set dummy0 master br-virt
ip link set dummy0 up
Et j'aurai une interface dummy0 toute moche qui sert juste Í rien (enfin on se comprend).
Avis personnel : la sortie en format JSON, c'est ultra-lourd Í lire, je
dois scroller pour tout lire alors que le format par défaut tient en 3
lignes.
Ok, je le saurai pour les prochaines fois, promis. ;)
> Ah et sinon, ça n'a peut-être rien Í voir mais, quand
> je pinge l'IP de br-virt (10.111.222.1) directement sur
> ma machine physique :
(...)
> ce qui fonctionne très bien dans ce cas, alors si je
> fais un "tcpdump icmp" sur l'interface br-virt, rien
> ne s'affiche :
Normal, le trafic émis Í destination de n'importe quelle adresse locale
passe par l'interface de loopback.
Le vendredi 19 aoÍ»t 2022 Í 01:17:12 UTC+2, Pascal Hambourg a écrit :
Oui, j'avais essayé mais sans succès : ------------------------------- # Création de br-virt: ip link add br-virt type bridge ip address add 10.111.222.1/24 dev br-virt ip link set br-virt up # Création d'une interface dummy pontée sur br-virt: ip link add dummy0 type dummy ip addr add 10.111.222.200/24 dev dummy0 ip link set dummy0 master br-virt
Sauf erreur de ma part, tu ne l'as pas activée (up).
En effet, tu as raison. Je me demande si je n'ai pas fait une coquille, j'ai dÍ» mettre "br-virt" au lieu de "dummy0", comme un con. Et le pire, c'est que c'est ça la solution Í mon problème ! :) Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0. Je fais donc juste : ip link add dummy0 type dummy ip link set dummy0 master br-virt ip link set dummy0 up Et au moment de cette derrière commande, dummy0 et surtout br-virt passent en état UP immédiatement. Et lÍ , je démarre la VM et paf ! J'arrive bien Í la pinguer cette fois. o/ Merci Í toi Pascal, parce que ça doit faire 4 jours que je bloque sur cette connerie. Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r). En conclusion, dans mon script il va falloir que je mette ceci : ip link add br-virt type bridge ip address add 10.111.222.1/24 dev br-virt ip link set br-virt up ip link add dummy0 type dummy ip link set dummy0 master br-virt ip link set dummy0 up Et j'aurai une interface dummy0 toute moche qui sert juste Í rien (enfin on se comprend).
Avis personnel : la sortie en format JSON, c'est ultra-lourd Í lire, je dois scroller pour tout lire alors que le format par défaut tient en 3 lignes.
Ok, je le saurai pour les prochaines fois, promis. ;)
Ah et sinon, ça n'a peut-être rien Í voir mais, quand je pinge l'IP de br-virt (10.111.222.1) directement sur ma machine physique :
(...)
ce qui fonctionne très bien dans ce cas, alors si je fais un "tcpdump icmp" sur l'interface br-virt, rien ne s'affiche :
Normal, le trafic émis Í destination de n'importe quelle adresse locale passe par l'interface de loopback.
Ah ok, je ne savais pas, c'est bon Í savoir. Merci beaucoup pour ton aide Pascal.
Pascal Hambourg
Le 19/08/2022 Í 03:58, flaf a écrit :
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur. Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
Le 19/08/2022 Í 03:58, flaf a écrit :
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite,
il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf
cas très particulier (configuration en pont-routeur avec ebtables) une
interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04
(noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la
moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans
le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin
si, juste Í faire en sorte que mon putain de bridge soit UP).
Si je pouvais trouver la référence/documentation qui fait mention de ce changement
de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit
documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15
sans rien trouver de probant. Il me semblait que ce comportement était
bien antérieur.
Autre chose : est-il nécessaire d'utiliser une interface bridge ?
Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble
qu'on pouvait spécifier une interface ethernet normale, et la VM était
pontée avec le réseau connecté Í cette interface. Cependant je ne me
rappelle pas avoir vérifié si une interface bridge était créée
implicitement pour ce pontage ou si virtualbox se greffait directement
sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce
cas il devrait suffire d'associer la VM directement Í une interface
dummy active.
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur. Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
Pascal Hambourg
Le 19/08/2022 Í 03:58, flaf a écrit :
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur. Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
Le 19/08/2022 Í 03:58, flaf a écrit :
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite,
il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf
cas très particulier (configuration en pont-routeur avec ebtables) une
interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04
(noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la
moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans
le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin
si, juste Í faire en sorte que mon putain de bridge soit UP).
Si je pouvais trouver la référence/documentation qui fait mention de ce changement
de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit
documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15
sans rien trouver de probant. Il me semblait que ce comportement était
bien antérieur.
Autre chose : est-il nécessaire d'utiliser une interface bridge ?
Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble
qu'on pouvait spécifier une interface ethernet normale, et la VM était
pontée avec le réseau connecté Í cette interface. Cependant je ne me
rappelle pas avoir vérifié si une interface bridge était créée
implicitement pour ce pontage ou si virtualbox se greffait directement
sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce
cas il devrait suffire d'associer la VM directement Í une interface
dummy active.
Au départ j'ai bien mon interface br-virt qui a un état DOWN (en rouge). Ensuite, il s'avère que je n'ai même pas besoin de mettre une adresse IP Í dummy0.
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Mais alors, franchement, c'est vraiment vache ce truc. Parce qu'avec Ubuntu 20.04 (noyau Linux 5.4.0-122-generic ), tout marchait parfaitement sans que je « ponte » la moindre interface Í mon bridge br-virt. Et c'était très bien comme ça parce que, dans le fond, cette interface dummy elle ne sert strictement Í rien dans mon cas (enfin si, juste Í faire en sorte que mon putain de bridge soit UP). Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur. Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
flaf
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas. Dans mon cas, je me suis juste dis que je n'avais aucune raison de mettre une IP Í cette interface.
Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur.
Ok. Bon... on va dire que, avant ma migration quand j'étais sous Ubuntu 20.04, j'étais sans doute dans une sorte de « corner case » avec mon bridge sans interface pontée et que j'avais eu juste de la chance que ça marche ainsi. Désormais, je me rappellerai qu'il faut impérativement au moins une interface pontée (même de type dummy sans IP) pour que le bridge ait un "operational state" Í UP (même si personnellement je trouve ça dommage).
Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
Alors déjÍ , d'après mes recherches, tu ne verras jamais aucune interface créée par Virtualbox (par exemple avec "ip l" ou "ip a", même en jouant avec les namespaces etc.). C'est dommage pour le debug et pour comprendre ce qu'il se passe mais c'est ainsi. De ce que j'ai compris, Virtualbox utilise son propre module kernel qui s'appelle vboxnetflt et c'est lui qui gère le cÍ´té réseau. Alors peut-être qu'il crée des interfaces virtuelle etc. mais on n'en sait rien et on ne voit rien avec les outils habituels comme ip. Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi accès Í Internet, ce que je ne souhaitais pas. En fait, sur mon desktop, j'ai quelques services réseau qui écoutent sur br-virt et uniquement sur cette interface comme un serveur DNS, un serveur DHCP (ça serait embêtant s'il écoutait sur eth0 !) et un serveur HTTP proxy aussi. Comme ça, mes VM n'ont pas d'accès Internet mais disposent tout de même d'un DHCP, d'un DNS et d'un proxy. Ça me permet de tester des déploiements dans des conditions qui ressemblent Í ce que j'ai en production. D'o͹ mon idée de départ d'utiliser un bridge br-virt. Ça m'a semblé une bonne façon de faire par rapport Í cette problématique, non ? Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24, sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être pas un bon argument, je ne sais pas... VoilÍ , j'espère que ça répond Í tes interrogations.
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf
cas très particulier (configuration en pont-routeur avec ebtables) une
interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas. Dans mon cas, je me suis juste dis que je n'avais aucune
raison de mettre une IP Í cette interface.
> Si je pouvais trouver la référence/documentation qui fait mention de ce changement
> de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit
> documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15
sans rien trouver de probant. Il me semblait que ce comportement était
bien antérieur.
Ok. Bon... on va dire que, avant ma migration quand j'étais sous Ubuntu 20.04, j'étais
sans doute dans une sorte de « corner case » avec mon bridge sans interface pontée
et que j'avais eu juste de la chance que ça marche ainsi. Désormais, je me rappellerai
qu'il faut impérativement au moins une interface pontée (même de type dummy sans
IP) pour que le bridge ait un "operational state" Í UP (même si personnellement je
trouve ça dommage).
Autre chose : est-il nécessaire d'utiliser une interface bridge ?
Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble
qu'on pouvait spécifier une interface ethernet normale, et la VM était
pontée avec le réseau connecté Í cette interface. Cependant je ne me
rappelle pas avoir vérifié si une interface bridge était créée
implicitement pour ce pontage ou si virtualbox se greffait directement
sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce
cas il devrait suffire d'associer la VM directement Í une interface
dummy active.
Alors déjÍ , d'après mes recherches, tu ne verras jamais aucune interface créée par
Virtualbox (par exemple avec "ip l" ou "ip a", même en jouant avec les namespaces
etc.). C'est dommage pour le debug et pour comprendre ce qu'il se passe mais c'est
ainsi. De ce que j'ai compris, Virtualbox utilise son propre module kernel qui s'appelle
vboxnetflt et c'est lui qui gère le cÍ´té réseau. Alors peut-être qu'il crée des interfaces
virtuelle etc. mais on n'en sait rien et on ne voit rien avec les outils habituels comme ip.
Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur
mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure
de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi
accès Í Internet, ce que je ne souhaitais pas. En fait, sur mon desktop, j'ai quelques
services réseau qui écoutent sur br-virt et uniquement sur cette interface comme
un serveur DNS, un serveur DHCP (ça serait embêtant s'il écoutait sur eth0 !) et un
serveur HTTP proxy aussi. Comme ça, mes VM n'ont pas d'accès Internet mais
disposent tout de même d'un DHCP, d'un DNS et d'un proxy. Ça me permet de tester
des déploiements dans des conditions qui ressemblent Í ce que j'ai en production.
D'o͹ mon idée de départ d'utiliser un bridge br-virt. Ça m'a semblé une bonne façon
de faire par rapport Í cette problématique, non ?
Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu
utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24,
sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité
d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise
Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie
d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien
un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça
m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être
pas un bon argument, je ne sais pas...
VoilÍ , j'espère que ça répond Í tes interrogations.
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
En effet j'ai oublié d'aborder ce point dans ma réponse précédente, sauf cas très particulier (configuration en pont-routeur avec ebtables) une interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas. Dans mon cas, je me suis juste dis que je n'avais aucune raison de mettre une IP Í cette interface.
Si je pouvais trouver la référence/documentation qui fait mention de ce changement de comportement dans le noyau Linux, j'en serais tout ému (si tant est que ce soit documenté quelque part, ce qui est loin d'être sÍ»r).
J'ai regardé dans les changelogs du noyau entre les versions 5.4 et 5.15 sans rien trouver de probant. Il me semblait que ce comportement était bien antérieur.
Ok. Bon... on va dire que, avant ma migration quand j'étais sous Ubuntu 20.04, j'étais sans doute dans une sorte de « corner case » avec mon bridge sans interface pontée et que j'avais eu juste de la chance que ça marche ainsi. Désormais, je me rappellerai qu'il faut impérativement au moins une interface pontée (même de type dummy sans IP) pour que le bridge ait un "operational state" Í UP (même si personnellement je trouve ça dommage).
Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. Cependant je ne me rappelle pas avoir vérifié si une interface bridge était créée implicitement pour ce pontage ou si virtualbox se greffait directement sur l'interface ethernet pour émettre et recevoir des paquets. Dans ce cas il devrait suffire d'associer la VM directement Í une interface dummy active.
Alors déjÍ , d'après mes recherches, tu ne verras jamais aucune interface créée par Virtualbox (par exemple avec "ip l" ou "ip a", même en jouant avec les namespaces etc.). C'est dommage pour le debug et pour comprendre ce qu'il se passe mais c'est ainsi. De ce que j'ai compris, Virtualbox utilise son propre module kernel qui s'appelle vboxnetflt et c'est lui qui gère le cÍ´té réseau. Alors peut-être qu'il crée des interfaces virtuelle etc. mais on n'en sait rien et on ne voit rien avec les outils habituels comme ip. Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi accès Í Internet, ce que je ne souhaitais pas. En fait, sur mon desktop, j'ai quelques services réseau qui écoutent sur br-virt et uniquement sur cette interface comme un serveur DNS, un serveur DHCP (ça serait embêtant s'il écoutait sur eth0 !) et un serveur HTTP proxy aussi. Comme ça, mes VM n'ont pas d'accès Internet mais disposent tout de même d'un DHCP, d'un DNS et d'un proxy. Ça me permet de tester des déploiements dans des conditions qui ressemblent Í ce que j'ai en production. D'o͹ mon idée de départ d'utiliser un bridge br-virt. Ça m'a semblé une bonne façon de faire par rapport Í cette problématique, non ? Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24, sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être pas un bon argument, je ne sais pas... VoilÍ , j'espère que ça répond Í tes interrogations.
Pascal Hambourg
Le 19/08/2022 Í 13:24, flaf a écrit :
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
une interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas.
Les interfaces qui font partie d'un pont sont comme les port d'un switch ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. (...)
Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi accès Í Internet, ce que je ne souhaitais pas.
J'avais bien compris, d'o͹ ma suggestion d'utiliser une interface dummy et non une interface ethernet physique.
Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24, sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être pas un bon argument, je ne sais pas...
C'est une raison valable, il peut être fastidieux de modifier une configuration réseau après coup. Dans ce cas tu pourrais associer la VM de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge, au moins on aurait l'impression qu'elle sert Í quelque chose et le bridge serait vraiment utilisé comme un pont.
Le 19/08/2022 Í 13:24, flaf a écrit :
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
une interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas.
Les interfaces qui font partie d'un pont sont comme les port d'un switch
ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du
bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Autre chose : est-il nécessaire d'utiliser une interface bridge ?
Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble
qu'on pouvait spécifier une interface ethernet normale, et la VM était
pontée avec le réseau connecté Í cette interface. (...)
Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur
mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure
de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi
accès Í Internet, ce que je ne souhaitais pas.
J'avais bien compris, d'o͹ ma suggestion d'utiliser une interface dummy
et non une interface ethernet physique.
Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu
utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24,
sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité
d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise
Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie
d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien
un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça
m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être
pas un bon argument, je ne sais pas...
C'est une raison valable, il peut être fastidieux de modifier une
configuration réseau après coup. Dans ce cas tu pourrais associer la VM
de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge,
au moins on aurait l'impression qu'elle sert Í quelque chose et le
bridge serait vraiment utilisé comme un pont.
Le vendredi 19 aoÍ»t 2022 Í 09:39:14 UTC+2, Pascal Hambourg a écrit :
une interface pontée ne devrait pas avoir d'adresse IP.
Ah ok, je ne savais pas.
Les interfaces qui font partie d'un pont sont comme les port d'un switch ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Autre chose : est-il nécessaire d'utiliser une interface bridge ? Je n'ai plus utilisé virtualbox depuis des lustres mais il me semble qu'on pouvait spécifier une interface ethernet normale, et la VM était pontée avec le réseau connecté Í cette interface. (...)
Ensuite, tu as raison, je pourrais parfaitement « bridger » directement mes VM sur mon interface eth0 qui est l'interface physique de mon desktop, celle qui me procure de l'Internet. Et ça juste marche évidemment. Mais dans ce cas, les VM ont aussi accès Í Internet, ce que je ne souhaitais pas.
J'avais bien compris, d'o͹ ma suggestion d'utiliser une interface dummy et non une interface ethernet physique.
Enfin, tu me diras que, dans ce cas, pourquoi un bridge ? J'aurais parfaitement pu utiliser directement une interface de type dummy (dummy-virt) avec l'IP 10.111.222.1/24, sans m'embêter avec un bridge. Ça juste marche (je l'ai testé) et ça m'aurait évité d'avoir le problème exposé dans ce fil de discussion. Mais je me dis que j'utilise Virtualbox sur ma machine comme pour l'instant et peut-être qu'un jour j'aurai envie d'utiliser autre chose, comme kvm par exemple. Et lÍ , je pense que ce sera bel et bien un bridge qu'il faudra sur mon desktop. Alors je m'étais dit autant utiliser un bridge, ça m'évitera de changer la conf de mon desktop si je passe Í kvm... Après, c'est peut-être pas un bon argument, je ne sais pas...
C'est une raison valable, il peut être fastidieux de modifier une configuration réseau après coup. Dans ce cas tu pourrais associer la VM de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge, au moins on aurait l'impression qu'elle sert Í quelque chose et le bridge serait vraiment utilisé comme un pont.
flaf
Le vendredi 19 aoÍ»t 2022 Í 14:17:31 UTC+2, Pascal Hambourg a écrit :
Les interfaces qui font partie d'un pont sont comme les port d'un switch ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Ok, c'est très clair.
C'est une raison valable, il peut être fastidieux de modifier une configuration réseau après coup. Dans ce cas tu pourrais associer la VM de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge, au moins on aurait l'impression qu'elle sert Í quelque chose et le bridge serait vraiment utilisé comme un pont.
Ah c'est carrément une bonne idée ça. Pour l'avoir testé, évidemment ça juste marche et, comme tu dis, ça rend la configuration plus logique, du coup ça me plaÍ®t. Je vais faire comme ça. Merci encore pour ton aide Pascal.
Le vendredi 19 aoÍ»t 2022 Í 14:17:31 UTC+2, Pascal Hambourg a écrit :
Les interfaces qui font partie d'un pont sont comme les port d'un switch
ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du
bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Ok, c'est très clair.
C'est une raison valable, il peut être fastidieux de modifier une
configuration réseau après coup. Dans ce cas tu pourrais associer la VM
de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge,
au moins on aurait l'impression qu'elle sert Í quelque chose et le
bridge serait vraiment utilisé comme un pont.
Ah c'est carrément une bonne idée ça. Pour l'avoir testé, évidemment
ça juste marche et, comme tu dis, ça rend la configuration plus logique, du
coup ça me plaÍ®t. Je vais faire comme ça.
Le vendredi 19 aoÍ»t 2022 Í 14:17:31 UTC+2, Pascal Hambourg a écrit :
Les interfaces qui font partie d'un pont sont comme les port d'un switch ethernet. D'ailleurs elles sont appelées "ports" dans la terminologie du bridge. Est-qu'on configure une adresse IP sur un port de switch ? Non.
Ok, c'est très clair.
C'est une raison valable, il peut être fastidieux de modifier une configuration réseau après coup. Dans ce cas tu pourrais associer la VM de virtualbox Í l'interface dummy pontée au lieu de l'interface bridge, au moins on aurait l'impression qu'elle sert Í quelque chose et le bridge serait vraiment utilisé comme un pont.
Ah c'est carrément une bonne idée ça. Pour l'avoir testé, évidemment ça juste marche et, comme tu dis, ça rend la configuration plus logique, du coup ça me plaÍ®t. Je vais faire comme ça. Merci encore pour ton aide Pascal.
