unraid unable to reach gateway


Gog

Recommended Posts

For years I've been using DHCP with a reserved IP for unraid.  I've played with this recently (and a DNS server but all that is disabled now) so it might be related.

 

Unraid won't ping my gateway or the internet but only if it's on 192.168.1.74.  If I release the reservation, it resets on .46 and it works.  I can configure a static IP to .111 and it works.  If I use a static IP with .74, I get 100% packet loss on pings.  For all these tests, the array is stopped, I have a bunch of docker container but that's all stopped too.  I've tried this without reboots so the IP is litteraly the only thing that changed between tests.

 

I've gone through every config screen on the gateway and the only place I see the IP and/or the MAC is in the device table. 

 

192.168.1.74 is hardcoded all over the place but with the array stopped I don't see what config could have an effect.

 

I also have one VM I use and a few that are usually stopped, only started for experiments.  These come and go as I reboot with different IPs.  I did not expect that one...

 

Any suggestions or do I rebuild the config from scratch?

 

I'm not familiar with route but from what I read, the gateway config looks ok

 

root@Tower:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    1      0        0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

root@Tower:~# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.74  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 0c:c4:7a:69:41:8c  txqueuelen 0  (Ethernet)
        RX packets 107843  bytes 23898437 (22.7 MiB)
        RX errors 0  dropped 2007  overruns 0  frame 0
        TX packets 102551  bytes 27536726 (26.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.42.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 00:00:00:00:00:00  txqueuelen 0  (Ethernet)
        RX packets 14906  bytes 1770590 (1.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15787  bytes 6858978 (6.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether 0c:c4:7a:69:41:8c  txqueuelen 1000  (Ethernet)
        RX packets 568093  bytes 157746880 (150.4 MiB)
        RX errors 0  dropped 12513  overruns 0  frame 0
        TX packets 742564  bytes 602355552 (574.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xf7600000-f767ffff

eth1: flags=4355<UP,BROADCAST,PROMISC,MULTICAST>  mtu 1500
        ether 0c:c4:7a:69:41:8d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xf7500000-f757ffff

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 14270  bytes 11909320 (11.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14270  bytes 11909320 (11.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:27:15:21  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

Link to comment

When set to x.x.x.74, can the server ping itself on .74?

 

Have you tried rebooting the gateway/router and any other switches in your network?

 

Hi Peter

Yes, it can ping itself.  I rebooted the gateway yesterday and the switch and wireless APs this morning, no change

 

 

root@Tower:/# ping 192.168.1.74
PING 192.168.1.74 (192.168.1.74) 56(84) bytes of data.
64 bytes from 192.168.1.74: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 192.168.1.74: icmp_seq=2 ttl=64 time=0.014 ms
64 bytes from 192.168.1.74: icmp_seq=3 ttl=64 time=0.025 ms
64 bytes from 192.168.1.74: icmp_seq=4 ttl=64 time=0.024 ms
^C
--- 192.168.1.74 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.014/0.020/0.025/0.007 ms
root@Tower:/# ping tower
PING Tower (127.0.0.1) 56(84) bytes of data.
64 bytes from Tower (127.0.0.1): icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from Tower (127.0.0.1): icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from Tower (127.0.0.1): icmp_seq=3 ttl=64 time=0.025 ms
64 bytes from Tower (127.0.0.1): icmp_seq=4 ttl=64 time=0.025 ms
64 bytes from Tower (127.0.0.1): icmp_seq=5 ttl=64 time=0.024 ms
^C
--- Tower ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.019/0.023/0.025/0.004 ms

 

Link to comment

I'm not sure whether this is relevant, but: when I ping localhost (127.0.0.1), I get round trip times which are of the same order of magnitude as you are seeing (mine are 0.035ms), but when I ping the network address, my round trip times are an order of magnitude larger (0.2ms) - much the same as when I ping my router.

 

This suggests, to me, that packets to the network address are travelling further (or through more layers) than those to the localhost address.  In your case, the round trip times sre almost identical, which may mean that the packets never reach the 'outside world'.  It would be interesting to repeat the tests when using the .46 address.

Link to comment

Couldn't experiment on this last night, apparently plex watching is a requirement to gift wrapping sessions

 

I get the same ping time, around 0.02 when I use .74 or .111

 

My plex users are rioting... I give up, I'm switching to .111 and rebuilding.  I'll go one "feature" at a time, hopefully I'll be able to pinpoint the trigger if it happens again.

 

thanks for trying.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.