
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2021 08:46 AM
I have a large customer looking to leverage dynamic variables on their endpoints to lock certain endpoints into a particular department (serviced by a set of IDF), certain switches and potentially a certain port on a switch. I can do all this easily using dynamic variable matching, but the customer asked how does this scale. Do we have any data on dynamic variable performance? The majority of the matches would use the Contains logic, but I do have one doing a MATCHES (Regex).
As an example I use the version under the network device to tag it with departments serviced by that switch "HR-Legal-IT-Any". Then on the endpoint I add 3 custom attributes:
- Department code
- Switch
- Port
Then my rules simply says:
- Device:Version Contains Endpoint:Department Code
- Network Access:Network Device Name Matches Endpoint:Switch
- RADIUS:NAS-Port-ID Contains Endpoint:Port
So under the endpoint I can set the 3 attributes to say:
- HR
- .*
- Ethernet
That would allow the device to connect to any switch coded for HR on any port.
I can set another endpoint like this:
- Any
- IDF-1
- 1/0/1
To lock the device into the IDF-1 switch on port 1/0/1.
Just not sure how to measure scalability.
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2021 08:27 PM
@paul ,
First, I love your use of Endpoint Customer Attributes to solve this problem!
As you probably already know, we don't have any specific performance info for string matching using CONTAINS vs REGEX. You gave a couple great examples but I don't know how many of these you have in total. We do have some policy maximums @ https://cs.co/ise-scale to keep in mind so you don't get too crazy with the number or rules.
Attribute | ISE 2.2 Maximums | ISE 2.4 Maximums | ISE 2.6 |
---|---|---|---|
Maximum Policy Sets | 100 | 200 | 200 |
Maximum Authentication Rules | Simple Policy Mode: 100 Policy Set Mode: 200 |
Policy Set Mode: 1000 | Policy Set Mode: 1000 |
Maximum Authorization Rules | Simple Policy Mode: 600 Policy Set Mode: 700 |
Policy Set Mode: 3,000 (3200 Authz profiles) |
Policy Set Mode: 3,000 (3200 Authz profiles) |
Suggestions:
- You said you're doing this by Department ... I highly recommend assigning each Network Device with Network Device Groups (NDGs) with it's respective Department rather than repurposing the Software Version field and doing a string compare! This is exactly what NDGs were meant for!
- With NDGs in place, it may help to split some (all?!?) Departments into their own Policy Sets to branch by Network Device Group totally eliminate compares for other Departments.
- Review your Policy Set(s) Hit Counts and move the rules with the higher counts to the top for faster matching and fewer compares overall
- Shorter strings ("HR") match faster than longer strings ("Human Resources") so use shorter strings when possible without sacrificing human readability. It looks like you're doing this with HR and eliminating "GigabitEthernet" from your port name but you asked about performance so I wanted to confirm this is good!
- For rules with similar hit counts, move the first order compares with shorter strings to the top
- For timing data, look at your LiveLog Details for total authentication time to compare your different methods
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2021 04:34 PM
Hi @paul ,
I didn't find a Dynamic Variable performance/scale info, but please take a look at: TECSEC-3416, search for: Dynamic Variable Substitution (rule reduction) and Auth Policy Scale.
Hope this helps !!!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2021 08:27 PM
@paul ,
First, I love your use of Endpoint Customer Attributes to solve this problem!
As you probably already know, we don't have any specific performance info for string matching using CONTAINS vs REGEX. You gave a couple great examples but I don't know how many of these you have in total. We do have some policy maximums @ https://cs.co/ise-scale to keep in mind so you don't get too crazy with the number or rules.
Attribute | ISE 2.2 Maximums | ISE 2.4 Maximums | ISE 2.6 |
---|---|---|---|
Maximum Policy Sets | 100 | 200 | 200 |
Maximum Authentication Rules | Simple Policy Mode: 100 Policy Set Mode: 200 |
Policy Set Mode: 1000 | Policy Set Mode: 1000 |
Maximum Authorization Rules | Simple Policy Mode: 600 Policy Set Mode: 700 |
Policy Set Mode: 3,000 (3200 Authz profiles) |
Policy Set Mode: 3,000 (3200 Authz profiles) |
Suggestions:
- You said you're doing this by Department ... I highly recommend assigning each Network Device with Network Device Groups (NDGs) with it's respective Department rather than repurposing the Software Version field and doing a string compare! This is exactly what NDGs were meant for!
- With NDGs in place, it may help to split some (all?!?) Departments into their own Policy Sets to branch by Network Device Group totally eliminate compares for other Departments.
- Review your Policy Set(s) Hit Counts and move the rules with the higher counts to the top for faster matching and fewer compares overall
- Shorter strings ("HR") match faster than longer strings ("Human Resources") so use shorter strings when possible without sacrificing human readability. It looks like you're doing this with HR and eliminating "GigabitEthernet" from your port name but you asked about performance so I wanted to confirm this is good!
- For rules with similar hit counts, move the first order compares with shorter strings to the top
- For timing data, look at your LiveLog Details for total authentication time to compare your different methods
