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. :)
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 ?
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 ?
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=c3=a7ois 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...
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
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
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...
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 ?
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 ?
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 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 <flaf@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:
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.
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=c3=a7ois 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 ttld time=0.054 ms 64 bytes from 10.111.222.1: icmp_seq=2 ttld time=0.055 ms 64 bytes from 10.111.222.1: icmp_seq=3 ttld 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 ?
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 :
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 ttld time=0.054 ms 64 bytes from 10.111.222.1: icmp_seq=2 ttld time=0.055 ms 64 bytes from 10.111.222.1: icmp_seq=3 ttld 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=c3=a7ois 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 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 :~# ------------------------------------- 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 ?
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:
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
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 ?
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 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 :~# ------------------------------------- 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 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.
François Lafont <flaf@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.
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
Le jeudi 18 aoÍ»t 2022 Í 12:51:38 UTC+2, Marc SCHAEFER a écrit :
François Lafont 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.
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.
Le jeudi 18 aoÍ»t 2022 Í 12:51:38 UTC+2, Marc SCHAEFER a écrit :
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.
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.
Le jeudi 18 aoÍ»t 2022 Í 12:51:38 UTC+2, Marc SCHAEFER a écrit :
François Lafont 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.
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 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
flaf flaf <flaf.misc@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
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.
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.
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.
