cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2509
Views
5
Helpful
2
Replies

Dynamic Variable Scalability

paul
Advocate
Advocate

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:

  1. Department code
  2. Switch
  3. Port

Then my rules simply says:

  1. Device:Version Contains Endpoint:Department Code
  2. Network Access:Network Device Name Matches Endpoint:Switch
  3. RADIUS:NAS-Port-ID Contains Endpoint:Port

So under the endpoint I can set the 3 attributes to say:

  1. HR
  2. .*
  3. Ethernet

That would allow the device to connect to any switch coded for HR on any port.

 

I can set another endpoint like this:

  1. Any
  2. IDF-1
  3. 1/0/1

To lock the device into the IDF-1 switch on port 1/0/1.

 

Just not sure how to measure scalability.

 

 

1 Accepted Solution

Accepted Solutions

thomas
Cisco Employee
Cisco Employee

@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

 

View solution in original post

2 Replies 2

Marcelo Morais
VIP Advisor VIP Advisor
VIP Advisor

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 !!!

thomas
Cisco Employee
Cisco Employee

@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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers