VMs attached to the same bridge cannot ping each other
up vote
1
down vote
favorite
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
New contributor
add a comment |
up vote
1
down vote
favorite
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
New contributor
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
yesterday
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
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
"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
yesterday
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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
New contributor
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
New contributor
New contributor
edited yesterday
Rui F Ribeiro
38.6k1479128
38.6k1479128
New contributor
asked yesterday
user3427483
62
62
New contributor
New contributor
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
yesterday
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
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
"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
yesterday
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
yesterday
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
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
"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
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
"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
yesterday
"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
yesterday
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
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!
New contributor
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',
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
});
}
});
user3427483 is a new contributor. Be nice, and check out our Code of Conduct.
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
up vote
0
down vote
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!
New contributor
add a comment |
up vote
0
down vote
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!
New contributor
add a comment |
up vote
0
down vote
up vote
0
down vote
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!
New contributor
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!
New contributor
edited yesterday
New contributor
answered yesterday
user3427483
62
62
New contributor
New contributor
add a comment |
add a comment |
user3427483 is a new contributor. Be nice, and check out our Code of Conduct.
user3427483 is a new contributor. Be nice, and check out our Code of Conduct.
user3427483 is a new contributor. Be nice, and check out our Code of Conduct.
user3427483 is a new contributor. Be nice, and check out our Code of Conduct.
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
yesterday
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
yesterday
@sourcejedi Nothing more than one line "ip addr add 192.168.122.10/24 dev ens3"
– user3427483
yesterday
Have you enabled IP forwarding in the host?
– Rui F Ribeiro
yesterday
"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
yesterday