Here is a question that often gets asked regarding defining applications in Scrutinizer v6.X. In order to follow this discussion, you need to understand that every packet has a source and destination port.

Q: If I have tcp/5678 as the socket on one side of the flow, and tcp/1234 on the other… How do I tell Scrutinizer that I’m interested in the fact that it’s tcp/5678 and I don’t really care about tcp/1234?

In order to answer this question, it might be best that I explain Scrutinizer’s logic by digressing on how Scrutinizer v6 and v7 deal with the issue.

Scrutinizer v6.X:
The collector will look at both ports (5678, 1234) and perform the following logic:
– Which port is lower: 1234! Is it labeled (e.g. http)?
– Yes: save it as the common port (1234) else,
– Is 5678 labeled?
– Yes: save it as the common port (5678) else,
– Save 1234 as the common port
– Note: if both were labeled, it would have gone with the lower port.

Does the above make it clear? Basically, you have to remove the label on port 1234 to force Scrutinizer to use 5678.

Scrutinizer v7.0:
The collector will use more logic. The steps above are still used, but we added a nice feature. Let’s say you want a certain range of ports matched up with a range of IP addresses to be labeled as an application (e.g. Citrix). You can do this as well. Basically, 5678 may not be saved as the common port, but it will be saved as an application because either the source or destination IP address was identified as part of an application.

There is a screen capture of  the v7 interface in the “Sneak peak of Scrutinizer v7” blog post. Scroll down to the section on “Define Application Groups”.

applicationgroups

Does this help: How can we improve it for your company?

Mike Patterson author pic

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related

Leave a Reply