AP doesn't resolve Radius hostname when TTL expires

  • 1
  • Question
  • Updated 5 years ago
  • Answered
We noticed AP only resolves radius hostname when bootup.
We update our DNS record with a new IP address of our radius server.

DNS TTL is 300sec but even after 24h APs where still contacting our old radius server. Reboot our AP solves this issue.

Is there a specific reason APs ignore DNS TTL or can we consider this as a bug?
Photo of Steven Liefferinckx

Steven Liefferinckx

  • 17 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 1
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Steven,
That was implemented long before I joined Aerohive, but the basic rationale I've been told is that the underlying assumption at that time was all named entities our APs would need to talk to would be statically-assigned devices.

I will take this up with engineering and while there is a possibility I will be able to get this remedied in a future release, it won't be soon so please plan accordingly.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Conceptually, yes, by the book it should in the strict sense respect the TTL and update accordingly.

However, I strongly agree with Mike that practically it is realistic to expect the address of such servers to remain constant and to design systems with that assumption.

In the very unusual/atypical eventuality that the addresses of one or more RADIUS servers change, it is unlikely to be that unduly burdensome to have to reboot the NASes (switches/APs) when they do.

For me, it is an issue that would warrant being documented as being the implemented behaviour but nothing more.
Photo of Steven Liefferinckx

Steven Liefferinckx

  • 17 Posts
  • 0 Reply Likes
Mike, Nick,

As you already mentioned strict TTL should be respected (which I expected).

I'm just not a fan of partial feature implementation. Or you require an IP address and make it static or implement the hostname option and implement all functionality which goes along with it.

The problem is that by changing radius IP, which isn't indeed rear, we need to restart all APs - DHCP server doesn't like this - in a small maintenance window.

Steven.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
What should the system do if the DNS server(s) becomes unavailable, should the strict TTL be respected there too, by the book? Pick your poison comes to my mind.

The APs can be rebooted concurrently from within one place within HiveManager, so I am certainly curious about the maintenance window comment.

If the DHCP server(s) cannot cope with that type of load, I would suggest that there might be a bigger issue to be looked at.

Nick
Photo of Steven Liefferinckx

Steven Liefferinckx

  • 17 Posts
  • 0 Reply Likes
Of course TTL always need to be respected. DNS servers, just as all others, are redundant even in different DCs.

Reboot all AP, about 7K, is a lot of DHCP requests when they restart at the same time. So split them up per location will significant increase the maintenance window.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I am not disagreeing with you regarding the TTL merely musing... It is additional complexity and another thing to go wrong. While you may have highly available DNS, others may well not etc.

7000 DHCP requests is not that high, but the clients bouncing on that as well and requesting again could be. I believe that a system should be able to cope with this event, however.