Scott Harkless Posted November 19, 2019 Share Posted November 19, 2019 So when i first installed this I did a bonded network. I am having issues where when i reboot unraid it comes back with a 169.X.X.X ip address so its unreachable. I have tried everything to get this working and now I just want to blow away the bond so I can actually use my server. Is there a way to do this from the command line since that is the only way i can get to it right now. I have tried to delete the /boot/config/network.cfg and network-rules.cfg files and reboot that did nothing. Please HELP!!!!! Quote Link to comment
John_M Posted November 19, 2019 Share Posted November 19, 2019 Check your DHCP server and cabling. Your NIC will assume a link local address if it doesn't succeed in soliciting an IP address from a DHCP server, which doesn't have much to do with whether or not bonding is used. Post your diagnostics (type diagnostics at the console). Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 I know its not a DHCP issue because nothing else on my network has an issue just this server. I will try to get the diagnostics over here somehow Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 Ok here is the diag from the console. tower-diagnostics-20191118-2044.zip Quote Link to comment
John_M Posted November 19, 2019 Share Posted November 19, 2019 (edited) Early in the startup a lease is requested but none is offered so a link local address is chosen: Nov 18 20:17:40 Tower kernel: igb 0000:01:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Nov 18 20:17:40 Tower dhcpcd[1816]: br0: carrier acquired Nov 18 20:17:40 Tower kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Nov 18 20:17:40 Tower kernel: bond0: (slave eth0): making interface the new active one Nov 18 20:17:40 Tower kernel: device eth0 entered promiscuous mode Nov 18 20:17:40 Tower kernel: bond0: active interface up! Nov 18 20:17:40 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready Nov 18 20:17:40 Tower kernel: br0: port 1(bond0) entered blocking state Nov 18 20:17:40 Tower kernel: br0: port 1(bond0) entered forwarding state Nov 18 20:17:40 Tower dhcpcd[1816]: br0: soliciting a DHCP lease Nov 18 20:17:45 Tower dhcpcd[1816]: br0: probing for an IPv4LL address Nov 18 20:17:50 Tower dhcpcd[1816]: br0: using IPv4LL address 169.254.144.133 Nov 18 20:17:50 Tower dhcpcd[1816]: br0: adding route to 169.254.0.0/16 Nov 18 20:17:50 Tower dhcpcd[1816]: br0: adding default route Nov 18 20:17:50 Tower dhcpcd[1816]: forked to background, child pid 1872 Nov 18 20:17:50 Tower rc.inet1: ip link set br0 up A little later, dhcpd is woken up by the offer of a lease, so the link local address is replaced by the leased one: Nov 18 20:18:40 Tower dhcpcd[1872]: br0: offered 192.168.0.132 from 192.168.0.1 Nov 18 20:18:40 Tower dhcpcd[1872]: arp_new: Socket operation on non-socket Nov 18 20:18:40 Tower dhcpcd[1872]: br0: probing address 192.168.0.132/24 Nov 18 20:18:40 Tower dhcpcd[1872]: arp_probe: Socket operation on non-socket Nov 18 20:18:46 Tower dhcpcd[1872]: br0: leased 192.168.0.132 for 7200 seconds Nov 18 20:18:46 Tower avahi-daemon[2787]: Registering new address record for 192.168.0.132 on br0.IPv4. Nov 18 20:18:46 Tower dhcpcd[1872]: br0: adding route to 192.168.0.0/24 Nov 18 20:18:46 Tower dhcpcd[1872]: br0: changing default route via 192.168.0.1 Nov 18 20:18:46 Tower dhcpcd[1872]: arp_tryfree: Socket operation on non-socket Nov 18 20:18:46 Tower dhcpcd[1872]: br0: deleting route to 169.254.0.0/16 Then someone logs in from a host on the same network and appears to take the interface down: Nov 18 20:19:24 Tower webGUI: Successful login user root from 192.168.0.32 Nov 18 20:19:43 Tower ool www[3267]: /usr/local/emhttp/plugins/dynamix/scripts/netconfig 'eth0' Nov 18 20:19:43 Tower rc.inet1: ip -4 addr flush dev eth0 Nov 18 20:19:43 Tower rc.inet1: ip link set eth0 down Nov 18 20:19:43 Tower kernel: bond0: (slave eth0): link status definitely down, disabling slave Nov 18 20:19:43 Tower kernel: device eth0 left promiscuous mode Nov 18 20:19:43 Tower kernel: bond0: now running without any active interface! Nov 18 20:19:43 Tower kernel: br0: port 1(bond0) entered disabled state Edited November 19, 2019 by John_M Typo Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 So I watch it boot up and it shows me it has the 169 IP. Sometimes I wait and see if the web comes up but if it does not then I will log into the console to see what is going on. I think it has something to do with the bond but not sure how to prove that or get rid of the bond totally. Quote Link to comment
bonienl Posted November 19, 2019 Share Posted November 19, 2019 (edited) Since you use a single interface only for the connection (you do have more interfaces), you can remove the bond configuration. Take the USB stick out and modify the network.cfg file in the /config folder as follows: # Generated settings: IFNAME[0]="br0" BRNAME[0]="br0" BRSTP[0]="no" BRFD[0]="0" BRNICS[0]="eth0" PROTOCOL[0]="ipv4" USE_DHCP[0]="yes" DHCP_KEEPRESOLV="no" USE_DHCP6[0]="yes" DHCP6_KEEPRESOLV="no" SYSNICS="1" The problem seems to be your DHCP server, which is extremely slow in handing out an IP address and confuses the server. What are you using as DHCP server and is it configured properly? An alternative is to give the server a fixed address. Edited November 19, 2019 by bonienl Quote Link to comment
unw1red Posted November 19, 2019 Share Posted November 19, 2019 Can you post the config for your switch for the UNRaid interfaces? Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 Using my firewall which is pfSense right now getting ready to move over to a Sophos XG 210. Everything is configured correctly like i said i have many things on my network and have not had any issues with them getting an address. Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 1 minute ago, unw1red said: Can you post the config for your switch for the UNRaid interfaces? I have a cisco WS-C2960S-48FPD-L and i know that i have 4 ports that are configured in a port channel but not sure the settings on that had a buddy configure it for me. I also cant get into the enable to view the configuration now for some reason which is why I am in the process of configuring a Cisco 3850 switch to replace this one. Quote Link to comment
unw1red Posted November 19, 2019 Share Posted November 19, 2019 You need to make sure both sides of the link are configured the same. Sometimes, a LAGG can be configured to LOAD BALANCING on one side and 802.3ad on the other and it will bounce interfaces until the end of time. Quote Link to comment
bonienl Posted November 19, 2019 Share Posted November 19, 2019 9 minutes ago, Scott Harkless said: I am in the process of configuring a Cisco 3850 switch Start simple without bonding (port-channel) on the server and switch. Once working you can always extend the connection. Quote Link to comment
Scott Harkless Posted November 19, 2019 Author Share Posted November 19, 2019 My goal in the end is to have 4-1gb ports into one interface which is why i did the bond. I might start looking for a 10gb card since my new switch has 4 10gb ports on it. Quote Link to comment
Scott Harkless Posted November 20, 2019 Author Share Posted November 20, 2019 So question for you guys on this. I have a new switch and a dual port 10g network card coming this weekend. Is it as easy as just shutting down removing the 2 cards i have now and installing the new card or do i have to do a reload of unraid to get it working? My plan is just to do a active/passive with the two 10g links as i will never need more then that lol Quote Link to comment
bonienl Posted November 20, 2019 Share Posted November 20, 2019 Simply replacing the existing cards should work, but you may need/want to adjust interface assignments. I.e. define which interface is eth0, etc... Quote Link to comment
Scott Harkless Posted November 20, 2019 Author Share Posted November 20, 2019 Is that done in the network-rules.cfg? Quote Link to comment
bonienl Posted November 20, 2019 Share Posted November 20, 2019 3 minutes ago, Scott Harkless said: Is that done in the network-rules.cfg? You can make adjustments in the GUI under Network Rules, this subsequently updates the .cfg file. A reboot is required to make the new assignments effective. Quote Link to comment
Scott Harkless Posted November 20, 2019 Author Share Posted November 20, 2019 (edited) Really not trying to play dumb but i dont see Network Rules anywhere. I think i just found it Edited November 20, 2019 by Scott Harkless Quote Link to comment
bonienl Posted November 20, 2019 Share Posted November 20, 2019 (edited) 21 minutes ago, Scott Harkless said: Really not trying to play dumb but i dont see Network Rules anywhere Sorry my bad, it is indeed "Interface Rules" Note: these rules will be updated after the new interfaces are added (and old ones removed) and the system is started (it requires discovery of changes) Edited November 20, 2019 by bonienl Quote Link to comment
Scott Harkless Posted November 25, 2019 Author Share Posted November 25, 2019 Well i think with everything i did this weekend I might have fixed my issue with networking. I plan on updating my server to RC6 tomorrow and will update the thread then. Quote Link to comment
Scott Harkless Posted November 26, 2019 Author Share Posted November 26, 2019 Looks like I am all fixed just did a reboot after upgrading to RC7 and it came back up no problem. That is the first time that has ever happened since i got this thing running. Thanks for all the help guys. Quote Link to comment
Recommended Posts
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.