Performance difference between "matches" and "contains" conditions

[giosif]

Hi,

In a project, we are using 802.1X with EAP-TLS and are trying to differentiate access based on certain details in the client certificate.

I am trying to understand whether we should look to have those specific details in the certificate as value of a dedicated attribute (e.g. specific SAN entry) or as part of the value of a "shared" attribute (e.g. CN contains, among others, a string we use for differentiation).

These two alternative options would translate into an authorization policy rule using as condition either "Matches" (for the dedicated attribute option) or "Contains" (for the "shared" atrribute option).

Does anyone know if there is any performance difference on ISE side between using one or the other of the above conditions?

I suspect there is no such performane difference, but can someone please confirm?

Thank you!

[Craig Hyps · Accepted solution]

No specific testing conducted on the two pattern matching options.  "Contains" is certainly more finite in terms of pattern match, so theoretically it would be possible to have a more complex string pattern using "Match", but as noted, no specific testing done to determine if any noticeable impact.

/Craig

[giosif]

Thanks, Craig!

I guess it's the same situation (i.e. no specific testing info) also for "Equals" vs "Contains", as well as for "Equals" vs "Match", correct?

Regards,

George

[Arne Bier]

I was also interested in the original question that was asked - it's certainly relevant when the AAA server is processing a heavy load.  On Cisco Prime Access Registrar I found that when creating tcl scripts to process radius packets, the choice of string comparison operator makes a difference in overall throughput.  That was due to the how tcl implemented those operations.

Doing some bulk EAP-TLS authentications in my dual PSN ISE lab revealed nothing significant, because the time to send 100 requests (using eapol_test and some python magic to generate unique Calling-Station-Id) varied between 4 and 18 seconds.  ISE must be doing all sorts of cool things in between (inter-PSN NodeGroup stuff, profiling, log de-duplication because MnT was enabled on both,  etc), and it's hard to get a sensible baseline.

There was no observable difference between Equals and Matches because of the wide range of test times returned (I used the unix 'time' command as a stopwatch for each iteration of tests).

I changed my setup to include only one PSN node, and disabled profiling.  The node only handled Services.

Results were more stable - waiting for the SSD and the CPU to quiesce, I got range of results of 4.2 - 3.8 seconds using Matches operator.

With Equals I got a range of 4.2 - 3.4 seconds

Hardly scientific - but it may appear as if the Equals operator has a slight benefit - something that would only be properly revealed by proper code profiling.  At the end of the day, in real life situations, I doubt it will make any significant difference.