What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

IPFIX channel definition question

Votes:

0

If I define channels to include certain ports, let's say one channel for port 161

  1. 161:SNMP SourcePort[161] or DestinationPort[161]

and then have a catch-all/other channel that is just for UDP

  1. 17:UDP Protocol[UDP]

will channel 17 also include the flow data for UDP port 161 or will the first definition capture it and then stop being "processed"?

definitions ipfix sensors

Created on Feb 9, 2017 4:53:50 PM



7 Replies

Votes:

0

Hi Kyle,

The channel 17 will include the traffic of the source port 161 as well. The information will be filtered per channel, not per scan. So every channel is using the same raw information.

Best regards.

Created on Feb 10, 2017 10:23:42 AM by  Dariusz Gorka [Paessler Support]



Votes:

0

Thanks. After I posted this I did some more reading in the Paessler manuals and what you say seems to conflict with this line from this document about channel definitions.

https://monitoring.ns-data.com/help/xflow_packet_sniffer_channel_definitions.htm

Because data is accounted to the first match, make sure you start with the most specific rule at the top and get less specific to the bottom.

Created on Feb 10, 2017 1:57:02 PM



Votes:

0

Hi Kyle,

Sorry, I maybe didn't made it clear. If you filter first for UDP traffic of the source port 161, then the traffic will also be displayed in the UDP-only channel but just the traffic of source port 161. If you filter first for TCP traffic and in a second channel for UDP traffic, then the UDP traffic will not be available for the second channel.

So the best way would be: Rule 1: UDP Rule 2: Source Port 161

Best regards.

Created on Feb 10, 2017 2:18:02 PM by  Dariusz Gorka [Paessler Support]



Votes:

0

Actually what I want is the opposite where the UDP-only channel is a catch-all for all the other non-specified UDP traffic I have already defined. So I have it like this.

  1. 53:DNS SourcePort[53] or DestinationPort[53]
  2. 161:SNMP SourcePort[161] or DestinationPort[161]
  3. 443:HTTPS SourcePort[443] or DestinationPort[443]
  4. 17:UDP Protocol[UDP]

Created on Feb 10, 2017 2:36:55 PM



Votes:

0

Hi Kyle,

So, if traffic is counted for a specific channel, it can't be counted again. Your definitions would work fine.

But you could change them to:

#1:DNS
Port[53]
#2:SNMP
Port[161]
#3:HTTPS
Port[443]
#4:UDP
Protocol[UDP]

Created on Feb 10, 2017 2:54:41 PM by  Dariusz Gorka [Paessler Support]

Last change on Feb 10, 2017 3:02:46 PM by  Dariusz Gorka [Paessler Support]



Votes:

0

I have this nicely loading up the channels now. But something still isn't right. Although my "Other" channel is now just a fraction of what it was, the "Other" value on Top Talkers and Top Connections is still often very high, often near 50%. I don't understand what is being represented in these "Other" categories. If a connection or conversation isn't between to IP endpoints, what else is it?

Created on Feb 13, 2017 6:50:17 PM



Votes:

0

Hi Kyle,

'Other' in the TopConnections means the summary of all entries beyond the limit (default: 100) of entries in the TopConnections-List. 'Other' in TopProtocols however most likely means a protocol which doesn't match with the protocols detectable by the Sensor itself.

Best regards.

Created on Feb 14, 2017 8:24:05 AM by  Dariusz Gorka [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.