VMs attached to the same bridge cannot ping each other
Clash Royale CLAN TAG#URR8PPP
I am now trying to host two VMs directly by qemu, without any tools like libvirt.
I did setup the bridge/tap interfaces for each of them like
ip link add br0 type bridge
ip addr add 192.168.122.1/24 dev br0
ip link set br0 up
ip tuntap add mode tap tap0
ip link set tap0 master br0
ip link set tap0 up // tap1 as well
and launch VMs by command:
qemu-system-x86_64 -enable-kvm -m 1G
-cdrom archlinux-2018.12.01-x86_64.iso
-drive file=vm.raw,format=raw,id=hd0
-device virtio-net,netdev=network0
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=network1
-netdev user,id=network1
Note that I assign two network card intentionally. The user
network ensures that the VMs can access Internet, and I want the tap network available as a subnet. I assign manual IPs to the VMs' network interface in their console.
With this setup, the host can ping each VM, and each VM can ping the host, but VM0 just cannot ping VM1 and vice versa. I tried to play around with the iptable rules like
iptables -A FORWARD -i br0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -j MASQUERADE
But still in vain.
Clarification 1. (to sourcejedi)
As you can see this launch command is a liveCD of Arch Linux. This boot directly into shell. By default, the interface from tap has no IP nor route settings.
The qemu is 3.0.0.
Host is Arch Linux.
Clarification 2.
It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication.
networking iptables virtual-machine qemu
add a comment |
I am now trying to host two VMs directly by qemu, without any tools like libvirt.
I did setup the bridge/tap interfaces for each of them like
ip link add br0 type bridge
ip addr add 192.168.122.1/24 dev br0
ip link set br0 up
ip tuntap add mode tap tap0
ip link set tap0 master br0
ip link set tap0 up // tap1 as well
and launch VMs by command:
qemu-system-x86_64 -enable-kvm -m 1G
-cdrom archlinux-2018.12.01-x86_64.iso
-drive file=vm.raw,format=raw,id=hd0
-device virtio-net,netdev=network0
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=network1
-netdev user,id=network1
Note that I assign two network card intentionally. The user
network ensures that the VMs can access Internet, and I want the tap network available as a subnet. I assign manual IPs to the VMs' network interface in their console.
With this setup, the host can ping each VM, and each VM can ping the host, but VM0 just cannot ping VM1 and vice versa. I tried to play around with the iptable rules like
iptables -A FORWARD -i br0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -j MASQUERADE
But still in vain.
Clarification 1. (to sourcejedi)
As you can see this launch command is a liveCD of Arch Linux. This boot directly into shell. By default, the interface from tap has no IP nor route settings.
The qemu is 3.0.0.
Host is Arch Linux.
Clarification 2.
It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication.
networking iptables virtual-machine qemu
tcpdump
bypassesiptables
. When pinging between VMs, if you runtcpdump
inside the VMstcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?
– sourcejedi
Dec 13 at 9:45
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19
add a comment |
I am now trying to host two VMs directly by qemu, without any tools like libvirt.
I did setup the bridge/tap interfaces for each of them like
ip link add br0 type bridge
ip addr add 192.168.122.1/24 dev br0
ip link set br0 up
ip tuntap add mode tap tap0
ip link set tap0 master br0
ip link set tap0 up // tap1 as well
and launch VMs by command:
qemu-system-x86_64 -enable-kvm -m 1G
-cdrom archlinux-2018.12.01-x86_64.iso
-drive file=vm.raw,format=raw,id=hd0
-device virtio-net,netdev=network0
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=network1
-netdev user,id=network1
Note that I assign two network card intentionally. The user
network ensures that the VMs can access Internet, and I want the tap network available as a subnet. I assign manual IPs to the VMs' network interface in their console.
With this setup, the host can ping each VM, and each VM can ping the host, but VM0 just cannot ping VM1 and vice versa. I tried to play around with the iptable rules like
iptables -A FORWARD -i br0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -j MASQUERADE
But still in vain.
Clarification 1. (to sourcejedi)
As you can see this launch command is a liveCD of Arch Linux. This boot directly into shell. By default, the interface from tap has no IP nor route settings.
The qemu is 3.0.0.
Host is Arch Linux.
Clarification 2.
It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication.
networking iptables virtual-machine qemu
I am now trying to host two VMs directly by qemu, without any tools like libvirt.
I did setup the bridge/tap interfaces for each of them like
ip link add br0 type bridge
ip addr add 192.168.122.1/24 dev br0
ip link set br0 up
ip tuntap add mode tap tap0
ip link set tap0 master br0
ip link set tap0 up // tap1 as well
and launch VMs by command:
qemu-system-x86_64 -enable-kvm -m 1G
-cdrom archlinux-2018.12.01-x86_64.iso
-drive file=vm.raw,format=raw,id=hd0
-device virtio-net,netdev=network0
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=network1
-netdev user,id=network1
Note that I assign two network card intentionally. The user
network ensures that the VMs can access Internet, and I want the tap network available as a subnet. I assign manual IPs to the VMs' network interface in their console.
With this setup, the host can ping each VM, and each VM can ping the host, but VM0 just cannot ping VM1 and vice versa. I tried to play around with the iptable rules like
iptables -A FORWARD -i br0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.122.0/24 -j MASQUERADE
But still in vain.
Clarification 1. (to sourcejedi)
As you can see this launch command is a liveCD of Arch Linux. This boot directly into shell. By default, the interface from tap has no IP nor route settings.
The qemu is 3.0.0.
Host is Arch Linux.
Clarification 2.
It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication.
networking iptables virtual-machine qemu
networking iptables virtual-machine qemu
edited Dec 13 at 10:22
Rui F Ribeiro
38.8k1479128
38.8k1479128
asked Dec 13 at 9:25
user3427483
62
62
tcpdump
bypassesiptables
. When pinging between VMs, if you runtcpdump
inside the VMstcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?
– sourcejedi
Dec 13 at 9:45
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19
add a comment |
tcpdump
bypassesiptables
. When pinging between VMs, if you runtcpdump
inside the VMstcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?
– sourcejedi
Dec 13 at 9:45
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19
tcpdump
bypasses iptables
. When pinging between VMs, if you run tcpdump
inside the VMs tcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?– sourcejedi
Dec 13 at 9:45
tcpdump
bypasses iptables
. When pinging between VMs, if you run tcpdump
inside the VMs tcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?– sourcejedi
Dec 13 at 9:45
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19
add a comment |
1 Answer
1
active
oldest
votes
In theory, once two taps are attached the VMs and both of them connects to a bridge on the host with proper IP setup (DHCP or manual), they should be able to ping each other without iptable tweaks.
This question stems from the fact that I launch each VM by an over-simplified command, which assign all network devices an identical MAC address. That is to say, one should always assign distinct MAC addresses to her virtual cluster, such as a simple augmentation to the original command:
-device virtio-net,netdev=network0,mac=52:54:01:12:34:56
And finally, thanks for all the hints from sourcejedi!
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487719%2fvms-attached-to-the-same-bridge-cannot-ping-each-other%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
In theory, once two taps are attached the VMs and both of them connects to a bridge on the host with proper IP setup (DHCP or manual), they should be able to ping each other without iptable tweaks.
This question stems from the fact that I launch each VM by an over-simplified command, which assign all network devices an identical MAC address. That is to say, one should always assign distinct MAC addresses to her virtual cluster, such as a simple augmentation to the original command:
-device virtio-net,netdev=network0,mac=52:54:01:12:34:56
And finally, thanks for all the hints from sourcejedi!
add a comment |
In theory, once two taps are attached the VMs and both of them connects to a bridge on the host with proper IP setup (DHCP or manual), they should be able to ping each other without iptable tweaks.
This question stems from the fact that I launch each VM by an over-simplified command, which assign all network devices an identical MAC address. That is to say, one should always assign distinct MAC addresses to her virtual cluster, such as a simple augmentation to the original command:
-device virtio-net,netdev=network0,mac=52:54:01:12:34:56
And finally, thanks for all the hints from sourcejedi!
add a comment |
In theory, once two taps are attached the VMs and both of them connects to a bridge on the host with proper IP setup (DHCP or manual), they should be able to ping each other without iptable tweaks.
This question stems from the fact that I launch each VM by an over-simplified command, which assign all network devices an identical MAC address. That is to say, one should always assign distinct MAC addresses to her virtual cluster, such as a simple augmentation to the original command:
-device virtio-net,netdev=network0,mac=52:54:01:12:34:56
And finally, thanks for all the hints from sourcejedi!
In theory, once two taps are attached the VMs and both of them connects to a bridge on the host with proper IP setup (DHCP or manual), they should be able to ping each other without iptable tweaks.
This question stems from the fact that I launch each VM by an over-simplified command, which assign all network devices an identical MAC address. That is to say, one should always assign distinct MAC addresses to her virtual cluster, such as a simple augmentation to the original command:
-device virtio-net,netdev=network0,mac=52:54:01:12:34:56
And finally, thanks for all the hints from sourcejedi!
edited Dec 14 at 2:23
answered Dec 14 at 1:21
user3427483
62
62
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487719%2fvms-attached-to-the-same-bridge-cannot-ping-each-other%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
tcpdump
bypassesiptables
. When pinging between VMs, if you runtcpdump
inside the VMstcpdump
show 1) the ECHO request being received 2) the ECHO reply being received ?– sourcejedi
Dec 13 at 9:45
but you must have set up some network configuration inside the guests, otherwise the host would have nothing to ping. What is that configuration?
– sourcejedi
Dec 13 at 9:48
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
Dec 13 at 9:50
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
Dec 13 at 10:22
"It turns out that the default MAC are both 52:54:00:12:34:56, so they cannot establish any communication." Sounds like you found the answer :-). This site allows and encourages you to post answers for your own questions.
– sourcejedi
Dec 13 at 15:19