Multiple NICs on the same IPv4 network - Error - Fix Common Problems


Recommended Posts

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 by bellyup
thank(s)
  • Like 1
Link to comment

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 by Moose808
Link to comment

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.

 

 

  • Like 2
  • Thanks 2
Link to comment
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.

 

Link to comment

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 by TexasDave
  • Like 1
Link to comment

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

 

Clipboard01.thumb.png.092864c81ae0b2240825033c69d608e2.png

 

Clipboard02.png.c5634edb0b550dbccfd3ceaf9e089307.png

Edited by TexasDave
  • Like 1
Link to comment

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.

  • Thanks 1
Link to comment

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

Link to comment

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 by John_M
Typos
  • Like 2
Link to comment

# 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 by LordShad0w
Link to comment
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"


 

  • Like 1
Link to comment
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 :)

Link to comment
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

Link to comment
  • 2 months later...

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.