For some reason, when I reboot my server it forgets about how the bonding is configured.  I am bonding eth0, eth1, and eth2 using 802.3ad (mode 4).  I am also bonding eth4 and eth5 using 802.3ad (mode 4).  After the last reboot, the messages on the screen said bond0 was invalid.  I was able to get it working after the reboot.  When I tried to open the gui it failed.  I have to type in 127.0.0.1 to get to the gui.  Sometimes when I reboot the server it comes back.

 

When I opened the network page, eth0 had bonding enabled with bond members of eth0, eth1, and eth2.  Eth1 & Eth2 were not reporting that they were part of bond0.

 

Jul  2 23:09:21 mccserverur01 rc.inet1: ip -4 addr add 127.0.0.1/8 dev lo
Jul  2 23:09:21 mccserverur01 rc.inet1: ip -6 addr add ::1/128 dev lo
Jul  2 23:09:21 mccserverur01 rc.inet1: ip link set lo up
Jul  2 23:09:21 mccserverur01 rc.inet1: modprobe bonding mode=4 miimon=
Jul  2 23:09:21 mccserverur01 kernel: bonding: `' invalid for parameter `miimon'
Jul  2 23:09:21 mccserverur01 rc.inet1: ip link set bond0 up
Jul  2 23:09:21 mccserverur01 rc.inet1: ip link set eth0 master bond0 down
Jul  2 23:09:21 mccserverur01 rc.inet1: ip link set eth1 master bond0 down
Jul  2 23:09:21 mccserverur01 rc.inet1: ip link set eth2 master bond0 down

 

 

Can you show your "network.cfg" file, it is located on your flash device in the /config folder.

 

I think I may have found the source of the issue at hand.  Ever since I installed 6.4, may main network bond comes up initially with an address of 169.254.??.?? and then complains that it is invalid on the screen but I cannot find those entries in the log file.  I have also seen addresses being handed out in my unifi controller starting with 169.254.??.?? and 172.17.0.??.  I believe the source of the problem is the new docker DHCP process.  The docker configuration setting "DHCPv4 pool of custom network bond0" is/was set to blank.  Last night for about 3 hours my network was in chaos because something started to disrupt the unfi USG dhcp server.  I finally for some reason remembered that docker process has DHCP server capabilities and shout it down.  As soon as I shutdown the docker process my network went back to normal.  I do not ever intend on having docker containers hand out ip addresses to anything.  Is there anyway to disable the docker DHCP server so this does not happen again?

 

The only interface used by unRaid is bond0, all other interfaces are used by my virtual machine except for the entries in bold.  The entries in bold are bogus, I have tried to remove them but they keep coming back.

 

See this post for Docker DHCP issue.

 

network.cfg

# Generated settings:
IFNAME[0]="bond0"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="10.205.1.1"
DNS_SERVER2="10.205.2.1"
BONDNAME[0]="bond0"
BONDNICS[0]="eth0 eth1 eth2"
BONDING_MODE[0]="4"
DESCRIPTION[0]="eth0"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="yes"
IPADDR[0]="10.205.1.6"
NETMASK[0]="255.255.255.0"
GATEWAY[0]="10.205.1.1"
METRIC[0]="1"
IPADDR6[0]="fe80::225:90ff:fe66:89f8"
NETMASK6[0]="64"
GATEWAY6[0]=""
PRIVACY6[0]=""
MTU[0]=""
IFNAME[1]="br3"
BRNAME[1]="br3"
BRNICS[1]="eth3"
BRSTP[1]="no"
BRFD[1]="0"
DESCRIPTION[1]="eth3"
PROTOCOL[1]="ipv4"
USE_DHCP[1]=""
IPADDR[1]=""
NETMASK[1]=""
GATEWAY[1]=""
METRIC[1]=""
IPADDR6[1]=""
NETMASK6[1]=""
GATEWAY6[1]=""
PRIVACY6[1]=""
MTU[1]=""
IFNAME[2]="br4"
BONDNAME[2]="bond4"
BONDING_MIIMON[2]="100"
BRNAME[2]="br4"
BRSTP[2]="no"
BRFD[2]="0"
BONDING_MODE[2]="4"
BONDNICS[2]="eth4 eth5"
BRNICS[2]="bond4"
DESCRIPTION[2]="eth4"
PROTOCOL[2]="ipv4"
USE_DHCP[2]=""
METRIC[2]=""
MTU[2]=""
IFNAME[3]="eth115"
DESCRIPTION[3]="eth115"
PROTOCOL[3]=""
USE_DHCP[3]=""
IPADDR[3]=""
NETMASK[3]=""
GATEWAY[3]=""
METRIC[3]=""
IPADDR6[3]=""
NETMASK6[3]=""
GATEWAY6[3]=""
PRIVACY6[3]=""
MTU[3]=""

IFNAME[4]="eth116"
DESCRIPTION[4]="eth116"
PROTOCOL[4]=""
USE_DHCP[4]=""
IPADDR[4]=""
NETMASK[4]=""
GATEWAY[4]=""
METRIC[4]=""
IPADDR6[4]=""
NETMASK6[4]=""
GATEWAY6[4]=""
PRIVACY6[4]=""
MTU[4]=""
SYSNICS="5"

 

The server is assigned 10.205.1.6 notice it is reporting that it is assigned 169.254.76.230

 

root@mccserverur01:~# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 10.205.1.6  netmask 255.255.255.0  broadcast 10.205.1.255
        inet6 fe80::225:90ff:fe66:89f8  prefixlen 64  scopeid 0x20<link>
        ether 00:25:90:66:89:f8  txqueuelen 1000  (Ethernet)
        RX packets 22262757  bytes 9167171872 (8.5 GiB)
        RX errors 0  dropped 85  overruns 0  frame 0
        TX packets 200650061  bytes 26828194621 (24.9 GiB)
        TX errors 0  dropped 7 overruns 0  carrier 0  collisions 0
 

Edited July 7, 20178 yr by csmccarron

Docker doesn't have a DHCP service.

It dynamically assigns a static IP address out a a pool.

On 7/4/2017 at 8:35 PM, csmccarron said:

# Generated settings:
IFNAME[0]="bond0"
DHCP_KEEPRESOLV="no"
DNS_SERVER1="10.205.1.1"
DNS_SERVER2="10.205.2.1"
BONDNAME[0]="bond0"
BONDNICS[0]="eth0 eth1 eth2"
BONDING_MODE[0]="4"
DESCRIPTION[0]="eth0"
PROTOCOL[0]="ipv4"
USE_DHCP[0]="yes"
IPADDR[0]="10.205.1.6"
NETMASK[0]="255.255.255.0"
GATEWAY[0]="10.205.1.1"
METRIC[0]="1"
IPADDR6[0]="fe80::225:90ff:fe66:89f8"
NETMASK6[0]="64"
GATEWAY6[0]=""
PRIVACY6[0]=""
MTU[0]=""

Your network.cfg says that unRaid is looking for a DHCP server.

unRAID uses dhcpcd which will use the (infamous) 169.254.0.0/16 network if it fails to find a DHCP server.

 

Try this:

1. Disable Docker and VMs
2. Shutdown unRAID
3. Plug the flash drive into another PC and delete/rename the config/network.cfg file (This will reset your network settings - to a single br0 and all nics bonded to it)
4. Start unRAID (Have a local keyboard mouse available to configure if you can't access unRAID over the network)
5. Reprogram your network settings.

 

See if the problem occurs again after this.

Edited July 7, 20178 yr by ken-ji

That is correct.  The address is assigned from my Unifi controller on the network which is also the DNS server.  This 169 address thing only started when I installed 6.4 and the problem disappears if I disable the docker process.  This new docker process has some sort of DHCP functionality that needs to be disabled if not being used.  My Unifi Controller assigns the correct address to bond0 but during the boot process it must get a temporary bogus address from the docker DHCP process.  Again, my bonded connection only started failing since 6.4.  I really do not think it is a problem with then bond itself, I think the docker DHCP process is somehow screwing up everything.  All I have to do to fix it, is uncheck 1 NIC from the bond, recheck the NIC and click apply.  The bond is then properly reassembled and starts up (although the screen does not refresh properly which is another problem).  I do the same thing to the second bond and then turn my dockers and VM's back on.  Its just a pain in the ass!

 

I will try your suggestion to get rid of the two bogus NICs.  They have been in there for a while.

 

Thanks,

Chris

Edited July 7, 20178 yr by csmccarron

There is a missing parameter in the network configuration files which causes a problem when creating multiple bond interfaces. The temporary workaround is indeed to recreate each bond interface separately. Next version will have a correction.

 

Ok @bonienl, I manually updated the network.cfg file as you described.  I can now reboot my server and the network will come up correctly but it originally still gets that bogus169.254 address.  The unRaid GUI shows the incorrect address but ifconfig shows the correct address.  When the system is booting bond0 is assigned the 169.254 address.  This did not happen in 6.3.5.

 

bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 10.205.1.6  netmask 255.255.255.0  broadcast 10.205.1.255
        inet6 fe80::225:90ff:fe66:89f8  prefixlen 64  scopeid 0x20<link>
        ether 00:25:90:66:89:f8  txqueuelen 1000  (Ethernet)
        RX packets 39795  bytes 33815177 (32.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18369  bytes 2950911 (2.8 MiB)
        TX errors 0  dropped 3 overruns 0  carrier 0  collisions 0

 

Thanks

 

2 minutes ago, csmccarron said:

When the system is booting bond0 is assigned the 169.254 address.  This did not happen in 6.3.5.

 

This is under investigation at the moment.

Cool, let me know if you need me to test something.

 

 

This appears to be fixed.  I also do not see the errors during boot up.  I have not tried to recreate the bonds under network setup yet.