Back
Lesson 3 of 7

ISE High Availability

Objective

In this lesson you will design and validate ISE High Availability (HA) by planning and configuring a primary and secondary PAN, grouping PSNs into node groups, and verifying basic load distribution. High availability for ISE ensures authentication and profiling services remain available during hardware or software failures and supports capacity scaling in production. Real-world scenario: in a global campus with multiple access switches and thousands of endpoints, you deploy a dedicated Primary Administration Node (PAN) and a secondary PAN for failover, and distribute Policy Service Nodes (PSNs) into node groups to balance authentication load and replication traffic.

Topology (quick recap from Lesson 1)

Note: this lesson adds a second PAN and two PSNs for HA/load balancing. Interfaces and IPs used in the exercises are shown below.

ASCII topology (IP addresses shown on every interface)

                      +------------------+
                      |    AD-DC         |
                      |  lab.nhprep.com  |
                      |  IP: 10.1.2.10   |
                      +------------------+
                               |
                               | (VLAN 20 / 10.1.2.0/24)
                               |
              +------------------------------------+
              |            Distribution SW         |
              |            (SW1)                   |
              | Gi0/1 -> 10.1.1.1/24 (ISE mgmt)    |
              | Gi0/2 -> 10.1.2.1/24 (AD vlan)     |
              +------------------------------------+
                 |                   |             |
   (VLAN 10)     |                   |             |
10.1.1.10:443    |                   |             |
 PAN-Primary ---  |                   |             |
                 |                   |             |
10.1.1.11:443    |                   |             |
 PAN-Secondary --+                   |             |
                                     |             |
10.1.1.20:1812                       |             |
 PSN1 -------------------------------+             |
                                     |             |
10.1.1.21:1812                       |             |
 PSN2 --------------------------------+------------+

Device table

DeviceRoleManagement IP
PAN-PrimaryISE Primary PAN10.1.1.10
PAN-SecondaryISE Secondary PAN10.1.1.11
PSN1Policy Service Node10.1.1.20
PSN2Policy Service Node10.1.1.21
SW1Distribution switch/NAD10.1.1.1
AD-DCActive Directory10.1.2.10

Quick Recap

  • You already deployed a single-node ISE in Lesson 1 (PAN + PSN on one appliance).
  • This lesson expands that deployment to HA: adding a secondary PAN and two PSNs, grouping PSNs, and preparing network devices (switches) for robust authentication flows.

Key Concepts — Theory and Practical Effects

  • PAN vs PSN roles

    • PAN (Primary Administration Node) hosts the management and administrative services (config database). Only one PAN is "primary" and handles configuration changes; a secondary PAN is for failover/management separation. In production, keeping PAN functions resilient prevents configuration lockouts.
    • PSNs perform real-time authentication, profiling, and policy enforcement. PSNs must be distributed and grouped for capacity and redundancy.
    • Analogy: Think of the PAN as the “master office” where policies are written, and PSNs as “branch offices” that apply those policies at the door.

  • Node Groups & Load Balancing

    • Node groups let you assign sets of PSNs to handle requests for certain network devices (NADs) or policies. In production, node groups distribute load and localize authentication traffic to preferred PSNs to minimize latency and avoid bottlenecks.
    • ISE will replicate configuration and profiling data between nodes; placing PSNs in groups and tuning replication topology reduces cross-site traffic.

  • Authentication and Policy Flow

    • When a switch forwards an 802.1X or RADIUS MAB request, it targets configured ISE nodes. PSNs reply to authentication requests on RADIUS ports (1812/1813). In production this must be low-latency; high profiling/auth rates require tighter latency budgets (slides noted "Higher Auth/Profiling Rates may require lower latency").

  • Failover behavior

    • PAN failover: only one PAN executes configuration changes. The secondary PAN stands ready to take over or serve read-only data. PSN failover: when a PSN is unavailable, NADs must be able to reach other PSNs in the node group — hence, proper node group and network routing are crucial.

Tip: Use wildcard or multi-SAN certificates for ISE nodes so a single certificate can cover multiple PAN/PSN hostnames and avoid certificate trust issues across nodes.

Step-by-step configuration

Each step below includes commands, intent, why it matters, and verification output.

Step 1: Prepare the distribution switch for IBNS 2.0 mode

What we are doing: Convert the switch to the new-style authentication display (IBNS 2.0) to enable advanced ISE features such as SGT and dynamic data exchange. This switch-level change is required for full ISE integration and will affect how the switch presents authentication information to administrators and ISE.

configure terminal
authentication display new-style
end

What just happened:

  • Entered global configuration mode and executed authentication display new-style. This command switches the switch into the IBNS 2.0 display style, enabling advanced display and operations used with ISE (such as more dynamic authorization and SGT-related display behaviors).
  • end exits configuration mode and saves the running config state for immediate operation.

Real-world note: Converting to new-style is one-way on many platforms — a switch may require reformatting to revert. Only perform this on switches intended for long-term ISE integration.

Verify:

show running-config | include authentication display
!
authentication display new-style

Expected output explanation: The running configuration includes the authentication display new-style line, confirming the switch is in IBNS 2.0 display mode.

Step 2: Create an Easy Connect AD-only ACL on the NAD (Switch)

What we are doing: Configure an access-list that permits the minimum services required for Easy Connect to allow a machine to perform AD authentication and related services before full access is granted. This prevents captive restrictions from blocking AD communication that would allow Easy Connect to bind MAB sessions to user logins.

configure terminal
ip access-list extended EASY-CONNECT-AD
 permit udp any eq bootpc any eq bootps
 permit udp any any eq domain
 permit icmp any any
 permit tcp any host 10.1.2.10 eq 88
 permit udp any host 10.1.2.10 eq 88
 permit udp any host 10.1.2.10 eq ntp
 permit tcp any host 10.1.2.10 eq 135
 permit udp any host 10.1.2.10 eq netbios-ns
 permit tcp any host 10.1.2.10 eq 139
 permit tcp any host 10.1.2.10 eq 389
 permit udp any host 10.1.2.10 eq 389
 permit tcp any host 10.1.2.10 eq 445
 permit tcp any host 10.1.2.10 eq 636
 permit udp any host 10.1.2.10 eq 636
exit
end

What just happened:

  • Created an extended ACL named EASY-CONNECT-AD that allows DHCP, DNS, ICMP, Kerberos (88), NTP, RPC/NetBIOS/AD LDAP (389/636), SMB (445) and common AD endpoints to reach the AD Domain Controller at IP 10.1.2.10.
  • This ACL ensures endpoints in a restricted (pre-auth) VLAN can still reach AD services necessary for Easy Connect to correlate login events with MAB sessions.

Real-world note: Replace 10.1.2.10 with your AD-DC IP. In production, keep this ACL as small as possible to minimize attack surface.

Verify:

show ip access-lists EASY-CONNECT-AD
Extended IP access list EASY-CONNECT-AD
    10 permit udp any eq bootpc any eq bootps
    20 permit udp any any eq domain
    30 permit icmp any any
    40 permit tcp any host 10.1.2.10 eq 88
    50 permit udp any host 10.1.2.10 eq 88
    60 permit udp any host 10.1.2.10 eq ntp
    70 permit tcp any host 10.1.2.10 eq 135
    80 permit udp any host 10.1.2.10 eq netbios-ns
    90 permit tcp any host 10.1.2.10 eq 139
   100 permit tcp any host 10.1.2.10 eq 389
   110 permit udp any host 10.1.2.10 eq 389
   120 permit tcp any host 10.1.2.10 eq 445
   130 permit tcp any host 10.1.2.10 eq 636
   140 permit udp any host 10.1.2.10 eq 636

Expected output explanation: The ACL named EASY-CONNECT-AD is present with the listed permit statements, confirming the switch will allow necessary AD-related traffic.

Step 3: Ensure network reachability between PAN/PSNs and NADs

What we are doing: Add static routes (or verify routing) on the distribution switch so the switch can reach PANs and PSNs for RADIUS and admin tasks. NAT or routing misconfiguration will prevent RADIUS/CoA from functioning correctly.

configure terminal
ip route 10.1.1.0 255.255.255.0 10.1.1.254
end

What just happened:

  • Added a route to the 10.1.1.0/24 network via next hop 10.1.1.254. This ensures the switch can reach the ISE nodes (10.1.1.10, 10.1.1.11, 10.1.1.20/21) for RADIUS authentication and CoA messages. In production, routing is usually provided by upstream routers — static routes are acceptable for lab validation.

Real-world note: In production environments, use dynamic routing or ensure redundant paths exist to ISE nodes to avoid single points of failure.

Verify:

show ip route 10.1.1.0
Routing entry for 10.1.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.1.1.254

Expected output explanation: The route to 10.1.1.0/24 points at 10.1.1.254, confirming the device will forward traffic to the ISE management network.

Step 4: Configure node groups and assign PSNs (GUI steps with verification via network)

What we are doing: In the ISE admin GUI (PAN), create a node group called PSN-Group-1 and add PSN1 (10.1.1.20) and PSN2 (10.1.1.21). This groups authentication nodes for load distribution and policy targeting.

# Web UI action (performed on PAN-Primary at 10.1.1.10 via browser)
# (No CLI is provided for PAN GUI tasks in the reference material; perform these steps in the ISE Admin GUI)

What just happened:

  • In the PAN GUI you created a group that logically groups PSNs so that policies or network devices can reference a single group rather than individual nodes. This simplifies assignment and enables the PAN to distribute authentication requests across the PSNs in that group.

Real-world note: Use node groups to separate PSNs by geography, function, or capacity. For example, create separate node groups for campus and data-center PSNs.

Verify (network-level verification): Use ping from the switch to each PSN to ensure network reachability and verify the PAN is receiving heartbeats from PSNs (PAN GUI shows node status).

ping 10.1.1.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

ping 10.1.1.21
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.21, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms

Expected output explanation: Successful pings show the switch can reach the PSNs. In addition, the PAN GUI (10.1.1.10) will show PSN nodes as "Registered" / "Available" when replication and heartbeats are functioning.

Step 5: Configure primary and secondary PAN roles (GUI steps + verification)

What we are doing: In the ISE GUI, designate 10.1.1.10 as the Primary PAN and 10.1.1.11 as the Secondary PAN (or set up the secondary to be a backup). This ensures configuration changes are accepted by the primary, and the secondary holds replicated copies for resilience.

# Web UI action (performed on PAN-Primary at 10.1.1.10 and PAN-Secondary 10.1.1.11)
# (Assign node roles within the ISE Admin GUI; no CLI shown in reference)

What just happened:

  • The PAN roles are set so the administrative writes are performed on the Primary PAN. The secondary node keeps a replicated copy and can be promoted if needed. This separation prevents split-brain and ensures a single source of truth for configuration.

Real-world note: Never allow unsupervised primary PAN failover; test promotions in maintenance windows and ensure database replication is healthy before promoting a secondary PAN.

Verify (GUI + network verification): From an administrative workstation, confirm the GUI reports the PAN roles and check that the secondary PAN has current replication timestamps. Network-level simple check — confirm HTTPS connectivity to both PANs.

# From your admin workstation using CURL or browser; CLI verification on switch to check HTTPS tcp connection can respond
telnet 10.1.1.10 443
Trying 10.1.1.10...
Connected to 10.1.1.10.
Escape character is '^]'.
^]
telnet> quit

telnet 10.1.1.11 443
Trying 10.1.1.11...
Connected to 10.1.1.11.
Escape character is '^]'.
^]
telnet> quit

Expected output explanation: TCP port 443 accepts connections on both PAN addresses, indicating the web admin interfaces are reachable. Full PAN role status is visible in the ISE Admin GUI.

Verification Checklist

  • Check 1: Switch is in IBNS 2.0 display mode. Verify with show running-config | include authentication display — expect authentication display new-style.
  • Check 2: Easy Connect AD-only ACL present and correct. Verify with show ip access-lists EASY-CONNECT-AD — expect entries permitting AD/DC services to 10.1.2.10.
  • Check 3: PSNs are reachable and in the node group. Verify network reachability with ping 10.1.1.20 and ping 10.1.1.21 — expect success. Verify PSN status and node-group membership in PAN GUI — expect Registered/Available and PSN-Group-1 assignment.
  • Check 4: PAN primary/secondary roles configured and replication healthy. Verify connectivity to both PANs (TCP/443) and view role/replication timestamps in PAN GUI.

Common Mistakes

SymptomCauseFix
PSNs show as Unavailable in PAN GUINetwork reachability problem (routing, ACLs, firewall)Verify routes, apply correct ACLs, ensure 1812/1813 and management ports are reachable and not filtered
Clients cannot complete Easy Connect AD loginAD ACL missing or too restrictiveApply the AD-focused ACL (EASY-CONNECT-AD) and confirm AD-DC IP is correct (10.1.2.10)
Switch still behaves like legacy IBNSauthentication display new-style not applied or not savedRe-run configure terminal → authentication display new-style → end. Confirm with show running-config
PAN secondary not showing recent replication timestampPAN replication misconfigured or secondary unreachableVerify network connectivity to secondary PAN, confirm PAN services up (HTTPS reachable), and check replication status in PAN GUI

Key Takeaways

  • PAN and PSN roles are distinct: PAN is the management/admin node; PSNs handle runtime authentication and profiling. Keep PAN resilient and PSNs distributed for capacity and redundancy.
  • Use node groups to control PSN assignment and load distribution; this reduces configuration complexity and localizes authentication traffic.
  • Prepare network devices: convert to IBNS 2.0 if required, and apply minimal AD-permitting ACLs for Easy Connect so endpoints can reach AD while unauthenticated.
  • Verify at both the network layer (ping, TCP connect) and in the ISE GUI (node registration and replication timestamps) — both are needed to ensure HA will function in production.

Warning: In production, test failover procedures in a maintenance window. PAN promotions and PSN removals can affect auth traffic — always validate replication and backups before making topology changes.

This lesson covered the planning and initial configuration tasks to put ISE into a highly available architecture: switch preparation, Easy Connect ACLs, route reachability, node group creation, and PAN role assignment. In the next lesson we'll validate authentication failover behaviors and measure load distribution across the PSN node group.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security