January 8, 20188 yr unRAID is using DHCP and successfully gets IP/subnet/gateway/DNS assignments from the DHCP server, but on the network page it lists an APIPA address for br0 with correct subnet/gateway/DNS settings. This incorrect address is also used by unRAID for things like docker webui links, etc. I use 802.3ad bonding and have bridging enabled if that makes any difference. IPv4 only. You can see from my screenshot that unRAID is in fact accessible by the IP it gets from the DHCP server and not the one displayed in the network settings.
January 8, 20188 yr Looks like the GUI went out of sync. Can you do create_network_ini And refresh the network page.
January 8, 20188 yr Author 23 minutes ago, bonienl said: Looks like the GUI went out of sync. Can you do create_network_ini And refresh the network page. That worked temporarily, but the problem reappeared after reboot. Here are the system log entries that pertain to br0: 1400: Jan 8 14:08:30 unRAID rc.inet1: ip link add name br0 type bridge stp_state 0 forward_delay 0 1401: Jan 8 14:08:30 unRAID rc.inet1: ip link set br0 up 1404: Jan 8 14:08:30 unRAID rc.inet1: ip link set bond0 promisc on master br0 up 1410: Jan 8 14:08:30 unRAID kernel: br0: port 1(bond0) entered blocking state 1411: Jan 8 14:08:30 unRAID kernel: br0: port 1(bond0) entered disabled state 1412: Jan 8 14:08:30 unRAID kernel: br0: port 1(bond0) entered blocking state 1413: Jan 8 14:08:30 unRAID kernel: br0: port 1(bond0) entered forwarding state 1414: Jan 8 14:08:30 unRAID rc.inet1: polling up to 60 sec for DHCP server on interface br0 1415: Jan 8 14:08:30 unRAID rc.inet1: timeout 60 dhcpcd -w -q -t 10 -h unRAID -4 br0 1416: Jan 8 14:08:30 unRAID dhcpcd[1968]: br0: carrier lost 1417: Jan 8 14:08:30 unRAID kernel: br0: port 1(bond0) entered disabled state 1420: Jan 8 14:08:32 unRAID dhcpcd[1968]: br0: carrier acquired 1425: Jan 8 14:08:32 unRAID kernel: br0: port 1(bond0) entered blocking state 1426: Jan 8 14:08:32 unRAID kernel: br0: port 1(bond0) entered forwarding state 1428: Jan 8 14:08:33 unRAID dhcpcd[1968]: br0: soliciting a DHCP lease 1429: Jan 8 14:08:38 unRAID dhcpcd[1968]: br0: probing for an IPv4LL address 1430: Jan 8 14:08:43 unRAID dhcpcd[1968]: br0: using IPv4LL address 169.254.71.75 1431: Jan 8 14:08:43 unRAID dhcpcd[1968]: br0: adding route to 169.254.0.0/16 1432: Jan 8 14:08:43 unRAID dhcpcd[1968]: br0: adding default route 1434: Jan 8 14:08:43 unRAID rc.inet1: ip link set br0 up 1446: Jan 8 14:08:43 unRAID ntpd[2072]: Listen normally on 1 br0 169.254.71.75:123 1707: Jan 8 14:08:46 unRAID dhcpcd[2018]: br0: offered 10.254.0.211 from 10.254.0.1 1708: Jan 8 14:08:46 unRAID dhcpcd[2018]: br0: probing address 10.254.0.211/24 2099: Jan 8 14:08:50 unRAID dhcpcd[2018]: br0: leased 10.254.0.211 for infinity 2100: Jan 8 14:08:50 unRAID dhcpcd[2018]: br0: adding route to 10.254.0.0/24 2101: Jan 8 14:08:50 unRAID dhcpcd[2018]: br0: changing default route via 10.254.0.1 2102: Jan 8 14:08:50 unRAID dhcpcd[2018]: br0: deleting route to 169.254.0.0/16 2124: Jan 8 14:08:52 unRAID ntpd[2072]: Listen normally on 3 br0 10.254.0.211:123 2125: Jan 8 14:08:52 unRAID ntpd[2072]: Deleting interface #1 br0, 169.254.71.75#123, interface stats: received=0, sent=0, dropped=0, active_time=9 secs 2400: Jan 8 14:08:54 unRAID avahi-daemon[6275]: Joining mDNS multicast group on interface br0.IPv6 with address fe80::80e8:5aff:fe72:ff2e. 2401: Jan 8 14:08:54 unRAID avahi-daemon[6275]: New relevant interface br0.IPv6 for mDNS. 2402: Jan 8 14:08:54 unRAID avahi-daemon[6275]: Joining mDNS multicast group on interface br0.IPv4 with address 10.254.0.211. 2403: Jan 8 14:08:54 unRAID avahi-daemon[6275]: New relevant interface br0.IPv4 for mDNS. 2407: Jan 8 14:08:54 unRAID avahi-daemon[6275]: Registering new address record for fe80::80e8:5aff:fe72:ff2e on br0.*. 2408: Jan 8 14:08:54 unRAID avahi-daemon[6275]: Registering new address record for 10.254.0.211 on br0.IPv4. Edited January 8, 20188 yr by ksarnelli
January 9, 20188 yr Does your switch support LACP? It looks like initial bonding doesn't work properly. You can test by changing the bonding mode, e,g use mode 1 (active-standby).
January 9, 20188 yr Author 7 hours ago, bonienl said: Does your switch support LACP? It looks like initial bonding doesn't work properly. You can test by changing the bonding mode, e,g use mode 1 (active-standby). Yes, it supports LACP and bonding is working correctly. I didn't have this issue with 6.3.
January 9, 20188 yr In your log the interface br0 starts with requesting a link local address (169.254), which will only happen if it times out on the initial request (it should wait up to 10 seconds), but there are unforeseen "carrier lost" messages in between. Perhaps due to LACP? The offer for the "real" IP address comes a few seconds later and the GUI should catch that, but it doesn't in your case. Need to figure out why. Perhaps as a quick test. Don't use bonding with LACP and see if the same thing still happens? Ps. Sure Cisco supports LACP.
January 11, 20188 yr Author On 1/9/2018 at 10:39 AM, bonienl said: In your log the interface br0 starts with requesting a link local address (169.254), which will only happen if it times out on the initial request (it should wait up to 10 seconds), but there are unforeseen "carrier lost" messages in between. Perhaps due to LACP? The offer for the "real" IP address comes a few seconds later and the GUI should catch that, but it doesn't in your case. Need to figure out why. Perhaps as a quick test. Don't use bonding with LACP and see if the same thing still happens? Ps. Sure Cisco supports LACP. Hoping to be able to test this today. Finding a window to reboot this server isn't easy
January 11, 20188 yr Bonding works fine for me on 21b - I'm using a HP 1920-24G switch with 802.3ad bonding. Edited January 11, 20188 yr by HellDiverUK
January 11, 20188 yr Author Tried a few things: Updated to RC 21b - same issue Change bonding to mode 1 (active-backup) and removed aggregation setting on those switch ports: unRAID displayed correct IP address Changed bonding mode back to 4 (802.3ad) and reconfigured switch: issue came back As I mentioned previously, I never had this issue with 6.3 - it only surfaced after upgrading to a 6.4 RC. Also, the bonding is working properly and the server does indeed have the correct IP address, it's just the UI that is displaying/using it incorrectly. Also, even though we don't know why the "carrier lost" is occurring on 6.4, it seems to me that there is a separate bug that aggravates the issue: the logic within "create_network_ini" should be automatically executed whenever an interface IP changes.
January 11, 20188 yr "create_network_ini" is called every time when a change in IP is detected. The difference between 6.3 and 6.4 is that in the latter version a check is added to see if the interface is physically up (carrier present) before proceeding. I think the loss of carrier in the middle of the IP assignment process and the added checking of the interface state in 6.4 is causing your issue. I am going to remove this state check. Thanks for testing.
January 11, 20188 yr Author 4 minutes ago, bonienl said: "create_network_ini" is called every time when a change in IP is detected. The difference between 6.3 and 6.4 is that in the latter version a check is added to see if the interface is physically up (carrier present) before proceeding. I think the loss of carrier in the middle of the IP assignment process and the added checking of the interface state in 6.4 is causing your issue. I am going to remove this state check. Thanks for testing. Ahhh. Much appreciated, thank you!
Archived
This topic is now archived and is closed to further replies.