Hi there guys! Great news this week. We’ve decided to start beta for the first phase of our NetFlow migration tool.
With this simple tool, we’ll be able to take all your NetFlow v5 records you collected from Scrutinizer v6 and be able to migrate them over to the new Scrutinizer v7 format.

We’re going to start this migration test one bite at a time, since your archived NetFlow and sFlow database integrity is important to us.

I’ve seen some really incredible Network Topology maps out there and I’m sure there was significant time invested to make them that way. So lets start out by making life easier and let our network traffic map migration tool move them over for you!

If you’d like to volunteer and help me beta test the migration, I would love to help.
Call our customer support desk at (207) 324-8805 ext. 4 and we can schedule a time to get things going.

PS: The migration BETA is for the Flash maps only. The google map integration needs a few more tweeks. We will be announcing the release of the full database migration tool at a later date once internal testing has come to a completion.

We’ve just about finished it. The dust is beginning to settle here in the office and we’re now left looking at this new product we’ve made…and we LOVE it. With the release of Scrutinizer v7 pending, we thought that now would be a good time to tell you all the cool things you will be able to do in this version that is unique to this release.

Over the next five weeks or so, we’ll be showing you some fantastic new features that will demonstrate how serious we are about customer feature requests and feedback. These features are included because of you. We hope you enjoy them.

Read more »

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”.

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

Michael Patterson
Scrutinizer Product Manager