Vaseer Posted January 19, 2017 Share Posted January 19, 2017 (edited) For the second time I have noticed, that unRAID got 2 local IPs. 10.1.0.12 (MAC BC:5F:F4:C8:B8:55) that is statically assigned to it by pfSense router and 10.1.0.254 (MAC 5e:d3:0a:b0:21:26) - not used on local network by any other device. My local network is 10.1.0.0/24 and all local devices has IPs assigned statically by pfSense. NIC's MAC address must be on DHCP list to get local IP. 5e:d3:0a:b0:21:26 is not on DHCP list. Since my unRAID MB has dual NIC, I am using bonding on eth0 (BC:5F:F4:C8:B8:55) and eth1 (bc:5f:f4:c8:b8:53) and everything is working great. First time I noticed that unRAID got 10.1.0.254 was couple months back, when we have power outage. When power came back, unRAID has started but pfSense has not. I had manually start pfSense. Later on I was trying to connect to unRAID movie share from KODI via NFS - on this device NFS share was never before added/accessed. KODI > browse NFS > it has found NFS share on IP 10.1.0.254 (10.1.0.12 was not on the list). Never before had it found NFS share on 10.1.0.254 (only on 10.1.0.12). I tried accessing unRAID UI via 10.1.0.12 and 10.1.0.254 and both IPs were leading to same page. On second KODI box I had added same NFS share before and when I checked path it was "nfs://10.1.0.12/mnt/..." and I could access it. If I tried added new NFS share it also found 10.1.0.254. When I rebooted unRAID, it got only 10.1.0.12. 10.1.0.254 was not assigned/reachable on the local network. Today I noticed the same thing. unRAID uptime 32 days. Version: 6.2.4. After unRAID restart, it got only 10.1.0.12. 10.1.0.254 was not reachable on local network. When I checked Hardware profile and ifconfig via SSH, I saw new device (after reboot it is gone): 01p017dd5eaa2f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.1.0.254 netmask 255.255.255.0 broadcast 0.0.0.0 ether 5e:d3:0a:b0:21:26 txqueuelen 1 (Ethernet) RX packets 29557443 bytes 2238824173 (2.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 27225376 bytes 265900467691 (247.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Any ideas why this is happening? I have attached Hardware profile and ifconfig before and after reboot and diagnostics after reboot. alfheimr-diagnostics-20170119-1114.zip HardwareProfile-ifconfig.zip Edited February 25, 2017 by Vaseer Quote Link to comment
Frank1940 Posted January 19, 2017 Share Posted January 19, 2017 I downloaded and looked at your configuration files. If you want a static IP address and you have already told pfSense to always assign it that address, why don't you also assign that as a static IP address in unRAID? I think your problem is happening because you are telling unRAID to use DCHP to get the IP address, and if pfSense is not running at the time when unRAID boots, how is it going to get the right address? (Perhaps, I should point out that the IP address for unRAID is set during the boot process and can't just be changed at some later time.) Of course, the obvious solution is to always assure that pfSense is running before you boot the server... Quote Link to comment
Vaseer Posted January 20, 2017 Author Share Posted January 20, 2017 Yesterday, when I second time noticed that unRAID has 10.1.0.254, uptime of pfSense was 42 days, unRAID 32 days. I will try and set static IP in unRAID settings, but I doubt that this will do any difference, because unRAID was always accessible via 10.1.0.12 (even when it had two IPs). 10.1.0.254 was extra IP, that I do not know where it come from and why. DHCP on pfSense is limited to static assigning IP's and there is no dynamic IP pool (for 10.1.0.0/24 network). I would still like to know, where did "new" network device come from: 01p017dd5eaa2f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.1.0.254 netmask 255.255.255.0 broadcast 0.0.0.0 ether 5e:d3:0a:b0:21:26 txqueuelen 1 (Ethernet) RX packets 29557443 bytes 2238824173 (2.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 27225376 bytes 265900467691 (247.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 If you check Hardware profile and ifconfig output before and after reboot, you will see, that after reboot "01p017dd5eaa2f4" is gone. Quote Link to comment
Frank1940 Posted January 20, 2017 Share Posted January 20, 2017 I am assuming that you are running some Dockers and VM's on this server. When that happens, there is an internal process which (for the lack of a better term) can create some virtual IP addresses that that network traffic gets sent to the right process. I don't run any Dockers or VM's so I don't have any real hands-on experience with what I think you are seeing. Furthermore, I don't have a server with dual NIC's. (I also seem to recall if an unRAID server is using DHCP to get an LAN IP address and the external LAN DHCP service is not available, an IP address is still assigned and I seem to vaguely recall that it begins with 10.x.x.x) I am hoping that someone with a better understanding will jump in and give you a hand. Quote Link to comment
Vaseer Posted February 25, 2017 Author Share Posted February 25, 2017 (edited) It has happened again, except this time there was 2 "unassigned" IPs/interfaces (01p004a9b136b7a and 01p16ebf7e560f4) in ifconfig output: ifconfig 01p004a9b136b7a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.1.0.254 netmask 255.255.255.0 broadcast 0.0.0.0 ether 72:67:96:a2:e7:40 txqueuelen 1000 (Ethernet) RX packets 133948 bytes 11712424 (11.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 55098 bytes 50200191 (47.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 01p16ebf7e560f4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 8.1.0.253 netmask 255.255.255.0 broadcast 0.0.0.0 ether 6a:78:13:b7:47:f0 txqueuelen 1000 (Ethernet) RX packets 2358 bytes 152114 (148.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 79 bytes 12711 (12.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500 inet 10.1.0.12 netmask 255.255.255.0 broadcast 10.1.0.255 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 16907948 bytes 2147614322 (2.0 GiB) RX errors 0 dropped 73078 overruns 0 frame 0 TX packets 33092565 bytes 44535099230 (41.4 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 ether 02:42:b9:b3:59:d0 txqueuelen 0 (Ethernet) RX packets 566258 bytes 423468679 (403.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 612877 bytes 306642661 (292.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 8334757 bytes 1066148269 (1016.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 16546254 bytes 22267237161 (20.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 8573191 bytes 1081466053 (1.0 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 16546311 bytes 22267862069 (20.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.255.255.255 loop txqueuelen 1 (Local Loopback) RX packets 246203 bytes 45144238 (43.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 246203 bytes 45144238 (43.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 veth1d869d2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 52:f6:d1:4b:39:33 txqueuelen 0 (Ethernet) RX packets 29203 bytes 14444263 (13.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 34168 bytes 41438246 (39.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 veth2e08630: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether d2:28:78:d0:da:bd txqueuelen 0 (Ethernet) RX packets 26732 bytes 5509023 (5.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 29408 bytes 14987268 (14.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethab0a207: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether b6:5d:43:3f:49:49 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1887 bytes 357330 (348.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 After reboot: ifconfig bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500 inet 10.1.0.12 netmask 255.255.255.0 broadcast 10.1.0.255 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 458691 bytes 607881444 (579.7 MiB) RX errors 0 dropped 114 overruns 0 frame 0 TX packets 252118 bytes 94079946 (89.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 ether 02:42:70:1a:f7:e7 txqueuelen 0 (Ethernet) RX packets 893 bytes 72878 (71.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1005 bytes 1074400 (1.0 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 229230 bytes 304049263 (289.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126061 bytes 47019045 (44.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether bc:5f:f4:c8:b8:55 txqueuelen 1000 (Ethernet) RX packets 229462 bytes 303833661 (289.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 126058 bytes 47060963 (44.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.255.255.255 loop txqueuelen 1 (Local Loopback) RX packets 412 bytes 102623 (100.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 412 bytes 102623 (100.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 veth4381222: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 7a:94:ab:99:8b:21 txqueuelen 0 (Ethernet) RX packets 363 bytes 42383 (41.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 418 bytes 203670 (198.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 veth382cd7d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 1e:43:e0:6c:ff:78 txqueuelen 0 (Ethernet) RX packets 530 bytes 42997 (41.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 668 bytes 883077 (862.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethc4f6301: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 3e:c0:44:19:5b:50 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 79 bytes 11832 (11.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 unRAID version is now 6.3.2 Diagnostics attached. alfheimr-diagnostics-20170225-2301.zip Edited February 25, 2017 by Vaseer Quote Link to comment
saarg Posted February 25, 2017 Share Posted February 25, 2017 Are you running any VPN servers or similar? Most likely there are something you installed creating those new interfaces. Does the same thing happen if you boot into safe mode and disable docker? Quote Link to comment
Vaseer Posted February 27, 2017 Author Share Posted February 27, 2017 No VPN server on unRAID (I have VPN server on pfSense router, which is completely different machine). There are 11 dockers on unRAID, from which 6 are always running (see attached picture). Funny thing is, that additional interfaces are not present after reboot. At this moment unRAID's uptime is 1 day 3 hours and no additional interface is present. Last time uptime was ~6 days. I tried turning on all dockers and no additional interface appeared. Quote Link to comment
saarg Posted February 27, 2017 Share Posted February 27, 2017 What about the pipework container? Doesn't it do some network modifications? Quote Link to comment
Vaseer Posted March 19, 2017 Author Share Posted March 19, 2017 Yes, Pipework does some network changes but if I understand correctly, changes are for selected dockers only. In my case dockers Transmission and cloud9ide. I was using Pipework before and never noticed that behavior. Fun fact: Using NFS, devices no longer find shares on IP 10.1.0.12, but when 10.1.0.254 appears, they find NFS shares on .254 Quote Link to comment
saarg Posted March 20, 2017 Share Posted March 20, 2017 I don't know how pipework works, but it doesn't hurt to disable it for testing. 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.