You are not logged in.
I have trouble addressing VMs in my network for example via ssh.
Sometimes ssh to 192.168.178.93 will lead to connection attempt to 192.168.178.83
I m a bit lost in finding the root-cause, its sporadic nature and the problem itslef really scares and drives me nuts.
Workarounds are connecting to different clients and sshing from there. But i cant find a rule in from which device it always works reliable.
I would appreciate a helping hand here.
ip addr:
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: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether b4:2e:99:e0:fd:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.83/24 brd 192.168.178.255 scope global dynamic noprefixroute enp5s0
valid_lft 704816sec preferred_lft 596816sec
inet6 2002:5097:b6e6:0:6a0b:db2:2ced:dea3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6644sec preferred_lft 3044sec
inet6 fe80::8c1:1250:f2be:f415/64 scope link
valid_lft forever preferred_lft forever
3: macvtap0@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:fd:3e:c7 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.97/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap0
valid_lft 704816sec preferred_lft 596816sec
inet6 fe80::c440:6a6b:72fb:8e66/64 scope link
valid_lft forever preferred_lft forever
4: macvtap1@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:0b:d2:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.93/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap1
valid_lft 704815sec preferred_lft 596815sec
inet6 fe80::d330:74ea:3886:de59/64 scope link
valid_lft forever preferred_lft forever
5: macvtap2@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:e1:de:9a brd ff:ff:ff:ff:ff:ff
inet 192.168.178.63/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap2
valid_lft 704816sec preferred_lft 596816sec
inet6 fe80::f611:302c:dcfe:6da8/64 scope link
valid_lft forever preferred_lft foreverarp-scan :
...
192.168.178.63 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.65 52:54:00:e1:de:9a QEMU
192.168.178.83 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
...
192.168.178.93 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.93 52:54:00:0b:d2:a9 QEMU (DUP: 2)
192.168.178.97 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.97 52:54:00:fd:3e:c7 QEMU (DUP: 2)
...Not sure if i have a mac issue and also, apparently sometimes arp-scan seems to not see the addresses also.
Last edited by lDariuz (2021-06-06 08:50:29)
Offline
I wonder how IP would work reliably with MAC addresses duplicated all over the place. Then again, I don't know anything about Macvtap.
Offline
I wonder how IP would work reliably with MAC addresses duplicated all over the place. Then again, I don't know anything about Macvtap.
Yes i was reall thinking the same ... i mean this b4:2e:99:e0:fd:15 mac has 192.168.178.63,192.168.178.83,... basically all ips assigned. This looks wrong. but then where does it come from and how to change that i dont know ... ip addr doesnt look totaly wrong to me though ...
Offline
How were these macvtap2 devices created? Using the `ip link add` command?
Could you please post the result of `ip link show`?
Offline
How were these macvtap2 devices created? Using the `ip link add` command?
Could you please post the result of `ip link show`?
ip link show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether b4:2e:99:e0:fd:15 brd ff:ff:ff:ff:ff:ff
3: macvtap0@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
link/ether 52:54:00:fd:3e:c7 brd ff:ff:ff:ff:ff:ff
4: macvtap1@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
link/ether 52:54:00:0b:d2:a9 brd ff:ff:ff:ff:ff:ff
5: macvtap2@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 500
link/ether 52:54:00:e1:de:9a brd ff:ff:ff:ff:ff:ffI think virt-manager did it with wizard. I haven't touched them directly.
Last edited by lDariuz (2021-06-06 15:39:57)
Offline
That looks reasonable. All devices have distinct MAC addresses.
How frequently have you observed being directed to the wrong IP address?
If I wanted to reproduce your setup, how would I go about it?
Offline
Unfortunately i don't know exactly what versions i used to create the VMs back then but i tried again with following steps:
virt-manager:
Create a new VM use (arch) .iso. (optionally do not create a disk)
Click through wizard until step 5of5.
Select macvtap device.. on Network Setting and enter valid device name for me enp5s0.
It should create a VM with basically this setting:
Newly Created VM:
...
<interface type="direct">
<mac address="52:54:00:00:e0:06"/>
<source dev="enp5s0" mode="bridge"/>
<target dev="macvtap3"/>
<model type="virtio"/>
<alias name="net0"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
...From there i see:
ip addr
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: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether b4:2e:99:e0:fd:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.83/24 brd 192.168.178.255 scope global dynamic noprefixroute enp5s0
valid_lft 670444sec preferred_lft 562444sec
inet6 2002:5097:b6e6:0:6a0b:db2:2ced:dea3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 7073sec preferred_lft 3473sec
inet6 fe80::8c1:1250:f2be:f415/64 scope link
valid_lft forever preferred_lft forever
3: macvtap0@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:fd:3e:c7 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.97/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap0
valid_lft 670443sec preferred_lft 562443sec
inet6 fe80::c440:6a6b:72fb:8e66/64 scope link
valid_lft forever preferred_lft forever
4: macvtap1@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:0b:d2:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.93/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap1
valid_lft 670443sec preferred_lft 562443sec
inet6 fe80::d330:74ea:3886:de59/64 scope link
valid_lft forever preferred_lft forever
5: macvtap2@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:e1:de:9a brd ff:ff:ff:ff:ff:ff
inet 192.168.178.63/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap2
valid_lft 670444sec preferred_lft 562444sec
inet6 fe80::f611:302c:dcfe:6da8/64 scope link
valid_lft forever preferred_lft forever
6: macvtap3@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
link/ether 52:54:00:00:e0:06 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.59/24 brd 192.168.178.255 scope global dynamic noprefixroute macvtap3
valid_lft 863909sec preferred_lft 755909sec
inet6 fe80::40a1:4b5:afdb:b87a/64 scope link
valid_lft forever preferred_lft foreverarp-scan --localnet | grep -E "QEMU|GIGA"
...
new(?) 192.168.178.59 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
new(?) 192.168.178.61 52:54:00:00:e0:06 QEMU
192.168.178.63 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.65 52:54:00:e1:de:9a QEMU
192.168.178.83 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.93 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.93 52:54:00:0b:d2:a9 QEMU (DUP: 2)
192.168.178.97 b4:2e:99:e0:fd:15 GIGA-BYTE TECHNOLOGY CO.,LTD.
192.168.178.97 52:54:00:fd:3e:c7 QEMU (DUP: 2)
..now i m a bit confused by the apr-scan output ... i think it looks different from the VMs created back then.
Interestingly the virt-manager menu shows now some difference too while ip address is unknown for old device with 52:54:00:0b:d2:a9 or 52:54:00:fd:3e:c7
It is known for newly created device. 52:54:00:00:e0:06 > 192.168.178.61
Also continuing in ISO VM by doing
passwd
and sshing from remote do successfull connect in contrast to the other VMs where it is currently not working... Not sure if and how the problem is resolved though as i think it might created a new GIGA-BYTE entry though maybe with different address.
Thank you already a lot tucuxi! This made some things clearer to me .. So i think whatever created the wrong setting might be now fixed. Though i think i need to change the ip of the GIGA device somehow and i do not know how to do that now ...
Any help or even comparison with your output would be much appriciated...
Last edited by lDariuz (2021-06-06 18:14:51)
Offline