Unraid IP keeps changing every minute!

[livingonline8]

Hello everyone, 

 

I have an unraid server running the latest stable version. My router died so I swapped it with a Ubiquiti USG router that I was using in the past just fine. 

The problem is after turning on the server, I can access the GUI and shares in the first couple of minutes and then the server IP gets changed randomly every few minutes!! 

 

So, I decided to use a static IP, Same issue with one minor difference, still I can access the GUI and shares in the first couple of minutes but then I cannot access anything although the IP does not change!! (I check if the server IP changed in the router) 

 

This Unifi USG router was working fine with this server a couple years ago. But, now that my ASUS router died and wanted to g back and use USG, all I did, connected it, updated it and it has this issue with randomly changing my server IP. all my other devices are working fine. 

 

is the problem in my server? is it my router? 

 

I would really appreciate the help, I have attached the diagnostics file 

 

tower-diagnostics-20220509-0558.zip

[livingonline8]

I am really lost here... I tried everything I can think of

 

Expected behaviour:

Start the unraid server, it gets an IP address from USG router, access your unraid server at anytime from GUI and shares.  

 

Current behaviour: 

Start the unraid server, it gets an IP address from USG router(i.e. 192.168.1.88), I can access the GUI and shares, Thenfew minutes after starting my unraid server, I cannot see the shares in my network tab on my Macbook pro and the GUI is unreachable! 

 

checking the USG router through the controller, I find out the unraid IP was changed to (i.e. 192.168.1.92). Now, I can access the unraid GUI again using that ip address, few minutes after that, I lose access to unraid GUI, Checking USG router, I find out the unraid IP was changed to new IP address (i.e. 192.168.1.74) 

 

Troubleshooting steps:

Rebooted the network and server multiple time 

Assigned static IP address ( I still lose access to GUI although the unraid server IP did not change because I made it static)

Stopped dockers

checked access management for ports 

checked network settings on unraid 

 

@bonienl @limetech I am completely lost in here, Please I would really appreciate the help 

Edited May 9, 2022 by livingonline8

[MAM59]

You should check the dhcp lifetime settings (TTL, time to live) inside your router's dhcp server.

 

Maybe it is set to 5min but should be 5hours or, more likely, 5 days

 

Even for dialup devices 5mins would be ridiculously too low.

 

the names may be different. this example is for an ISC DHCP Server:

#short Leases (1 day)
#default-lease-time 65535;
#max-lease-time 86400;

#longe Leases (1 week)
default-lease-time 691200;
max-lease-time 1382400;

(the time is givin in "Seconds", thats why those numbers are so huge)

Edited May 9, 2022 by MAM59

[livingonline8]

2 hours ago, MAM59 said:

You should check the dhcp lifetime settings (TTL, time to live) inside your router's dhcp server.

 

Maybe it is set to 5min but should be 5hours or, more likely, 5 days

 

Even for dialup devices 5mins would be ridiculously too low.

 

the names may be different. this example is for an ISC DHCP Server:

#short Leases (1 day)
#default-lease-time 65535;
#max-lease-time 86400;

#longe Leases (1 week)
default-lease-time 691200;
max-lease-time 1382400;

(the time is givin in "Seconds", thats why those numbers are so huge)

Thank you for your reply 

I just checked the DHCP Lease Time on my router and it is set to 28800 seconds

that is 8 hours! 

 

this setting is fine, it must be something else that makes my router change the unraid IP server every few minutes  

Edited May 9, 2022 by livingonline8

[livingonline8]

@MAM59 also note, I lose access to my server even if I set it up with a static IP address from my router

 

I checked the diagnostic file and it does show errors about claiming IP but defense failed!! whatever that means  

[MAM59]

5 minutes ago, livingonline8 said:

this setting is fine, it must be something else that makes my router change the unread IP server every few minutes

the next chance of problemmaker would be an ethernet loop.

If your server has more than one lan card and both are connected to the router, it may get confused. If you have created a "bonded interface", make sure the bonding method is the same that your router accepts.

(maybe called Trunk or Link Aggregation)

Edited May 9, 2022 by MAM59

[livingonline8]

9 minutes ago, MAM59 said:

the next chance of problemmaker would be an ethernet loop.

If your server has more than one lan card and both are connected to the router, it may get confused. If you have created a "bonded interface", make sure the bonding method is the same that your router accepts.

(maybe called Trunk or Link Aggregation)

My server does have two eth ports but I am connected to router using one only. 

 

Can you tell me how can I stop bonding on the unpaid server since I am not using it

 

I think it is active in my settings for some reason. Please check my screenshot that I attached 

[livingonline8]

Also I noticed the server is acting funny getting a new IP every few minutes as soon as I start the Pi-hole or Adguard Home dockers! 

although in my previous ASUS router this was not the case 

Edited May 9, 2022 by livingonline8

[livingonline8]

ok here is the sys log for what's going on as soon as I start Adguard Home docker, I timed it at 13:17 

the unraid server had this IP 192.168.1.250 and as soon I started Adguard Home docker, my server switched IP to 192.168.1.251

few minutes later it is 192.168.1.252...then few more minutes and it is 192.168.1.249

 

Please check the new attached diagnostics 

May  9 13:17:47 Tower kernel: eth0: renamed from veth846d0ed
May  9 13:17:47 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:47 Tower kernel: device br0 entered promiscuous mode
May  9 13:17:48 Tower dhcpcd[4443]: br0: 02:01:4e:36:f1:43(02:01:4e:36:f1:43) claims 192.168.1.250
May  9 13:17:49 Tower dhcpcd[4443]: br0: 02:01:4e:36:f1:43(02:01:4e:36:f1:43) claims 192.168.1.250
May  9 13:17:49 Tower dhcpcd[4443]: br0: 10 second defence failed for 192.168.1.250
May  9 13:17:49 Tower dhcpcd[4443]: br0: deleting route to 192.168.1.0/24
May  9 13:17:49 Tower dhcpcd[4443]: br0: deleting default route via 192.168.1.1
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2002.0 try https://www.rsyslog.com/e/2359 ]
May  9 13:17:49 Tower rsyslogd: omfwd/udp: socket 2: sendto() error: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: omfwd: socket 2: error 101 sending via udp: Network is unreachable [v8.2002.0 try https://www.rsyslog.com/e/2354 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower rsyslogd: action 'action-2-builtin:omfwd' suspended (module 'builtin:omfwd'), next retry is Mon May  9 13:18:19 2022, retry nbr 0. There should be messages before this one giving the reason for suspension. [v8.2002.0 try https://www.rsyslog.com/e/2007 ]
May  9 13:17:49 Tower dhcpcd[4443]: br0: rebinding lease of 192.168.1.250
May  9 13:17:49 Tower dhcpcd[4443]: br0: probing address 192.168.1.250/24
May  9 13:17:50 Tower dhcpcd[4443]: br0: 02:01:4e:36:f1:43(02:01:4e:36:f1:43) claims 192.168.1.250
May  9 13:17:50 Tower dhcpcd[4443]: br0: DAD detected 192.168.1.250
May  9 13:17:50 Tower ntpd[2439]: Deleting interface #46 br0, 192.168.1.250#123, interface stats: received=27, sent=27, dropped=0, active_time=187 secs
May  9 13:17:50 Tower ntpd[2439]: 216.239.35.0 local addr 192.168.1.250 -> <null>
May  9 13:17:50 Tower ntpd[2439]: 216.239.35.4 local addr 192.168.1.250 -> <null>
May  9 13:17:50 Tower ntpd[2439]: 216.239.35.8 local addr 192.168.1.250 -> <null>
May  9 13:17:50 Tower ntpd[2439]: 216.239.35.12 local addr 192.168.1.250 -> <null>
May  9 13:17:51 Tower dhcpcd[4443]: br0: soliciting a DHCP lease
May  9 13:17:52 Tower dhcpcd[4443]: br0: offered 192.168.1.251 from 192.168.1.1
May  9 13:17:52 Tower dhcpcd[4443]: br0: probing address 192.168.1.251/24
May  9 13:17:57 Tower dhcpcd[4443]: br0: leased 192.168.1.251 for 28800 seconds
May  9 13:17:57 Tower dhcpcd[4443]: br0: adding route to 192.168.1.0/24
May  9 13:17:57 Tower dhcpcd[4443]: br0: adding default route via 192.168.1.1
May  9 13:17:59 Tower ntpd[2439]: Listen normally on 47 br0 192.168.1.251:123
May  9 13:17:59 Tower ntpd[2439]: new interface(s) found: waking up resolver

 

tower-diagnostics-20220509-1334.zip

Edited May 9, 2022 by livingonline8

[Frank1940]

Disclosure:  I am  no networking Guru.  (I just read a lot of posts.)  Here is what I would try:

 

1-- Shut the server down.  (A quick push-- 1 second-  of the power button should result in a 'clean' shutdown.)

 

2--  Pull the flash/boot drive.   Plug into PC

 

3-- Go to the   /config  folder/directory.  rename the two .cfg files  that begin with 'network'.  (Example:  add a   .old   or .bak  extension to the file.)

 

4-- Eject the flash drive, pull it from the PC and plug back into the server.

 

5-- Boot the server.  (Those two files will be rebuilt by Unraid when it finds them missing.)

 

You could just delete the files but renaming them gives you the option of a quick recovery.   (It also might be well to make a complete backup of that flash drive while you have it in your PC.  You never know when you might need one!)

[MAM59]

checking you posts again, I found something strange:

 

Your syslog shows you have an 2 Port Intel IXGB (10Gbe) card, but your screenshot of the network config shows an interface from some unknown taiwan company

INVENTEC CORPORATION

Adresse:No. 255, Jen-Ho Road Sec. 2, 33547,
Tachi Taoyuan 33547
TW

 

This is a bit confusing... is there a 3rd card in your server, that you did not show us for now (scroll down the page and take screenshots of the rest. There should be at least eth1 and a section where you can see/adjust, what mac address gets what interface name).

 

Your syslog shows that you get an address from the dhcp server, but when trying to see if this address is already in use elsewhere a device with the address

br0: 02:01:4e:36:f1:43(02:01:4e:36:f1:43) claims 192.168.1.200

(THIS is the intel card!)

and since your network uses a failover bonding (set to NO!!!), packets from the mystic card echo back to the intel which instantly pulls back her address.

 

Note this mystic device can also be a wild running docker pseudo card or something. Turn off dockers and see what happens.

 

(Dockers are shit anyway!)

 

[MAM59]

there is another simple but effective possible error:

 

Your lan may contain a dead or not really functioning device like a not well connected lan. There are cases where the receive lines work (link is on), but sending lines are not (link only on one side).

Or a broken card, which can receive, but not send (NOT IN YOUR SERVER, BUT ELSEWHERE IN YOUR LAN!).

what happens then is really hard to describe and partly random. But you can think of it as "fighting for addresses". Both receivers take the new address and probes for "free" will fail, so the server assign the next address and the circle begins .

 

Try to find this 02:01:4e:36:f1:43 and eliminate it. Maybe it is even the router himself and he is broken? (look for addressen that start with 02:01:4e:)

[Vr2Io]

23 hours ago, livingonline8 said:

Assigned static IP address ( I still lose access to GUI

 

20 hours ago, livingonline8 said:

br0: DAD detected 192.168.1.250

 

20 hours ago, livingonline8 said:

Also I noticed the server is acting funny getting a new IP every few minutes as soon as I start the Pi-hole or Adguard Home dockers!

 

Although it look like DHCP issue, but base on above founding, it should relate network looping happen ( focus on DAD - Duplicate Address Detection ), I suspect it cause by DNS resolve looping there, pls check does DNS resolve loop on USG between Unraid, you can try setting Unraid use external DNS instead USG/pihole/adguard for troubleshooting.

Edited May 10, 2022 by Vr2Io

[MAM59]

Slightly offtopic opinion: I would get rid of the pihole docker. it is a real bad idea.

 

You produce a chicken and egg problem at booting times with it. Unraid needs to ask dns, dockers are not started yet. This will at least result in serious timeouts if it wont even produce more harm by supplying false data (which is cached then and not corrected for an amount of time)

 

Pihole belongs to be run on a seperate pi.