NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will learn the differences between the four primary Cisco ISE personas: the Policy Administration Node (PAN), Monitoring & Troubleshooting (MnT), Policy Service Node (PSN), and pxGrid. You will see how to plan which persona belongs on which node, understand distributed versus standalone deployments, and perform the basic network-side configuration that supports ISE node placement (management VLAN, SVI). This matters in production because correct persona placement and network reachability determine authentication capacity, logging reliability, and integration with external systems (SIEM, MDM, NAC). In a real enterprise, you might co-locate PAN+MnT in a primary datacenter and distribute PSNs near branch offices to reduce authentication latency and central bandwidth use.

Quick Recap

This lesson continues from Lesson 1 topology. We will not add new network devices, but we will add management IPs for the ISE nodes (PAN, MnT, PSN, pxGrid) and configure the management SVI on the access switch that connects those ISE appliances. Use the same switch and routing fabric from Lesson 1. The new IP addresses used in the lab are shown in the topology below.

ASCII Topology (management plane)

Device table

Device	Role
R1	L3 gateway for management (10.255.255.1/24)
MgmtSwitch	Access switch for ISE management VLAN
ISE-PAN	Policy Administration Node (10.255.255.11)
ISE-MnT	Monitoring & Troubleshooting Node (10.255.255.12)
ISE-PSN	Policy Service Node (10.255.255.13)
ISE-pxG	pxGrid-enabled node (10.255.255.14)

IP addressing table

Host	Interface	IP / Mask	Gateway
MgmtSwitch Vlan10	SVI Vlan10	10.255.255.2/24	10.255.255.1
R1 Gi0/0	to MgmtSwitch	10.255.255.1/24	-
ISE-PAN	Mgmt0/0	10.255.255.11/24	10.255.255.1
ISE-MnT	Mgmt0/0	10.255.255.12/24	10.255.255.1
ISE-PSN	Mgmt0/0	10.255.255.13/24	10.255.255.1
ISE-pxG	Mgmt0/0	10.255.255.14/24	10.255.255.1

Tip: In production, management networks are isolated and often have ACLs and tracking to prevent accidental exposure of administrative interfaces.

Key Concepts (theory before hands-on)

ISE Personas — A persona is a logical role that an ISE node performs. Think of personas like job descriptions: the device hardware or VM runs the software, personas determine what functions that node performs (e.g., the PAN is the “policy author” and replicator).
- PAN (Policy Administration Node): central GUI and policy configuration point. PAN stores policy and pushes configuration to other nodes. In production, you usually have 2 PANs for redundancy (active/standby).
- MnT (Monitoring & Troubleshooting): collects logs (accounting, auth, posture) and provides the monitoring GUI and reports. Large deployments separate MnT to avoid storage/CPU contention with policy processing.
- PSN (Policy Service Node): performs the runtime authentication/authorization (RADIUS/TACACS+). PSNs should be close to the endpoints to minimize latency.
- pxGrid: provides context sharing to external systems (SIEM, MDM). pxGrid can run on dedicated nodes or be co-located with PAN/MnT depending on scale.
Distributed vs Standalone — A standalone node (all personas on one box) is useful for labs; distributed places specific personas on dedicated nodes for scale, performance, and locality. Distributed deployments allow:
- Scale: you can add PSNs to increase concurrent authentications.
- Locality: co-locate PSNs near AD/DCs or network devices to reduce auth latency.
- Resilience: multiple PANs/MnTs reduce single points of failure.
Replication & Latency — Policy replication and logging rely on timely communication between PAN, MnT, and PSNs. A guardrail of ~300 ms round-trip latency between PAN and other ISE nodes is recommended; above this, replication and profiling efficiency degrade.
Protocol Behavior — When a switch sends an 802.1X authentication, the switch (NAD) sends a RADIUS Access-Request to a PSN. If the PSN needs policy or identity info, it queries the PAN or identity stores. MnT receives accounting and logging messages via internal logging replication to perform reporting.
Analogy: Think of the PAN as the “head office” writing company rules, PSNs as local branches enforcing rules for end-users, MnT as the centralized audit/forensics team, and pxGrid as the integration bus connecting to partners.

Step-by-step configuration

We will configure the management SVI on the switch so the ISE nodes can reach one another and the gateway. Then we will demonstrate basic verification commands that show node reachability and status. Because persona assignment is performed in the ISE GUI during installation and jump-start, we will focus on the network-side configuration and verification that a distributed deployment requires.

Step 1: Configure the management VLAN SVI on MgmtSwitch

What we are doing: Create VLAN 10, configure the SVI for the ISE management network, and ensure the default gateway is reachable. This SVI gives management connectivity for PAN, MnT, PSN, and pxGrid nodes and matters because ISE uses a stable management address for replication, logging, and pxGrid communications.

configure terminal
vlan 10
 name ISE-MGMT
exit
interface Vlan10
 description ISE management SVI
 ip address 10.255.255.2 255.255.255.0
 no shutdown
exit
ip route 0.0.0.0 0.0.0.0 10.255.255.1
end
write memory

What just happened: The VLAN 10 SVI was created and assigned address 10.255.255.2/24. This SVI allows devices connected to access ports in VLAN 10 to communicate with the router gateway (10.255.255.1). The static default route ensures the switch can reach outside the management network (useful for remote syslog, NTP, or contacting external admin networks).

Real-world note: In production, management SVIs are usually placed in an out-of-band management VRF or physically separate switch to reduce attack surface.

Verify:

show ip interface brief

Expected output:

Interface              IP-Address      OK? Method Status                Protocol
Vlan10                 10.255.255.2    YES manual up                    up
GigabitEthernet1/0/1   unassigned      YES unset  up                    up
GigabitEthernet1/0/2   unassigned      YES unset  up                    up
GigabitEthernet1/0/3   unassigned      YES unset  up                    up
GigabitEthernet1/0/4   unassigned      YES unset  up                    up

Step 2: Configure access ports for ISE appliances

What we are doing: Place the switch ports connected to each ISE node into VLAN 10 as access ports. If ports are trunked in your infrastructure, you would allow VLAN 10. This ensures the ISE appliances receive the SVI management IPs and can communicate.

configure terminal
interface GigabitEthernet1/0/1
 description ISE-PAN Mgmt
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
exit
interface GigabitEthernet1/0/2
 description ISE-MnT Mgmt
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
exit
interface GigabitEthernet1/0/3
 description ISE-PSN Mgmt
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
exit
interface GigabitEthernet1/0/4
 description ISE-pxG Mgmt
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
exit
end
write memory

What just happened: Each physical interface is now an access port in VLAN 10 and has PortFast enabled to bring the port quickly to forwarding state which speeds up appliance boot connectivity. With this configuration, when the ISE nodes are plugged in (and configured with IPs in the 10.255.255.0/24 network), they will reach the SVI.

Real-world note: PortFast should only be configured on ports connected to endpoints or servers, not on uplinks.

Verify:

show running-config interface GigabitEthernet1/0/1
show running-config interface GigabitEthernet1/0/2
show running-config interface GigabitEthernet1/0/3
show running-config interface GigabitEthernet1/0/4

Expected output (sample for Gi1/0/1; other ports similar):

interface GigabitEthernet1/0/1
 description ISE-PAN Mgmt
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
end

Step 3: Verify routing to ISE management addresses from the gateway (R1)

What we are doing: Ensure the L3 gateway can reach each ISE management address. This is critical because the PAN must be reachable by other ISE nodes for policy replication and PSNs must reach PAN/MnT for authorization and logging.

show ip route 10.255.255.0
ping 10.255.255.11
ping 10.255.255.12
ping 10.255.255.13
ping 10.255.255.14

What just happened: The commands check the route to the ISE management network and test ICMP reachability to each ISE node. Successful pings confirm basic IP connectivity; lack of responses would indicate interface, VLAN, or cabling issues.

Real-world note: In production, you should also verify ACLs and firewalls along the path allow TCP/UDP ports used by ISE (for example, RADIUS, Syslog, pxGrid). If a firewall blocks management, replication and logging will fail even though ICMP works.

Verify (expected outputs):

R1#show ip route 10.255.255.0
Routing entry for 10.255.255.0/24
  Known via "connected", distance 0, metric 0
  Redistributing via ospf 1
  Last update from 0.0.0.0 on GigabitEthernet0/0
  * 10.255.255.0 is directly connected, GigabitEthernet0/0

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

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

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

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

Step 4: Confirm ISE node service reachability (basic network-level checks)

What we are doing: From the management workstation (or R1 if you have network tools), verify that the ISE nodes respond on their management IPs and that basic services like NTP or HTTPS are reachable. While detailed persona assignment happens inside ISE, network accessibility is a precondition for successful persona replication and pxGrid integration.

telnet 10.255.255.11 443
telnet 10.255.255.12 443
telnet 10.255.255.13 1812
telnet 10.255.255.14 8443

What just happened: These commands attempt TCP connections to commonly used ports (HTTPS 443 for GUI, RADIUS 1812 for PSN). Successful TCP connections indicate that the node is listening and that no network filter is blocking the flow. Failure indicates a firewall, host-based firewall, or service not running.

Real-world note: In production, you must verify both control-plane ports (e.g., SSH, HTTPS) and data-plane ports (RADIUS/TACACS+/syslog) because ISE requires many protocols to be reachable for full functionality.

Verify (example expected outputs):

Manager#telnet 10.255.255.11 443
Trying 10.255.255.11...
Connected to 10.255.255.11.
Escape character is '^]'.
^]quit
Connection closed.

Manager#telnet 10.255.255.13 1812
Trying 10.255.255.13...
Connected to 10.255.255.13.
Escape character is '^]'.
^]quit
Connection closed.

Step 5: Document persona placement and latency requirements

What we are doing: Record where each persona will live (which node) and test latency between PAN and PSN/MnT. This is a planning step that ensures replication will be reliable; the recommended guardrail is approximately 300 ms round-trip between PAN and PSN/MnT.

ping 10.255.255.11 source 10.255.255.12
ping 10.255.255.12 source 10.255.255.11

What just happened: These source-specified pings measure RTT between the two addresses. If RTT << 300 ms, replication is likely fine. If RTT approaches or exceeds 300 ms, you should reconsider node placement, possibly moving PAN closer to PSNs or adding additional PAN/MnT in another DC.

Real-world note: For geographically distributed environments, co-locate PSNs with Active Directory to reduce authentication delays caused by identity store queries.