We are migrating from DCRUM 12.04 to 2017 May SP4 currently running on parallel infrastructures. However the number of operation counts are not matching up. After excluding the "SSL connection Hello*" and "Encrypted data exchange", the resulting http URLs are approx 1/3 less than 12.04 versions counts. I have compared the software services configuration and setup parameters, but nothing looks different. Any thoughts?
Solved! Go to Solution.
Please find the below documented informaiton.
Review the below link for the changes in the current release.
I am not sure i follow your answer @Babar Q. The post states that even after excluding the SSL Handshake data they are still seeing 1/3 the number of URLs. I am facing a similar issue (even though i am not able to compare to my 12.4 upgrade). I am looking at a pure count of operations against a software service. The service is using the HTTPS analyzer and we have an RSA key to decrypt the traffic. There are multiple different ciphers being used and some are Diffie-Hellman so i understand that we won't be able to see all details about all requests. However, if i just do a simple operation count during a specific hour and compare that to IIS log entries, i am seeing approx. 1/3 less traffic hitting DCRUM.
1.Does your answer above apply to my situation?
2. What are best practices for troubleshooting this type of discrepancy?
Hello @Graham D.
I would recommend to have a look on the below links for better understanding SS decryption.
Hello @Babar Q.,
Sorry for the misunderstanding, my issue is not with the decryption (i don't think). I expect that some of my traffic will continue to be encrypted because it is using Diffie-Hellman. What i can't explain is why the TOTAL count of operations is so far off from what i can see in other tools. I fully understand that this may not be a DCRUM problem and was hoping to get some guidance on how to remove DCRUM as the cause of the issue. If i can prove that DCRUM is not the cause of the missing data then i can better navigate the other possible causes.
Hey @Babar Q.,
We are not showing any dropped packets (0% for both types). We have around a 4% sequence gap rate and during our health check we were told that is acceptable. However, i don't think we are set to SPAN bidirectional and i am inquiring about those settings now. Can you give me a quick explanation on why that is needed? I am not a networking engineer and my simple understanding is that data flows 1-way into DCRUM (not bidirectionaly).
Also, thank you very much for your responsiveness.
Hello @Graham D.
Basically bi-directional is to solve the unidirectional traffic which indicates that the NAM Probe cannot reliably monitor and analyze traffic, such that a significant portion of user sessions is not included in performance analysis.
Have a look on the below link for more insight.