I was using the network daughter board in the past but I only have one port active now. The other card and onboard are disabled in the bios.

 

I get the Error Found from "Fix common plugin app":

eth4 and eth8 both have IP addresses on the 169.254.0.0 network. This is rarely a valid configuration

 

I've tried to delete all of these entries by clicking the trash can but they don't delete. Everything works but is there a simple way to fix this?

IPv4      default              br4 via link           210

IPv4      default              br8 via link           211

IPv4      169.254.0.0/16   br4                      210

IPv4      169.254.0.0/16   br8                      211

 

Thanks for any help you can offer.

Edited March 9, 20215 yr by bellyup
thank(s)

I've been using the same on-board NIC plus an add-on 4-interface NIC for many months on unRaid.  I've also been running Fix Common Problems since creating the server.

 

Only today did I start getting the "rarely a valid configuration" message.  Only eth0 (on-board) and eth1 (add-on 1st port) NICs are active.  Both have been on the same IP LAN for the whole time to provide remote access capability if the primary port dies.

 

My guess is the Fix Common Problems Plug-In changed recently and is now complaining about something it ignored before.

 

I'll be looking for more info.  In the meantime, I'll just click "ignore" in the FCP Plug-In.

 

If you server's network interfaces are working fine, I wouldn't make changes.  If you do, backup your server's boot USB drive to another USB drive first just in case. 

Edited March 8, 20215 yr by Moose808

I'm baaaa-aaaack! 

 

I took a look at this doc, and decided my setup really was an invalid configuration.  Since I wasn't using bonding to combine the NICs, the 2 NICs on one LAN can cause conflicts.

 

https://www.ni.com/en-us/support/documentation/supplemental/11/best-practices-for-using-multiple-network-interfaces--nics--with.html#section--1358462000

 

So, I:

1.  Shutdown my one VM that was running (VMs)

2.  Shutdown the VM manager (Settings)

3.  Shutdown the Docker Manager (Settings)

4.  Changed the eth1 NIC settings (Settings -> Network Settings)

     "Downed" the eth1 port in the settings

     Changed the 10.0.1.216 NIC IPV4 address to 192.168.0.215 to match the eth0 node (.215)

     Changed the Default Gateway to blank (0.0.0.0) so only one default GW exists on the server using the 10.0.1.x LAN

5.  Restarted the VM Manager (Settings)

6.  Restarted Docker Manager (Settings)

7.  Restarted my VM (VMs)

 

Then I reran the Fix Common Problems Plug-In.  The error no longer appears.

 

Hope that helps.

 

 

Your awesome. Thank you very much. 

9 hours ago, Moose808 said:

I took a look at this doc, and decided my setup really was an invalid configuration.  Since I wasn't using bonding to combine the NICs, the 2 NICs on one LAN can cause conflicts.

 

This test was put in by @ljm42  I'm glad that it did work correctly and found the invalid configuration.

 

OK - I had the same error in FCP and was following @Moose808 kind instructions above but made a typo (I think) and now cannot get into the unRAID Web Interface.

Is there a way I can get back in perhaps by LAN cable directly into the unRAID box?  I cannot ssh in...

If not - I gues I can hook a monitor and keyboard up? Is there a way to reset the ethernet devices or edit them from the shell?

Thanks!

EDIT: Hooked up monitor and keyboard and booted in to safe mode.

Edited March 8, 20215 yr by TexasDave

OK - back in by booting in safe mode turning off the second eth1.

Atatched are the two entries for eth0 and eth1.

If I wanted to get rid of the original Fix Common Problem error - how would I configure eth1 (along with eth0)?

Or just leave it off for now? My system is working again and no errors from FCP

Thanks

 

 

Edited March 8, 20215 yr by TexasDave

On 3/8/2021 at 8:42 AM, TexasDave said:

If I wanted to get rid of the original Fix Common Problem error - how would I configure eth1 (along with eth0)?

 

The key thing is you should not have two network interfaces connected to the same network unless they are bonded; TCP/IP networking isn't meant to work that way. Things will "mostly work" but then some day you'll have a weird problem that you can't explain, such as WireGuard responding on eth1 but not eth0:

 https://forums.unraid.net/topic/86021-wireguard-shows-data-inout-but-no-handshake/?tab=comments#comment-948325 

(that is just an example, certainly not the only thing that could go wrong)

 

This site has good background on using multiple network interfaces: https://www.ni.com/en-us/support/documentation/supplemental/11/best-practices-for-using-multiple-network-interfaces--nics--with.html#section--1358462000

The key statement being "Avoid Assigning Multiple NICs in the Same Computer to the Same Subnet"

 

 

The simplest solution is to disable eth1 in the Unraid webgui, and physically unplug the network cable from eth1.

 

Or return to Unraid's default - a bonded connection with eth0 and eth1 in bonding mode "active backup". This allows you to plug a network cable into either eth0 or eth1 without having to know which port is which on the back of your computer. You could theoretically plug in both ports, but there isn't much point in that kind of redundancy in a home environment. There is no speed improvement.

 

Be sure to read the inline help and search the Internet if you want to try other bonding modes, most of them require you to have a managed switch specifically configured for the bond. A good starting point: https://wiki.linuxfoundation.org/networking/bonding#switch_configuration

 

One other thing to mention - a bonded network connection has a unique MAC address, different from either of your physical nics. So if you turn bonding on or off you will likely get a different IP address from DHCP.

 

P.S. There are some advanced configurations where multiple nics on the same network are fine. If you are sure your use case is valid then you can ignore this test. But if you haven't done anything special to allow both nics to coexist on the same network then you really should consider removing one or moving to a bond.

@ljm42 - many thanks for your help, explanation and pointers to learn more. I really appreciate it....

Well, that was interesting.  I too got the "multiple NICs on same subnet" message from FCP.  I had forgotten I even had eth1 assigned in unRAID as it was not serving any real purpose.  I thought, what the heck, I'll make an active backup bond with the two NICs. 

 

Bad choice apparently.  Fortunately I did backup the flash before making this change and that saved my bacon.

 

When I made the bond and l clicked apply, I lost network connectivity on my entire LAN,  Nothing with a wired Ethernet connection had Internet access and, of course, I lost the unRAID GUI. WiFi still worked.

 

I pressed the power button to down the server gracefully, or so I thought.  As soon as the unRAID server went offline, all network connectivity was restored to the rest of the LAN.  I then copied over the config folder from the flash backup (instead of just network.cfg because I did not know if anything else was impacted.)

 

After restoring from backup, the server again booted properly but it started a parity check which I cancelled for now.  Everything is back the way it was and I will just start by taking down eth1 in unRAID and disconnecting the cable.

Eth0 and eth3 on same ipv4 network error. Except, I don't even have an eth3. wtf?
Error would not go away and now whatever I did broke my setup even though it still seems the same. No github ( I even reset the router and yes I am using default of 8888 8844), no apps, no nothing, though it still shows network traffic on the dashboard.
I am incredibly confused. I am also a know-nothing when it comes to networking.
Worth mentioning that I showed no errors on the previous stable build prior to upgrade. Not sure if relevant, but there it is. Likely something pre-existing that it just didn't bitch about before.
Any help would be greatly appreciated. Thank you in advance.
- M

10 minutes ago, LordShad0w said:

Any help would be greatly appreciated.

 

It's difficult to guess. Post your diagnostics.

 

Here you go, sorry for not doing it on the initial post. 

tower-diagnostics-20210309-1613.zip

According to ethtool and ifconfig in your diagnostics you have eth0 and eth1. However your network.cfg file references eth0 and eth3 instead and they are both on the same network.

 

# Generated settings:
IFNAME[0]="eth0"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="no"
IPADDR[0]="192.168.1.6"
NETMASK[0]="255.255.255.0"
GATEWAY[0]="192.168.1.1"
METRIC[0]="1"
DNS_SERVER1="8.8.8.8"
DNS_SERVER2="8.8.4.4"
USE_DHCP6[0]="yes"
DHCP6_KEEPRESOLV="no"
IFNAME[1]="eth3"
PROTOCOL[1]="ipv4"
USE_DHCP[1]="no"
IPADDR[1]="192.168.1.119"
NETMASK[1]="255.255.255.0"
GATEWAY[1]="192.168.1.1"
SYSNICS="2"

 

I'm not sure what you aim to achieve but you probably want to recreate the network.cfg file. If you have a DHCP server you could simply delete the /boot/config/network.cfg file and reboot. It will then be recreated with safe DHCP settings. You can then edit it via the GUI Settings -> Network.

 

Edited March 10, 20215 yr by John_M
Typos

# Generated settings:
IFNAME[0]="bond0"
BONDNAME[0]="bond0"
BONDING_MIIMON[0]="100"
BONDING_MODE[0]="1"
BONDNICS[0]="eth0 eth1"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="yes"
DHCP_KEEPRESOLV="yes"
DNS_SERVER1="8.8.8.8"
DNS_SERVER2="8.8.4.4"
USE_DHCP6[0]="yes"
DHCP6_KEEPRESOLV="no"
IFNAME[1]="eth1"
PROTOCOL[1]="ipv4"
USE_DHCP[1]="no"
IPADDR[1]="192.168.1.6"
NETMASK[1]="255.255.255.0"
GATEWAY[1]="192.168.1.1"
SYSNICS="2"

 

edited to this from my backup and now I can't access anything. Sorry for being so helpless on this but I need step by step what to do if anyone is willing. Sorry again, and thanks.

ETA
I can't even get anything to come up in GUI mode on the slide out server monitor as it can never load the page. Please tell me I didn't nuke my setup

Edited March 10, 20215 yr by LordShad0w

17 hours ago, LordShad0w said:

can't even get anything to come up in GUI mode on the slide out server monitor as it can never load the page. Please tell me I didn't nuke my setup

 

So one option would be to pull the config/network.cfg out of your diagnostics and put it on your flash drive in the config folder, overwriting the file there. That will get you back to your previous config.

 

However, the logs in your diagnostics show tons of networking errors, likely related to exactly what this FCP message was warning you about.

 

I would do what @John_M suggested and simply delete the config/network.cfg off your flash drive and reboot. Unraid will create a new one when it boots back up. It looks like you have DHCP on your network so it will grab an IP address from there and you should be good to go.

 

EDIT - hmm, after looking at the logs again perhaps you don't have DHCP? Try this for your config/network.cfg file:

USE_DHCP="no"
IPADDR="192.168.1.6"
NETMASK="255.255.255.0"
GATEWAY="192.168.1.1"
BONDING="yes"
BRIDGING="yes"
DNS_SERVER1="8.8.8.8"

 

Thank you both so much, this worked out perfectly. I was really sweating for hot minute there!
Since I set a static IP for the servers MAC address on the router it automatically went back to how it was, but zero errors now. Again, Thank You!

4 hours ago, LordShad0w said:

Thank you both so much, this worked out perfectly. I was really sweating for hot minute there!
Since I set a static IP for the servers MAC address on the router it automatically went back to how it was, but zero errors now. Again, Thank You!

that is great, glad there is no more mysterious eth3

On 3/8/2021 at 7:12 PM, Hoopster said:

When I made the bond and l clicked apply, I lost network connectivity on my entire LAN,  Nothing with a wired Ethernet connection had Internet access and, of course, I lost the unRAID GUI. WiFi still worked.

That is very strange, an "active backup" bond should be safe.

 

On 3/8/2021 at 7:12 PM, Hoopster said:

After restoring from backup, the server again booted properly but it started a parity check which I cancelled for now.

I wonder why it it started a parity check? In order to muck with the network settings the array has to be stopped. If the system crashes when the array is stopped there is no reason for a parity check.

 

I did add one more note to my post - a bond has a different MAC address from your NIC, so if you are using DHCP and switch to a bond you will get a different IP. This doesn't sound like it was your problem though.

 

On 3/8/2021 at 7:12 PM, Hoopster said:

I will just start by taking down eth1 in unRAID and disconnecting the cable.

that was my choice too

Just want to add to this thread, that I also am getting this warning. However, it's basically by design for me at the moment since I am having to keep my Dockers on eth0 while my vm's are on eth1 to avoid the floating issue within unraid of call traces. Setting network type of virtio-net is not a sure fire fix as I already have that and still get them. Setting dockers on one nic and VM's on the other seems to bring some stability until this issue truly gets fixed.