Ubuntu server randomly looses LAN connection

Hello,

I have this remote Ubuntu 12.04 minimal headless server which I access and manage over reverse-SSH-tunnel (because it's behind a NAT firewall).

However, the issue I'm facing is, that randomly it cannot be accessed, whether remotely or over the LAN.
When I say random,at times it can go for days and at times it doesn't go for more than 24hrs.

At first I thought it was maybe a power-saving thing or maybe the UPS having a problem or maybe even a hardware issue with the server itself, so I asked a guy on-site to make some observations:

- Server is not powering off
- server is not going into power saving mode
- I asked the guy there to press the power button and the server nicely shut down and powered off, so it had not crashed or frozen
- Then he pressed the power button again and the server booted up, connected to the internet and I could immediately access it over reverse-SSH-tunnel

I suspected that it could be a random clash of IP number - maybe the IP number assigned could have been in use previously and maybe an issue.
I also suspected some hardware issue with the network card.
So I set a background continuous ping command

ping 173.194.47.23 -i 600 >> ping.txt &

The result was, that after 48hrs I got 140 lines of which the first 136 lines were responses and the remaining 4 lines we, "Destination Host Unreachable".
Seeing that I had set the ping interval to 600 and there are 140 files, I can see the command went on for about 23.5hrs
Here's the results of ping.txt:

PING 173.194.47.23 (173.194.47.23) 56(84) bytes of data.
    64 bytes from 173.194.47.23: icmp_req=1 ttl=52 time=236 ms
    64 bytes from 173.194.47.23: icmp_req=2 ttl=52 time=231 ms
    64 bytes from 173.194.47.23: icmp_req=3 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=4 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=5 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=6 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=7 ttl=52 time=232 ms
    64 bytes from 173.194.47.23: icmp_req=8 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=9 ttl=52 time=232 ms
    64 bytes from 173.194.47.23: icmp_req=10 ttl=52 time=234 ms
    64 bytes from 173.194.47.23: icmp_req=11 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=12 ttl=52 time=228 ms
    64 bytes from 173.194.47.23: icmp_req=13 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=15 ttl=52 time=220 ms
    64 bytes from 173.194.47.23: icmp_req=16 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=17 ttl=52 time=229 ms
    64 bytes from 173.194.47.23: icmp_req=18 ttl=52 time=236 ms
    64 bytes from 173.194.47.23: icmp_req=19 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=20 ttl=52 time=235 ms
    64 bytes from 173.194.47.23: icmp_req=21 ttl=52 time=217 ms
    64 bytes from 173.194.47.23: icmp_req=22 ttl=52 time=219 ms
    64 bytes from 173.194.47.23: icmp_req=23 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=24 ttl=52 time=220 ms
    64 bytes from 173.194.47.23: icmp_req=25 ttl=52 time=222 ms
    64 bytes from 173.194.47.23: icmp_req=26 ttl=52 time=218 ms
    64 bytes from 173.194.47.23: icmp_req=28 ttl=52 time=240 ms
    64 bytes from 173.194.47.23: icmp_req=29 ttl=52 time=224 ms
    64 bytes from 173.194.47.23: icmp_req=30 ttl=52 time=230 ms
    64 bytes from 173.194.47.23: icmp_req=31 ttl=52 time=221 ms
    64 bytes from 173.194.47.23: icmp_req=32 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=34 ttl=52 time=224 ms
    64 bytes from 173.194.47.23: icmp_req=35 ttl=52 time=277 ms
    64 bytes from 173.194.47.23: icmp_req=36 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=37 ttl=52 time=216 ms
    64 bytes from 173.194.47.23: icmp_req=38 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=39 ttl=52 time=217 ms
    64 bytes from 173.194.47.23: icmp_req=40 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=41 ttl=52 time=685 ms
    64 bytes from 173.194.47.23: icmp_req=42 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=43 ttl=52 time=233 ms
    64 bytes from 173.194.47.23: icmp_req=44 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=45 ttl=52 time=242 ms
    64 bytes from 173.194.47.23: icmp_req=46 ttl=52 time=239 ms
    64 bytes from 173.194.47.23: icmp_req=47 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=48 ttl=52 time=229 ms
    64 bytes from 173.194.47.23: icmp_req=49 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=50 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=51 ttl=52 time=238 ms
    64 bytes from 173.194.47.23: icmp_req=52 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=53 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=54 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=55 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=57 ttl=52 time=233 ms
    64 bytes from 173.194.47.23: icmp_req=58 ttl=52 time=228 ms
    64 bytes from 173.194.47.23: icmp_req=59 ttl=52 time=229 ms
    64 bytes from 173.194.47.23: icmp_req=61 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=62 ttl=52 time=221 ms
    64 bytes from 173.194.47.23: icmp_req=63 ttl=52 time=222 ms
    64 bytes from 173.194.47.23: icmp_req=64 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=65 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=66 ttl=52 time=218 ms
    64 bytes from 173.194.47.23: icmp_req=67 ttl=52 time=208 ms
    64 bytes from 173.194.47.23: icmp_req=68 ttl=52 time=220 ms
    64 bytes from 173.194.47.23: icmp_req=69 ttl=52 time=216 ms
    64 bytes from 173.194.47.23: icmp_req=70 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=71 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=72 ttl=52 time=221 ms
    64 bytes from 173.194.47.23: icmp_req=73 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=74 ttl=52 time=209 ms
    64 bytes from 173.194.47.23: icmp_req=75 ttl=52 time=207 ms
    64 bytes from 173.194.47.23: icmp_req=76 ttl=52 time=214 ms
    64 bytes from 173.194.47.23: icmp_req=77 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=78 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=79 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=80 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=81 ttl=52 time=213 ms
    64 bytes from 173.194.47.23: icmp_req=82 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=83 ttl=52 time=203 ms
    64 bytes from 173.194.47.23: icmp_req=84 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=85 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=86 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=87 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=88 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=89 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=90 ttl=52 time=203 ms
    64 bytes from 173.194.47.23: icmp_req=91 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=92 ttl=52 time=212 ms
    64 bytes from 173.194.47.23: icmp_req=93 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=94 ttl=52 time=207 ms
    64 bytes from 173.194.47.23: icmp_req=95 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=96 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=97 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=98 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=99 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=100 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=101 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=102 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=103 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=104 ttl=52 time=204 ms
    64 bytes from 173.194.47.23: icmp_req=105 ttl=52 time=205 ms
    64 bytes from 173.194.47.23: icmp_req=106 ttl=52 time=206 ms
    64 bytes from 173.194.47.23: icmp_req=107 ttl=52 time=216 ms
    64 bytes from 173.194.47.23: icmp_req=108 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=109 ttl=52 time=221 ms
    64 bytes from 173.194.47.23: icmp_req=110 ttl=52 time=224 ms
    64 bytes from 173.194.47.23: icmp_req=111 ttl=52 time=224 ms
    64 bytes from 173.194.47.23: icmp_req=112 ttl=52 time=226 ms
    64 bytes from 173.194.47.23: icmp_req=113 ttl=52 time=212 ms
    64 bytes from 173.194.47.23: icmp_req=114 ttl=52 time=218 ms
    64 bytes from 173.194.47.23: icmp_req=115 ttl=52 time=208 ms
    64 bytes from 173.194.47.23: icmp_req=116 ttl=52 time=209 ms
    64 bytes from 173.194.47.23: icmp_req=117 ttl=52 time=211 ms
    64 bytes from 173.194.47.23: icmp_req=118 ttl=52 time=210 ms
    64 bytes from 173.194.47.23: icmp_req=119 ttl=52 time=215 ms
    64 bytes from 173.194.47.23: icmp_req=120 ttl=52 time=227 ms
    64 bytes from 173.194.47.23: icmp_req=121 ttl=52 time=229 ms
    64 bytes from 173.194.47.23: icmp_req=122 ttl=52 time=222 ms
    64 bytes from 173.194.47.23: icmp_req=123 ttl=52 time=237 ms
    64 bytes from 173.194.47.23: icmp_req=124 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=125 ttl=52 time=224 ms
    64 bytes from 173.194.47.23: icmp_req=126 ttl=52 time=219 ms
    64 bytes from 173.194.47.23: icmp_req=127 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=128 ttl=52 time=223 ms
    64 bytes from 173.194.47.23: icmp_req=129 ttl=52 time=225 ms
    64 bytes from 173.194.47.23: icmp_req=130 ttl=52 time=242 ms
    64 bytes from 173.194.47.23: icmp_req=131 ttl=52 time=240 ms
    64 bytes from 173.194.47.23: icmp_req=132 ttl=52 time=246 ms
    64 bytes from 173.194.47.23: icmp_req=133 ttl=52 time=235 ms
    64 bytes from 173.194.47.23: icmp_req=134 ttl=52 time=231 ms
    64 bytes from 173.194.47.23: icmp_req=135 ttl=52 time=229 ms
    64 bytes from 173.194.47.23: icmp_req=136 ttl=52 time=223 ms
    From 192.168.0.10 icmp_seq=137 Destination Host Unreachable
    From 192.168.0.10 icmp_seq=138 Destination Host Unreachable
    From 192.168.0.10 icmp_seq=139 Destination Host Unreachable
    From 192.168.0.10 icmp_seq=140 Destination Host Unreachable

The funny thing is, why did the pinging stop after 4 unreachables? The server remained ON; it had not crashed; it had not gone into sleep mode.

All other machines on the LAN are Windows based and there's not tech-guys on-site.

Any help and suggestions on how to handle and fault-find this, would be highly appreciated.

what steps do you take after this point, where the ping.txt stops updating, to get the connectivity back? does the ping process also get killed? Besides possible hardware issues, I wonder if some firewall rules are eagerly labelling moderate usage as signs of DoS and blocking or turning off services and/or dropping off connections.

Originally Posted by pintooo15 what steps do you take after this point, where the ping.txt stops updating, to get the connectivity back?

All that can be done is to reboot the server.

Originally Posted by pintooo15 does the ping process also get killed?

Looks like. 'Cos it shows 4 "Destination host unreachable" and nothing more, even though the server was powered up much longer and when attended to(about more than 48hrs later), the followng observations were made:

• Server power indicator was ON and not blinking (so it was not in any power saving mode)
• Someone on-site just gave a single-touch to the power botton and the server shut-down (he did not have to keep the power button pressed) which means the server and OS were alive and had not crashed.
• In every such "unreachable" scenarion, the server is just rebooted and can then be accessed fom the LAN as normal

Originally Posted by pintooo15 Besides possible hardware issues, I wonder if some firewall rules are eagerly labelling moderate usage as signs of DoS and blocking or turning off services and/or dropping off connections.

There's no firewall.

Calculating, it works out the last process in the ping took place at about 14:02 (17th Feb), so I looked for a syslog file in /var/log and in there at about 14:02 is:

Feb 17 14:02:47 dhclient: last message repeated 4 times

However,way back at about 13:29, issues seem to have started as autossh has been unable to connect.But I still can't figure out where the problem lies;I am however getting a feeling that it's to do with renewing the IP number? I've uploaded a portion of the syslog.1 file which I feel links to the problem. Here's the link.

Pastebin the log txt file please. pastebin.ca is a good option. only suggesting.

If it is possible to attach a console/screen to the server box, you will have more options to diagnose the connectivity situation. First thing is you would take a look at /var/log/* to grep for stuff like "disconnected" or "dropped" or "rejected" or something in conjuntion with NetworkManager or pppd or whatever process manages the network connection. I won't care about specific services like ssh because even your ping fails. My intention is to just find a way to 1. get a time of the network going down and observing what (if any) other relevant processes might have logged that time. and 2. isolate the issue as either a software (some process dying or just tired of your networking load), hardware (network card) or firewall (NAT firewall) issue.

The dhclient line "last message repeated 4 times" refers to the line above it, which was repeated four times. Do paste that here. If it's a server, why is it's IP renewing and why is there a DHCP client running?

Originally Posted by pintooo15 Pastebin the log txt file please. pastebin.ca is a good option. only suggesting.

Thanks Pintooo15.

I had to delay my reply here, 'cos I ran another continuous ping command - this time logging date and time as well and was thus waiting for it to go down.

Well, it ran for a few days and then went down again, so I feel we're now in a better position as we can actually match the ping results to the logs.
I've done some pastebin's for the ping results as well as some files I found in the /var/log/ that happened to match the time to the ping results:
Ping Results: http://pastebin.com/Q1SDHk0j
dmesg.o http://pastebin.com/qkAwqzdy
Syslog.7 http://pastebin.com/i7YPEi2t

There was also a 'wtmp.1' file which matched the time of the failing ping, but was unable to pastebin it so it's available at:
http://www.fileconvoy.com/dfl.php?id...e460f6b4ed106d

Originally Posted by pintooo15 If it is possible to attach a console/screen to the server box, you will have more options to diagnose the connectivity situation. First thing is you would take a look at /var/log/* to grep for stuff like "disconnected" or "dropped" or "rejected" or something in conjuntion with NetworkManager or pppd or whatever process manages the network connection. I won't care about specific services like ssh because even your ping fails. My intention is to just find a way to 1. get a time of the network going down and observing what (if any) other relevant processes might have logged that time. and 2. isolate the issue as either a software (some process dying or just tired of your networking load), hardware (network card) or firewall (NAT firewall) issue.

The server is a headless on and is in a different city with no tech guy around so attaching a screen to it could pose problems.
I do however have full SSH access to it with Webmin and Nagios3 installed (if these could be of help).

Originally Posted by pintooo15 The dhclient line "last message repeated 4 times" refers to the line above it, which was repeated four times. Do paste that here.

Feb 25 23:56:19 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67

Originally Posted by pintooo15 If it's a server, why is it's IP renewing and why is there a DHCP client running?

Isn't the IP renewing 'cos it's connected to a DHCP router?
When installing Ubuntu 12.04 minimal, I just did the default installation and did not select DHCP client as a service or anything.

Your server must be behind a firewall of sorts, if you get an IP address dynamically from the service provider. Does the IP of the server ever change?

BTW what's up with the two networks? Your ping returns 173.194... then gets an icmp alert from a 192.168.0.10 address? It looks like the 173... is the external IP of the internet facing router you are behind, and perhaps the 192.168.0.10 is the IP of your server's interface. Where did you get the 173... number from? Does this server have a routable host name? If so, does pinging it by name resolve to the 173.194.x.x address?

Your problem might be something the service provider is doing. They no doubt have to deal with a lot of mayhem coming off the internet. It would help us if we knew what services this server is presenting to the outside world.

Thanks Catworld.

Originally Posted by catworld Your server must be behind a firewall of sorts, if you get an IP address dynamically from the service provider. Does the IP of the server ever change?

Well, I've actually asked for a topology of the network and will post it here, but in the meantime: Yes the whole network is behind the IPS's NAT Firewall. Once in, there's a LAN in which this server sits. The server itself is set to DHCP and there must be some DLink or Linksys router managing this LAN (and providing local 192.168.0.xxx IP#'s). As for the ISP providing IP#'s - they provide dynamic IP's and we have no control over this.

Originally Posted by catworld BTW what's up with the two networks? Your ping returns 173.194... then gets an icmp alert from a 192.168.0.10 address? It looks like the 173... is the external IP of the internet facing router you are behind, and perhaps the 192.168.0.10 is the IP of your server's interface. Where did you get the 173... number from? Does this server have a routable host name? If so, does pinging it by name resolve to the 173.194.x.x address?

The 173.194... comes from the ping result, doesn't it? (I was pinging to 173.194...) and 192.168.0.10 is the IP# of the server itself.

Originally Posted by catworld Your problem might be something the service provider is doing. They no doubt have to deal with a lot of mayhem coming off the internet. It would help us if we knew what services this server is presenting to the outside world.

The server does not provide any services to the outside world. It's housing an Electronic Medical Records database app built around Apache, PHP, MySQL; so those on the LAN wanting to access this app just point their web browser to http://192.168.0.10/openemr
It's only connection to the outside world is for me to be able to login over reverse-ssh-tunnel and provide support & updates (there's also Nagios & Webmin installed on it).
However, when the server is unreachable, not only me but all those on it's LAN too cannot access it - yet as previously mentioned, it's powered up and not in sleep mode or anything.

In your Syslog.7:
Feb 25 23:26:37 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:26:38 openemr dhclient: DHCPACK of 192.168.0.10 from 192.168.0.1
Feb 25 23:26:38 openemr dhclient: bound to 192.168.0.10 -- renewal in 1598 seconds.

This is normal. But in the local network I would suggest to use static IP. But anyway - this is normal behavior.
Next after 1598 seconds:
Feb 25 23:53:16 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:53:32 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:53:42 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:53:57 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:54:15 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
Feb 25 23:54:57 dhclient: last message repeated 3 times
Feb 25 23:55:18 openemr dhclient: DHCPREQUEST of 192.168.0.10 on eth0 to 192.168.0.1 port 67
....Feb 26 00:26:39 openemr postfix/master[1208]: reload -- version 2.9.3, configuration /etc/postfix

Feb 26 00:26:39 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Feb 26 00:26:42 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Feb 26 00:26:49 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Feb 26 00:26:56 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Feb 26 00:27:11 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
Feb 26 00:27:27 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20
Feb 26 00:27:47 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
Feb 26 00:27:50 openemr nagios3: Auto-save of retention data completed successfully.
Feb 26 00:28:00 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
Feb 26 00:28:18 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Feb 26 00:28:33 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Feb 26 00:28:45 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
Feb 26 00:29:03 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20
Feb 26 00:29:23 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Feb 26 00:29:30 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
Feb 26 00:29:44 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
Feb 26 00:29:53 openemr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19


Your dhcp server doesn't work properly.
And ones again - for the local network interface use static IP.

Using static might be the answer, but then the ISPs routing or arp tables might potentially lose the server, no?

If the ultimate problem is the DHCP server it would be the ISPs problem... maybe. I'd ask them how they run the DHCP service. Maybe there's some minute incompatibility in the stack between the ISP and your distro's implementation.

His server uses 192.168.0.10 - those are LAN IPs and don't have any relation to ISP IPs. All OP needs to do is to make DHCP address pool higher then 192.168.0.10, so 192.168.0.2-10 can be used for static.

This is what I think.

Is the OP running the dhcp server? I thought the ISP is the one handing out addresses, and the OP has no access to dhcp configs.