Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

Home > Success Center > Netflow Traffic Analyzer (NTA) > NTA - Knowledgebase Articles > Breaking down sFlow packet in Wireshark

Breaking down sFlow packet in Wireshark

Table of contents

Updated: July 11, 2016


This article provides steps about how to break down an sFlow packet in Wireshark.


All versions of NTA



The first thing to note about examining an SFlow trace is that Wireshark might not decode them correctly.



To see what Wireshark is decoding these packets as:

1. Right-click the packet, and choose Decode As. Make sure sFlow is selected.

2. Click OK. You should be able to use Wireshark to drill into the sFlow packets.



The example packets below show an sFlow v5 packet and an sFlow v2 packet – the “Datagram Version” on the first line of the sFlow section.



sFlow works in a very different way to the default setup of Netflow. Netflow by default will export a summary of every flow is sees on a port – sFlow will sample some of the packets traversing through the port.

sFlow Header



Datagram Version

Version of sFlow being sent by the device

Address Type

Ipv4 (1) or ipv6 (2)

Agent Address

IP Address the sFlow messages will be sent from.

Sub-Agent ID

This is unique to sFlow v5 – only sFlow v5 supports the switch/router running multiple separate sFlow agent processes. They collect, assemble and export their sFlow information separately. If the device is running multiple agent processes, each process is given a unique ID.

Sequence Number

The number of sFlow datagrams/packets  sent by the device – note how this differs from the way Netflow sequencing works.


Time in milliseconds since the router last rebooted.


Number of sFlow samples contained in the current packet

sFlow Sample


sFlow sample enterprise & type:

The Enterprise types allows individual enterprises to define thir own sample types. This is 0 by default. For example, a Foundry ACL based sample: Enterprise 1991, Format 1, includes additional fields specifically for that Foundry flow.
The Type defines the format of the sample. This includes Flow sample (type 1), Counter sample (type 2), Expanded Flow Sample (type 3) etc. Packet definitions for these sample types can be found here:

Sample Length:

Length in bytes of the sample – this includes all data about the sample from Sequence number onwards to the sampled packet or part of packet)

Sample Sequence number:

Counter value – this is incremented every time the source takes a sample.

Source ID Type:

The type of indexing used to identify the source interface. This can be SNMP inferface index (ifIndex), VLAN  ID (smonVlanDataSource),  or a physical entity (for example, the backplane = 4)

Source ID index:

Index of the source, the type of this index is defined in the ‘Source ID Type” field.

Sampling Rate:

1 in X packets are sampled (eg, above, 1 in 100 packets sampled)

Sample Pool:

Total number of packets that could have been sampled (including those that were sampled)

Dropped Packets

Number of packets dropped due to lack of resources

Input interface index:

SNMP interface index of the interface the packet arrived in from. 0 if unknown.

Multiple outputs / output interface:

For a point to point, the multiple outputs is zero, and the SNMP interface index shows the interface the packet left on.  0 if unknown.
For point to multipoint (broadcast/multicast), the first bit indicates there were multiple output interfaces, and the rest shows the number of output interfaces.

Number of records

Number of sampled records contained in the sFlow sample.

Sample Type:

Can be Header, ipv4 packet or ipv6 packet. The sample itself is contained in the sFlow Sample record (in above example, the sampled header can be seen)

Record length:

Length of the packet before it was sampled

Raw Header Sample

Header Protocol

Format of the sampled header.  Eg, Ethernet (1), Token Ring (3), FDDI (4), Frame Relay (5), MPLS (13) etc.

Frame length

Length of the frame before sampling

Stripped bytes:

Number of bytes removed by the sampling process

Header length

Number of bytes in the header sample

Header Sample

The header of the packet that was sampled

IPv4 Sample


Length of the IP packet (doesn’t include lower level encapsulation)


IP Protocol type (eg, TCP = 6, UDP = 17)

Source IP

Source Endpoint

Destination IP

Destination Endpoint

Source Port

TCP/UDP source port number

Destination Port

TCP/UDP destination port number

TCP Flags

The TCP flags set in the sampled packet


Type of Service field – We use this for the Netflow ToS graphs/data. 0x00 corresponds to the default CS0 type of service. More about Quality of Service policies can be found here:



Last modified