AND a second server has issues on the same day &#Y$*(@^!!

[1812]

When it rains it pours....

 

 

This is a backup server. Was running 6.2.4. Web GUI becomes unresponsive after a couple minutes. Can ping but not ssh/telnet.

 

I moved the 2 pci cards (HBA and SAS expander) and os usb stick to another computer on the off chance that the onboard ethernet or some other hardware was going wonky on the first server.

 

Problem persisted.

 

I upgraded to 6.3.5 on the "new" computer, problem persisted.

 

I was able to get the Web GUI up for a brief minute window after it not loading and grabbed diagnostics... but I don't think they show anything unless I'm glossing over something....

brahmsbackup-diagnostics-20170831-1453.zip

[1812]

Figured it out..... feel pretty dumb....

 

Roku grabbed the ip while the backup server was shut down (it only runs every couple days.) When the server kept trying to use the ip, it caused the conflict....... limited access... etc....

 

 

 

[wayner]

Were you using DHCP for your unRAID server?  Why not use a static IP outside of your DHCP range.  That way this won't happen again, unless you manually reuse the IP by mistake.

[Frank1940]

Look at the range where your router assigns IP addresses.  If it starts at 192.168.1.2 and  goes up, you should be manually assigning IP addresses up in the area beyond 192.168.1.245.   Your home type router will never need an address that far up the chain!  (A friend of mine who ran a WIFI network for a public school once told me that home routers will become also most totally unresponsive when you have more than about 50 devices actively connected regardless of the actual data traffic.) 

[1812]

5 hours ago, wayner said:

Were you using DHCP for your unRAID server?  Why not use a static IP outside of your DHCP range.  That way this won't happen again, unless you manually reuse the IP by mistake.

 

unRaid server was set static inside the DHCP range...  The roku grabbed the static ip because I didn't assign it to the server on my router, and the lease expired.

 

5 hours ago, Frank1940 said:

Look at the range where your router assigns IP addresses.  If it starts at 192.168.1.2 and  goes up, you should be manually assigning IP addresses up in the area beyond 192.168.1.245.   Your home type router will never need an address that far up the chain!  (A friend of mine who ran a WIFI network for a public school once told me that home routers will become also most totally unresponsive when you have more than about 50 devices actively connected regardless of the actual data traffic.) 

 

I could do that. I should do that... lol...

[tdallen]

I do several things with my router (an Asus).  First, I assign the DHCP pool to be .10 - .252 .  Then I use the router function to statically assign .9 to my unRAID server, by MAC address.  Finally I assign my unRAID server .9 in the unRAID GUI.  No conflicts.

[JonathanM]

50 minutes ago, tdallen said:

I do several things with my router (an Asus).  First, I assign the DHCP pool to be .10 - .252 .  Then I use the router function to statically assign .9 to my unRAID server, by MAC address.  Finally I assign my unRAID server .9 in the unRAID GUI.  No conflicts.

 

Some routers handle things a tiny bit different, where dhcp addresses that should be mapped to specific MAC addresses must still be part of the dhcp pool range. PFSense works that way, IIRC.

 

If you assign an address manually on the device itself in the dhcp pool range, you will create issues if you don't also reserve that address in the pool. Different routers handle it in different ways, but as long as there is no way the dhcp server can hand out one of your manually assigned addresses, you are good.

 

Remember though, if you manually set an IP address on the device itself, many times you are responsible for setting the rest of the network info as well, gateway, subnet mask, dns, etc. If you let the dhcp server hand out that same address, typically all the other stuff will be set correctly as well.

[wayner]

On 9/1/2017 at 8:51 PM, jonathanm said:

Remember though, if you manually set an IP address on the device itself, many times you are responsible for setting the rest of the network info as well, gateway, subnet mask, dns, etc. If you let the dhcp server hand out that same address, typically all the other stuff will be set correctly as well.

After much discussion and learning through the years IMHO the best way to do things is to use DHCP reservations to IP addresses outside of the DHCP pool range for devices for which you want static IPs.  I set my DHCP pool to 192.168.1.100 - 192.168.1.185.  For stuff that I want static I then use the DHCP reservations on my router to assign to IP addresses below 100 or above 185.

I used to use static IP addresses set on the device but when you want to change things that becomes a pain in the butt as you have to physically go to the device and make the changes, sometimes using remote controls that aren't very user friendly.  Using a DHCP reservation on your router can all be done in one central location and you can use a spreadsheet or other method to track what you have assigned.  The one downside to this is that if you change routers it can be a pain in the butt to get everything back up to where you want it - but now that I use Unifi with its software controller that should be less of an issue.

I would also recommend using some network utilities to scan your LAN and keep an eye on things.  On Windows WakeMeOnLAN is good tool for scanning your LAN - not just for sending WOL packets.  On iOS Fing is pretty good.

One other networking recommendation is to use an usual subnet numbering scheme on your LAN - for example don't use 192.168.1.X or 192.168.0.X - maybe use 192.168.168.X.  The reason for this is that if you are using a VPN to get into your LAN and the local network uses the same subnet then it can be difficult or impossible to get to IP addresses on your LAN.  A couple of weeks ago I was at a hotel where they used 192.168.1.X as the LAN numbering scheme and I was able to connect to my home network via VPN but I couldn't access my unRAID server at 192.168.1.99 since that conflicted with the hotel LAN.