Clearing DNS cache and DHCP lease table

[adrianw]

Good news - my new 8800AXL stays up permanently replacing the 7800N which had started rebooting several times a day.

Also good news - many of the config changes which required the 7800N to be restarted can be done without a restart of the 8800AXL.

Now the problem:
I have assigned fixed IP addresses to most (but not all) of the devices on my network.
To refer to them by name, I've created entries in the Static DNS table.

I created an isolated wi-fi SSID which uses the subnet 192.168.2.xxx; the rest of my network is on 192.168.1.xxx
As a test, I connected my iMac to the guest network, and it acquired the address 192.168.2.8
I suppose I should have explicitly release the DHCP lease, but I didn't.
I just reconnected the device to its normal static 192.168.1.5 address
The problem is that the DNS nameserver continued to resolve imac.local.host to 192.168.2.8
Even when I added an entry to the static dns table pointing imac.local.host to 192.168.1.5, it didn't change the DNS server's response of 192.168.2.8

After 24 hours when the DHCP lease for 192.168.2.8 had expired, the DNS didn't change.

Since there is no command to do so, eventually I had to reboot the 8800AXL to flush the DNS cache.
Unfortunately it also cleared the DHCP table.
Some devices still thought they had a long lease on their address, and the DHCP server (having cleared the DHCP table) was handing out the same addresses to other machines.

What I really needed was a command to flush the DNS cache without clearing the DHCP table.
An interface to delete individual DHCP leases would be useful (like on my old Thomson Alcatel Speedtouch 716WL)

[billion_fan]

Good news - my new 8800AXL stays up permanently replacing the 7800N which had started rebooting several times a day.

Also good news - many of the config changes which required the 7800N to be restarted can be done without a restart of the 8800AXL.

Now the problem:
I have assigned fixed IP addresses to most (but not all) of the devices on my network.
To refer to them by name, I've created entries in the Static DNS table.

I created an isolated wi-fi SSID which uses the subnet 192.168.2.xxx; the rest of my network is on 192.168.1.xxx
As a test, I connected my iMac to the guest network, and it acquired the address 192.168.2.8
I suppose I should have explicitly release the DHCP lease, but I didn't.
I just reconnected the device to its normal static 192.168.1.5 address
The problem is that the DNS nameserver continued to resolve imac.local.host to 192.168.2.8
Even when I added an entry to the static dns table pointing imac.local.host to 192.168.1.5, it didn't change the DNS server's response of 192.168.2.8

After 24 hours when the DHCP lease for 192.168.2.8 had expired, the DNS didn't change.

Since there is no command to do so, eventually I had to reboot the 8800AXL to flush the DNS cache.
Unfortunately it also cleared the DHCP table.
Some devices still thought they had a long lease on their address, and the DHCP server (having cleared the DHCP table) was handing out the same addresses to other machines.

What I really needed was a command to flush the DNS cache without clearing the DHCP table.
An interface to delete individual DHCP leases would be useful (like on my old Thomson Alcatel Speedtouch 716WL)

Let me check with my engineers and get to you

[adrianw]

After I rebooted the 8800AXL (to flush the DNS cache) I have started getting problems with the DHCP table

The lease table (under Status/DHCP) seems to be getting cleared quite often.
The system log shows frequent entries like this
Sep 2 07:59:17 daemon info syslog: 192.168.1.100 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.101 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.102 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.103 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.104 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.105 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.106 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.107 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.108 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.109 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.110 belongs to someone, reserving it for 3600 seconds
Sep 2 07:59:17 daemon info syslog: 192.168.1.111 belongs to someone, reserving it for 3600 seconds

This is similar to the problem described here : viewtopic.php?f=19&t=3600#p11403
I am starting to agree with Capt.Nemo that although the 8800AXL hardware is doing a great job of keeping the ADSL connection the

Details:
Latest firmware 2.32e
A guest wireless access point is defined, although it is disabled until the next time it's needed.
Other than the (disabled) guest network, I am not using the 8800AXL as a wireless router. The signal is not strong enough to reach the far ends of my house.
I am using a TP-Link wireless access point with a wired connection to the 8800AXL sited to provide better coverage (the access point is using the 8800AXL's DHCP server).

[billion_fan]

Do these devices 192.168.1.100 ~ 192.168.1.111 have fixed IP addresses setup??

[nanotm]

you have two problems, the primary one is that you have to switch off every device including the power line adaptors when you reboot the router to clear the address table information in everything not just the router (some of it may allow arp flushing) otherwise your address information gets blocked,

the secondary one is you cross connected an apple device between the 192.168.2.xx and 192.168.1.xx networks and now you need to change the access pass words for your wifi on both subnets and never use it wired to avoid that problem from happening again /

[adrianw]

@billion_fan:
192.168.1.100 ~ 192.168.1.199 is the range of dynamic IP addresses that the DHCP server is configured to issue.

@nanotm:
Yes I did switch my iMac between the 192.168.1.xx and 192.168.2.xx subnets.
In principle I don't see why you shouldn't be able to do that (to test client isolation for example).
But in practice since this iMac's MAC address is assigned to a static IP address on the 192.168.1.xx subnet I can see it might cause problems.

Turning off all devices as well as rebooting the router seems unnecessarily complicated for a problem that could be cured by a flush dns cache command.
And if you have a T1000 or its younger sibling the T1501 you can't power it off anyway except by cutting the mains supply.
http://www.powerethernet.com/product/po ... t1000.html

[billion_fan]

@billion_fan:
192.168.1.100 ~ 192.168.1.199 is the range of dynamic IP addresses that the DHCP server is configured to issue.

@nanotm:
Yes I did switch my iMac between the 192.168.1.xx and 192.168.2.xx subnets.
In principle I don't see why you shouldn't be able to do that (to test client isolation for example).
But in practice since this iMac's MAC address is assigned to a static IP address on the 192.168.1.xx subnet I can see it might cause problems.

Turning off all devices as well as rebooting the router seems unnecessarily complicated for a problem that could be cured by a flush dns cache command.
And if you have a T1000 or its younger sibling the T1501 you can't power it off anyway except by cutting the mains supply.
http://www.powerethernet.com/product/po ... t1000.html

I can only think that devices are holding onto the DHCP lease (maybe these devices are plugged to your homeplug or switch or both), hence when the router is trying to assign a IP address to another device the IP is showing up as used, and jumping over to the next IP address until one is found that is not in use (looking at the timing of the logs, this looks like what's happened)

Still waiting for a reply from our engineers about flushing the DNS cache

[nanotm]

in principle you should but apple has some strange network implementation system that causes it to mess up, I had similar problems before and its something to do with the bonjour service, the only way to fix it was to totally start again from scratch, or to power down everything and change some passwords, but unless you find a way to flush the arp/dns on everything connected to the network you risk having it come back/

with respect to your powerline based system flipping the mains circuit breaker(s) for 2 minutes will do the job just as effectively as unwiring them and be a lot safer as well

[nanotm]

I don't use telnet if I can help it but doesn't "dns route flush" work to clear the dns cache ? and the arp table should be "clear arp-cache" and "clear ip arp" certainly those must have worked for me on a billion router in the past because I have them in the notepad under billion telnet commands I made after messing about for a week on one after I replaced it

[sebus05]

None of these commands is recognized