Design Guide
Cisco Secure User Registration Tool
Version 2.0
The purpose of this design guide is to describe how the Cisco Secure User Registration Tool can be designed to work successfully. Additionally, this document will make reference to specific networking practices that can significantly impact a Cisco Secure User Registration Tool deployment. The following network prerequisites are essential building blocks before deploying Cisco Secure User Registration Tool.
The following is recommended:
- Network design should adhere to a standard multi-layer design with a core, distribution and access layer.
- Trunking and Virtual Trucking Protocol (VTP) Services are deployed to allow multiple VLANs per access switch with at least 1 login and 1 authorized VLAN per VTP domain.
- VTP domains are deployed on a building or geographic basis and separated by a router.
- Dynamic Host Configuration Protocol (DHCP) deployment is stable and operational.
- Domain Name System (DNS) service is stable and operational.
- IP Connectivity exists between the URT components in the network.
- Microsoft has been consulted for best practices for deploying in Microsoft environments
- Network Security Policy—for intranet network traffic enforcement.
- Entire network is stable and operational.
Figure 1 depicts a sample multilayer network design model.
Figure 1: Network Design Model
Introduction
Figure 2 illustrates the most common deployment of the Cisco URT. In this scenario, the network has a cluster of Cisco Catalyst® switches, one Cisco URT administrative server, two VLAN policy servers (VPSs), one VTP domain, and one Primary Domain Controller (PDC) Windows NT/2000 domain. This is sufficient for a small network of up to 4,000 switch ports or users that will have little to no growth. The actual number of Cisco Catalyst switches will vary depending on their port density. For this small network, two VPSs have enough capacity to provide full redundancy; the loss of one VPS will not affect the ability of the Cisco Secure URT system to process user logins. If redundancy is a concern, a third VPS could be deployed as a hot standby in the event both primary and secondary VPSs are down. The details of switch-to-VPS distribution, redundancy, and expanded deployment designs will be discussed later in this guide.
Figure 2: Common Deployment of the Cisco Secure URT
The Cisco Secure URT will function well and scale up to 500,000 switch ports based on the following key components: scaling, load balancing, and redundancy. All three of these components should be considered of equal importance when implementing the Cisco Secure URT.
Scalability
The following recommendations provide guidelines on how to scale the components of the Cisco Secure URT as networks grow. One Cisco Secure URT administrative server can handle a maximum of 500,000 users logins and up to 100 VPSs. One of the key parameters of the Cisco Secure URT is how many user logins can be processed. This guide relates user logins to a single switch port. This is a fair assumption because the Cisco Secure URT works only in environments in which one client or PC is attached to a switch port. One VPS can handle a maximum of 5,000 switch ports or user logins.
Table 1 shows the scaling limits of a VPS. The chart has a dual purpose: to introduce the concept of scaling based on the maximum number of switch ports a VPS can handle and to explain why not to deploy a VPS without considering current port-count requirements and future growth needs.
Table 1: Scaling Limits of VPS
| Maximum ports per VPS | Headroom | Recommended Operational Ports |
|---|---|---|
|
5,000 |
20% |
4,000 |
At 100 percent capacity, a VPS can handle as many as 5,000 switch ports. Cisco recommends that you plan for 80 percent capacity and reserve the remaining 20 percent for growth (listed as headroom in the chart). This will be referred to as the 80/20 rule.
Table 2 shows examples of the maximum number of ports for different types of Cisco Catalyst switches. One of the issues that cannot be overlooked in scaling the Cisco Secure URT is that the scaling parameters of the VPS are based on switch ports while the graphical user interface (GUI) only refers to the switch level. This chart is useful in estimating the number of ports per switch and determining how many switches to deploy per VPS. An assumption is made that 90 percent of the ports will be in use. The average port usage should be modified based on port density of actual deployed switches.
Table 2: Maximum Number of Ports in Cisco Catalyst Switches
| Maximum number of ports | Average percentage used | Average number of ports used | Switches per VPS pair | |
|---|---|---|---|---|
| Catalyst 6506 |
248 |
90% |
223 |
18 |
| Catalyst 6509 |
384 |
90% |
346 |
12 |
| Catalyst 6513 |
576 |
90% |
518 |
8 |
| Catalyst 5505 |
96 |
90% |
86 |
46 |
| Catalyst 5500 |
288 |
90% |
259 |
15 |
| Catalyst 4003 |
80 |
90% |
72 |
56 |
| Catalyst 4006 |
240 |
90% |
216 |
19 |
| Catalyst 3524 |
24 |
90% |
22 |
185 |
| Catalyst 3548 |
48 |
90% |
43 |
93 |
| Catalyst 2924 |
24 |
90% |
22 |
185 |
For example, the average number of used ports in a fully configured Cisco Catalyst 6506 Switch is 223. This gives you a guideline on how to calculate the number of switches you can deploy per VPS pair (primary and secondary). This is calculated by dividing the operational ports per VPS (4,000) by the average ports per switch (223). In this case you can deploy 18 Cisco Catalyst 6506 switches per pair of VPSs. This will allow for growth of ports per switch and additional switches. If your environment deploys mixed switch types, take that into account when determining the number of switches per VPS. Keeping records of this data is an important administration function that needs to be done outside of the Cisco Secure URT. This will become extremely important when taking into account load balancing, which is addressed later in the guide. Understanding how to distribute switch-to-VPS assignments is explained later in this guide as well.
The last scaling considerations in a Cisco Secure URT design are the protocols used to communicate between the Cisco Secure URT components and how they are affected by the network infrastructure. Figures 3, 4, 5 and 6 show the port numbers used and the direction flow of the protocols.
Figure 3: VPS to Administrative Server
Figure 4: Cisco Secure URT Client Module to VPS
Figure 5: VPS to Switch
Figure 6: Administrative Server to Switch
The Cisco Secure URT was designed to operate in a LAN environment. Although it is technically possible to deploy the Cisco Secure URT across a WAN, considerations for bandwidth, latency, and the reliability of the WAN must be considered.
Cisco Secure URT protocols are not bandwidth-intensive but are event-driven with predefined intervals for communication. The only material impact that Cisco Secure URT protocols may have on network traffic is the event logging between the Cisco Secure URT administrative server and the VPS if it is enabled. This could be significant during the morning sign-on rush when a majority of users log in or during VPS failover and fail-back. This could potentially saturate a slow-speed WAN.
In addition, a WAN can introduce latency when Cisco Secure URT protocols compete with routing protocol updates and various other traffic types that share the same bandwidth to establish communications. This will adversely affect the length of time it takes to complete the logon process from start to finish.
Finally, because the Cisco Secure URT is critical for the successful operation of the network, a WAN infrastructure must be reliable. The Cisco Secure URT is not designed to operate long term with any of its components offline.
To summarize the WAN concerns, the Cisco Secure URT administrative server (protocols in Figures 3 and 6) can be separated from the other components over a WAN, if redundancy over the WAN is reliable. If the WAN link is down (or the administrative server is down), the VPSs process logins and will locally store the history and log information. The Cisco-URT-client-to-VPS and the switch-to-VPS communications (Figures 5 and 4) are critical for successful login processing and should be contained within the same Layer 2 switch domain and local IP subnet.
Load Balancing
Load balancing the number of ports per VPS is important because it provides a lighter operational load on each one and reduces the number of ports to reassign during a VPS failover. Table 3 is an extension of Table 1. It shows how you would load balance 5,000 switch ports over two VPSs. The 80/20 rule recommends using 4,000 operational ports. By load balancing these ports across two VPSs, the actual operational load will only be 40 percent on each VPS or 2,000 operational primary ports.
Table 3: Scaling Limits of Redundant VPS
| Maximum Number of Ports | Headroom | Recommended Operational Ports | Primary Ports | Secondary Ports |
|---|---|---|---|---|
|
5,000 |
20% |
4,000 |
2,000 |
2,000 |
In the event a switch's primary VPS fails, the secondary VPS will have sufficient capacity to handle the additional load and still be at the recommended number of operational ports. Currently there is no way to automatically load balance switches per VPS. To implement load balancing (and redundancy) you will have to manually configure this using the GUI on the Cisco Secure URT administrative server on a per-switch basis (Figure 7).
Figure 7: URT Administration GUI
From the GUI, each switch can be configured so that separate VPSs can be designated a role of primary, secondary, or tertiary (the second "secondary" in the GUI). You can visually see the relationship between a switch and the assigned VPSs. To equally load balance the switch-to-VPS ratio, the network administrator will have to manually keep a record of the switch-to-VPS assignment, their designated roles, and the count of ports per switch. This can be done using a spreadsheet with simple calculations. It is imperative to keep good records to ensure that ports are properly load balanced between VPSs. An example is provided in Calculation Examples section.
Failover and Recovery
Figure 8 illustrates a scenario with multiple VPSs, one domain controller, and one administrative server in a single VTP domain. The design has the switch-to-VPS configuration load balanced so each VPS is servicing only 40 percent of its login capacity. VPS Y at the bottom of the diagram is a hot standby for all the switches and provides an additional layer of redundancy in the event a switch loses its primary and secondary VPS. This scenario allows for a minimal number of affected switch ports while retaining full redundancy. This is beneficial because it reduces the potential amount of reconfirmation messages and log messages generated. If you use a failover model with a loaded primary and empty secondary VPS, the full load of a VPS would need to failover, taking longer and causing double the amount reconfirmations and log entries as in a load-balanced scenario.
Figure 8: Cisco Secure URT Design with Redundancy and Load Balancing
To describe the scenario in Figure 8, in the event that the primary VPS (VPS 1) fails for Switch Group 1, the secondary VPS (VPS 2) would take over and service the logins. The secondary VPS (VPS 2) would now be operating at 80 percent capacity because it is processing logins as the primary VPS for Switch Group 2 as well as the secondary VPS for Switch Group 1. VPS 2 would continue to service clients in Switch Group 1 until VPS 1 comes back online. The fail-back is automatic once VPS 1 is online. For optimal recovery times is it suggested that the management interface for the switches and associated VPSs servers be within the same Layer 2 domain and be on the same local IP subnet.
The following scenarios explain the failure steps in detail:
Figure 9 illustrates what happens when the primary VPS fails.
1. Before failure, "keep alive" packets are constantly sent between the VPSs.
2. When the primary VPS fails, keep-alive acknowledgements stop being received by the secondary VPS.
3. The secondary VPS sends a reconfirm message to the switch.
4. The switch then sends a reconfirm packet out to all the VPSs configured in order of primary, secondary, and tertiary.
5. One of the VPSs will acknowledge the reconfirm back to the switch; in this case it is the secondary VPS.
6. Once the switch receives the acknowledgement from the secondary VPS, it reconfirms every active dynamic port to verify the Media Access Control (MAC) address to VLAN mapping. This generates log messages from the secondary VPS to the Cisco Secure URT administrative server for each port that is reconfirmed if logging is enabled.
7. The switch marks the secondary VPS as active and starts using it for all further login requests.
8. The secondary VPS notifies all other VPSs that it is now the active VPS for the switch.
Figure 9: VPS Failure Scenario
Figure 9 also illustrates what happens when the primary VPS comes back online.
A. Every five minutes, the switch will send a reconfirm message to the configured primary VPS to see if it is online.
B. When the primary VPS is available, it will respond to the switch, re-establish ownership of the switch, and proceed from Step 6, including re-verifying all the dynamic switch ports and logging the events.
Note You cannot manually re-establish ownership from the secondary to the primary VPS from the command-line interface (CLI) using the reconfirm command. The CLI command causes the switch to reconfirm with its currently active VPS—in this case, the secondary VPS if the primary is not online.
Figure 10 illustrates what happens when a Cisco Secure URT client logs in while the primary VPS is offline.
1. The Cisco Secure URT client logs in to the NT/2000 domain controller on the login VLAN.
2. The logon script from the NT/2000 domain controller is processed, including the URT .BAT file.
3. The Cisco Secure URT client attempts to log in to the primary VPS but receives no response. (The primary VPS is learned when processing the Cisco Secure URT login script.)
4. The Cisco Secure URT client sends discovery packets to all known VPSs. The list of VPSs is learned from processing the Cisco Secure URT login script.
5. The currently active VPS (in this case, the secondary VPS) will respond to the Cisco Secure URT client discovery. This is possible because all the VPSs for a switch know which one is currently active, and only the active VPS will respond.
6. The Cisco Secure URT client logs in to the secondary VPS and proceeds as normal.
Figure 10: Client Login to a Failed VPS
Calculation Examples
The deployment cannot be successfully planned until you consider all the scaling, load-balancing, and redundancy characteristics of the Cisco Secure URT. Here is an example of how to calculate the deployment for a network with about 7,000 users and Cisco Catalyst 4006 switches as the access switches. The assumption is only one VTP domain:
- 7,000 users on Cisco Catalyst 4006 switches is about 33 access switches (7,000 users/ports divided by 216 ports per switch)
- 7,000 switch ports would require 3.5 VPSs or four VPSs, plus one additional VPS for hot standby (7,000 ports divided by 2,000 ports per VPS)
- Distributing 33 switches among four VPSs allocates 8.25 switches per VPS. Realistically, you should assign eight switches each to three VPSs and nine switches to the fourth. This is acceptable because nine switches multiplied by 216 ports equals 1,944 ports. This is still fewer than the recommended 2,000 operational ports per VPS. (33 switches divided by four VPSs)
Table 4 summarizes these results. It is best to use one spreadsheet and to keep all the calculations and summary tables in one place for record-keeping. Creating a table like this makes using the Cisco Secure URT GUI for VPS-to-switch assignments faster and less error-prone. As networks grow, periodically audit the port-to-switch-to-VPS allocation to be sure they remain load-balanced. Failing to maintain proper load balancing can lead to failover scenarios when a VPS becomes overloaded.
Table 4: Switch to VPS Assignment Table
| VSP 1 | VPS 2 | VPS 3 | VPS 4 | VPS 5 | |
|---|---|---|---|---|---|
| Switch 1 to 7 |
PRI |
SEC |
SEC2 |
||
| Switch 8 to 15 |
PRI |
SEC |
SEC2 |
||
| Switch 16 to 23 |
PRI |
SEC |
SEC2 |
||
| Switch 24 to 33 |
SEC |
PRI |
SEC2 |
Supported Network Configurations
Figure 11 shows one Cisco Secure URT administrative server, multiple VTP domains, and multiple (PDC)
NT/2000 domain controllers. The number of (PDC) NT/2000 domains that can be supported is equal to the Microsoft-recommended maximum. Based on a good multilayer design, the VTP domains would be connected (and separated) by a Layer 3 core.
Figure 11: Typical URT Configuration
In this case, you would calculate the switch-to-VPS assignment just as in the example above (Figure 11), but you would make a separate calculation per VTP domain. From a Cisco Secure URT perspective, the network would scale up the limits of one Cisco Secure URT administrative server supporting up to 500,000 ports and 100 VPSs.
As of Cisco Secure URT Version 2.0 you cannot deploy more than one Cisco Secure URT administrative server per (PDC) NT/2000 domain. However, you can have multiple (PDC) NT/2000 domains per Cisco Secure URT administrative server as shown earlier. The only exception is when the (PDC) NT/2000 domains are separated by a router boundary and the users on either side of the router boundary will not be sharing resources and using the same user ID. This implementation must be treated as two separate installations of the Cisco Secure URT as shown in Figure 12.
Figure 12: Multiple URT Administrative Servers Configuration
To support a design in which a user exists in two different NT/2000 domains and there are two Cisco Secure URT administrative servers (Figure 12), the network administrator would need to:
1. Maintain separate Cisco URT-user-to-VLAN mappings,
2. Deploy a customized Cisco Secure URT login script for each respective (PDC) NT/2000 domain controller for both (PDC) NT/2000 domains, and
3. Prevent the Cisco Secure URT administrative server from discovering the (PDC) NT/2000 domains across the WAN. This is necessary because one Cisco Secure URT administrative server will automatically create/update the URT.BAT login scripts referencing the VPSs it controls but not the VPSs controlled by the other Cisco Secure URT administrative server. Creating a design to work in this environment is beyond the scope of this guide.
With the exceptions above (separate Cisco Secure URT installations or a custom-engineered solution), the design in Figure 12 is not a supported environment as of Cisco Secure URT Version 2.0.
Performance Testing Results
The test environment consisted of a switch simulator that can support a maximum of 500 ports. The data was based on that limitation, but could scale to a much larger simulated environment to support the maximum average 1,000 switch/logins every 60 seconds up to 5,000. The engineering performance results used actual XML configuration data as a source for this case study. The criteria used to assemble the data points were based on the maximum number of switch/port logins the VPS server could handle and users login activity over a period of time. The data source was collected between 8:00 am and 9:30 am, a peak period for login activity for most corporations.
"Real World" Expectations
Figure 13 below shows an average, sustainable throughput of 12 logins per second for a continuous stream of 500 login sessions. It is important to note that 500 sessions is not a limit of the VPS server, but the limit of the number of ports that the switch simulator supported. URT was able to process 250 logon sessions in the less than 10 seconds, and 1000 logon requests produced a logon delay of less than 10 seconds.
Figure 13: Throughput vs. Active Sessions per Second
Stress Test Environment
This stress test was designed to overrun the VPS server, but the results show the VPS server was able to successfully process the 5,000 login requests without failure. During the stress testing, it was found that as the number of login requests approached 5000 user requests, the logon delay reached 250 seconds. This is not a concern here, because the VPS server would never receive that many requests without first factoring other external elements outside of URT (DHCP, NT/2000 controller etc.). In reality, 5,000 users would not be logging in simultaneously, but would log in over a much broader time period.
MAC Address to VLAN Associations
Another option to user login for VLAN port assignments is to use client system MAC address to assign the system to the appropriate VLAN. Testing has show that there is a direct correlation between the number of VLAN-to-MAC-address associations and the performance of the VPS appliance. This is due to the memory available on the VPS and its ability to handle JAVA. Currently, the VPS has a ceiling of 512 kilobytes of JAVA memory usage. Exceeding this limit will over stress the system. For optimum performance, the VPS should not exceed 490 kilobytes of JAVA memory usage.
VLAN-to-MAC-address associations are directly proportional to the number of VTP domains handled by URT. This can be easily calculated by the following formula: #VLAN/MAC associations = #MAC addresses X #VTP domains
Figure 14: Region of optimum number of MAC addresses to VLAN associations per number of VTP domains
Figure 14 represents the results of tests using the above formula. Testing has shown that the limit is 175,000 VLAN/MAC address associations. This is represented by the green region in Figure 14. This region is the where the number of VTP domains times the number of MAC addresses does not exceed 175,00, which will keep the JAVA memory usage at or below the 490 kilobytes mark. The maximum number that will push the JAVA memory usage to the 512 kilobytes maximum is 250,000 VLAN/MAC address associations. This is represented by the yellow region in Figure 14. A maximum of 35 VTP domains was tested.
For a more accurate and useful correlation of the number of MAC addresses that can be safely used for a given number of VTP domains is provided in Table 5. Using this table, the network administrator can easily determine the number of VPS systems necessary to administer MAC address to VLAN associations.
Table 5: Number of MAC addresses number of VTP domains
| # VTP Domains | Optimum # MAC Addresses | Max # MAC Addresses |
|---|---|---|
|
1 |
175000 |
250000 |
|
2 |
87500 |
125000 |
|
3 |
58333 |
83333 |
|
4 |
43750 |
62500 |
|
5 |
35000 |
50000 |
|
6 |
29167 |
41667 |
|
7 |
25000 |
35714 |
|
8 |
21875 |
31250 |
|
9 |
19444 |
27778 |
|
10 |
17500 |
25000 |
|
11 |
15909 |
22727 |
|
12 |
14583 |
20833 |
|
13 |
13462 |
19231 |
|
14 |
12500 |
17857 |
|
15 |
11667 |
16667 |
|
16 |
10938 |
15625 |
|
17 |
10294 |
14706 |
|
18 |
9722 |
13889 |
|
19 |
9211 |
13158 |
|
20 |
8750 |
12500 |
|
21 |
8333 |
11905 |
|
22 |
7955 |
11364 |
|
23 |
7609 |
10870 |
|
24 |
7292 |
10417 |
|
25 |
7000 |
10000 |
|
26 |
6731 |
9615 |
|
27 |
6481 |
9259 |
|
28 |
6250 |
8929 |
|
29 |
6034 |
8621 |
|
30 |
5833 |
8333 |
|
31 |
5645 |
8065 |
|
32 |
5469 |
7813 |
|
33 |
5303 |
7576 |
|
34 |
5147 |
7353 |
|
35 |
5000 |
7143 |
Note This limitation of MAC address to VLAN associations will be further relaxed in the next release of URT.
Conclusion
The Cisco Secure URT is a powerful tool for network user authorization and port-level access in a LAN environment. Like any part of a network that is critical for operations, care must be given in the design of the Cisco Secure URT components. This guide addressed the key issues of scaling, load balancing and redundancy. The importance of carefully planning the load of switch ports per VPS, documenting the results, and maintaining this during growth should not be overlooked. Combining these ideas with a good multilayer network design and the necessary services need for a successful Cisco Secure URT deployment (DNS, DHCP, and security) will provide a high-performance solution for networks requiring port-level access security by user ID.