I had the issue of duplicate IP's on my network and happened across another post that seemed to sort things out. But it introduced a new issue that I haven't been able to figure out.

 

I figured out my error after re-reading the post @murkus wrote. I had the custom network for the eth0 still enabled in the docker config.

 

That solved the duplicate IP, different MAC issue!

 

BUT! I seem to have now run into another problem. HAOS VM is using the vhost0 network and it is accessible on the network. But there was an error in HAOS about a failed mounted network storage volume that is located on the host system.

 

[853.7504591] CIFS: VFS: Error connecting to socket. Aborting operation.
[853.7518201] CIFS: VFS: cifs mount failed w/return code = -115

 

After pulling my hair out I determined that while everyone on the network can access the HAOS website, and HAOS can ping and mount shares on other systems, HAOS can't ping or mount anything on the host system and the host system can't ping the VM.

 

HOST (UnRaid): 192.168.200.88

HAOS VM: 192.168.200.87

 

Can't ping VM from HOST

root@KNOXX:~# ping 192.168.200.87
PING 192.168.200.87 (192.168.200.87) 56(84) bytes of data.
From 192.168.200.88 icmp_seq=1 Destination Host Unreachable
From 192.168.200.88 icmp_seq=2 Destination Host Unreachable
From 192.168.200.88 icmp_seq=3 Destination Host Unreachable
From 192.168.200.88 icmp_seq=4 Destination Host Unreachable
From 192.168.200.88 icmp_seq=5 Destination Host Unreachable
From 192.168.200.88 icmp_seq=6 Destination Host Unreachable
From 192.168.200.88 icmp_seq=7 Destination Host Unreachable
^C
--- 192.168.200.87 ping statistics ---
8 packets transmitted, 0 received, +7 errors, 100% packet loss, time 7195ms
pipe 4
root@KNOXX:~# 

 

Can't ping HOST from VM

 

Host UnRaid routing table

root@KNOXX:~# ip route
default via 192.168.200.1 dev eth0 metric 1 
default via 192.168.202.1 dev eth0.2 metric 2 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.88 metric 1 
192.168.200.0/24 dev br1 proto kernel scope link src 192.168.200.253 metric 1 linkdown 
192.168.202.0/24 dev vhost0.2 proto kernel scope link src 192.168.202.2 
192.168.202.0/24 dev eth0.2 proto kernel scope link src 192.168.202.2 metric 1 
root@KNOXX:~# 

 

HAOS VM routing table

# ip route
default via 192.168.200.1 dev enp1s0 proto static metric 100
172.30.32.O/23 dev hassio proto kernel scope link src 172.30.32.1
172.30.232.0/23 dev docker0 proto kernel scope link src 172.30.232.1
192.168.2OO.0/24 dev enp1s0 proto kernel scope link src 192.168.2OO.87 metric 100

 

 

Any thoughts??

BUMP

 

This has to be an issue with UR as I can map SMB drives in HAOS on other systems on the network. It's just connecting to the host IP address or hostname that does not work.

 

Also, the duplicate HOST IP is on the network again with a different MAC. I suspect that this is the main culprit. I believe the HAOS VM, because it goes through the MACVTAP, it believes that eth0.2 'IS' the system I am trying to connect to. Since there are no shares there (it's a bridge after all) it fails.

 

I've cleaned up a bunch of things that were not being used, mainly extra NICs that were in the system that I chose not to use. There is only one physical NIC in the system now and it has no bridging or bonding set. I do have a VLAN configured on it and that is being used for most of my Docker containers.

 

 

 

 

 

Docker config

 

 

Now from what I gather, because I have a VLAN set, the system is creating a VHOST for it, eth0.2 as well as etho. It is the MAC for eth0.2 that is causing the duplicated HOST IP on the network

 

root@KNOXX:~# 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: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 3c:8c:f8:ee:59:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.88/24 metric 1 scope global eth0
       valid_lft forever preferred_lft forever
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:8c:f8:ee:59:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.2/24 metric 1 scope global eth0.2
       valid_lft forever preferred_lft forever
6: vhost0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500
    link/ether 02:65:43:f8:ad:c4 brd ff:ff:ff:ff:ff:ff
7: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500
    link/ether 02:65:43:f8:ad:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.2/24 scope global vhost0.2
       valid_lft forever preferred_lft forever
8: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:b4:d2:d6:aa 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
10: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ca:33:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
11: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
    link/ether 52:54:00:94:77:76 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe94:7776/64 scope link 
       valid_lft forever preferred_lft forever
root@KNOXX:~# 

 

But I am lost as to why the MAC address for both eth0.2@eth0 and [email protected], which is reported in UR as having the IP 192.168.202.2, shows up on the network as having the IP 192.168.200.88 ?!?!?

 

 

 

Also, I am curious as to why the MACVTAP is IPV6 only? I have IPV6 disabled in UR and across my network. It's also disabled in HAOS. Does this matter in this instance or is that strictly for internal purposes and one of the reasons the MACVTAP approach works as it does?

 

I believe I wrote something about that in my thread. You have 2 parameters that can have 4 value combinations, while the combination where both are enabled leads to create vhost0@eth...

to avoid vhost0@eth0 to use the same IP as eth0 (will be alarmed by arpwatch, pfSense, TrueNAS, etc.): do no NOT enable BOTH of IPv4 custom network on interface eth0 (optional) (default is ON) and Host access to custom networks (default is OFF)

 

Have you tried to enable one and disable the other?

From what I am reading I believe you use HAOS in a VM, not in a container on unraid. The two above parameters should not have an impact on VMs, only on Docker containers, but I am no expert.

The VM Manager settings use different mechanisms (br0 or virbr0) to ensure communication between host and guest VMs (maybe you check out the "Default network source:" in the VM Manager settings, this is the help text copied from the UI:

Select the name of the network you wish to use as default for your VMs. You can choose between 'bridges' created under network settings or 'libvirt' created with virsh command in the terminal. The bridge 'virbr0' and the associated virtual network 'default' are created by libvirt.
Both utilizes NAT (network address translation) and act as a DHCP server to hand out IP addresses to virtual machines directly. More optional selections are present for bridges under network settings or for libvirt networks with the virsh command in the terminal.

If your are unsure, choose 'virbr0' as the recommended Unraid default.

NOTE: You can also specify a network source on a per-VM basis.

IMPORTANT: Neither Libvirt nor Unraid automatically brings up an interface that is assigned to a Libvirt network. Before you use a Libvirt network, please go to Settings -> Network Settings and, if necessary, manually set the associated interface to up.)

Have the same problem.

@aglyons

were you able to solve the problem? If so, how?

 

For me it looks like this.

Unraid server is displayed twice in the Fritzbox (currently no longer, I don't know what I changed, probably it no longer appears twice after an Unraid crash / hard reset).

In addition, I can no longer access my Unraid CIFS share from my Home Assistant VM. Ping does not go through either.

From the UR server to the HA VM no ping goes through either.

I have now spent 3 hours reading all possible posts on this topic and on the topic of ipvlan (“Call traces and crashes related to macvlan”) and am confused as to which settings I should now set so that everything works again?!

Here are my settings:

 

Docker custom network type: macvlan

Host access to custom networks: Enabled

Preserve user defined networks: Yes

IPv4 custom network on interface eth0: Subnet: 192.168.178.0/24 Gateway: 192.168.178.1 DHCP pool: not set

Enable bonding: No

Enable bridging: No

Edited October 6, 20241 yr by bluebug

I honestly don't know what the problem is, specifically with Unraid. I've run VM's on VMware with no issues at all. I dumped VMWare when I set up the Unraid server. When they came out with the "fix" for call trace crashes, they went and did some funky workaround which seems overly complicated and possibly introduces new issues, like this.

 

I'm not sure why UR has such issues with Docker containers using the bridge network. I have another server running Ubuntu with Docker with all containers using the bridge driver and have never had a call trace lockup ever.

 

It got to the point for me that I gave up on VMs in UR and restored the HAOS config onto a small NUC dedicated to HAOS. I'm sorry that I can't give you a solution other than to suggest giving up on UR VMs and possibly considering moving Docker containers to another system running just Docker.

 

One thing that really drives me nuts with UR is HOW docker containers are managed. If no template is created in the apps, it isn't easy to translate a container's requirements into a UR template. I've learned that docker-compose Yaml's are the better way to go, as when you start a container with docker run, when you remove the container, your run command is gone, so you either have to remember all your volume mappings and ENV vars. Compose files are not deleted when the container is in, so all your settings remain. But Docker-Compose in UR is only supported with a plugin. While it allows you to create the Yaml's, there are quirks. Again, there's something weird with defining the network to use. I have some compose containers in UR, and even though I've tried every network named in Docker, it still creates its own network with a useless 28-character name, which messes up the UI.

 

mh...ok thanks for your feedback. Had hoped for a different solution 🙂

 

I tried the following config again yesterday:

 

Docker custom network type: macvlan

Host access to custom networks: Enabled

Preserve user defined networks: Yes

IPv4 custom network on interface br0: Subnet: 192.168.178.0/24 Gateway: 192.168.178.1 DHCP pool: not set

Enable bonding: No

Enable bridging: Yes

 

As a result, I was able to access the Unraid shares again via Home Assistant VM (br0).

 

However, I now have 2x  Unraid server on my Fritzbox with the same IP. Once the “shim-br0” interface and once the eth0/br0 interface.

Not bad in itself, but the Fritzbox thinks that it doesn't like the double IP and therefore blocks its internet access 😞

 

My Unraid server can no longer access any address on the Internet, so I can't install any Docker / plugin updates.

 

Also all dockers in bridge mode can no longer access the network.

 

Does anyone have any ideas about this? I'm really lost at the moment. Everything used to work before.

 

Very strange after I changed everything back as follows, everything works again:

 

Docker custom network type: macvlan

Host access to custom networks: Enabled

Preserve user defined networks: Yes

IPv4 custom network on interface eth0: Subnet: 192.168.178.0/24 Gateway: 192.168.178.1 DHCP pool: not set

Enable bonding: No

Enable bridging: NO

 

This is exactly what I had set at the beginning. Maybe it was due to the Unraid server crash I had the other day.

 

Edited October 7, 20241 yr by bluebug

so the problem is not quite solved.

 

So everything still works but on the fritzbox I see the ip of the unraid server twice again
nd on one of them it has supposedly blocked access because it is a duplicate IP.
Unraid server and all dockers have access to the internet.
Does anyone have an idea how to prevent this?

I gave up running VM's on UR and moved my HAOS onto bare metal -a small NUC.

 

I'm still running MACVLAN and I don't have duplicated IP's in Unifi anymore.

 

Network settings have a VLAN created with no IP assigned on the primary NIC.

 

Docker settings are as follows

 

Docker custom network type: macvlan

Host access to custom networks: Disabled

Preserve user defined networks: No

IPv4 custom network on interface eth0: Subnet: 192.168.1.0/24 Gateway: 192.168.200.1 DHCP pool: not set

IPv4 custom network on interface eth0.2: Subnet: 192.168.2.0/24 Gateway: 192.168.202.1 DHCP pool: not set

 

Hope this helps sort you out.

 

A.