ISE Deployment Models: Standalone, Distributed, Node Groups & Dedicated MnT

Overview

“How many ISE nodes do we need?” is the first question in every ISE design, and it is usually answered with a number instead of a shape. The number is the wrong half. Two deployments with four nodes each can have completely different failure behaviour depending on which node runs what.

This lesson gives you the vocabulary to describe a deployment exactly, the four shapes Cisco supports and the limits that separate them, and what each shape does when a node dies. The last section reads the course lab’s own deployment table and names its shape.

Terminology: Node, Persona, Role

Three words carry every ISE deployment conversation, and they are not interchangeable:

• Node — one ISE instance, physical appliance or virtual machine
• Persona — a set of services a node runs: Administration, Policy Service, Monitoring, pxGrid
• Role — standalone, primary or secondary, and it applies only to the Administration and Monitoring personas

The personas themselves were the subject of the previous lesson (ISE Personas: PAN, MnT, PSN & pxGrid Controller — What Each Node Actually Runs); here is the one-line version of each, because every shape below is a rearrangement of them:

Design Choice: Standalone — One Node, Every Persona

A standalone deployment is a single node running the Administration, Policy Service and Monitoring personas together. It is what you have the moment you finish installing ISE: the node is standalone, and you cannot edit its personas until it becomes the primary node of a deployment.

Cisco’s own guidance is blunt: do not use a standalone deployment in production, because there is nothing to fail over to. It’s the right shape for a lab, a proof of concept, or the staging hour of a production build before the second node exists.

Design Choice: Small, Medium and Large

Once there is a second node, the deployment is distributed: administration and monitoring stay centralised on at most two nodes each, and policy decisions spread across Policy Service nodes. Cisco’s Performance and Scalability Guide sorts distributed deployments into three sizes.

Enlarge figure: Four ISE deployment shapes drawn the same way: standalone as one node with the three core personas; small as two nodes each with every persona; medium as two PAN/MnT/pxGrid nodes above up to six dedicated PSNs; large as dedicated PAN, MnT and pxGrid pairs above up to 50 PSNs

Read the table as a progression. Each step moves one kind of work off the nodes that hold the configuration:

1. Small keeps everything together and buys redundancy by duplicating the whole node.
2. Medium takes the Policy Service persona off the Administration and Monitoring nodes. Cisco is explicit that a medium deployment cannot run the Policy Service persona on a node that runs Administration or Monitoring.
3. Large then separates Administration from Monitoring as well, and Cisco says to register the Monitoring nodes as Dedicated MnT at that size.

Design Choice: Dedicated MnT

The Monitoring persona writes every authentication, accounting and posture record from every node, and 60 percent of a Monitoring node’s disk is set aside for that log store. Cisco recommends not running the Monitoring and Policy Service personas on the same node, and in a large deployment recommends the Dedicated MnT option, which disables every other persona on the node and stops configuration replication to it.

The reasoning is the same as keeping a syslog server off the firewall it collects from: when authentication volume spikes, the node writing the logs shouldn’t also be the node answering the requests.

Cisco’s Administrator Guide describes the Monitoring pair as offering active standby rather than high availability, and the secondary doesn’t take over the primary role by itself. When the primary MnT has been down for more than five minutes, the PAN starts reading monitoring data from the secondary; the secondary’s role changes only when an administrator changes it. (The ISE 3.5 Installation Guide words this loosely as automatic promotion; the Administrator Guide’s deployment chapter is the precise one.)

Failure Modes: When the Primary PAN Goes Down

In a two-PAN deployment the primary PAN is active and the secondary Administration persona is on standby: it receives every configuration change but doesn’t act on it administratively. Other personas on that node, such as its Policy Service, keep working. What matters is what the rest of the deployment can still do while no PAN is active.

The pattern: Policy Service nodes keep authenticating from the configuration already replicated to them. What stops are the operations that need an active PAN — creating guest accounts, recording newly profiled endpoints, issuing certificates from the internal CA, and pxGrid’s registration and subscription.

Enlarge figure: The primary PAN fails: RADIUS authentication of existing endpoints and posture keep working; new guests, newly profiled endpoints, BYOD with the internal CA and the pxGrid service wait for a PAN; the secondary PAN is promoted either by an administrator on its own GUI or at the request of a non-Administration health check node

There are two ways to get the secondary PAN promoted:

• Manual promotion — an administrator logs in to the secondary PAN’s own GUI and promotes it. No extra nodes are needed.
• PAN auto-failover — a health check node watches the primary PAN and asks the secondary to take over when the primary stops answering.

Auto-failover has requirements that are easy to miss:

• At least three nodes — the two Administration nodes and a health check node that is not an Administration node (a PSN, MnT or pxGrid node)
• A health check node per data centre — if the two PANs are in different data centres, each needs its own
• About 20 minutes by default — Cisco’s Administrator Guide puts the default failure-detection time at 10 minutes and the promotion at another 10
• No automatic failback — when the old primary returns it becomes the secondary and must be synchronised by hand

Design Choice: PSN Node Groups

A node group is a set of Policy Service nodes on the same fast LAN that share session information and heartbeat each other. It solves one specific failure.

Guest, posture and MDM flows park an endpoint in a URL-redirect state on one PSN while the user completes a portal or a posture check. If that PSN dies mid-flow, the endpoint is stranded: the network device still holds a redirect that points at a dead node. In a node group, a surviving peer knows which sessions were on the failed node and sends a Change of Authorization (CoA) for them, so each endpoint restarts its flow on a live PSN.

Enlarge figure: A node group recovering stranded sessions: an endpoint held in URL redirect by PSN A through the switch; PSN A fails; PSN B, its node-group peer, knows the sessions and sends the switch a CoA so the endpoint restarts its flow on a live PSN

What a node group needs:

• CoA from every member — Cisco’s wording is that every node in the group is configured on the network device “as RADIUS clients and authorized for CoA”; on a Cisco switch that means each PSN is listed as a dynamic-authorization client with its shared key
• A fast LAN between members — Layer 2 adjacency is not required but is highly recommended; members talk over TCP port 7800
• A reason to exist — Cisco recommends node groups when the deployment uses URL-redirect services, with N+1 or N+2 redundancy inside the group

Scale & Limits: Distance Between Nodes

A distributed deployment can span sites, but not arbitrary distances. Cisco’s scale-limits table sets 300 milliseconds as the maximum network latency between the primary PAN and any other node, including the secondary PAN, the Monitoring nodes and every PSN. Every node also has to resolve every other node’s name in DNS, forward and reverse — Cisco says registration fails without it — and Cisco’s guidelines say to use the same NTP server on every node.

Cisco’s performance figures were measured with all nodes in one data centre at under 5 ms. Treat 300 ms as the limit a deployment is supported at, and the published session numbers as sizing guidance under Cisco’s test conditions — real capacity still depends on the hardware, the services enabled and the traffic mix.

🔬 See It in the Lab: Name the Lab’s Deployment Model

This reads the deployment the previous lesson built. Nothing here changes configuration.

Step 1 — list the nodes and what they run. From WS-ADMIN-01, ask the primary PAN, ISE-01 (10.82.22.161), for its deployment table through the OpenAPI, with the admin credentials in a .netrc file:

WS-ADMIN-01$ curl -sk --netrc-file ~/.netrc -H 'Accept: application/json' https://ise-01.securitylessons.lab/api/v1/deployment/node | python3 -m json.tool
{
    "response": [
        {
            "hostname": "ise-01",
            "fqdn": "ise-01.securitylessons.lab",
            "ipAddress": "10.82.22.161",
            "roles": [
                "PrimaryAdmin",
                "PrimaryMonitoring"
            ],
            "services": [
                "Session",
                "Profiler"
            ],
            "nodeStatus": "Connected"
        },
        {
            "hostname": "ise-02",
            "fqdn": "ise-02.securitylessons.lab",
            "ipAddress": "10.82.22.165",
            "roles": [
                "SecondaryAdmin",
                "SecondaryMonitoring"
            ],
            "services": [
                "Session",
                "Profiler"
            ],
            "nodeStatus": "Connected"
        }
    ],
    "version": "1.0.0"
}

Two nodes; each carries an Administration role, a Monitoring role and the Session service, which is the Policy Service persona. The three core personas run on both nodes, primary and secondary, and pxGrid is off. Measured against the table in this lesson, that is the small deployment — the smallest shape Cisco recommends for production.

Step 2 — check whether this pair can fail over by itself. In the GUI, open Administration › System › Deployment and click PAN Failover.

The page offers one check box, Enable PAN Auto Failover — and in this lab ISE will not let you tick it: the box is rendered disabled. That matches the rule above. Auto-failover needs a health check node that is not an Administration node, and both of this deployment’s nodes are Administration nodes. With two nodes, the recovery path for this lab is manual promotion from ISE-02’s own GUI.

🎥 [Video: node, persona, role; the four shapes as one repeated drawing; the session numbers that pick a size and why an extra node does not move a small deployment’s limit; the primary PAN dying on the whiteboard with manual promotion against auto-failover; the node group as a stranded-session fix; the lab’s deployment table read aloud. Matches video.script_outline. Runtime: ~9 minutes]