ISE Node registration problems in distributed deployment

[tlenzenh]

Hi Team,

Got a question in relation to some issues I am seeing at a customer deployment with ISE 1.4 (new deployment) with 2x PAN, 2x MnT and 2x PSN nodes.

For the initial registration of each node with the primary PAN, we need to configure the FQDN of each node (for which DNS has to work).

For reasons unknown to me yet, I had some intermittent connectivity issues between the nodes and DNS during that process. Sometimes I had to try adding the node 4-5 times before it would eventually register with the PAN. It would say that the hostname is unknown and I should check DNS config of each node. Eventually after many attempts each node would be registered with the PAN.

Now that I started to do some other config and came back to the Deployment menu I can see that all nodes are in Disconnected state.

So here is my question:

Assuming the nodes were all registered correctly at the beginning, does DNS still play a role whenever the PAN communicates with all the other nodes? I’m just trying to work out why they all show as disconnected – is it because there is yet again an issue with DNS communication or is there maybe another IP connectivity problem between the nodes.

Any idea what role DNS plays in node communication after initial node registration is complete?

Thanks

Thomas

[Timothy Abbott · Accepted solution]

Hi,

DNS resolution is important in any deployment.  As ISE learns about new devices, users, etc.  it has to replicate that information as well as keep configuration information synchronized through out the entire deployment.

Regards,

-Tim

[tlenzenh]

Thanks Tim,

I understand DNS is important but my particular question is to understand if or how DNS is used for inter-node communication after the initial node registration between primary PAN and all other nodes/personas is complete. Do the ISE nodes perform a DNS lookup of an adjoining node every time they communicate with that node?

Thanks

Thomas

[Jason Kunst]

with any operating system there is a cache of the DNS entry that only last so long, once it times out it needs to look it up again, this is a safeguard in case the ip address of the name has changed in your DNS, perhaps the node had to move to a new subnet for where it got another ip but the name would still stay the same

[tlenzenh]

Thanks Jason!

Thomas Lenzenhofer

Security Network Consulting Engineer

Cisco Security Solutions

Cisco APJC/Australia

[vibobrov]

I ran into it first hand at a customer. They had a wrong primary DNS server, but the correct secondary DNS server. Linux isn't that good at "remembering" that the primary server is down. It would always try to resolve against the primary DNS server first. It also appeared that the resolver in linux doesn't really cache names like Windows does. I tried to always live-resolve all names.

That short name resolution delay introduced significant delays in replication. Luckily for us, we caught it before the system was put into production.

Thanks

[Peter Koltl]

My additional questions:

If the customer is concerned about potential DNS disturbances, should we recommend adding static ip host commands on the ISE nodes for the other node FQDNs to provide continuous service even at DNS failures?

What is the default DNS caching time used by ISE and can it be tuned?

Which one is the Cisco-recommended setup for the most robust customer requirements : dynamic resolving with DNS or static resolving of ISE node FQDNs by ip host entries?