Understanding the Deployment
Available Languages
Table Of Contents
Understanding the Cisco ISE Network Deployment
Understanding Node Types, Personas, Roles, and Services
Cisco ISE Deployment Terminology
Understanding Distributed Deployment
Before Registering Secondary Nodes
Guidelines for Setting Up a Distributed Deployment
Cisco ISE Architecture Overview
Small Cisco ISE Network Deployments
Medium Cisco ISE Network Deployments
Large Cisco ISE Network Deployments
Dispersed Cisco ISE Network Deployments
Configuration of a Cisco ISE Node
Switch Configurations Required to Support Cisco ISE Functions
Planning an Inline Posture Deployment
Inline Posture Planning Considerations
Choosing an Inline Posture Operating Mode
Deploying Inline Posture as Standalone or High Availability
About Inline Posture High Availability
Understanding the Cisco ISE Network Deployment
This chapter provides information on how to deploy the Cisco Identity Services Engine (ISE) 3300 Series appliance and its related components, several network deployment scenarios, and describes the switch configurations that are needed to support Cisco ISE. This chapter contains the following topics:
•
Configuration of a Cisco ISE Node
•
•
Before Deploying Cisco ISE
This section provides the following reference information that aids you in better understanding what is needed before you deploy the Cisco ISE appliances in your network environment:
•
•
•
•
Understanding Node Types, Personas, Roles, and Services
Cisco ISE provides a highly available and scalable architecture that supports both standalone and distributed deployments. In a distributed environment, you configure one primary Administration ISE node and the rest are secondary nodes. The topics in this section provide information about Cisco ISE terminology, supported node types, distributed deployment, and the basic architecture.
Cisco ISE Deployment Terminology
Table 1-1 describes some of the common terms used in Cisco ISE deployment scenarios.
Types of Nodes
A Cisco ISE network has only two types of nodes:
•
–
Note
–
Note
–
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 Monitoring personas collect log messages. In case the primary Monitoring persona goes down, the secondary Monitoring persona automatically assumes the role of the primary Monitoring persona.
Note
•
Note
Note
In a distributed deployment, you can have the following combination of nodes on your network:
•
•
•
•
Understanding Distributed Deployment
An ISE distributed deployment consists of one primary Administration ISE node and multiple secondary nodes. Each ISE node in a deployment can assume any of the following personas: Administration, Policy Service, and Monitoring.
Note
After you install ISE on all your nodes as described in this guide, the nodes come up in a standalone state. You must then define one node to be your primary Administration ISE node. After defining a primary Administration ISE node, you can choose to configure other personas on that node, such as Policy Service or Monitoring. After you define personas on the primary Administration ISE node, you can register other secondary nodes with the primary Administration ISE node and then define personas for the secondary nodes.
When you register an ISE node as a secondary node, ISE immediately creates a database link from the primary to the secondary node and begins the process of replicating or sharing ISE configuration data from the primary to the secondary nodes. This process ensures consistency between the configuration data that is present in all the ISE nodes that are part of your deployment.
A full replication typically occurs when you first register an ISE node as a secondary node. An 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 primary Administration ISE node are reflected in the secondary nodes. The process of replication ensures that all ISE nodes in a deployment are in sync. You can view the status of replication from the deployment pages of the ISE administrative user interface.
The Policy Service ISE nodes that reside in a single location behind a load balancer and share a common multicast address can be grouped together. In such scenarios, you can define node groups and assign the nodes to the particular group.
To remove a node from a deployment, you must deregister it. When you deregister a secondary node from the primary Administration ISE node, the status of the deregistered node changes to standalone and the connection between the primary and the secondary node will be lost. Replication updates are no longer sent to the deregistered secondary node.
Note
The application server in an ISE node restarts when you make any of the following changes:
•
•
•
•
•
•
•
Note
Note
Note
When the Cisco ISE installation has been completed, you must configure one of your Cisco ISE instances as the primary node. You can edit the primary node and enable any service that you want to run on the primary.
Before Registering Secondary Nodes
Prerequisites:
•
•
•
•
•
•
•
•
Note
You can register the secondary nodes and edit their configuration profiles by using the user interface of the primary node. After you install a secondary node, Cisco ISE immediately creates a database link between the primary and the secondary node for replicating and synchronizing all changes. In addition, you can remove a node from the deployment by deregistering it. This action deletes it from the deployment.
When you deregister a node from the primary, the status of the deregistered node changes to standalone. Any connection between the primary and the secondary nodes is lost, no replication updates are sent to the secondary node.
Next Steps:
For more information on configuring Cisco ISE nodes, see:
•
–
Guidelines for Setting Up a Distributed Deployment
Observe the following guidelines before you attempt to set up Cisco ISE appliances in a distributed deployment:
•
•
•
•
Note
•
•
•
•
Note
When the Cisco ISE installation is complete, you must configure one of your Cisco ISE nodes as the primary node. You can edit the primary node and enable any service that you want to run on the primary. You can register secondary nodes and edit their configuration by using the user interface of the primary node. After you install a secondary node, Cisco ISE immediately creates a database link between the primary and secondary nodes for replicating and synchronizing all changes.
When you deregister a node from the primary, the status of the deregistered node changes to standalone. To register a deregistered node back with the primary, you must first reset the database configuration on the node and bring it back to a freshly installed node state and then register it again.
For more information:
See the Cisco Identity Services Engine User Guide, Release 1.0 for more information about:
•
•
•
Cisco ISE Architecture Overview
Figure 1-1 illustrates a basic overview of the Cisco ISE architecture that includes the following components:
•
–
–
•
•
Note
The policy information point represents the point at which external information is communicated to the Policy Service persona. For example, external information could be a Lightweight Directory Access Protocol (LDAP) attribute.
Figure 1-1 Cisco ISE
Architecture
Deployment Scenarios
This section describes three scenarios in which Cisco ISE can be deployed in a distributed deployment:
•
•
•
Small Cisco ISE Network Deployments
The smallest Cisco ISE deployment consists of two Cisco ISE nodes as shown in Figure 1-2, with one Cisco ISE node functioning as the primary appliance in a small network that supports up to 3,000 concurrent endpoints.
Note
The primary node provides all the configuration, authentication, and policy capabilities that are required for this network model, while the secondary Cisco ISE node functions in a backup role. The secondary node supports the primary node and maintains a functioning network whenever connectivity is lost between secondary network appliances, network resources, or RADIUS.
RADIUS is where the centralized AAA operations are performed between clients and the primary Cisco ISE node. As a result, the key requirement is to ensure that you can synchronize or replicate all of the content that resides on the primary Cisco ISE node with the secondary Cisco ISE node(s).
Being able to synchronize between the primary and secondary node makes it possible to keep the secondary node current with the state of your primary node. In a small network deployment, this type of configuration model allows you to configure both your primary and secondary node on all RADIUS clients by using this type of deployment or a similar approach.
Figure 1-2 Small Cisco ISE Network Deployment
As the number of devices, network resources, users, and AAA clients increases in your network environment, we recommend that you change your deployment configuration from the basic small model and use more of a split or distributed deployment model, as shown in Figure 1-3.
Note
Split Cisco ISE Deployments
In the case of split Cisco ISE deployments, you will continue to maintain primary and secondary nodes as described in the small Cisco ISE deployment. However, the AAA load is split between these two Cisco ISE nodes to optimize the AAA workflow. Each Cisco ISE appliance (primary or secondary) needs to be able to handle the full workload if there are any problems with AAA connectivity. When running under normal network operations, neither the primary or secondary node carries the full load of handling AAA requests because this workload is distributed between the two nodes.
The ability to split the load in this way directly reduces the stress on each Cisco ISE node in the system. In addition, splitting the load also provides better loading while still maintaining the functional status of the secondary node during the course of normal network operations.
Another advantage is that each node can perform its own specific operations, such as network admission or device administration, and still perform all the AAA functions in the event of a failure. If you have two Cisco ISE nodes that process authentication requests and collect accounting data from AAA clients, we recommend that you set up one of the Cisco ISE nodes to act as a log collector. Figure 1-3 shows the secondary Cisco ISE node in this role.
Figure 1-3 Split Cisco ISE Network Deployment
In addition, the split Cisco ISE node deployment design provides an advantage because it also allows for growth, as shown in Figure 1-4.
Medium Cisco ISE Network Deployments
As small, local networks grow, you can keep pace and manage network growth by adding additional Cisco ISE nodes to create a medium network that supports up to 6,000 concurrent endpoints. In medium network deployments, consider promoting one Cisco ISE node to perform as the primary to handle all the configuration services, and secondary Cisco ISE nodes to manage all your AAA functions.
As the amount of log traffic increases in the network, you can choose to either use the primary Cisco ISE node as your centralized log collector or dedicate one of the secondary Cisco ISE nodes to serve in this capacity for your network.
Figure 1-4 Medium Cisco ISE Network Deployment
Large Cisco ISE Network Deployments
We recommend that you use centralized logging (as shown in Figure 1-5) for larger Cisco ISE networks that support up to 10,000 concurrent endpoints. To use centralized logging, you must set up a dedicated logging server that serves as a Monitoring persona (for monitoring and logging) to handle the potentially high syslog traffic that a large, busy network can generate.
Because syslog messages are generated for outbound log traffic, any RFC-3164-compliant syslog appliance can serve as the collector for outbound logging traffic. A dedicated logging server enables you to use the reports and alert features that are available in Cisco ISE to support all the Cisco ISE nodes. See Understanding the Setup Program Parameters, page 3-3 when configuring the Cisco ISE software to support a dedicated logging server.
You can also consider having the appliances send logs to both a Monitoring persona on the Cisco ISE node and a generic syslog server. Adding a generic syslog server provides a redundant backup if the Monitoring persona on the Cisco ISE node goes down.
In large centralized networks, you should use a load balancer (as shown in Figure 1-5), which simplifies the deployment of AAA clients. Using a load balancer requires only a single entry for the AAA servers, and the load balancer optimizes the routing of AAA requests to the available servers.
However, having only a single load balancer introduces the potential for having a single point of failure. To avoid this potential issue, deploy two load balancers to ensure a measure of redundancy and failover. This configuration requires you to set up two AAA server entries in each AAA client, and this configuration remains consistent throughout the network.
Figure 1-5 Large Cisco ISE Network Deployment
Dispersed Cisco ISE Network Deployments
Dispersed Cisco ISE network deployments are most useful for organizations that have a main campus with regional, national, or satellite locations elsewhere. The main campus is where the primary network resides, is connected to additional LANs, ranges in size from small to large, and supports appliances and users in different geographical regions or distant locations.
To optimize AAA performance, each remote site should have its own AAA infrastructure (as shown in Figure 1-6). A centralized management model helps maintain a consistent, synchronized AAA policy. A centralized configuration model uses a primary Cisco ISE node with secondary Cisco ISE nodes. We still recommend that you use a separate Monitoring persona on the Cisco ISE node, but each remote location should retain its own unique network requirements.
Figure 1-6 Dispersed Cisco ISE Deployment
Some factors to consider when planning a network that has several remote sites include the following:
•
•
•
•
•
Configuration of a Cisco ISE Node
This section briefly describes the roles that various Cisco ISE appliances play in a network deployment and how to configure them. For more information on assigning a role to a node and configuring it, see the Cisco Identity Services Engine User Guide, Release 1.0. This section contains:
All Cisco ISE appliances have a similar installation procedure. For specific details, see the following sections:
•
•
Note
Primary Node
In a Cisco ISE deployment, only one appliance can serve as a Cisco ISE primary node. This primary node provides configuration capabilities and is the source for all replication operations.
When in a primary-secondary pair, only the primary and secondary nodes that operate as the Administration persona need to be configured in the license file. When you install the license file on the primary, the license requirements for the secondary node are met.
Secondary Node
Because the network can only have a single primary Cisco ISE node, all other Cisco ISE nodes function as secondary nodes. Although the Cisco ISE secondary nodes receive all the system configurations from the primary node, you must configure the following on each secondary node:
•
•
•
In a primary-secondary node pair, the secondary node is registered and it begins to receive the full synchronization of the configuration and replication updates from the primary node in the network.
Logging Server
You can configure to use either a primary node or one of the secondary nodes as the dedicated logging server for your network. In this role, the logging server receives logs from the primary node and all the secondary nodes deployed in the Cisco ISE network. We recommend that you designate one of the Cisco ISE secondary nodes as the Monitoring persona and exclude this particular secondary node from any of the AAA activities. Three main logging categories are captured:
•
•
•
For a complete description that provides more details on logging categories and best practices for configuring the logging server, see Chapter 13, "Logging" in the Cisco Identity Services Engine User Guide, Release 1.0.
Switch Configurations Required to Support Cisco ISE Functions
To ensure that Cisco ISE is able to interoperate with network switches, and functions from Cisco ISE are successful across the network segment, you must configure your network switches with certain required NTP, RADIUS/AAA, 802.1X, MAB, and other settings.
For more information:
•
Planning an Inline Posture Deployment
This section is only intended to provide a brief overview of what is needed to plan and deploy Inline Posture in a Cisco ISE network. It is the responsibility of your network or system architect to research the issues involved in Inline Posture deployment to determine what best suits your network needs and requirements.
Before you start any planning for deploying or configuring Inline Posture for your network, you must first understand what types of Inline Posture operating modes and deployment options are supported.
Note
Inline Posture Planning Considerations
This section poses some basic questions and considerations that must be addressed by your network or system architect when planning to deploy Inline Posture nodes. Ensure that you have understood the following planning and deployment issues prior to starting any Inline Posture node configuration in a distributed Cisco ISE network deployment:
•
•
•
Note
•
•
The following topics in this section provide some basic information on Inline Posture nodes, but these topics are not intended to provide you with all the information needed to complete a comprehensive deployment plan for your network.
Choosing an Inline Posture Operating Mode
Which Inline Posture operating mode you choose largely depends on your existing network architecture. The choice you make limits many of the other configuration options you may want in your Cisco ISE deployment. Therefore, you need to fully understand each of the following primary Inline Posture operating modes:
•
•
Note
Inline Posture Routed Mode
In the routed mode, an Inline Posture node operates as a Layer 3 router and functions as the default gateway for an untrusted (outside Cisco ISE) network with its managed clients. All traffic between an untrusted and trusted network passes through this Inline Posture routed mode. The routed mode applies IP filtering rules, the configured access policies, and other traffic-based policies you have set up for your network.
When you configure an Inline Posture node in its routed mode, specify the IP addresses of its two interfaces:
•
•
The trusted and untrusted addresses should be on different subnets. An Inline Posture node can manage one or more subnets, and the untrusted interface acts as a gateway for the managed subnets. Figure 1-7 illustrates an example of an Inline Posture routed mode configuration.
Figure 1-7 Inline Posture Routed Mode Configuration
Inline Posture Bridged Mode
When operating in a bridged mode, the Inline Posture node operates like a standard Ethernet bridge. This configuration is used most often when the untrusted network already contains a gateway, and you do not want or plan to make any changes to the existing configuration.
Figure 1-8 shows the Inline Posture node acting as a bridge for the Layer 2 client traffic from the WLC into the Cisco ISE network. While in this configuration, the Inline Posture node requires subnet entries for the subnets to be able to respond to and send ARP broadcasts to the correct VLANs.
The Layer 2 flow of traffic from the three example subnets (10.20.80.0/24, 10.20.90.0/24, and 10.20.60.0/24) all reflect the use of the bridged mode on the Inline Posture node using VLAN mapping. The only difference between the three subnet examples is that for the 10.20.60.0/24 subnet, the Inline Posture main interfaces reside within this subnet.
Figure 1-8 Inline Posture Bridged Mode Configuration
Deploying Inline Posture as Standalone or High Availability
The most important decision you may make about your Inline Posture deployment is whether to deploy it as a single, standalone Inline Posture node, or as a primary-secondary pair to ensure high availability and provide redundancy for network reliability.
A standalone Inline Posture node is a single Inline Posture node that provides Inline Posture services, while working independently of all other nodes in your Cisco ISE network. You may decide to deploy a single standalone Inline Posture node for a network that serves a smaller facility or for a small network where network redundancy is not a major concern.
When you configure a pair of Inline Posture nodes for high availability, they act as primary-secondary pair to provide additional redundancy and reliability. This primary-secondary pair ensures that your network continues functioning even if one node in the pair fails. If the primary node fails, the secondary node takes over and provides the needed Inline Posture functionality.
About Inline Posture High Availability
Inline Posture high availability consists of two Inline Posture nodes that are configured as a primary-secondary pair. In this configuration, the primary node acts as the RADIUS proxy and forwards all network packets. If the primary node fails, the secondary Inline Posture node in this pair takes over.
In an Inline Posture stateless high-availability deployment that has a primary-secondary pair configuration, the secondary node acts as a backup unit and does not forward any packets between the interfaces. Stateless means that sessions that have been authenticated and authorized by the primary node are automatically authorized again once a failover occurs.
The secondary node monitors the primary node using the heartbeat protocol (on the eth2 and eth3 interfaces). The heartbeat protocol requires that messages are sent at regular intervals between the two nodes. If the heartbeat stops or does not receive a response back in the allotted time, failover occurs and recovery action takes place.
When the heartbeat protocol is active in an Inline Posture high-availability configuration, it requires a network connection between the eth2 and eth3 interfaces of the Inline Posture primary-secondary pair. The eth2 and eth3 interfaces of each node in an Inline Posture high-availability pair (primary and secondary) are configured to use heartbeat protocol exchanges between the two nodes. For this reason, you must make a direct cable connection between the eth2 interfaces of both Inline Posture nodes, and likewise, there must also be a direct cable connection between the eth3 interfaces of both nodes to ensure redundancy.
Note
Figure 1-9 Heartbeat Protocol: eth2 and eth3 Interface Ethernet Cable Connections
Feedback