You are not logged in.

#1 2021-06-06 08:23:13

lDariuz
Member
Registered: 2015-09-14
Posts: 4

Trouble with addressing QENU (Macvtap) VM via ssh

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 forever

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

#2 2021-06-06 08:35:00

tucuxi
Member
From: Switzerland
Registered: 2020-03-08
Posts: 291

Re: Trouble with addressing QENU (Macvtap) VM via ssh

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

#3 2021-06-06 08:46:42

lDariuz
Member
Registered: 2015-09-14
Posts: 4

Re: Trouble with addressing QENU (Macvtap) VM via ssh

tucuxi wrote:

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

#4 2021-06-06 13:07:49

tucuxi
Member
From: Switzerland
Registered: 2020-03-08
Posts: 291

Re: Trouble with addressing QENU (Macvtap) VM via ssh

How were these macvtap2 devices created? Using the `ip link add` command?

Could you please post the result of `ip link show`?

Offline

#5 2021-06-06 15:33:08

lDariuz
Member
Registered: 2015-09-14
Posts: 4

Re: Trouble with addressing QENU (Macvtap) VM via ssh

tucuxi wrote:

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

I think virt-manager did it with wizard. I haven't touched them directly.

Last edited by lDariuz (2021-06-06 15:39:57)

Offline

#6 2021-06-06 16:41:06

tucuxi
Member
From: Switzerland
Registered: 2020-03-08
Posts: 291

Re: Trouble with addressing QENU (Macvtap) VM via ssh

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

#7 2021-06-06 17:55:39

lDariuz
Member
Registered: 2015-09-14
Posts: 4

Re: Trouble with addressing QENU (Macvtap) VM via ssh

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 forever

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

Board footer

Powered by FluxBB