cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2634
Views
0
Helpful
0
Comments
Bastien Migette
Cisco Employee
Cisco Employee

 

 

Introduction

 

ISE distributed deployment with split domain / dns configuration (workaround CSCua55485)

 

The current ISE version (1.1.1) doesn't allow to have ISE in different domains for a distributed deployment. There's a bug filed (CSCua55485), and it is planned to be fixed in ISE 1.2.

 

The symptoms are:

  • ISE Registration is successful
  • The deployment page shows "NODE-NOT-REACHEABLE"
  • Both ISEs are in different DNS Domain

 

This article will explain in detail what are the conditions and how can we overcome it in order to have a working ISE Deployment in this case.

 

Description - CSCua55485

 

(Cisco ISE distributed deployment does not work with split-domain configuration):

 

 

This fix addresses an issue users can experience while adding nodes to an existing distributed deployment. If the existing Cisco ISE nodes belong to different domains (or even different sub-domains), you may not be able to introduce new nodes to the deployment as designed. The primary cause of this failure involves Cisco ISE using the hostnames from different domains to resolve to the IP address rather than using the proper FQDN during registration.

 

 

Note If all of your Cisco ISE nodes are deployed are in same domain, you can apply this patch using the standard Administrator user interface method. If your Cisco ISE nodes are deployed in different domains, however, you must install this patch on the Cisco ISE nodes via the administrator CLI. Once the patch has been applied on the deployment, you can then apply future patches using the standard Administrator user interface method.

 

http://www.cisco.com/en/US/docs/security/ise/1.1.1/release_notes/ise111_rn.html#wp381747

 

Initial configuration

 

  • I have 2 ISEs
    • Isedns1 in domain wlaaan2003.com => 10.48.39.237
    • Isedns2 in domain wlaaan2008.com => 10.48.39.238
    • I have added DNS Entries in respective DNS domain so each ISE can ping the other but not the FQDN (see captures below):
    • Set the ISE to trust each-other’s certificates.

 

Below is some ping test to validate the setup:

 

isedns1/admin# ping isedns2 => Initially, can’t ping isedns2, as not in same domain.% Error:
Error invoking ping for the provided host isedns1/admin# ping isedns1 =>testing local host just to test dns is workingPING isedns1
(10.48.39.237) 56(84) bytes of data. 64 bytes from 10.48.39.237: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from 10.48.39.237: icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from 10.48.39.237: icmp_seq=3 ttl=64 time=0.041 ms 64 bytes from 10.48.39.237: icmp_seq=4 ttl=64 time=0.036 ms --- isedns1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 0.027/0.034/0.041/0.005 ms isedns1/admin# ping isedns2 % Error: Error invoking ping for the provided host isedns1/admin# ping isedns2.wlaaan2008.com => testing FQDN of remote ISEPING isedns2.wlaaan2008.com
(10.48.39.238) 56(84) bytes of data. 64 bytes from 10.48.39.238: icmp_seq=1 ttl=64 time=0.320 ms 64 bytes from 10.48.39.238: icmp_seq=2 ttl=64 time=0.467 ms 64 bytes from 10.48.39.238: icmp_seq=3 ttl=64 time=0.388 ms 64 bytes from 10.48.39.238: icmp_seq=4 ttl=64 time=0.494 ms --- isedns2.wlaaan2008.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.320/0.417/0.494/0.069 ms

Wlaaan2003 Domain DNS Configuration

 

 

 

1.png

 

 

 

 

Wlaaan2008 Domain DNS Configuration

 

 

2.png

 

Registrating ISE

 

 

3.png

 

 

At this stage, although the registration is completed successfully, the node is marked as unreachable, as we can see in the below capture:

 

 

4.png


Modifying DNS Configuration to make the setup working

 

 

The problem above is due to the fact that the ISEs will create a rule in their firewall to allow the remote ISE to connect to its database.

This process ensure that only authorized devices can connect to the database. Since there's a database password, this is an additional

layer of security.

 

This process however makes a DNS lookup using the hostname of the ISE, and when it is in a different domain, this lookup won't succeed.

 

For reference, we can see the following entry in the ise-psc.log file (in operations > Download logs):

cpm.admin.infra.action.DeploymentEditAction- Ignoring exception during enableFirewalls java.net.UnknownHostException: isedns2

 

That's why we need to Deregister the ISE first so after the DNS is fixed, the firewall script will work.

 

On Wlaaan2003 DNS:

 

 

 

5.png

 

 

on Wlaaan2008 DNS:

 

 

 

6.png

 

 

So now we note that both ISEs are added into the local domain of each other. If you have a distributed deployment with more than 2 ISEs,

you need to make sure that the Admins ISE are able to lookup with every Other ISEs by hostname, and that the Other ISEs are able to

lookup the Admins ISE.

 

If we register the ISE again, we can see that the replication works fine.

 

 

 

7.png

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: