View Source and destination ports on netflow flows

I'm not really sure I understand the complete question.

The Top XX conversations section in most of the NTA pages will not show protocols and application ports by default. You could add those to that view once you narrow down the conversation you want to look at. Source and Destination in one flow will only show one protocol. Lets say 10.199.25.10 to 10.199.25.9 is one conversation in one flow direction which will give you port information used. From the summary page you should be able to include all conversations you would like to see from the Flow Navigator:

Use NetFlow Flow Navigator - SolarWinds Worldwide, LLC. Help and Support

The problem is that when ik look at a single flow I only see the Protocol. Cause how does Solarwinds determine what is the protocol? on a flow that has a Source ip of 10.10.20.20 and source port TCP/4523 and a destination IP of 172.16.25.53 and destination port of TCP/4224

Which of these normally not monitored ports will NTA choose as the protocol for that flow? and can i build a view that shows me both the source and destination ports ??

Anybody??

The way Scrutinizer chooses what application to register a flow under is by looking at the source and destination ports, of the bat it will choose the lowest of them, but it also checks its "well known port repository"(it is called monitored ports i NTA) and if the lowest port is not in the  "well known port repository" but the high port is, it will show the high/source port as the Application for the flow.

We are running a lot of software that is using some rare ports, and when I tested Scrutinizer and monitored one single device, it seemed like that device was communicating on 3600+ applications!! I Then found out how the application is defined and realized that Scrutinizer was showing every source port that was present in its  "well known port repository".

After I i registered the real destination port in the  "well known port repository" the device started communicating on only one port.

I am curious how this is done on NTA as I am unable to find a view where I can see a flow complete with Source port, source IP, destination ip and destination port.

Hope somebody can help

Regards Jens 

Many applications require the use of a wide range of source ports, but only one single destination port.  Based on that, Netflow can look at the destination port and compare and correlate it with a list of applications known to use only that destination port.

While on the other hand, looking at source ports is a much more daunting challenge, given virtually every application on the Internet accepts traffic from ports 1024 through 65535.

We write customizations for in-house apps that MAY require a specific source port to tie directly to a specific destination port.  It saves having to assign multiple IP addresses for application servers--many applications can be hosted on one server without that server (and app) being required to have yet another dedicated IP address.  It makes it easier when DNS resolves to one IP address, and the app defines when a flow must include a specific source port and destination port.

Given how many systems were built to accommodate many incoming (or outgoing) requests for access to a specific port (let's say port 80 for fun), and also given how NAT/PAT through firewalls lets companies make all of their traffic look like it's coming from one source IP address, it makes sense for the web applications to keep track of the many sessions using two identifiers:  Source IP address and source port.  The port is used to associate a flow with one session. 

Does this help you understand why your more specific request for tracking source AND destination ports has fallen through the cracks?  Your request isn't invalid.  It's simply something that designers and programmers didn't think would be easily accommodated because they wrote their programs to use a wide range of source ports.

So what you are saying is that no matter what NTA will choose the destination port as the application port?

The reason I am interested is that we communicate no many nonstandard ports, on some of our systems the engineer setting up the system can freely choose what port to use.

That makes it hard for me to determine if the application NTA is reporting is indeed the destination port/ application port and not a random chosen source port.

And the last software I worked with would use the source port for application port if the destination port was not in its "Application registry" which in our case was fairly often.

So the reason for me to see both source and destination port on a flow is purely to make sure that the application port for the flow is correct, since I dont know the procedure NTA uses for choosing the Application Port.

Regards Jens

Let's slightly modify your interpretation of what said: it seems that Industry engineers (perhaps including Solarwinds staff) determined how Solarwinds Netflow recognizes applications.  You'll need to read the RFC's and become familiar with Netflow, and its descendent IPFIX, before we can agree on whether source port(s) can be reliably associated with applicaitons:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiahoDtpNXZAhUDb60KHbIDDxgQFghG…

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiU9pySpdXZAhUCXq0KHfr9Ai4QFgg5…

Source port is used by the sending host to help keep track of new incoming connections and existing data streams, while destination port is typically used by the receiving host to provide access to defined applications.

Source Port, if it weren't required to be flexible (to be used across a large range of ports), could used to identify an application, but it would happen much more easily if it is associated with a single port instead of with a range of source ports.  The majority of applications I work with do not limit themselves to a single source port.  instead, they use a wide range of source ports--many use any TCCP port from 1024 to 65535.

These same applications DO frequently target a single destination port, or a small range of destination ports.

Understanding why many different applications require the use of a wide range of source ports goes with the idea of thousands (or millions) of source devices initiating requests across the Internet.  Using ranges lets firewalls and servers separate individual flows and assign them to individual source devices that make the requests.  It's why/how NAT/PAT work, and really needs to be understood before someone can define which application MUST be running if source port X and destination port Y are discovered.

Although 65535 ports are a lot, they're not enough to ensure every app has its own unique signature.  Other apps MUST be allowed to use the same source ports, and occasionally people write new apps that require destination ports previously reserved for specific apps, and this causes complications when trying to identify what an app is based on its ports.

Now, with so many overlapping source & destination ports, it makes more sense to dig more deeply into the traffic flow and analyze the traffic patters to discover the most likely app running over a given set of ports. Read the RFC's to see how Netflow and IPFIX work, and to learn if what you need can be made to happen.

Then work with Solarwinds Technical Support to see if they can help you adjust NTA to better identify apps based on your needs.

And let us know what you learn.  I think many folks here could leverage the kind of functionality you want.

I am well aware of the meaning of source ports. I only pointed out that some Flow applications can in some situations assign the application to the source port.

Witch is rather stupid given that the source port nearly never defines the application.

But I think I have found it out my self, and is doesn't seem like there is any source assignments in my installation

Regards Jens