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"?

Article Comments

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.


Feb, 2017 - Permalink

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.


Feb, 2017 - Permalink

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.


Feb, 2017 - Permalink

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]

Feb, 2017 - Permalink

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]

Feb, 2017 - Permalink

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?


Feb, 2017 - Permalink

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.


Feb, 2017 - Permalink