The following terms are
commonly used when discussing Cisco ISE deployment scenarios:
Service: A service is a specific feature that a persona provides such as network access, profiler, posture, security group
access, monitoring and troubleshooting, and so on.
Node: A node is an individual instance that runs the Cisco ISE software. Cisco ISE is available as an appliance and also as
a software that can be run on VMware. Each instance (appliance or VMware) that runs the Cisco ISE software is called a node.
Persona: The persona of a node determines the services provided by the node. A Cisco ISE node can assume any of the following
personas: Administration, Policy Service, Monitoring, and pxGrid. The menu options that are available through the Admin portal are dependent on the role and personas that a Cisco ISE node
assumes.
Deployment Model: Determines if your deployment is distributed, standalone, or high availability in standalone, which is a
basic two-node deployment.
Personas in Distributed Cisco ISE Deployments
A Cisco ISE node can assume the Administration, Policy Service, or Monitoring personas.
A Cisco ISE node can provide various services based on the persona that it assumes. Each node in a deployment can assume the
Administration, Policy Service, and Monitoring personas. In a distributed deployment, you can have the following combination
of nodes in your network:
Primary Policy Administration node (primary PAN) and secondary Policy Administration node (secondary PAN) for high availability
Primary Monitoring node (primary MnT node) and secondary Monitoring node (secondary MnT node) for high availability
A pair of health check nodes or a single health check node for the primary PAN automatic failover
One or more Policy Service nodes (PSNs) for the session failover
Environment download is successful, with only the up and running Cisco ISE node present in the result.
Cisco ISE Distributed Deployment
A deployment that has more than one Cisco ISE node is called a distributed deployment. To support failover and to improve
performance, you can set up your deployment with multiple Cisco ISE nodes in a distributed fashion. In a Cisco ISE distributed
deployment, the administration and monitoring activities are centralized, and processing is distributed across the PSNs. Depending
on your performance needs, you can scale your deployment. Each Cisco ISE node in a deployment can assume any of the following
personas: Administration, Policy service, and Monitoring.
Cisco ISE Deployment Setup
After you install Cisco ISE on all your nodes, as described in the Cisco Identity Services Engine Hardware Installation Guide, the nodes come up in a standalone state. You must then define one node as your primary PAN. While defining your primary
PAN, you must enable the administration and monitoring personas on that node. You can optionally enable the policy service
persona on the primary PAN. After you complete the task of defining personas on the primary PAN, you can then register other
secondary nodes to the primary PAN and define personas for the secondary nodes.
All Cisco ISE system and functionality-related configurations should be done only on the primary PAN. The configuration changes
that you perform on the primary PAN are replicated to all the secondary nodes in your deployment.
There must be at least one MnT in a distributed deployment. At the time of configuring your primary PAN, you must enable the
Monitoring persona. After you register an MnT node in your deployment, you can edit the primary PAN and disable the Monitoring
persona, if required.
Data Replication from Primary to Secondary ISE Nodes
When you register a Cisco ISE node as a secondary node, Cisco ISE immediately creates a data replication channel from the
primary to the secondary node and begins the process of replication. Replication is the process of sharing Cisco ISE configuration
data from the primary to the secondary nodes. Replication ensures consistency among the configuration data available in all
the Cisco ISE nodes that are part of your deployment.
A full replication typically occurs when you first register a Cisco ISE node as a secondary node. Incremental replication
occurs after a full replication and ensures that any new changes such as additions, modifications, or deletions to the configuration
data in the PAN are reflected in the secondary nodes. The process of replication ensures that all Cisco ISE nodes in a deployment
are in sync. You can view the status of replication in the Node Status column in the Deployment window of the Cisco ISE Admin portal. When you register a Cisco ISE node as a secondary node or perform a manual synchronization
with the PAN, the node status shows an orange icon indicating that the requested action is in progress. Once the synchronization
is complete, the node status turns green indicating that the secondary node is synchronized with the PAN.
Cisco ISE Node Deregistration
To remove a node from a deployment, you must deregister it. When you deregister a secondary node from the primary PAN, the
status of the deregistered node changes to standalone and the connection between the primary and the secondary node is lost.
Replication updates are no longer sent to the deregistered standalone node.
When a PSN is deregistered, the endpoint data is lost. If you want the PSN to retain the endpoint data after it becomes a
standalone node, you can do one of the following:
Obtain a backup from the primary PAN and when the PSN becomes a standalone node, restore this data backup on it.
Change the persona of the PSN to administration (secondary PAN), synchronize the data from the Deployment window of the Admin portal, and then deregister the node. This node will now have all the data. You can then add a secondary
PAN to the existing deployment.
Note
You cannot deregister a primary PAN.
Guidelines for Setting Up a Distributed Deployment
Read the following statements
carefully before you set up Cisco ISE in a distributed environment.
Choose a node type for the Cisco ISE server. You must choose a Cisco ISE node for administration, policy service, and monitoring
capabilities.
Choose the same Network Time
Protocol (NTP) server for all the nodes. To avoid timezone issues among the
nodes, you must provide the same NTP server name during the setup of each node.
This setting ensures that the reports and logs from the various nodes in your
deployment are always synchronized with timestamps.
Configure the Cisco ISE administrator password when you install Cisco ISE. The previous Cisco ISE administrator default login
credentials (admin/cisco) are no longer valid. Use the username and password that was created during the initial setup or
the current password if it was changed later.
Configure the Domain Name System (DNS) server. Enter the IP addresses and fully qualified domain names (FQDNs) of all the
Cisco ISE nodes that are part of your distributed deployment in the DNS server. Otherwise, the node registration fails.
Configure the forward and the reverse DNS lookup for all the Cisco ISE nodes in your distributed deployment in the DNS server.
Otherwise, you may run into deployment related issues when registering and restarting Cisco ISE nodes. Performance might be
degraded if reverse DNS lookup is not configured for all the nodes.
(Optional) Deregister a secondary Cisco ISE node from the primary PAN to uninstall Cisco ISE from it.
Back up the primary MnT, and restore the data to the new secondary MnT. This ensures that the history of the primary MnT is
in sync with the new MnT as the new changes are replicated.
Ensure that the primary PAN and the standalone node that you are about to register as a secondary node are running the same
version of Cisco ISE.
While adding a new node to the deployment, make sure that the issuer certificate chain of wildcard certificates is part of
the trusted certificates of the new node. When the new node is added to the deployment, the wildcard certificates are then
replicated to the new node.
When configuring your Cisco ISE deployment to support Cisco TrustSec, or when Cisco ISE is integrated with Cisco DNA Center,
do not configure a PSN as SXP-only. SXP is an interface between Cisco TrustSec and non- Cisco TrustSec devices. SXP does not
communicate with the Cisco TrustSec enabled network devices.
Menu Options Available on Primary and Secondary Nodes
The menu options available in Cisco ISE nodes that are part of a distributed deployment depend on the personas that are enabled
on them. You must perform all administration and monitoring activities through the primary PAN. For other tasks, you must
use the secondary nodes. Therefore, the user interface of the secondary nodes provides limited menu options based on the persona
that is enabled on them.
If a node assumes more than one persona, for example, the Policy Service persona, and a Monitoring persona with a primary
role, then the menu options listed for the PSNs and the primary MnT is available on that node.
The following table lists the menu options that is available on Cisco ISE nodes that assume different personas.
Table 1. Cisco ISE Nodes and Available
Menu Options
Cisco ISE Node
Available Menu Options
All Nodes
View and configure the system time and the NTP server settings
Install the server certificate and manage certificate signing request. You can perform server certificate operations, for
all the nodes in the deployment, via the primary PAN that centrally manages all server certificates
Note
The private keys are not stored in the local database and are not copied from the relevant node. The private keys are stored
in the local file system.
Primary Policy Administration node (primary PAN)
All menus and sub-menus
Primary Monitoring node (primary MnT node)
Provides access to monitoring data
Note
The Operations menu can be viewed only from the primary PAN. The Operations menu does not appear in the monitoring nodes in Cisco ISE 2.1 and later.
PSNs (Policy Service nodes)
Options to join, leave, and test the Active Directory connection are available. Each PSN must be separately joined to the
Active Directory domain. You must first define the domain information and join the PAN to the Active Directory domain. Then,
join the other PSNs to the Active Directory domain individually.
Option to promote the secondary PAN to the primary PAN
Note
After you have registered the secondary nodes to the primary PAN, while logging in to the Admin portal of any of the secondary
nodes, you must use the login credentials of the primary PAN.
Configure a Cisco ISE Node
After you install a Cisco ISE node, all the default services provided by the Administration, Policy Service, and Monitoring
personas run on it. This node is in a standalone state. You must log in to the Admin portal of the Cisco ISE node to configure
it. You cannot edit the personas or services of a standalone Cisco ISE node. You can, however, edit the personas and services
of the primary and secondary Cisco ISE nodes. You must first configure a primary ISE node and then register secondary ISE
nodes to the primary ISE node.
If you are logging in to the
node for the first time, you must change the default administrator password and
install a valid license.
It is recommended not to change the host name and the domain name configured on Cisco ISE in production. If required, then
reimage the appliance, make changes, and configure the details during the initial deployment.
Check the check box next to
the Cisco ISE node that you want to configure, and click
Edit.
Step 3
Enter the values as required
and click
Save.
Configure a primary Policy Administration Node (PAN)
To set up a distributed deployment, you must first configure a Cisco ISE node as your primary PAN.
Procedure
Step 1
Choose Administration > System > Deployment.
The Register button will be disabled initially. To enable this button, you must configure a Primary PAN.
Step 2
Check the check box next to
the current node, and click
Edit.
Step 3
Click Make Primary to configure your primary PAN.
Step 4
Click
Save to save the
node configuration.
What to do next
Add secondary
nodes to your deployment.
Enable the
profiler service and configure the probes, if required.
Install Trusted
Certificates for Cisco ISE Inter-node Communication
When you set up the deployment, before you register a secondary node, you must populate the PAN's CTL with appropriate CA
certificates that are used to validate the Admin certificate of the secondary node. The procedure to populate the CTL of the
PAN is different for different scenarios:
If the secondary node is using a CA-signed certificate to communicate with the Cisco ISE administration portal, you must import
the CA-signed certificate of the secondary node, the relevant intermediate certificates (if any), and the root CA certificate
(of the CA that signed the secondary node's certificate) into the CTL of the PAN.
If the secondary node is using a self-signed certificate to communicate with the Cisco ISE administration portal, you can
import the self-signed certificate of the secondary node into the CTL of the PAN.
Note
If you change the Admin certificate on a registered secondary node, you must obtain appropriate CA certificates that can be
used to validate the secondary node’s Admin certificate and import it into the CTL of the PAN.
If you use self-signed certificates to secure communication between a client and PSN in a deployment, when BYOD users move
from one location to another, EAP-TLS user authentication fails. For such authentication requests that have to be serviced
between a few PSNs, you must secure communication between the client and the PSN with an externally-signed CA certificate
or use wildcard certificates signed by an external CA.
Ensure that the certificate issued by the external CA has basic constraints defined and the CA flag is set to true. To install CA-signed certificates for inter-node communication:
You can register Cisco ISE nodes to the primary PAN to form a multi-node deployment. Nodes in a deployment other than the
primary PAN are referred to as secondary nodes. While registering a node, you can select the personas and services that must
be enabled on the node. Registered nodes can be managed from the primary PAN (for example, managing the node personas, services,
certificates, licenses, applying patches, and so on).
When a node is registered, the primary PAN pushes the configuration data to the secondary node and the application server
on the secondary node restarts. After the complete data, further configuration changes done on the primary PAN are replicated
to the secondary node. The time taken for the changes to be replicated on the secondary node depends on various factors, such
as the network latency, load on the system, and so on.
Before you begin
Ensure that the primary PAN and the node being registered are DNS resolvable to each other. If the node being registered
uses an untrusted self-signed certificate, you are prompted with a certificate warning with the details of the certificate.
If you accept the certificate, it is added to the trusted certificate store of the primary PAN to enable TLS communication
with the node.
If the node uses a certificate that is not self-signed (for example, signed by an external CA), you must manually import the
relevant certificate chain of that node to the trusted certificate store of the primary PAN. When you import the secondary
node's certificate in to the trusted certificate store, check the Trust for Authentication within ISE check box in the Trusted Certificates window, for the PAN to validate the secondary node's certificate.
While registering a node with session services enabled (such as Network Access, Guest, Posture, and so on), you can add it
to a node group. See section Create a Policy Service Node Group for more details.
Procedure
Step 1
Log in to the primary PAN.
Step 2
Choose Administration > System > Deployment.
Step 3
Click Register to initiate registration of a secondary node.
Step 4
Enter the DNS-resolvable fully qualified domain name (FQDN) of the standalone node that you are going to register (in the
format hostname.domain-name, for example, abc.xyz.com). The FQDN of the Primary PAN and the node being registered must be
resolvable from each other.
Step 5
Enter the UI-based administrator credentials for the secondary node in the Username and Password fields.
Step 6
Click Next.
The primary PAN tries to establish TLS communication (for the first time) with the node being registered.
If the node uses a certificate that is trusted, you can proceed to step 7.
If the node uses a self-signed certificate that is not trusted, a certificate warning message is displayed. The certificate
warning message displays details about the certificate (such as, Issued-to, Issued-by, Serial number, and so on), which can
be verified against the actual certificate on the node. You can select the Import Certificate and Proceed option to trust this certificate and proceed with registration. Cisco ISE imports the default self-signed certificate of
that node to the trusted certificate store of the primary PAN. If you do not want to use the default self-signed certificate,
click Cancel Registration and manually import the relevant certificate chain of that node to the trusted certificate store of the primary PAN. When
you import the secondary node's certificate in to the trusted certificate store, check the Trust for Authentication within ISE check box for the PAN to validate the secondary node's certificate.
If the node uses a CA signed certificate, an error message is displayed that the registration cannot proceed until certificate
trust is set up.
Step 7
Select the personas and services to be enabled on the node, and then click Save.
When a node is registered, an alarm (which confirms that a node has been added to the deployment) is generated on the primary
PAN. You can view this alarm in the Alarms dashlet in the Cisco ISE GUI Dashboard. After the registered node is synchronized and restarted, you can log in to the secondary node GUI using the same credentials
used on the primary PAN.
What to do next
For
time-sensitive tasks such as guest user access and authorization, logging, and
so on, ensure that the system time on your nodes is synchronized.
If you registered a secondary PAN, and are using the internal Cisco ISE CA service, you must back up the Cisco ISE CA certificates
and keys from the primary PAN and restore them on the secondary PAN.
A Cisco ISE node with the Administration persona allows you to perform all administrative operations on Cisco ISE. It handles
all system-related configurations that are related to functionality such as authentication, authorization, auditing, and so
on. In a distributed environment, you can have a maximum of two nodes running the Administration persona. The Administration
persona can take on any one of the following roles: Standalone, Primary, or Secondary.
High Availability for the Administrative Node
In a high availability configuration, the primary Policy Administration node (PAN) is in the active state. The secondary PAN
is in the standby state, which means it receives all configuration updates from the primary PAN, but is not active in the
Cisco ISE network.
Cisco ISE supports manual and automatic failover. With automatic failover, when the primary PAN goes down, an automatic promotion
of the secondary PAN is initiated. Automatic failover requires a non-administration secondary node, which is called a health
check node. The health check node checks the health of the primary PAN. If the health detects that the primary PAN is down
or unreachable, the health check node initiates the promotion of the secondary PAN to take over the primary role.
To deploy the automatic failover feature, you must have at least three nodes, where two of the nodes assume the Administration
persona, and one node acts as the health check node. A health check node is a non-administration node and can be a PSN, MnT,
pxGrid node, or a combination of these. If the primary and secondary PANs are in different data centers, you must have a health
check node for each PAN.
The following table lists the features that are affected when the primary PAN goes down and the secondary PAN is yet to take
over.
Features
Available when primary PAN is down? (Yes/No)
Existing
internal user RADIUS authentication
Yes
Existing or new AD user RADIUS authentication
Yes
Existing
endpoint with no profile change
Yes
Existing
endpoint with profile change
No
New
endpoint learned through profiling.
No
Existing guest: Local Web Authentication (LWA)
Yes
Existing guest: Central Web Authentication (CWA)
Yes
(apart from flows enabled for device registration, such as Hotspot, BYOD, and
CWA with automatic device registration)
Guest
change password
No
Guest: AUP
No
Guest: Max Failed Login Enforcement
No
New
Guest (Sponsored or Self-registered)
No
Posture
Yes
BYOD
with Internal CA
No
Existing
Registered Devices
Yes
MDM on-boarding
No
pxGrid
Service
No
Log in to GUI of secondary nodes
Yes (The login process is delayed as a blocking call to the PAN is attempted to update the last login details. The login proceeds
once above call times-out)
To support certificate provisioning with the internal certificate authority, you must to import the root certificate of the
original primary PAN and its key into the new primary node, after promotion. Certificate provisioning does not work after
automatic failover for the PSN nodes that are added after the promotion of the secondary node to primary PAN.
High-Availability
Health Check Nodes
The health check node for Primary PAN is called the active health check node. The health check node for Secondary PAN is called
the passive health check node. The active health check node is responsible for checking status of Primary PAN, and managing
the automatic failover of Administration nodes. We recommended using two non-administration ISE nodes as health check nodes,
one for the Primary and one for the Secondary PAN. IF you use only one health check node, and that node goes down, automatic
failover will not happen.
When both PANs are in the same data center, you can use a single non-administration ISE node as the health check node for
both the Primary PAN and the Secondary PAN. When a single health check node checks the health of both the Primary PAN and
the Secondary PAN, it assumes both the active and passive roles.
A health check node is a non-administration node, which means it can be a Policy Service, Monitoring, or pxGrid node, or a
combination of those. We recommend that you designate PSN nodes in the same data center as the Administration nodes as health
check nodes. However, in a small or a centralized deployment, where the two Administration nodes are not in the same location
(LAN or data center), any node (PSN/pxGrid/MnT) not having the Administration persona can be used as health check node.
If you chose not to enable automatic failover, and rely on manually promoting the secondary node when the primary PAN fails,
then you do not need any check nodes.
Health Check Node for the Secondary PAN
The health check node for the Secondary PAN is a passive monitor. It does not take any action until the Secondary PAN has
been promoted as the Primary PAN. When the Secondary PAN takes over the primary role, its associated health check node takes
the active role for managing automatic failover of Administration nodes. The health check node of the previous Primary PAN
becomes the health check node for the Secondary PAN now and would monitor it passively.
Disabling and Restarting Health Check
When a node is removed from the health check role or auto-failover configuration is disabled, the health check service is
stopped on that node. When the auto-failover configuration is enabled on the designated high-availability health check node,
the node starts checking health of Administration nodes again. Designating or removing the high-availability health check
role on a node does not involve any application restart on that node; only the health check activities are started or stopped.
If the high-availability health check node is restarted, it ignores the previous downtimes of Primary PAN and starts checking
the health status afresh.
Health Check Nodes
The active health check node checks the health status of the primary PAN at a configured polling interval. It sends a request
to the primary PAN, and if the response that it receives matches the configuration, then the health check node considers the
primary PAN to be in good health. Otherwise, the health check node considers the primary PAN to be in bad health. If the health
of the primary PAN is bad continuously for more than the configured failover period, then the health check node initiates
failover to the secondary PAN.
If at any time during the health check, health status is found to be good after being reported as bad previously within the
failover period, then the health check node marks the primary PAN status as good, and resets the health check cycle.
Response from health check of the primary PAN is validated against the configuration values available on its health check
node. If the response does not match it would raise an alarm. However, a promotion request will be made to the secondary PAN.
Changing Health Nodes
You can change the Cisco ISE node that you are using for a health check, but there are some things to consider.
For example, assume that the health check node (H1) goes out-of-sync and some other node (H2) is made the health check node
of the primary PAN. In such a case, once the primary PAN goes down, there is no way for H1 to know that there is another node
(H2) checking the same primary PAN. Later, if H2 goes down or out of network, an actual failover is required. The secondary
PAN, however, retains the right to reject the promotion request. So, once the secondary PAN has been promoted to the primary
role, a promotion request from H2 is rejected with an error. Even if a health check node for the primary PAN is out of sync,
it continues to check the health of the primary PAN.
Automatic Failover to the Secondary PAN
You can configure Cisco ISE to automatically the promote the secondary PAN when the primary PAN becomes unavailable. The configuration
is done on the primary Policy Administration node (Primary PAN) in the Deployment window. The navigation path for this window is Administration > System > Deployment. The failover period is defined as the number of times configured in Number of Failure Polls Before Failover times the number of seconds configured in Polling Interval. With the default configuration, that time is 10 minutes. Promotion of the secondary PAN to primary takes another 10 minutes.
So by default, the total time from primary PAN failure to secondary PAN working is 20 minutes.
When the secondary PAN receives the failover call, it carries out the following validations before proceeding with the actual
failover:
The primary PAN isn’t available in the network.
The failover request came from a valid health check node.
The failover request is for this PAN.
If all the validations pass, the secondary PAN promotes itself to the primary role.
The following are some sample (but not limited to) scenarios where automatic failover of the secondary PAN would be attempted.
Health of primary PAN is consistently not good for the Number of failure polls before failover value during the polling period.
Cisco ISE services on the primary PAN are manually stopped, and remain stopped for the failover period.
The primary PAN is shut down using soft halt or reboot option, and remains shut down for the configured failover period.
The primary PAN goes down abruptly (power down), and remains down for the failover period.
The network interface of primary PAN is down (network port shut or network service down), or it’s not reachable by the health
check node for any other reason, and remains down for the configured failover period.
Health Check Node Restarts
Upon restart, the high availability health check node ignores the previous downtimes of primary PAN and checks the health
status afresh.
Bring Your Own Device In Case Of Automatic Failover To Secondary PAN
When the primary PAN is down, authentication isn’t interrupted for the endpoints that already have certificates issued by
the primary PAN root CA chain. This is because all the nodes in the deployment have the entire certificate chain for trust
and validation purposes.
However, until the secondary PAN is promoted to primary, new BYOD devices won’t be onboarded. BYOD onboarding requires an
active primary PAN.
Once the original primary PAN is brought back up or the secondary PAN is promoted, new BYOD endpoints will be onboarded without
any issues.
If the primary PAN that failed can’t be re-joined as the primary PAN, regenerate the root CA certificate on the newly promoted
primary PAN (the original secondary PAN).
For existing certificate chains, triggering a new root CA certificate, results in the automatic generation of the subordinate
CA certificates. Even when new subordinate certificates are generated, endpoints certificates that were generated by the previous
chain continue to be valid.
Sample Scenarios
when Automatic Failover is Avoided
The following are
some sample scenarios that depict cases where automatic failover by the health
check node would be avoided or promotion request to the secondary node would be
rejected.
The node receiving the promotion request is not the secondary node.
The promotion request received by the secondary PAN does not have the correct primary PAN information.
The promotion request is received from an incorrect health check node.
The promotion request is received but the primary PAN is up and in good health.
The node receiving the promotion request goes out-of-sync.
Functionalities Affected by the PAN Automatic Failover Feature
The following table lists the functionalities that are blocked or require additional configuration changes if the PAN automatic
failover configuration is enabled in your deployment.
Functionality
Affect
Details
Operations that are
Blocked
Upgrade
Upgrade
via the CLI is blocked.
The PAN automatic failover feature will be available for configuration after you upgrade from a previous version of Cisco
ISE to release 1.4. By default, this feature is disabled.
To deploy the auto-failover feature, you must have at least three nodes, where two of the nodes assume the Administration
persona, and one node acts as the health check node. A health check node is a non-administration node and can be a PSN, MnT,
pxGrid node, or a combination of these. If the PANs are in different data centers, you must have a health check node for each
PAN.
Restore of
Backup
Restore
via the CLI and user interface will be blocked.
If the PAN automatic failover configuration was enabled prior to restore, you must reconfigure it after a successful restore.
Change
Node Persona
Change of
the following node personas via the user interface will be blocked:
Administration persona in both the primary and secondary PANs
Persona of the PAN
Deregistration of health check node after enabling the PAN automatic failover feature
Other CLI
Operations
The
following admin operations via the CLI will be blocked:
Patch
Installation and Roll back
DNS server change
IP
address change of eth1, eth2, and eth3 interfaces
Host
alias change of eth1, eth2, and eth3 interfaces
Timezone change
Other
Administration Portal Operations
The following administrative operations via the user interface will be blocked:
Patch
Installation and Roll back
Change of HTTPS certificate
Change of admin authentication type from password-based authentication to certificate-based authentication and vice versa
Users with
maximum connected devices cannot connect.
Some
session data is stored on the failed PAN, and can't be updated by the PSN.
Operations that Require PAN Automatic Failover to be Disabled
CLI
Operations
The following administrative operations via the CLI will display a warning message if the PAN automatic failover configuration
is enabled. These operations may trigger automatic failover if service or system is not restarted within the failover window.
Hence, while performing the below operations it is recommended to disable the PAN automatic failover configuration:
Manual stopping the Cisco ISE service
Soft reload (reboot) of Cisco ISE using the admin CLI
Configure Primary
PAN for Automatic Failover
Before you begin
To deploy the automatic failover feature, you must have at least three nodes, where two of the nodes assume the Administration
persona, and one node acts as the health check node. A health check node is a non-administration node and can be a PSN, MnT,
pxGrid node, or a combination of these. If the PANs are in different data centers, you must have a health check node for each
PAN.
Procedure
Step 1
Log in to the user interface of the primary PAN.
Step 2
Choose Administration > System > Deployment > PAN Failover.
Step 3
Check the Enable PAN Auto Failover check box, to enable automatic failover of the primary PAN.
You can only promote a secondary PAN to become the Primary PAN. Cisco ISE nodes that assume only the PSN, MnT, pxGrid node,
or a combination of these, cannot be promoted to become the Primary PAN.
Step 4
Select the health check node for primary PAN from the Primary Health Check Node drop-down list containing all the available secondary nodes.
It is recommended to have this node in the same location or data center as the primary PAN.
Step 5
Select the health check node for secondary PAN, from the Secondary Health Check Node drop-down list containing all the available secondary nodes.
It is recommended to have this node in the same location or data center as the secondary PAN.
Step 6
Provide the Polling Interval time after which the PAN status will be checked. The valid range is 30–300 seconds.
Step 7
Provide the count for Number of Failure Polls before Failover
The failover occurs if the status of the PAN is not good for the specified number of failure polls. The valid range is 2–60
counts.
Step 8
Click Save
What to do next
After the promotion of secondary PAN to the primary PAN, do the following:
Manually sync the old primary PAN to bring it back into the deployment.
Manually sync any other secondary node that is outof sync, to bring it back into the deployment.
Manually Promote Secondary PAN To Primary
If the primary PAN fails and you have not configured PAN automatic failover, you must manually promote the secondary PAN to become the new primary PAN.
Before you begin
Ensure that you have a second Cisco ISE node configured with the Administration persona to promote as your primary PAN.
Procedure
Step 1
Log in to the user interface of the secondary PAN.
Step 2
Step 3
In the Edit Node window, click Promote to Primary.
You can only promote a secondary PAN to become the primary PAN. Cisco ISE nodes that assume only the Policy Service or Monitoring
persona, or both, cannot be promoted to become the primary PAN.
Step 4
Click
Save.
What to do next
If the node that was originally the primary PAN, comes back up, it will be demoted automatically and become the secondary
PAN. You must perform a manual synchronization on this node (that was originally the primary PAN) to bring it back into the
deployment.
In the Edit Node window of a secondary node, you cannot modify the personas or services because the options are disabled. You have to log
in to the Admin portal to make changes.
Restoring Service to the Primary PAN
Cisco ISE does not support automatic fallback to original primary PAN. After the automatic failover to the secondary PAN
is initiated, if you bring the original primary PAN back into the network, you should configure it as the secondary PAN.
Policy Service Node
A Policy Service node (PSN) is a Cisco ISE node with the Policy Service persona and provides network access, posture, guest
access, client provisioning, and profiling services.
At least one node in your distributed setup should assume the Policy Service persona. This persona evaluates the policies
and makes all the decisions. Typically, there would be more than one PSN in a distributed deployment.
All PSNs that reside in the same high-speed Local Area Network (LAN) or behind a load balancer can be grouped together to
form a node group. If one of the nodes in a node group fails, the other nodes detect the failure and reset any URL-redirected
sessions.
High Availability in Policy Service Nodes
To detect node failure and to reset all URL-redirected sessions on the failed node, two or more PSNs can be placed in the
same node group. When a node that belongs to a node group fails, another node in the same node group issues a Change of Authorization
(CoA) for all URL-redirected sessions on the failed node.
All the nodes within the same
node group should be configured on the network access device (NAD) as RADIUS
clients and authorized for CoA, because any one of them can issue a CoA request
for the sessions that are established through any node in the node group. If
you are not using a load balancer, the nodes in a node group should be the same
as, or a subset of, the RADIUS servers and clients configured on the NAD. These
nodes would also be configured as RADIUS servers.
While a single NAD can be configured with many Cisco ISE nodes as RADIUS servers and dynamic-authorization clients, it is
not necessary for all the nodes to be in the same node group.
The members of a node group should be connected to each other using
high-speed LAN connection such as Gigabit Ethernet. The node group members need
not be L2 adjacent, but L2 adjacency is highly recommended to ensure sufficient
bandwidth and reachability. See
Create a Policy Service Node Group
section for more details.
Load Balancer To
Distribute Requests Evenly Among PSNs
When you have multiple PSNs in the deployment, you can use a load balancer to distribute the requests evenly. The load balancer
distributes the requests to the functional nodes behind it. Refer to Cisco and F5 Deployment Guide: ISE Load Balancing using BIG-IP for information, and to know about best practices when deploying PSNs behind a load balancer.
Session Failover in Policy Service Nodes
PSNs in a node group share session information. The nodes exchange heartbeat messages to detect node failures. If a node fails,
one of its peers from the node group knows which sessions were on the failed PSN, and issues a CoA to disconnect those sessions.
Most clients automatically reconnect, and establish a new session.
Some clients don’t automatically reconnect. For example, if a client connects via VPN, then that client may not see the CoA.
Clients that are IP Phones, multihost 802.1X ports, or virtual machines may also not see or be able to respond to a CoA. URL-redirected
clients (webauth) also can’t connect automatically. Those clients must manually reconnect.
Timing issues can also prevent reconnection. For example, if the posture state is pending at the time of PSN failover.
Number of Nodes in a Policy Service Node Group
The number of nodes that you
can have in a node group depends on your deployment requirements. Node groups
ensure that node failures are detected and that a peer issues a CoA for
sessions that are authorized, but not yet postured. The size of the node group
does not have to be very large.
If the size of the node group increases, the number of messages and heartbeats that are exchanged between the nodes increases
significantly. As a result, traffic also increases. Having fewer nodes in a node group helps reduce the traffic and at the
same time provides sufficient redundancy to detect PSN failures.
There is no hard limit on the number of PSNs that you can have in a node group cluster.
Monitoring Node
A Cisco ISE node with the Monitoring persona functions as the log collector and stores log messages from the PANs and PSNs
in your network. This persona provides advanced monitoring and troubleshooting tools that you can use to effectively manage
your network and resources. A node with this persona aggregates and correlates the data that it collects to provide you with
meaningful information in the form of reports.
Cisco ISE allows you to have a maximum of two nodes with this persona that can take on primary or secondary roles for high
availability. Both the primary and secondary MnT nodes collect log messages. If the primary MnT goes down, the primary PAN
points to secondary node to gather monitoring data. But the secondary node will not be promoted to primary automatically.
This should be done by manually modifying the Monitoring and Troubleshooting (MnT) role.
At least one node in your
distributed setup should assume the Monitoring persona. We recommend that you
not have the Monitoring and Policy Service personas enabled on the same Cisco
ISE node. We recommend that the node be dedicated solely to monitoring for
optimum performance.
You can access the Monitoring
menu from the PAN
in your deployment.
Manually Modify MnT Role
You can manually modify MnT roles (both from primary to secondary and from secondary to primary) from the primary PAN.
Procedure
Step 1
Log in to the user interface of the primary PAN.
Step 2
Choose Administration > System > Deployment.
Step 3
From the list of nodes, scheck the check box next to the MnT node for which you want to change the role.
Step 4
Click Edit.
Step 5
In the Monitoring section, change the role to Primary or Secondary.
Step 6
Click Save.
Note
You can enable the option if you want to disable all other personas and services enabled on that node. When this option is
enabled, the configuration data replication process is stopped on that node. This helps to improve the performance of the
MnT node. When you disable this option, manual synchronization is triggered.
Automatic Failover in MnT Nodes
MnT nodes do not offer high availablity, but do offer active standby. The PSN copies operational audit data to both the primary
and secondary MnT nodes.
Automatic Failover
Process
When a primary MnT node goes down, the secondary MnT node takes over all monitoring and troubleshooting information.
To manually convert the secondary node to a primary node, see promote the secondary node to a primary role. If the primary node comes back up after the secondary node was promoted, it takes the secondary role. If the secondary node
was not promoted, the primary MnT node resumes the primary role, after it comes back up.
Caution
When the primary node comes back up after a failover, obtain a backup of the secondary and restore the data to update the
primary node.
Guidelines for Setting Up an Active Standby Pair of MnT Nodes
You can specify two MnT nodes on a Cisco ISE network, and configure then to be an active standby pair. We recommend that you
back up the primary MnT node, and restore the data to the new secondary MnT node. This ensures that the history of the primary
MnT node is synchronized with the new secondary node as the primary replicates new data. The following rules apply to an active
standby pair:
All changes are logged to the primary MnT node. The secondary node is read-only.
Changes made to the primary node are automatically replicated on the secondary node
Both the primary and secondary nodes are listed as log collectors, to which all other nodes send logs.
The Cisco ISE dashboard is the main entry point for monitoring and troubleshooting. Monitoring information is displayed on
the dashboard from the PAN
. If the primary node goes down, monitoring information is available on the secondary node.
Backing up and purging MnT data is not part of a standard Cisco ISE node backup process. You must configure repositories for
backup and data purging on both the primary and secondary MnT nodes, and use the same repositories for each.
MnT Node Failover Scenarios
The following scenarios apply to the active-standby or single node configurations corresponding to the MnT nodes:
In an active-standby configuration of the MnT nodes, the primary PAN always points to the primary MnT node to collect the
monitoring data. After the primary MnT node fails, the PAN points to the standby MnT node. The failover from the primary node
to the secondary node happens after it is down for more than five minutes.
However, after the primary node fails, the secondary node does not become the primary node. In case the primary node comes
up, the PAN starts collecting the monitoring data again from the resumed primary node.
If the primary MnT node is down, and you want to promote the standby MnT node to active status, you can do so by manually modifying MnT role or by de-registering the existing primary MnT node. When you de-register the existing primary MnT node, the standby node
becomes the primary MnT node, and the PAN automatically points to the newly promoted primary node.
In an active-standby pair, if you de-register the secondary MnT node or if the secondary MnT node goes down, the existing
primary MnT node remains current the primary node.
If there is only one MnT node in the Cisco ISE deployment, then that node acts as the primary MnT node, and provides monitoring
data to the PAN. However, when you register a new MnT node, and make it the primary node in the deployment, the existing primary
MnT node automatically becomes the standby node. The PAN points to the newly registered primary MnT node to collect monitoring
data.
Cisco pxGrid Node
You can use Cisco pxGrid to share the context-sensitive information from Cisco ISE session directory with other network systems
such as Cisco ISE ecosystem partner systems and other Cisco platforms. The pxGrid framework can also be used to exchange policy
and configuration data between nodes like sharing tags and policy objects between Cisco ISE and third-party vendors, and for
other information exchanges. Cisco pxGrid also allows third-party systems to invoke adaptive network control actions (EPS) to quarantine users or devices or both in response to a network or security event. The Cisco TrustSec information like tag
definition, value, and description can be passed from Cisco ISE via Cisco TrustSec topic to other networks. The endpoint profiles
with Fully Qualified Names (FQNs) can be passed from Cisco ISE to other networks through an endpoint profile meta topic. Cisco
pxGrid also supports bulk download of tags and endpoint profiles.
You can publish and subscribe to SXP bindings (IP-SGT mappings) through Cisco pxGrid. For more information about SXP bindings,
see Security Group Tag Exchange Protocol.
In a high-availability configuration, Cisco pxGrid servers replicate information between the nodes through the PAN. When the
PAN goes down, the Cisco pxGrid server stops handling the client registration and subscription. You need to manually promote
the PAN for the Cisco pxGrid server to become active. You can check the Cisco pxGrid services window (Administration > pxGrid Services) to verify whether a Cisco pxGrid node is
currently in active or standby state.
On the active Cisco node that has the pxGrid persona, these processes show as Running. On the standby Cisco pxGrid node, they show as Standby. If the active pxGrid node goes down, the standby pxGrid node detects this, and starts the four pxGrid processes. Within
a few minutes, these processes show as Running, and the standby node becomes the active node. You can verify whether the Cisco pxGrid service is in standby on that node
by running the CLI command show logging application pxgrid/pxgrid.state.
For XMPP (Extensible Messaging and Presence Protocol) clients, Cisco pxGrid nodes work in active-standby high availability
mode which means that the Cisco pxGrid Service is in Running state on the active node and in Disabled state on the standby
node.
After the automatic failover to the secondary Cisco pxGrid node is initiated, if the original primary Cisco pxGrid node is
brought back into the network, the original primary Cisco pxGrid node will continue to have the secondary role and will not
be promoted back to the primary role unless the current primary node goes down.
Note
At times, the original primary Cisco pxGrid node might be automatically promoted back to the primary role.
In a high availability deployment, when the primary Cisco pxGrid node goes down, it might take around three to five minutes
to switchover to the secondary Cisco pxGrid node. It is recommended that the client waits for the switchover to complete,
before clearing the cache data just in case the primary Cisco pxGrid node fails.
The following logs are available for the Cisco pxGrid node:
pxgrid.log: State change notifications.
pxgrid-cm.log: Updates on publisher or subscriber or both and data exchange activity between the client and the server.
pxgrid-controller.log: Displays the details of client capabilities, groups, and client authorization.
pxgrid-jabberd.log: All logs related to system state and authentication.
pxgrid-pubsub.log: Information related to publisher and subscriber events.
Note
If Cisco pxGrid service is disabled on a node, port 5222 is down, but port 8910 (used by web clients) is functional and continues
to respond to the requests.
Note
You can enable Cisco pxGrid with Base license, but you must have a Plus license to enable the Cisco pxGrid persona. In addition, certain extended Cisco pxGrid services may be available in your Base installation if you have recently installed
an upgrade license for .
Note
Cisco pxGrid should be defined in order to work with the Passive ID Work Center. For more information,
see PassiveID Work Center.
Cisco pxGrid Client and Capability Management
Clients connecting to Cisco ISE must register and receive account approval before using Cisco pxGrid services. Cisco pxGrid
clients use the Cisco pxGrid client library available in the Cisco pxGrid SDK to become the clients. Cisco ISE supports both
auto and manual approvals. A client can log in to Cisco pxGrid using a unique name and certificate-based mutual authentication.
Similar to the AAA setting on a switch, clients can connect to either a configured Cisco pxGrid server hostname or an IP address.
Cisco pxGrid capabilities are information topics or channels on Cisco pxGrid for clients to publish and subscribe. In Cisco
ISE, only capabilities such as Identity, Adaptive Network Control (ANC) , and Security Group Access (SGA) are supported. When
a client creates a new capability, it appears in the View by Capabilities window. The navigation path for this window is Administration > pxGrid Services > View by Capabilities. You can enable or disable capabilities individually. Capability information is available from the publisher through publish,
directed query, or bulk download query.
When a web client publisher uses REST APIs or WebSocket protocols, the topics added in the web client publisher are not immediately
listed in the Administration > pxGrid Services > Web Clients tab in Cisco ISE. Such a web client topic appears in the Web Clients tab only after its first instance of publishing.
Note
Users that are assigned to Endpoint Protection service (EPS) user group can perform actions in session group, because Cisco
pxGrid session group is part of EPS group. If a user is assigned to EPS group, the user will be able to subscribe to the session
group on the Cisco pxGrid client.
Enable pxGrid Service
Before you begin
Enable the
pxGrid persona on at least one node to view the requests from the Cisco pxGrid
clients.
Procedure
Step 1
Choose Administration > pxGrid Services.
Step 2
Check the
checkbox next to the client and click
Approve.
Step 3
Click
Refresh to view the latest status.
Step 4
Select the capability you want to enable and click Enable.
Step 5
Click Refresh to view the latest status.
Enable pxGrid Capabilities
Before you begin
Enable the pxGrid persona on at least one node to view the requests from the Cisco pxGrid clients.
Enable a pxGrid client.
Procedure
Step 1
Choose Administration > pxGrid Services.
Step 2
Click
View by Capabilities at the top-right.
Step 3
Select the capability you want to enable and click
Enable.
Step 4
Click
Refresh to view the latest status.
Deploy Cisco pxGrid Node
You can enable Cisco pxGrid
persona both on a standalone node and distributed deployment node.
Before you begin
You can enable pxGrid with Base license, but you must have a Plus license to enable pxGrid persona. In addition, certain extended pxGrid services may be available in your Base installation if you have recently installed an
upgrade license .
All nodes use the CA certificate for Cisco pxGrid service usage. If you used the default certificate for Cisco pxGrid service
before upgrade, upgrade replaces that certificate with the internal CA certificate.
You must have port 8910 open for Websockets (pxGrid 2.0) and port 5222 open for XMPP (pxGrid V1.0). If the Cisco pxGrid service
is disabled on a node, port 5222 goes down, but port 8910 remains functional, and continues to respond to the requests.
Procedure
Step 1
Choose Administration > System > Deployment.
Step 2
In the Deployment Nodes window, check the check box next to the node for which you want to enable the Cisco pxGrid services, and click Edit.
Step 3
Click the General Settings tab and check the pxGrid check box.
Step 4
Click
Save.
When you upgrade from the previous version, the Save option might be disabled. This happens when the browser cache refers to the old files from the previous version of Cisco
ISE. Clear the browser cache to enable the Save option.
Cisco pxGrid Live
Logs
The Live Logs window displays all the pxGrid management events. Event info includes the client and capability names along
with the event type and timestamp.
The navigation path for this window is Administration > pxGrid Services > Live Log. You can also clear the logs and resynchronize or refresh the list.
Configure Cisco pxGrid Settings
Before you begin
To perform the
following task, you must be a Super Admin or System Admin.
Select the
following options based on your requirements:
Automatically approve new certificate-based accounts: Check this check box to automatically approve the connection requests from new Cisco pxGrid clients.
Allow password based account creation: Check this check box to enable username or password based authentication for Cisco pxGrid clients. If this option is enabled,
the Cisco pxGrid clients cannot be automatically approved.
A Cisco pxGrid client can register itself with the Cisco pxGrid controller by sending the username via REST API. The Cisco
pxGrid controller generates a password for the Cisco pxGrid client during client registration. The administrator can approve
or deny the connection request.
Step 3
Click
Save.
Generate Cisco pxGrid Certificate
Before you begin
Some versions of Cisco ISE have a certificate for Cisco pxGrid that uses NetscapeCertType. We recommend that you generate
a new certificate.
To perform the following task, you must be a Super Admin or System Admin.
A Cisco pxGrid certificate must be generated from the primary PAN.
If the Cisco pxGrid certificate uses the subject alternative name (SAN) extension, be sure to include the FQDN of the subject
identity as a DNS name entry.
Create a certificate template with digital signature usage and use that to generate a new Cisco pxGrid certificate.
Select one of the following options from the I want to drop-down list:
Generate a single certificate (without a certificate signing request): You must enter the Common Name (CN) if you select this option.
Generate a single certificate (with a certificate signing request): You must enter the Certificate Signing Request details if you select this option.
Step 3
Common Name (CN): (Required if you choose to Generate a single certificate (without a certificate signing request) option.) Enter the FQDN of the pxGrid client.
Step 4
Certificate Signing Request Details: (Required if you choose to Generate a single certificate (without a certificate signing request) option.) Enter the complete certificate signing request details.
Step 5
Description: (optional) You can enter a description for this certificate.
Step 6
Certificate Template: Click the pxGrig_Certificate_Template link to download the certificate template edit the template based on your requirements.
Step 7
Subject Alternative Name (SAN): You can add multiple SANs. The following options are available:
IP address: Enter the IP address of the Cisco pxGrid client to be associated with the certificate.
FQDN: Enter the fully qualified domain name of the pxGrid client.
Step 8
Select one of the following options from the Certificate Download Format drop-down list:
Certificate in Private Enhanced Electronic Mail (PEM) format, key in PKCS8 PEM format (including certificate chain): The root certificate, the intermediate CA certificates, and the end entity certificate are represented in the PEM format.
PEM formatted certificate are BASE64-encoded ASCII files. Each certificate starts with the "--------BEGIN CERTIFICATE-----"
tag and ends with the "-------END CERTIFICATE----" tag. The end entity’s private key is stored using PKCS* PEM. It starts
with the "-----BEGIN ENCRYPTED PRIVATE KEY----" tag and ends with the "-----END ENCRYPTED PRIVATE KEY----" tag.
PKCS12 format (including certificate chain; one file for both the certificate chain and key): A binary format to store the root CA certificate, the intermediate CA certificate, and the end entity 's certificate and
private key in one encrypted file.
Step 9
Certificate Password: Enter the password for the certificate and confirm the password by entering it again in the next field.
Step 10
Click Create.
The certificate that you created is visible in Cisco ISE in the Issued
Certificates window. The navigation
path for this window is Administration > System > Certificates > Certificate Authority > Issued Certificates. The certificate is also downloaded to your browser's downloads
directory.
Note
From Cisco ISE 2.4 patch 13 onwards, the certificate requirements have become stricter for
the pxGrid service. If you are using the Cisco ISE default self-signed
certificate as the pxGrid certificate, Cisco ISE might reject that certificate
after applying Cisco ISE 2.4 patch 13 or later versions. This is because the
older versions of that certificate have the Netscape Cert
Type extension specified as SSL Server,
which now fails (a client certificate is also required now).
Any client with a non-compliant certificate fails to integrate with Cisco ISE.
Use a certificate issued by the internal CA or generate a new certificate with
proper usage extensions:
The Key Usage extension in the certificate must contain the
Digital Signature and Key
Encipherment fields.
The Extended Key Usage extension in the certificate must contain the
Client Authentication and Server
Authentication fields.
The Netscape Certificate Type extension is not required. If you like
to include that extension, you must add both SSL
Client and SSL Server in the
extension.
If you are using a self-signed certificate, the Basic Constraints CA
field must be set to True and the Key Usage
extension must contain the Key Cert Sign field.
View Nodes in a Deployment
In the Deployment Nodes window, you can view all the Cisco ISE nodes, primary and secondary, that are part of your deployment.
Procedure
Step 1
Log in to the primary Cisco ISE Admin portal.
Step 2
ChooseAdministration > System > Deployment.
Step 3
Click Deployment from the navigation pane on the left.
All the Cisco ISE nodes that are part of your deployment are listed.
Synchronize Primary and Secondary Cisco ISE Nodes
You can make configuration changes to Cisco ISE only through the primary PAN. The configuration changes get replicated to all the secondary nodes. If, for some reason, this
replication does not occur properly, you can manually synchronize the secondary PAN with the primary PAN.
Procedure
Step 1
Log in to the primary PAN.
Step 2
ChooseAdministration > System > Deployment.
Step 3
Check the check box next to the node that you want to synchronize with the primary PAN, and click Syncup to force a full database replication.
Change Node Personas and Services
You can edit the Cisco ISE
node configuration to change the personas and services that run on the node.
Before you begin
When you enable or disable any of the services that run on a PSN or make any changes to a PSN, you will be restarting the
application server processes on which these services run. Expect a delay while these services restart.
Due to this delay in restart of services, automatic failover if enabled in your deployment, might get initiated. To avoid
this, make sure that the automatic failover configuration is turned off.
Procedure
Step 1
Log in to the primary PAN.
Step 2
Choose Administration > System > Deployment.
Step 3
Check the check box next to
the node whose personas or services you want to change, and then click
Edit.
Step 4
Choose the personas and
services that you want.
Step 5
Click
Save.
Step 6
Verify receipt of an alarm on your primary PAN to confirm the persona or service change. If the persona or service change
is not saved successfully, an alarm is not generated.
Effects of Modifying Nodes in Cisco ISE
When you make any of the following changes to a node in a Cisco ISE, that node restarts, which causes a delay:
Register a node (Standalone to Secondary)
Deregister a node (Secondary to Standalone)
Change a primary node to Standalone (if no other nodes are registered with it; Primary to Standalone)
Promote an Administration node (Secondary to Primary)
Change the personas (when you assign or remove the Policy Service or Monitoring persona from a node)
Modify the services in the Policy Service node (enable or disable the session and profiler services)
Restore a backup on the primary and a sync up operation is triggered to replicate data from primary to secondary nodes
Create a Policy Service Node Group
When two or more Policy Service nodes (PSNs) are connected to the same high-speed Local Area Network (LAN), we recommend that
you place them in the same node group. This design optimizes the replication of endpoint profiling data by retaining less
significant attributes local to the group and reducing the information that is replicated to the remote nodes in the network.
Node group members also check on the availability of peer group members. If the group detects that a member has failed, it
attempts to reset and recover all URL-redirected sessions on the failed node.
Note
We recommend that
you make all PSNs in the same local network part of the same node group. PSNs
need not be part of a load-balanced cluster to join the same node group.
However, each local PSN in a load-balanced cluster should typically be part of
the same node group.
Note
The node groups are used for the PSN failover for the sessions on which URL-redirect (posture services, guest services and
MDM) is imposed.
Before you can add PSNs as members to a node group, you must create the node group first. You can create, edit, and delete
PSN groups from the Deployment window of the Admin portal.
Before you begin
Node group members can communicate over TCP/7800.
Procedure
Step 1
ChooseAdministration > System > Deployment.
Step 2
Click the Settings icon from the top of the navigation pane on the left.
Step 3
Click Create Node Group.
Step 4
Enter a unique name for your
node group.
Note
We do not recommend configuring a node group with the name None, as it may cause undesirable issues in node registration.
Step 5
(Optional) Enter a
description for your node group.
Step 6
(Optional) Check the Enable MAR Cache Distribution check box and fill in the other options. Ensure that the MAR is enabled in the Active Directory window before enabling this option.
Step 7
Click
Submit to save
the node group.
After you save the node group, it should appear in the navigation pane on the left. If you do not see the node group in the
left pane, it may be hidden. Click the Expand button on the navigation pane to view the hidden objects.
What to do next
Add a node to a node group. Edit the node by choosing the node group from the Include node in node group drop-down list in the Policy Service area.
Configure MnT Nodes for Automatic Failover
If you have two MnT nodes in a deployment, you can configure a primary-secondary pair for automatic failover to avoid downtime
in the Cisco ISE Monitoring service. A primary-secondary pair ensures that a secondary MnT node automatically provides monitoring
should the primary node fail.
Before you begin
Before you can configure MnT nodes for automatic failover, they must be registered as Cisco ISE nodes.
Configure monitoring roles
and services on both nodes and name them for their primary and secondary roles,
as appropriate.
Configure repositories for backup and data purging on both the primary and secondary MnT nodes. For the backup and purging
features to work properly, use the same repositories for both the nodes. Purging takes place on both the primary and secondary
nodes of a redundant pair. For example, if the primary MnT node uses two repositories for backup and purging, you must specify
the same repositories for the secondary node.
Configure a data repository for a MnT node using the repository command in the system CLI.
Caution
For scheduled backup and purge to work properly on the nodes of a monitoring redundant pair, configure the same repository,
or repositories, on both the primary and secondary nodes using the CLI. The repositories are not automatically synced between
the two nodes.
From the Cisco ISE dashboard, verify that the MnT nodes are ready. The System Summary dashlet shows the MnT nodes with a green check mark to the left when their services are ready.
Procedure
Step 1
Choose Administration > System > Deployment.
Step 2
In the Deployment Nodes window, check the check box next to the MnT node that you want to specify as primary, and click Edit.
Step 3
Click the General Settings tab and choose Primary from the Role drop-down list.
When you choose an MnT node as primary, the other MnT node automatically becomes secondary. In the case of a standalone deployment,
primary and secondary role configuration is disabled.
Step 4
Click Save. Both the primary and secondary nodes restart.
Remove a Node from Deployment
To remove a node from a deployment, you must deregister it. The deregistered node becomes a standalone Cisco ISE node.
It retains the last configuration that it received from the primary PAN and assumes the default personas of a standalone node
that are Administration, Policy Service, and Monitoring. If you deregister an MnT node, this node will no longer be a syslog
target.
When a Primary PSN is deregistered, the endpoint data is lost. If you want the PSN to retain the endpoint data after it becomes
a standalone node, you can do one of the following:
Obtain a backup from the primary PAN and when the PSN becomes a standalone node, restore this data backup on it.
Change the persona of the PSN to Administration (secondary PAN), synchronize the data from the Deployment window of the Admin portal, and then deregister the node. This node will now have all the data. You can then add a secondary
PAN to the existing deployment.
You can view these changes from the Deployment window of the primary PAN. However, expect a delay of five minutes for the changes to take effect and appear in the Deployment window.
Before you begin
Before you remove any secondary node from a deployment, perform a backup of Cisco ISE configuration, which you can then restore later on, if needed.
Procedure
Step 1
ChooseAdministration > System > Deployment.
Step 2
Check the check box next to the secondary node that you want to remove, and then click Deregister.
Step 3
Click
OK.
Step 4
Verify receipt of an alarm on your primary PAN to confirm that the secondary node is deregistered successfully. If the secondary
node fails to deregister from the primary PAN, the alarm is not generated.
Shut Down a Cisco ISE Node
Before you issue the halt command from the Cisco ISE Command Line Interface (CLI), it is advised that you stop the Cisco ISE application service and
ensure that it is not performing any backup, restore, installation, upgrade, or remove operation. If you issue the halt command
while the Cisco ISE is performing any of these operations, you will get one of the following warning messages:
WARNING: A backup or restore is currently in progress! Continue with halt?
WARNING: An install/upgrade/remove is currently in progress! Continue with halt?
If no processes are running when you use the halt command or if you enter Yes in response to the warning message displayed, then you must respond to the following question:
Do you want to save the current configuration?
If you enter Yes to save the existing Cisco ISE configuration, the following message is displayed:
Saved the running configuration to startup successfully.
Note
It is recommended that you stop the application process before rebooting the appliance.
Change the Hostname or IP Address of a Standalone Cisco ISE Node
You can change the hostname, IP address, or domain name of standalone Cisco ISE nodes. You cannot use localhost as the hostname for a node.
Before you begin
If the Cisco ISE node is part of a distributed deployment, you must first remove it from the deployment and ensure that it is a standalone node.
Procedure
Step 1
Change the hostname or IP address of the Cisco ISE node using the hostname, ip address, or ip domain-name command from the Cisco ISE CLI.
Step 2
Reset the Cisco ISE application configuration using the application stop ise command from the Cisco ISE CLI to restart all the services.
Step 3
Register the Cisco ISE node to the primary PAN if it is part of a distributed deployment.
Note
If you are using the hostname while registering the Cisco ISE node, the fully qualified domain name (FQDN) of the standalone node that you are going to register, for example, abc.xyz.com must be DNS-resolvable from the primary PAN. Otherwise, node registration fails. You must enter the IP addresses and FQDNs
of the Cisco ISE nodes that are part of your distributed deployment in the DNS server.
After you register the Cisco ISE node as a secondary node, the primary PAN replicates the change in the IP address, hostname, or domain name to the other
Cisco ISE nodes in your deployment.
Replace the Cisco ISE Appliance Hardware
You should replace the Cisco ISE appliance hardware only if there is an issue with the hardware. For any software issues, you can reimage the appliance and
reinstall the Cisco ISE software.
Procedure
Step 1
Re-image or re-install the Cisco ISE software on the new nodes.
Step 2
Obtain a license with the UDI for the Primary and Secondary PANs and install it on the Primary PAN.
Step 3
Restore the backup on the replaced Primary PAN.
The restore script will try to sync the data on the Secondary PAN, but the Secondary PAN is now a standalone node and the
sync will fail. Data is set to the time the backup was taken on the Primary PAN.
Step 4
Register the new node as a secondary server with the Primary PAN.
Feedback