mifronte Posted February 5, 2020 Share Posted February 5, 2020 (edited) I just updated to 6.8.2 from 6.8.1 and the server is booting up to some unknown IP Address of 169.264.246.72. My network is in the 10.168.192.x range so I don't know where it is getting the IP address instead of from my DHCP. This means I cannot access the server via GUI. I am using IPMI remote console to access the console. Edited February 6, 2020 by mifronte 1 Quote Link to comment
mifronte Posted February 5, 2020 Author Share Posted February 5, 2020 From what I can tell, the array is booting up fine, but it is using the wrong IP address. Quote Link to comment
mifronte Posted February 5, 2020 Author Share Posted February 5, 2020 (edited) I have rebooted several times, including completely turning the the power. The server keeps booting to the IP address of 169.254.246.72. I will need help with executing console commands to get it the correct IP address. It is not getting it from my DHCP server. My unRAID is configure to bond the dual Intel NIC in my server. Edited February 5, 2020 by mifronte Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 (edited) Attached is the diagnostics. I was able to get the server to obtain an IP address from the DHCP by running the command: inet restart Hopefully someone can figure out why my server is not getting an IP address on reboot. This problem started with version 6.8.1. beanstalk-diagnostics-20200205-1849.zip Edited February 6, 2020 by mifronte Quote Link to comment
mlapaglia Posted February 6, 2020 Share Posted February 6, 2020 I have this issue as well. Luckily I have several NICs hooked up, so I log into the web interface through one of the other IPs, go to the network tab and tell the main NIC to go to static then back to DHCP where it grabs the correct ip address. It started happening for me on 6.8.1. Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 3 hours ago, mifronte said: Hopefully someone can figure out why my server is not getting an IP address on reboot. There seems to be some trouble to get the bonded interface up and ready. Feb 5 15:50:42 Beanstalk dhcpcd[1527]: br0: carrier lost Feb 5 15:50:42 Beanstalk kernel: br0: port 1(bond0) entered disabled state Feb 5 15:50:44 Beanstalk kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Feb 5 15:50:44 Beanstalk dhcpcd[1527]: br0: carrier acquired Feb 5 15:50:44 Beanstalk kernel: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex Feb 5 15:50:44 Beanstalk kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond Feb 5 15:50:44 Beanstalk kernel: bond0: first active interface up! Does your switch/router have proper support for LACP (802.3ad)? Instead of using mode 4, try mode 6 as bonding protocol. This requires no special configuration on your switch/router Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 (edited) Yes, my Cisco SG350 switch supports 802.3ad. It has always worked prior to 6.8.1 and it is working now after I ran the command inet restart after the server boots. Starting with 6.8.1, I started having problems with the server not acquiring an IP address during boot. Actually with 6.8.1, it happened the first reboot after updating. Then it worked when I rebooted the server again. Now with 6.8.2, the server does not obtain an IP address during the boot process at all. Could it be a timing issue and the boot process does not allow enough time to obtain an IP address before defaulting to the 169.x.x.x? Something starting with 6.8.1 that is giving me this problem. I would rather not have to change the bonding protocol because I do not want to mess with my switch LAG configuration since my current bonding setup has been working flawlessly for years. Edited February 6, 2020 by mifronte 1 Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 Have you configured your Cisco switch to use "active" mode on the port-channel? Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 You could also change to a static IP address and avoid any race condition. Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 (edited) 1 hour ago, bonienl said: Have you configured your Cisco switch to use "active" mode on the port-channel? Each port is set to auto negotiate. The LAG is using LACP and auto negotiate too. I don't see any "active" mode settings. Edited February 6, 2020 by mifronte Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 (edited) 8 minutes ago, bonienl said: You could also change to a static IP address and avoid any race condition. Not quite sure what "race condition" means. I do have the DHCP server configured to give my unRAID server a static IP. I guess the last resort is to hard code in the IP address into the unRAID settings if there is no other solution. Edited February 6, 2020 by mifronte Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 2 minutes ago, mifronte said: I don't see any "active" mode settings. When you configure an interface and make it a member of a port-channel, you would do something like channel-group 1 mode active 2 minutes ago, mifronte said: Not quite sure what "race condition" means. DHCP is trying to obtain an IP address while at the same time the bond channel is initializing. This results in a "no answer" for DHCP which gives the 169.254.x.x address assignment. When you set a fixed IP address on the server (something I recommend), there is no more dependency and it doesn't matter how long the bond initialization takes. Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 4 minutes ago, bonienl said: When you configure an interface and make it a member of a port-channel, you would do something like channel-group 1 mode active DHCP is trying to obtain an IP address while at the same time the bond channel is initializing. This results in a "no answer" for DHCP which gives the 169.254.x.x address assignment. When you set a fixed IP address on the server (something I recommend), there is no more dependency and it doesn't matter how long the bond initialization takes. My SG350 Cisco switch is a small business switch which uses a GUI interface and it does not use Cisco's IOS like the enterprise switches. So starting with 6.8.1, there must have been some changes in how the bond channel initializes and when DHCP client requests are made? I can definitely configure unRAID with a fixed IP, but this means starting at unRAID 6.8.1, it no longer can support DHCP or is this a bug that can be fixed? Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 (edited) LACP needs time to exchange settings and characteristics of the bonded interface between both parties. It might well be that this process takes longer due to different/more characteristics being exchanged. Your switch plays a role here too. In your case apparently this is on a critical path and results in DHCP not getting an answer in time. The most viable solution is using a static IP assignment. Actually, I am pretty sure it is a timing issue, because the DHCP request which is done a little later for the VLAN interface proceeds normally, indicating the bonded interface is up and running at that point. Edited February 6, 2020 by bonienl Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 That explanation sounds reasonable since running the command inet restart at the console after the server boots gets the correct IP. Would it be a good idea for me to put this command in my go script file if I prefer to keep my server using DHCP to get all of its networking configuration (i.e. local DNS, gateway, IP address)? Quote Link to comment
bonienl Posted February 6, 2020 Share Posted February 6, 2020 As a temporary solution you can add the command to the 'go' file As a permanent solution I've made an update to deal with the timing. Will come in the next version. 2 Quote Link to comment
mifronte Posted February 6, 2020 Author Share Posted February 6, 2020 7 hours ago, bonienl said: As a permanent solution I've made an update to deal with the timing. Will come in the next version. Muchas gracias! Quote Link to comment
mifronte Posted February 8, 2020 Author Share Posted February 8, 2020 (edited) On 2/6/2020 at 8:51 AM, bonienl said: As a temporary solution you can add the command to the 'go' file As a permanent solution I've made an update to deal with the timing. Will come in the next version. So I added the "inet restart" to the 'go' file and rebooted to test and it did not work. So I tried running the command through the console with the same result. It only worked after I first ran "inet" to clear the current 169.x.x.x IP and then "inet restart" got the correct IP from my DHCP. I did logged out between running the two commands just to see my current IP assignment on the login console since I did not know the command to show my current network configurations. Funny thing was, I was just trying to get help on the inet command and accidentally ran it without any arguments. So if I was to use the 'go' file, what would be a more elegant set of commands to clear the current IP assignment and request a new one from DHCP? Edited February 8, 2020 by mifronte Quote Link to comment
coolspot Posted February 15, 2020 Share Posted February 15, 2020 (edited) On 2/6/2020 at 12:05 AM, bonienl said: There seems to be some trouble to get the bonded interface up and ready. Feb 5 15:50:42 Beanstalk dhcpcd[1527]: br0: carrier lost Feb 5 15:50:42 Beanstalk kernel: br0: port 1(bond0) entered disabled state Feb 5 15:50:44 Beanstalk kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Feb 5 15:50:44 Beanstalk dhcpcd[1527]: br0: carrier acquired Feb 5 15:50:44 Beanstalk kernel: bond0: link status definitely up for interface eth0, 1000 Mbps full duplex Feb 5 15:50:44 Beanstalk kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond Feb 5 15:50:44 Beanstalk kernel: bond0: first active interface up! Does your switch/router have proper support for LACP (802.3ad)? Instead of using mode 4, try mode 6 as bonding protocol. This requires no special configuration on your switch/router I'm also having a similar issue - 6.7.2 didn't have this problem, but starting 6.8.x bonded LACP DHCP is having trouble on a SuperMicro board. The current workaround is to use a static IP address and this does fix the issue for now. Edited February 15, 2020 by coolspot 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.