Submit a ticketCall us

Get a crash course on Network Monitoring delivered right to your inbox
This free 7-day email course provides a primer to the philosophy, theory, and fundamental concepts involved in IT monitoring. Lessons will explain not only how to perform various monitoring tasks, but why and when you should use them. Sign up now.

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

Breaking down sFlow packet in Wireshark

Table of contents
Created by Brian O'Donovan, last modified by Steven Bansil_ret on Jul 11, 2016

Views: 985 Votes: 4 Revisions: 3

Updated: July 11, 2016

Overview

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

Environment

All versions of NTA

Steps

 

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.

SysUptime

Time in milliseconds since the router last rebooted.

NumSamples

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:
http://www.sflow.org/developers/diagrams/sFlowV5Sample.pdf

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

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

Protocol

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

ToS

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:  http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml

 

 

Last modified
00:06, 11 Jul 2016

Tags

Classifications

Public