Problème d'interface de type bridge qui ne répond pas aux VM VirtualBox

[François 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 :

---------------------------------------
$ sudo tcpdump -nn -i br-virt

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on br-virt, link-type EN10MB (Ethernet), snapshot length
262144 bytes

18:40:38.553085 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:39.577201 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:40.601450 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:41.625206 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:42.649061 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:43.673570 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:44.697205 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:45.721190 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:46.745489 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

18:40:47.769201 ARP, Request who-has 10.111.222.1 tell 10.111.222.19,
length 46

...
---------------------------------------

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 :

---------------------------------------
$ sudo tcpdump -nn -i br-virt

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. :)

Merci d'avance pour votre aide.

François Lafont

[Pascal Hambourg]

Le 17/08/2022 à 19:17, François Lafont a écrit :
>
> 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...

Probablement. A ma connaissance l'état de liaison d'un pont est lié à
celui de ses "ports". Quel est l'état des interfaces pontées côté hôte ?

[François Lafont]

Bonsoir,

On 8/17/22 23:02, Pascal Hambourg wrote:

> Probablement. A ma connaissance l'état de liaison d'un pont est lié à
> celui de ses "ports". Quel est l'état des interfaces pontées côté hôte ?

Et bien justement, avec Virtualbox, ça a toujours été un peu un mystère
pour moi, mais des commandes comme "ip l" ou "ip a" n'affichent jamais
aucune des interfaces pontées. Je ne sais même pas comment elles sont
définies d'ailleurs. Je serais intéressé d'avoir une explication là
dessus d'ailleurs : comment on peut afficher les interfaces pontées
que doit forcément créer Virtualbox lorsque que ses VM démarrent ?

Par exemple sur ma Ubuntu 20.04 où tout fonctionne et où j'ai en ce
moment même une VM UP et accessible (je me ssh dessus), j'ai ceci :

------------------------------------------------------------
$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000

link/ether b0:22:7a:ff:9d:bf brd ff:ff:ff:ff:ff:ff

3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000

link/ether a4:97:b1:5f:db:6b brd ff:ff:ff:ff:ff:ff

inet 192.168.0.138/24 brd 192.168.0.255 scope global dynamic
noprefixroute wlp2s0

valid_lft 83342sec preferred_lft 83342sec

inet6 fe80::25d:bcad:5217:40e0/64 scope link noprefixroute

valid_lft forever preferred_lft forever

4: br-virt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN group default qlen 1000

link/ether 3e:eb:3a:4f:82:ac brd ff:ff:ff:ff:ff:ff

inet 10.111.222.1/24 scope global br-virt

valid_lft forever preferred_lft forever

inet6 fe80::3ceb:3aff:fe4f:82ac/64 scope link

valid_lft forever preferred_lft forever

5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default

link/ether 02:42:ec:2b:8f:41 brd ff:ff:ff:ff:ff:ff

inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

valid_lft forever preferred_lft forever


$ sudo bridge link show
$ # n'affiche rien.

$ sudo brctl show

bridge name bridge id STP enabled interfaces

br-virt 8000.000000000000 no

docker0 8000.0242ec2b8f41 no
------------------------------------------------------------

D'après la dernière commande, aucune interface pontée sur br-virt,
alors que pourtant j'arrive à me ssh en ce moment même sur une VM
qui est UP et, d'après la GUI de Virtualbox, qui est bien bridgée
sur br-virt. Comment c'est possible ?

Et sur ma Ubuntu 22.04 où ça ne marche pas, c'est la même chose,
je n'ai trouvé aucune commande qui m'affiche le début d'une
interface pontée sur br-virt :

------------------------------------------------------------
$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000

link/ether 00:1b:21:dd:0b:a8 brd ff:ff:ff:ff:ff:ff

inet 192.168.0.1/24 brd 192.168.0.255 scope global dynamic
noprefixroute eth0

valid_lft 85307sec preferred_lft 85307sec

inet6 fe80::21b:21ff:fedd:ba8/64 scope link noprefixroute

valid_lft forever preferred_lft forever

3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
DOWN group default qlen 1000

link/ether 00:1b:21:dd:0b:a9 brd ff:ff:ff:ff:ff:ff

4: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
DOWN group default qlen 1000

link/ether 18:60:24:a5:78:4a brd ff:ff:ff:ff:ff:ff

altname enp2s0

altname eno2

5: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN group default qlen 1000

link/ether 18:60:24:a5:78:49 brd ff:ff:ff:ff:ff:ff

altname enp0s31f6

6: br-virt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default qlen 1000

link/ether 9a:aa:18:5f:0f:ee brd ff:ff:ff:ff:ff:ff

inet 10.111.222.1/24 scope global br-virt

valid_lft forever preferred_lft forever

7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default

link/ether 02:42:93:0e:6f:4c brd ff:ff:ff:ff:ff:ff

inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

valid_lft forever preferred_lft forever


$ sudo bridge link show
$ # n'affiche rien.

$ sudo brctl show

bridge name bridge id STP enabled interfaces

br-virt 8000.9aaa185f0fee no

docker0 8000.0242930e6f4c no
------------------------------------------------------------

Rien non plus. Avec Virtualbox, on a l'impression que les interfaces
sont cachées. Pourtant je me disais qu'avec la commande "ip" aucune
interface ne pouvait nous échapper, car il faut bien que le noyau
Linux soit au courant qu'une interface est créée, non ?

Du coup, malheureusement ça ne donne pas vraiment d'info...

[Pascal Hambourg]

Le 18/08/2022 à 00:05, François Lafont a écrit :
> On 8/17/22 23:02, Pascal Hambourg wrote:
>
>> Probablement. A ma connaissance l'état de liaison d'un pont est lié à
>> celui de ses "ports". Quel est l'état des interfaces pontées côté hôte ?
>
> Et bien justement, avec Virtualbox, ça a toujours été un peu un mystère
> pour moi, mais des commandes comme "ip l" ou "ip a" n'affichent jamais
> aucune des interfaces pontées. Je ne sais même pas comment elles sont
> définies d'ailleurs. Je serais intéressé d'avoir une explication là
> dessus d'ailleurs : comment on peut afficher les interfaces pontées
> que doit forcément créer Virtualbox lorsque que ses VM démarrent ?

Aucune idée...
As-tu essayé de ponter une interface factice (dummy) activée pour voir ?

[Marc SCHAEFER]

François Lafont <fl...@me.invalid> wrote:
> Et bien justement, avec Virtualbox, ça a toujours été un peu un mystère
> pour moi, mais des commandes comme "ip l" ou "ip a" n'affichent jamais
> aucune des interfaces pontées.

Ca pourrait être un autre namespace, je crois qu'on peut les lister sous
/proc/PID/ns/net, avec PID le numéro du processus.

J'ai déjà utilisé des namespaces privés pour le réseau, ainsi:

pid= # obtenir
netns=/var/run/netns
mkdir -p $netns
ln -s /proc/$pid/ns/net $netns/nom

ip netns exec nom ip link set up dev eth0

J'utilise ça pour gérer mes propres interfaces bridgées dans mon
mini-cloud, commutées ensuite via des VLAN dynamiques pour virtualiser
l'emplacement des machines (5 serveurs de virtualisation, les bridges
fonctionnent quel que soit le serveur.

[François Lafont]

On 8/18/22 07:37, Pascal Hambourg wrote:

> Aucune idée...
> As-tu essayé de ponter une interface factice (dummy) activée pour voir ?

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
-------------------------------

Et au final, j'ai toujours un br-virt vu comme down :

-------------------------------
$ ip -j link show dev br-virt | jq

[

{

"ifindex": 6,

"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 address show dev br-virt | jq

[

{

"ifindex": 6,

"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": "global",

"label": "br-virt",

"valid_life_time": 4294967295,

"preferred_life_time": 4294967295

}

]

}

]


$ ip -j link show dev dummy0 | jq

[

{

"ifindex": 8,

"ifname": "dummy0",

"flags": [

"BROADCAST",

"NOARP"

],

"mtu": 1500,

"qdisc": "noop",

"master": "br-virt",

"operstate": "DOWN",

"linkmode": "DEFAULT",

"group": "default",

"txqlen": 1000,

"link_type": "ether",

"address": "a2:d9:63:89:46:87",

"broadcast": "ff:ff:ff:ff:ff:ff"

}

]


$ ip -j address show dev dummy0 | jq

[

{

"ifindex": 8,

"ifname": "dummy0",

"flags": [

"BROADCAST",

"NOARP"

],

"mtu": 1500,

"qdisc": "noop",

"master": "br-virt",

"operstate": "DOWN",

"group": "default",

"txqlen": 1000,

"link_type": "ether",

"address": "a2:d9:63:89:46:87",

"broadcast": "ff:ff:ff:ff:ff:ff",

"addr_info": [

{

"family": "inet",

"local": "10.111.222.200",

"prefixlen": 24,

"scope": "global",

"label": "dummy0",

"valid_life_time": 4294967295,

"preferred_life_time": 4294967295

}

]

}

]


$ brctl show

bridge name bridge id STP enabled interfaces

br-virt 8000.9aaa185f0fee no dummy0

docker0 8000.02420dd8ebcb no
-------------------------------

Et au final, j'ai testé, je ne pingue toujours pas ma VM.


Perso, étant donné que ça marchait nickel en Ubuntu 20.04,
je verrais bien une histoire de mise à jour du noyau qui
ferait que les bridges ne se comportent plus tout à fait
pareil, une option du noyau qui aurait changé etc. Mais
bon, c'est une hypothèse...

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 :

-------------------------------
$ ping -n 10.111.222.1

PING 10.111.222.1 (10.111.222.1) 56(84) bytes of data.

64 bytes from 10.111.222.1: icmp_seq=1 ttl=64 time=0.054 ms

64 bytes from 10.111.222.1: icmp_seq=2 ttl=64 time=0.055 ms

64 bytes from 10.111.222.1: icmp_seq=3 ttl=64 time=0.047 ms
...
-------------------------------

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 :

-------------------------------
$ sudo tcpdump -nn -i br-virt icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode

listening on br-virt, link-type EN10MB (Ethernet), snapshot length
262144 bytes

... # rien ne s'affiche alors que le ping ci-dessus s'exécute ?

-------------------------------

Comment c'est possible un truc pareil ?

[François Lafont]

Re,

Je réponds au message que Marc Schaefer que j'ai vu
sur la page de Google du groupe, mais que je ne vois
pas apparaître sur mon client de news (aucune idée
de pourquoi).

> François Lafont <fl...@me.invalid> wrote:
>> Et bien justement, avec Virtualbox, ça a toujours été un peu un mystère
>> pour moi, mais des commandes comme "ip l" ou "ip a" n'affichent jamais
>> aucune des interfaces pontées.
>

> Ca pourrait être un autre namespace, je crois qu'on peut les lister sous
> /proc/PID/ns/net, avec PID le numéro du processus.
>
> J'ai déjà utilisé des namespaces privés pour le réseau, ainsi:
>
> pid= # obtenir
> netns=/var/run/netns
> mkdir -p $netns
> ln -s /proc/$pid/ns/net $netns/nom
>
> ip netns exec nom ip link set up dev eth0
>
> J'utilise ça pour gérer mes propres interfaces bridgées dans mon
> mini-cloud, commutées ensuite via des VLAN dynamiques pour virtualiser
> l'emplacement des machines (5 serveurs de virtualisation, les bridges
> fonctionnent quel que soit le serveur.

Alors je ne suis pas très calé en namespace. Sur ma machine, j'ai ceci :

-------------------------------------
~# ip netns list

~# # vide

~# lsns --type=net

NS TYPE NPROCS PID USER NETNSID NSFS COMMAND

4026531840 net 343 1 root unassigned /sbin/init splash

4026533005 net 1 1296 root unassigned /usr/libexec/accounts-daemon

4026533062 net 1 1841 rtkit unassigned /usr/libexec/rtkit-daemon

4026533128 net 1 8391 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 1
-isForBrowser -prefsLen 45458 -prefMapSize 2767

4026533422 net 1 9295 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 7
-isForBrowser -prefsLen 51136 -prefMapSize 2767

4026533480 net 1 8872 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 3
-isForBrowser -prefsLen 45564 -prefMapSize 2767

4026533538 net 1 8874 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 4
-isForBrowser -prefsLen 45564 -prefMapSize 2767

4026533596 net 1 9013 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 5
-isForBrowser -prefsLen 50171 -prefMapSize 2767

4026533654 net 1 27030 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 40
-isForBrowser -prefsLen 52443 -prefMapSize 276

4026533712 net 1 27070 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 41
-isForBrowser -prefsLen 52443 -prefMapSize 276

4026533771 net 1 28144 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 43
-isForBrowser -prefsLen 52443 -prefMapSize 276

4026533827 net 1 9481 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -parentBuildID
20220811234741 -prefsLen 51136 -prefMapSize

4026533943 net 1 9701 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 13
-isForBrowser -prefsLen 51136 -prefMapSize 276

4026534001 net 1 9705 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 14
-isForBrowser -prefsLen 51136 -prefMapSize 276

4026534059 net 1 26987 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 39
-isForBrowser -prefsLen 52443 -prefMapSize 276

4026534118 net 1 27453 flaf unassigned
/snap/firefox/1689/usr/lib/firefox/firefox -contentproc -childID 42
-isForBrowser -prefsLen 52443 -prefMapSize 276

root@flhpz4:~#
-------------------------------------

Ensuite, j'ai vu sur le web qu'on pouvait lister les network
namespaces comme ceci :

-------------------------------------
1563 net:[4026531840]

4 net:[4026533005]

4 net:[4026533062]

27 net:[4026533128]

28 net:[4026533422]

28 net:[4026533480]

27 net:[4026533538]

27 net:[4026533596]

29 net:[4026533654]

19 net:[4026533712]

20 net:[4026533771]

4 net:[4026533827]

28 net:[4026533943]

27 net:[4026534001]

28 net:[4026534059]

19 net:[4026534118]

-------------------------------------

Mais je ne sais pas trop quoi faire de ça. J'ai comprendre que
les nombres entre crochets correspondent à des numéros d'inodes.
Mais après, il y a moyen de lister des interfaces réseau contenues
dans ces namespaces ?

[Marc SCHAEFER]

François Lafont <fl...@me.invalid> wrote:
> Mais après, il y a moyen de lister des interfaces réseau contenues
> dans ces namespaces ?

Oui, sauf erreur avec

ip link show netns XXX

Il me *semble* que si tu veux donner des noms jolis tu dois passer par
le fameux symlink.

Une autre solution serait de directement regarder dans le /proc
correspondant aux processus de VBox.

[flaf flaf]

Heu... questions :

1. Dans ta commande, c'est quoi XXX ? Un PID, le numéro d'un inode ?

2. Sur ma Ubuntu 22.04, ta commande semble avoir une syntaxe incorrect :

~# ip link show netns 4026533005

Error: either "dev" is duplicate, or "4026533005" is a garbage.

[Marc SCHAEFER]

flaf flaf <flaf...@gmail.com> wrote:
> 1. Dans ta commande, c'est quoi XXX ? Un PID, le numéro d'un inode ?

Dans mon expérience, le nom du netns symlinké dans /var/run/netns

[Pascal Hambourg]

Le 18/08/2022 à 11:42, François Lafont a écrit :
> On 8/18/22 07:37, Pascal Hambourg wrote:
>
>> As-tu essayé de ponter une interface factice (dummy) activée pour voir ?
>
> 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).

> $ ip -j link show dev dummy0 | jq

(...)

>     "ifname": "dummy0",
>     "flags": [
>       "BROADCAST",
>       "NOARP"

(...)
>     "operstate": "DOWN",

Confirmé.

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.

> 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.

[flaf]

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.

[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).

[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.

[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.

[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.