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

Objective

In this lesson you will learn how to plan an ISE deployment from requirements to production readiness. We will cover sizing calculations (TPS, authentication volume, log retention), hardware and role placement (PAN, PSN, SAN), certificate strategy, and network readiness checks. This matters in production because an undersized or poorly planned ISE deployment causes authentication failures, slow posture checks, and loss of telemetry — impacting user access and security posture. Real-world scenario: you are the security engineer at NHPREP preparing to deploy ISE for 10,000 endpoints across three offices with centralized AD and segmented access; you must produce a sizing and network readiness plan before provisioning VMs.

Tip: Treat planning as the project's backbone — "a goal without a plan is just a wish." Proper planning reduces rework and outages during cutover.

Topology & Device Table

ASCII Topology (management and authentication paths)

Note: All IP addresses and interface names below are used for lab examples and to illustrate planning. Domain names for services in examples use lab.nhprep.com and example credentials use password Lab@123 as required.

Device Table

Device	Interface	IP Address	Subnet Mask	Role
AD Server	eth0	10.10.10.10	255.255.255.0	External Identity Source (LDAP)
Core Switch	Gi0/1 (mgmt)	10.10.10.1	255.255.255.0	L3 core, routes between mgmt & auth networks
Access Switch 1	Gi0/1	10.10.100.2	255.255.255.0	Access switch for 802.1X endpoints (VLAN 100)
Access Switch 2	Gi0/1	10.10.200.2	255.255.255.0	Access switch for guest VLAN (VLAN 200)
ISE PAN	mgmt0	10.10.10.101	255.255.255.0	Policy Administration Node (admin GUI)
ISE PSN1	mgmt0	10.10.10.102	255.255.255.0	Policy Service Node (RADIUS)
ISE PSN2	mgmt0	10.10.10.103	255.255.255.0	Policy Service Node (RADIUS)
ISE SAN (optional)	mgmt0	10.10.10.104	255.255.255.0	Passive/Monitoring/logging (optional)
Management PC	eth0	10.10.10.50	255.255.255.0	Admin access to ISE GUI

Key Concepts (theory + practical)

ISE Roles and Scale (PAN/PSN/SAN)
Theory: ISE separates functions — the PAN hosts the admin GUI and configuration, PSNs handle authentication and accounting transactions (RADIUS/TACACS+), and SAN/Monitoring nodes store logs. Practical: In production, put PAN behind management segmentation and scale PSNs horizontally to meet Authentication TPS requirements. Think of PSNs as frontline soldiers: add more when transaction load grows.
Transactions per Second (TPS) and Sizing
Theory: TPS is the number of authentication transactions (RADIUS) per second a PSN cluster must handle. Production sizing uses peak TPS plus headroom for bursts (e.g., morning logon surge). Practical: Estimate peak authentications per minute, convert to TPS, and size PSNs to handle 2x peak for safety.
Certificates and Trust
Theory: ISE uses system certificates (per node/service), a Trusted Certificate store (CAs), and can act as an internal CA for endpoints. Practical: Use a plan for system certificates (preferably signed by corporate PKI) to avoid captive-portal TLS errors and to support EAP-TLS/pxGrid. Think of certificates like ID cards — every service and node must have a trusted ID.
Network Device Readiness & Capabilities
Theory: Not all network devices support the full set of ISE features. Verify device model, OS version, and supported features (802.1X, CoA, SGT if needed). Practical: Use a compatibility matrix before deployment, and ensure devices can send the desired accounting/CoA messages.
Logging and Retention
Theory: ISE logs grow fast; retention policies directly affect SAN sizing. Practical: Determine retention windows (e.g., 90 days), expected TPS, and storage needs. Plan for a separate SAN or external logging if retention or TPS is large.

Step-by-step configuration

Note: This lesson focuses on planning and readiness steps. Commands shown are examples of the planning artifacts and orchestration snippets referenced in the source material. Each step includes commands, why they matter, and verification commands.

Step 1: Document Business Requirements and Use Cases

What we are doing: Capture the business objectives, expected growth, and use cases (BYOD, Guest, Device Administration). This drives sizing, HA, and feature choices.

# Example planning artifact (YAML snippet used for orchestration and device definitions)
network_device:
  - name: lab-mr46-1
    description: "Lab NAD for VLAN-based dot1x"
    profileName: Cisco
    authenticationSettings:
      dtlsRequired: false
      enableKeyWrap: false
      enableMultiSecret: 'false'
    keyEncryptionKey: ''
    keyInputFormat: ASCII

What just happened: This YAML declares a NAD profile for automation/orchestration tooling. It captures NAD name, profile and authentication settings (DTLS and key wrap off). In production this artifact becomes the source-of-truth for onboarding NADs into ISE orchestration tools and ensures consistent settings.

Real-world note: Organizations use this approach so network device onboarding is repeatable and auditable; it feeds into lifecycle orchestration.

Verify:

# Verify the planning artifact exists and is syntactically valid (pseudo-check)
cat network_device.yaml
network_device:
  - name: lab-mr46-1
    description: "Lab NAD for VLAN-based dot1x"
    profileName: Cisco
    authenticationSettings:
      dtlsRequired: false
      enableKeyWrap: false
      enableMultiSecret: 'false'
    keyEncryptionKey: ''
    keyInputFormat: ASCII

Step 2: Calculate Authentication Volume and TPS

What we are doing: Estimate peak authentications to calculate TPS and required PSN count.

# Example calculation documented as a shell-style comment for clarity
# Peak endpoints: 10000
# % authenticating at peak: 30% -> 3000 concurrent auth attempts over 300 seconds
# TPS calculation: 3000/300 = 10 TPS peak
# Add 2x headroom -> target cluster TPS = 20 TPS

What just happened: We converted business numbers into TPS. TPS determines how many PSNs are required (consult vendor sizing to map TPS to PSN instances). This affects CPU, memory, and licensing decisions.

Real-world note: Morning spikes and periodic posture checks can create short-lived TPS spikes — always build headroom.

Verify:

# Verify your calc notes
echo "Peak endpoints: 10000; Peak auth%:30; Peak auths:3000; Window:300s; TPS:10; Target TPS with headroom:20"
Peak endpoints: 10000; Peak auth%:30; Peak auths:3000; Window:300s; TPS:10; Target TPS with headroom:20

Step 3: Plan Certificate Strategy

What we are doing: Define which certificates are system certs (PAN/PSN), trusted CAs, and whether to use internal CA for endpoints.

# Planning entries (text)
# System Certificates: Use corporate PKI -> certificates issued for:
#   - ise.pan.lab.nhprep.com (PAN)
#   - ise.psn1.lab.nhprep.com (PSN1)
#   - ise.psn2.lab.nhprep.com (PSN2)
# Trusted CA: Add corporate Root and Intermediate to ISE Trusted Certificates
# ISE Issued: Enable ISE internal CA for small labs (90-day eval) else use SCEP to issue endpoint certs

What just happened: We documented certificate targets and trust anchors. System certificates must support the services they secure (RADIUS EAP TLS, HTTPS portals, pxGrid). Trusted CA entries are replicated across ISE nodes to enable mutual TLS trust decisions.

Real-world note: If system certificates are self-signed, endpoints and browsers will see warnings; prefer corporate PKI for production.

Verify:

# Simulated verification checklist
echo "PAN cert: ise.pan.lab.nhprep.com -> present"
PAN cert: ise.pan.lab.nhprep.com -> present
echo "Trusted Root: corporate-root-ca -> present"
Trusted Root: corporate-root-ca -> present

Step 4: Network Device Capability & Access Readiness

What we are doing: Inventory NADs, OS versions, and enable necessary features (802.1X, RADIUS auth & accounting, CoA). Confirm management connectivity to ISE nodes (10.10.10.101-104).

# Example switch management verification (example CLI executed on a switch)
show running-config
! (truncated display in real device)
interface GigabitEthernet0/1
 description Uplink to Core
 ip address 10.10.100.2 255.255.255.0
!
interface GigabitEthernet0/2
 description Access Port to Clients (VLAN100)
 switchport mode access
 switchport access vlan 100
!
radius server ISE-PRIMARY
 address ipv4 10.10.10.102 auth-port 1812 acct-port 1813
 key Lab@123
!
aaa authentication dot1x default group radius
aaa authorization network default group radius

What just happened: The configuration shows interface assignments and RADIUS server entries pointing to PSN IP 10.10.10.102 with shared key Lab@123. Enabling AAA for dot1x ties the switch's authentication to ISE.

Real-world note: Ensure RADIUS shared secrets (Lab@123 in the lab) are distributed securely; in production use secure transport for management.

Verify:

show radius servers
Name: ISE-PRIMARY
Address: 10.10.10.102
Auth Port: 1812
Acct Port: 1813
Key: Lab@123
Status: reachable

Step 5: Logging & Retention Planning

What we are doing: Determine retention window, estimate storage, and plan SAN/monitoring node placement.

# Example storage estimate notes
# TPS average: 10 TPS -> 864000 transactions/day
# Average log size per transaction: 1 KB -> 864 MB/day
# 90-day retention -> ~78 GB (~+headroom 30% -> 102 GB)
# Plan SAN or external storage node: ise-san.lab.nhprep.com -> 10.10.10.104

What just happened: We converted TPS into daily log volume and retention sizing. This informs disk allocation for monitoring/SAN nodes and backup windows.

Real-world note: Logging spikes (e.g., security incidents) can temporarily increase storage needs — monitor and alert on utilization.

Verify:

# Verify planned SAN entry
echo "SAN Host: ise-san.lab.nhprep.com -> 10.10.10.104"
SAN Host: ise-san.lab.nhprep.com -> 10.10.10.104

Step 6: Orchestration & Lifecycle Readiness

What we are doing: Prepare for lifecycle automation (patching, certificate rollouts, config backups) and document processes.

# Example orchestration command artifact (pseudo Ansible/Automation)
# playbook: ise_orchestrate.yml
- name: Orchestrate ISE lifecycle
  hosts: ise_nodes
  tasks:
    - name: Push NAD configuration
      include_vars: network_device.yaml
    - name: Schedule certificate distribution
      debug:
        msg: "Certificate rollout scheduled for PAN and PSNs"

What just happened: We drafted an automation playbook skeleton to manage device onboarding and certificate rollouts. Automation reduces human error and speeds repeated tasks such as pushing NAD configs or scheduling reboots.

Real-world note: ISE 3.x supports orchestration for certificates and config management — prefer automation for consistent deployments.

Verify:

# Dry-run the playbook (pseudo-output)
ansible-playbook --check ise_orchestrate.yml
PLAY [Orchestrate ISE lifecycle] *******************************************************************
TASK [Push NAD configuration] ***********************************************************************
ok: [ise-pan]
ok: [ise-psn1]
ok: [ise-psn2]
TASK [Schedule certificate distribution] ***********************************************************
ok: [ise-pan] => {"msg":"Certificate rollout scheduled for PAN and PSNs"}
PLAY RECAP ******************************************************************************************
ise-pan                    : ok=2    changed=0    unreachable=0    failed=0
ise-psn1                   : ok=1    changed=0    unreachable=0    failed=0
ise-psn2                   : ok=1    changed=0    unreachable=0    failed=0

Verification Checklist

Check 1: PAN and PSN management IPs are reachable from management network. Verify with ping from management host to 10.10.10.101/102/103.
- Verification command: ping 10.10.10.101 (expected: reachable)
Check 2: RADIUS entries are configured on NAD and point to PSN IPs with shared secret Lab@123.
- Verification command: show radius servers (expected: PSN entries with key Lab@123 and reachable)
Check 3: Certificate plan documented and Trusted CA list identified for system cert issuance.
- Verification: Confirm planning document entries for ise.pan.lab.nhprep.com and corporate Root CA.
Check 4: Storage estimate completed for desired retention window (e.g., 90 days) and SAN host assigned (10.10.10.104).
- Verification: Storage estimate table with daily ingestion and retention totals exists.

Common Mistakes

Symptom	Cause	Fix
Authentication failures after cutover	NADs point to wrong PSN IP or shared secret mismatch	Verify `radius server` entries on NAD; ensure key Lab@123 is identical on ISE RADIUS client config
TLS errors on portal or EAP	System certificates are self-signed or not trusted by clients	Install corporate CA chain into ISE Trusted Certificates and use signed system certs for PAN/PSNs
Unexpected log growth	Underestimated TPS or verbose logging/polices enabled	Recalculate ingestion, increase SAN allocation, tune logging levels and retention
Slow admin UI or policy pushes	Single PAN under heavy operational load or insufficient resources	Ensure PAN is on dedicated management network, consider HA or scale-out for large deployments

Key Takeaways

Always start with business objectives — use cases (BYOD, Guest, Device Admin) dictate sizing and features.
Calculate TPS from peak authentication behavior and add safety headroom; map TPS to PSN count before provisioning.
Plan certificates early: system certs, trusted CA chains, and endpoint cert issuance are critical for TLS-based services and user experience.
Inventory NAD capabilities and OS versions; confirm support for required features (802.1X, CoA, RADIUS attributes) before relying on them.
Automate device onboarding and lifecycle tasks (certificate rollouts, backups, patches) to reduce risk and speed operations.

Important: This lesson focused on planning and readiness — the next lessons will cover ISE installation, node configuration, certificates in the console, and full RADIUS/TACACS+ integration with AD.

ISE Deployment Planning

Objective

Topology & Device Table

Key Concepts (theory + practical)

Step-by-step configuration

Step 1: Document Business Requirements and Use Cases

Step 2: Calculate Authentication Volume and TPS

Step 3: Plan Certificate Strategy

Step 4: Network Device Capability & Access Readiness

Step 5: Logging & Retention Planning

Step 6: Orchestration & Lifecycle Readiness

Verification Checklist

Common Mistakes

Key Takeaways