Dynamic Variable Scalability

[paul]

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.

[Marcelo Morais]

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 · Accepted solution]

@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