RFC 3176
InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks
InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks 💖
okay bestie, let's start with the title block 🎀
- Network Working Group 🧚 (the group that put this out)
- Request for Comments: 3176
- Category: Informational 🌸
- Authors: P. Phaal, S. Panchen, N. McKee, all from InMon Corp. ✨
- Date: September 2001 📅
- Obsoletes / Updates: this doc doesn't list any RFCs it obsoletes or updates 🙈
Status of This Memo ✨
this memo gives info to the internet community 💅 it doesn't specify an internet standard of any kind. distribution of this memo is unlimited 🦋
Copyright Notice 🌈
Copyright (C) The Internet Society (2001). All Rights Reserved. 💜
Abstract 💖
okay so this memo defines InMon Corporation's sFlow system 🔥 sFlow is a technology for monitoring traffic in data networks that have switches and routers in them. the big parts are the sampling mechanisms that an sFlow Agent uses to monitor traffic 👀, the sFlow MIB that controls the sFlow Agent 🎛️, and the format of the sample data the sFlow Agent sends along to a central data collector 📦
Table of Contents 🧚
1. Overview ..................................................... 2
2. Sampling Mechanisms .......................................... 2
2.1 Sampling of Switched Flows ............................... 3
2.1.1 Distributed Switching .............................. 4
2.1.2 Random Number Generation ........................... 4
2.2 Sampling of Network Interface Statistics ................. 4
3. sFlow MIB .................................................... 5
3.1 The SNMP Management Framework ............................ 5
3.2 Definitions .............................................. 6
4. sFlow Datagram Format ........................................ 14
5. Security Considerations ...................................... 25
5.1 Control .................................................. 26
5.2 Transport ................................................ 26
5.3 Confidentiality .......................................... 26
6. References ................................................... 27
7. Authors' Addresses ........................................... 29
8. Intellectual Property Statement .............................. 30
9. Full Copyright Statement ..................................... 311. Overview 🦋
okay so sFlow is a way to monitor traffic in data networks with switches and routers 🌸 the sampling mechanisms in an sFlow Agent, the sFlow MIB that's used to control that agent, and the format of sample data sent to a central data collector are all covered here ✨
the whole architecture and sampling setup is built to give continuous monitoring across a whole site, and across the whole network too 🌐 it's made for high speed switched and routed networks and it's giving main character energy 👑
the design really focuses on three things 💅
- Monitoring network traffic accurately at Gigabit speeds and higher 🔥
- Scaling so tens of thousands of agents can be managed from a single point 🧚
- Keeping the agent implementation extremely low cost 💸
the sFlow monitoring system has two parts: an sFlow Agent (which lives inside a switch or router, or in a stand alone probe) and a central data collector, also called an sFlow Analyzer 🫶
the sFlow Agent uses sampling to capture traffic statistics from the device it's watching 👀 then it sends sFlow Datagrams right away to an sFlow Analyzer so the analysis can happen 💖
this doc describes the sampling mechanisms the sFlow Agent uses, the SFLOW MIB that the sFlow Analyzer uses to control the sFlow Agent, and the sFlow Datagram Format the sFlow Agent uses to send traffic data to the sFlow Analyzer 📦
2. Sampling Mechanisms 🎀
the sFlow Agent uses two kinds of sampling 🫶 there's statistical packet-based sampling of switched flows, and there's time-based sampling of network interface statistics ⏰
2.1 Sampling of Switched Flows 🌈
okay so a flow is all the packets that come in on one interface, go through the Switching/Routing Module, and get sent out another interface 🛣️ if you've got a one-armed router, the source and destination interface can be the same one 🙈 and for a broadcast or multicast packet there might be multiple destination interfaces 📢 the sampling mechanism must make sure that any packet in a flow has an equal chance of being sampled, no matter which flow it belongs to 💜
here's how flow sampling goes 💅 when a packet shows up on an interface, a filtering decision gets made about whether the packet should be dropped 🗑️ if it isn't filtered, the switching/routing function assigns it a destination interface ✨ then there's a decision about whether or not to sample the packet 🎲 it works with a counter that goes down with each packet, and when the counter hits zero, a sample gets taken 💥 whether or not a sample is taken, the counter Total_Packets goes up, since it counts every packet that could've been sampled 📊
taking a sample means either copying the packet's header or pulling out features from the packet (check the sFlow Datagram Format section for the different forms of sample 📖) every time a sample is taken, the counter Total_Samples goes up 📈 it's a count of how many samples got generated 🧮 the sampling entity sends samples to the sFlow Agent for processing, and each sample includes the packet info plus the values of the Total_Packets and Total_Samples counters 💖
when a sample gets taken, the counter that tracks how many packets to skip before the next sample should get reset 🔄 the counter should be set to a random integer, and the sequence of random integers used over time should be such that 🎲
(1) Total_Packets/Total_Samples = Ratethere's another way to do packet sampling too 🙌 you generate a random number for each packet, compare it to a preset threshold, and take a sample whenever the random number is smaller than the threshold 🎯 how you calculate a good threshold depends on the random number generator's characteristics, but the resulting sample stream still has to satisfy (1) 💅
2.1.1 Distributed Switching 🧚
the SFLOW MIB lets separate sampling entities be linked to different physical or logical parts of the switch, like interfaces, backplanes or VLANs 🔌 each sampling engine has its own independent state (so Total_Packets, Total_Samples, Skip and Rate) 🧠 and it forwards its own sample messages to the sFlow Agent 💌 the sFlow Agent is the one that packs the samples into datagrams to send to an sFlow Analyzer 📦 iconic teamwork 🫶
2.1.2 Random Number Generation 🎲
the big thing the random number generator needs is that the mean of the numbers it makes converges to the sampling rate you need 🎯
a uniform distribution random number generator works really well 💯 the range of skip counts (the variance) doesn't really change the results much, and a variation of +-10% of the mean is enough 🙌
the generator must make sure that every number between its max and min values is possible 🌈 a generator that can only make even numbers, or numbers that share a common divisor, is unsuitable 🙅♀️
a new skip value is only needed every time a sample is taken ✨
2.2 Sampling of Network Interface Statistics ⏰
the goal of counter sampling is to efficiently and periodically poll each data source on the device and pull out the key statistics 📊
for efficiency and scalability, the sFlow System does counter polling inside the sFlow Agent 🧠 a maximum polling interval is assigned to the agent, but the agent is free to schedule the polling however it wants to get the best internal efficiency 💪
flow sampling and counter sampling were designed as one integrated system 🫶 both kinds of samples get combined in sFlow Datagrams 📦 since flow sampling sends a steady but random stream of datagrams to the sFlow Analyzer, counter samples can be taken opportunistically to fill those datagrams up 🧩
one strategy for counter sampling: the sFlow Agent keeps a list of the counter sources it's sampling 📝 when a flow sample is generated, the agent looks at the list and adds counters to the sample datagram, least recently sampled first 🥇 counters only get added if the sources are within a short period, say 5 seconds, of failing to meet the required sampling interval (see sFlowCounterSamplingInterval in SFLOW MIB) ⏳ whenever a counter source's stats go into a sample datagram, the time that source was last sampled gets updated and the source moves to the end of the list 🔁 and periodically, say every second, the sFlow Agent checks the list and sends any counters that need to go out to meet the sampling interval requirement 🚀
another option: if the agent schedules counter sampling on a regular basis, it should give each counter source a different start time (preferably random) so counter sampling isn't synchronized within an agent or between agents 🎀 no matching vibes allowed 🙅♀️
3. sFlow MIB 🧚
okay the sFlow MIB defines a control interface for an sFlow Agent 🎛️ this interface gives you a standard mechanism for remotely controlling and configuring an sFlow Agent from afar 🌟 it's the reason you can manage the whole thing without touching each device 💖
3.1. The SNMP Management Framework ❄️
okay so the SNMP Management Framework is currently made of five major components 💅
- An overall architecture, described in RFC 2571 [2].
- Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The second version, called SMIv2, is described in STD 58, RFC 2578 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [9]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14].
- A set of fundamental applications described in RFC 2573 [15] and the view-based access control mechanism described in RFC 2575 [16].
if you want the full tea on the current SNMP Management Framework, check out RFC 2570 [17] 🦋
managed objects are accessed via a virtual information store called the Management Information Base, or MIB 🧚 objects in the MIB are defined using the mechanisms defined in the SMI, so everything lines up ✨
this memo specifies a MIB module that is compliant to the SMIv2 🎀 a MIB conforming to the SMIv1 can be produced through the appropriate translations. the resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. however, this loss of machine readable information is not considered to change the semantics of the MIB 💜
3.2. Definitions 🌸
here's the big MIB module itself, the actual source of truth, so read it closely bestie 🔥
SFLOW-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises
FROM SNMPv2-SMI
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
OwnerString
FROM RMON-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
sFlowMIB MODULE-IDENTITY
LAST-UPDATED "200105150000Z" -- May 15, 2001
ORGANIZATION "InMon Corp."
CONTACT-INFO
"Peter Phaal
InMon Corp.
http://www.inmon.com/
Tel: +1-415-661-6343
Email: peter_phaal@inmon.com"
DESCRIPTION
"The MIB module for managing the generation and transportation
of sFlow data records."
--
-- Revision History
--
REVISION "200105150000Z" -- May 15, 2001
DESCRIPTION
"Version 1.2
Brings MIB into SMI v2 compliance."
REVISION "200105010000Z" -- May 1, 2001
DESCRIPTION
"Version 1.1
Adds sFlowDatagramVersion."
::= { enterprises 4300 1 }
sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 }
sFlowVersion OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Uniquely identifies the version and implementation of this MIB.
The version string must have the following structure:
<MIB Version>;<Organization>;<Software Revision>
where:
<MIB Version> must be '1.2', the version of this MIB.
<Organization> the name of the organization responsible
for the agent implementation.
<Revision> the specific software build of this agent.
As an example, the string '1.2;InMon Corp.;2.1.1' indicates
that this agent implements version '1.2' of the SFLOW MIB, that
it was developed by 'InMon Corp.' and that the software build
is '2.1.1'.
The MIB Version will change with each revision of the SFLOW
MIB.
Management entities must check the MIB Version and not attempt
to manage agents with MIB Versions greater than that for which
they were designed.
Note: The sFlow Datagram Format has an independent version
number which may change independently from <MIB Version>.
<MIB Version> applies to the structure and semantics of
the SFLOW MIB only."
DEFVAL { "1.2;;" }
::= { sFlowAgent 1 }
sFlowAgentAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The address type of the address associated with this agent.
Only ipv4 and ipv6 types are supported."
::= { sFlowAgent 2 }
sFlowAgentAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address associated with this agent. In the case of a
multi-homed agent, this should be the loopback address of the
agent. The sFlowAgent address must provide SNMP connectivity
to the agent. The address should be an invariant that does not
change as interfaces are reconfigured, enabled, disabled,
added or removed. A manager should be able to use the
sFlowAgentAddress as a unique key that will identify this
agent over extended periods of time so that a history can
be maintained."
::= { sFlowAgent 3 }
sFlowTable OBJECT-TYPE
SYNTAX SEQUENCE OF SFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of the sFlow samplers within a device."
::= { sFlowAgent 4 }
sFlowEntry OBJECT-TYPE
SYNTAX SFlowEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Attributes of an sFlow sampler."
INDEX { sFlowDataSource }
::= { sFlowTable 1 }
SFlowEntry ::= SEQUENCE {
sFlowDataSource OBJECT IDENTIFIER,
sFlowOwner OwnerString,
sFlowTimeout Integer32,
sFlowPacketSamplingRate Integer32,
sFlowCounterSamplingInterval Integer32,
sFlowMaximumHeaderSize Integer32,
sFlowMaximumDatagramSize Integer32,
sFlowCollectorAddressType InetAddressType,
sFlowCollectorAddress InetAddress,
sFlowCollectorPort Integer32,
sFlowDatagramVersion Integer32
}
sFlowDataSource OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Identifies the source of the data for the sFlow sampler.
The following data source types are currently defined:
- ifIndex.<I>
DataSources of this traditional form are called 'port-based'.
Ideally the sampling entity will perform sampling on all flows
originating from or destined to the specified interface.
However, if the switch architecture only permits input or
output sampling then the sampling agent is permitted to only
sample input flows input or output flows. Each packet must
only be considered once for sampling, irrespective of the
number of ports it will be forwarded to.
Note: Port 0 is used to indicate that all ports on the device
are represented by a single data source.
- sFlowPacketSamplingRate applies to all ports on the
device capable of packet sampling.
- sFlowCounterSamplingInterval applies to all ports.
- smonVlanDataSource.<V>
A dataSource of this form refers to a 'Packet-based VLAN'
and is called a 'VLAN-based' dataSource. <V> is the VLAN
ID as defined by the IEEE 802.1Q standard. The
value is between 1 and 4094 inclusive, and it represents
an 802.1Q VLAN-ID with global scope within a given
bridged domain.
Sampling is performed on all packets received that are part
of the specified VLAN (no matter which port they arrived on).
Each packet will only be considered once for sampling,
irrespective of the number of ports it will be forwarded to.
- entPhysicalEntry.<N>
A dataSource of this form refers to a physical entity within
the agent (e.g., entPhysicalClass = backplane(4)) and is called
an 'entity-based' dataSource.
Sampling is performed on all packets entering the resource (e.g.
If the backplane is being sampled, all packets transmitted onto
the backplane will be considered as single candidates for
sampling irrespective of the number of ports they ultimately
reach).
Note: Since each DataSource operates independently, a packet
that crosses multiple DataSources may generate multiple
flow records."
::= { sFlowEntry 1 }
sFlowOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The entity making use of this sFlow sampler. The empty string
indicates that the sFlow sampler is currently unclaimed.
An entity wishing to claim an sFlow sampler must make sure
that the sampler is unclaimed before trying to claim it.
The sampler is claimed by setting the owner string to identify
the entity claiming the sampler. The sampler must be claimed
before any changes can be made to other sampler objects.
In order to avoid a race condition, the entity taking control
of the sampler must set both the owner and a value for
sFlowTimeout in the same SNMP set request.
When a management entity is finished using the sampler,
it should set its value back to unclaimed. The agent
must restore all other entities this row to their
default values when the owner is set to unclaimed.
This mechanism provides no enforcement and relies on the
cooperation of management entities in order to ensure that
competition for a sampler is fairly resolved."
DEFVAL { "" }
::= { sFlowEntry 2 }
sFlowTimeout OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The time (in seconds) remaining before the sampler is released
and stops sampling. When set, the owner establishes control
for the specified period. When read, the remaining time in the
interval is returned.
A management entity wanting to maintain control of the sampler
is responsible for setting a new value before the old one
expires.
When the interval expires, the agent is responsible for
restoring all other entities in this row to their default
values."
DEFVAL { 0 }
::= { sFlowEntry 3 }sFlowPacketSamplingRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The statistical sampling rate for packet sampling from this source.
Set to N to sample 1/Nth of the packets in the monitored flows. An agent should choose its own algorithm introduce variance into the sampling so that exactly every Nth packet is not counted. A sampling rate of 1 counts all packets. A sampling rate of 0 disables sampling.
The agent is permitted to have minimum and maximum allowable values for the sampling rate. A minimum rate lets the agent designer set an upper bound on the overhead associated with sampling, and a maximum rate may be the result of hardware restrictions (such as counter size). In addition not all values between the maximum and minimum may be realizable as the sampling rate (again because of implementation considerations).
When the sampling rate is set the agent is free to adjust the value so that it lies between the maximum and minimum values and has the closest achievable value.
When read, the agent must return the actual sampling rate it will be using (after the adjustments previously described). The sampling algorithm must converge so that over time the number of packets sampled approaches 1/Nth of the total number of packets in the monitored flows." DEFVAL { 0 } ::= { sFlowEntry 4 }
sFlowCounterSamplingInterval OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of seconds between successive samples of the counters associated with this data source. A sampling interval of 0 disables counter sampling." DEFVAL { 0 } ::= { sFlowEntry 5 }
sFlowMaximumHeaderSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of bytes that should be copied from a sampled packet. The agent may have an internal maximum and minimum permissible sizes. If an attempt is made to set this value outside the permissible range then the agent should adjust the value to the closest permissible value." DEFVAL { 128 } ::= { sFlowEntry 6 }
sFlowMaximumDatagramSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of data bytes that can be sent in a single sample datagram. The manager should set this value to avoid fragmentation of the sFlow datagrams." DEFVAL { 1400 } ::= { sFlowEntry 7 }
sFlowCollectorAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of sFlowCollectorAddress." DEFVAL { ipv4 } ::= { sFlowEntry 8 }
sFlowCollectorAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the sFlow collector. If set to 0.0.0.0 all sampling is disabled." DEFVAL { "0.0.0.0" } ::= { sFlowEntry 9 }
sFlowCollectorPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The destination port for sFlow datagrams." DEFVAL { 6343 } ::= { sFlowEntry 10 }
sFlowDatagramVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The version of sFlow datagrams that should be sent.
When set to a value not support by the agent, the agent should adjust the value to the highest supported value less than the requested value, or return an error if no such values exist." DEFVAL { 4 } ::= { sFlowEntry 11 }
-- -- Compliance Statements --
sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 } sFlowMIBGroups OBJECT IDENTIFIER ::= { sFlowMIBConformance 1 } sFlowMIBCompliances OBJECT IDENTIFIER ::= { sFlowMIBConformance 2 }
sFlowCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statements for the sFlow Agent."
MODULE -- this module MANDATORY-GROUPS { sFlowAgentGroup } OBJECT sFlowAgentAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "Agents need only support ipv4."
OBJECT sFlowCollectorAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "Agents need only support ipv4."
::= { sFlowMIBCompliances 1 }
sFlowAgentGroup OBJECT-GROUP OBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress, sFlowDataSource, sFlowOwner, sFlowTimeout, sFlowPacketSamplingRate, sFlowCounterSamplingInterval, sFlowMaximumHeaderSize, sFlowMaximumDatagramSize, sFlowCollectorAddressType, sFlowCollectorAddress, sFlowCollectorPort, sFlowDatagramVersion } STATUS current DESCRIPTION "A collection of objects for managing the generation and transportation of sFlow data records." ::= { sFlowMIBGroups 1 }
END
okay so the sFlow MIB is totally borrowing definitions from a bunch of older RFCs, like [18], [19], [20] and [21] 💅📚
4. sFlow Datagram Format ✨
bestie, this section is where the sFlow datagram format gets its official outfit 👗🦋 It's the standard way the sFlow Agent sends its sampled data off to a remote data collector 💖
The sFlow datagram format is written up using the XDR standard [1], and honestly XDR is so much more compact than ASN.1 🫶 It's also simpler for the sFlow Agent to encode and the sFlow Analyzer to decode, which is iconic 🔥
Samples get sent as UDP packets to the host and port set in the SFLOW MIB 🌸 The lack of reliability in UDP doesn't really mess with the accuracy of the measurements you get from an sFlow Agent, so no stress 😌
- If counter samples get lost, new values just get sent during the next polling interval 🧚 An undetected counter wrap is basically impossible. The sFlow datagram uses 64 bit octet counters, and with typical counter polling intervals between 20 to 120 seconds, the odds of a long enough run of lost sFlow datagrams to hide a counter wrap are super tiny 🙈
- The net effect of lost flow samples is a slight reduction in the effective sampling rate 🍓
UDP uses less memory for buffering, which is so giving 💜 It also delivers timely traffic info during intense periods of traffic, like a denial of service attack 😭 UDP is more robust than a reliable transport here because under overload, the only real effects are a slight bump in transmission delay and more lost packets. Neither of those really hurts an sFlow-based monitoring system 💅 If a reliable transport were used instead, an overload would cause long transmission delays and need large amounts of buffer memory on the agent, and nobody wants that 💀
While the sFlow Datagram structure lets multiple samples fit in each datagram, the sampling agent must not wait for a buffer to fill up before sending the sample datagram ⭐ sFlow sampling is all about timely info on traffic, so the agent may at most delay a sample by 1 second before it is required to send the datagram ⏰
The agent should try to piggyback counter samples on the datagram stream that comes from flow sampling 🎀 Before sending out a datagram, the leftover space in the buffer can be filled with counter samples. The agent gets to decide when it polls counters, and sFlowCounterSamplingInterval is a maximum, so the agent is free to sample counters early if there's room in a datagram 🦋 If counters must be sent to satisfy the maximum sampling interval, then a datagram must be sent containing the outstanding counters 💖
Here's the XDR description of an sFlow Datagram, bestie 👑
/* sFlow Datagram Version 4 */
/* Revision History
- version 4 adds support BGP communities
- version 3 adds support for extended_url information
*/
/* sFlow Sample types */
/* Address Types */
typedef opaque ip_v4[4];
typedef opaque ip_v6[16];
enum address_type {
IP_V4 = 1,
IP_V6 = 2
}
union address (address_type type) {
case IP_V4:
ip_v4;
case IP_V6:
ip_v6;
}
/* Packet header data */
const MAX_HEADER_SIZE = 256; /* The maximum sampled header size. */
/* The header protocol describes the format of the sampled header */
enum header_protocol {
ETHERNET-ISO8023 = 1,
ISO88024-TOKENBUS = 2,
ISO88025-TOKENRING = 3,
FDDI = 4,
FRAME-RELAY = 5,
X25 = 6,
PPP = 7,
SMDS = 8,
AAL5 = 9,
AAL5-IP = 10, /* e.g., Cisco AAL5 mux */
IPv4 = 11,
IPv6 = 12,
MPLS = 13
}
struct sampled_header {
header_protocol protocol; /* Format of sampled header */
unsigned int frame_length; /* Original length of packet before
sampling */
opaque header<MAX_HEADER_SIZE>; /* Header bytes */
}
/* Packet IP version 4 data */
struct sampled_ipv4 {
unsigned int length; /* The length of the IP packet excluding
lower layer encapsulations */
unsigned int protocol; /* IP Protocol type
(for example, TCP = 6, UDP = 17) */
ip_v4 src_ip; /* Source IP Address */
ip_v4 dst_ip; /* Destination IP Address */
unsigned int src_port; /* TCP/UDP source port number or
equivalent */
unsigned int dst_port; /* TCP/UDP destination port number or
equivalent */
unsigned int tcp_flags; /* TCP flags */
unsigned int tos; /* IP type of service */
}
/* Packet IP version 6 data */
struct sampled_ipv6 {
unsigned int length; /* The length of the IP packet excluding
lower layer encapsulations */
unsigned int protocol; /* IP next header
(for example, TCP = 6, UDP = 17) */
ip_v6 src_ip; /* Source IP Address */
ip_v6 dst_ip; /* Destination IP Address */
unsigned int src_port; /* TCP/UDP source port number or
equivalent */
unsigned int dst_port; /* TCP/UDP destination port number or
equivalent */
unsigned int tcp_flags; /* TCP flags */
unsigned int priority; /* IP priority */
}
/* Packet data */
enum packet_information_type {
HEADER = 1, /* Packet headers are sampled */
IPV4 = 2, /* IP version 4 data */
IPV6 = 3 /* IP version 6 data */
}
union packet_data_type (packet_information_type type) {
case HEADER:
sampled_header header;
case IPV4:
sampled_ipv4 ipv4;
case IPV6:
sampled_ipv6 ipv6;
}
/* Extended data types */
/* Extended switch data */
struct extended_switch {
unsigned int src_vlan; /* The 802.1Q VLAN id of incoming frame */
unsigned int src_priority; /* The 802.1p priority of incoming
frame */
unsigned int dst_vlan; /* The 802.1Q VLAN id of outgoing frame */
unsigned int dst_priority; /* The 802.1p priority of outgoing
frame */
}
/* Extended router data */Okay bestie, the extended router struct is up next 🦋 It carries the next hop address plus two prefix mask counts, one for source and one for destination 💅
struct extended_router {
address nexthop; /* IP address of next hop router */
unsigned int src_mask; /* Source address prefix mask bits */
unsigned int dst_mask; /* Destination address prefix mask bits */
}/* Extended gateway data */ ✨ Now we're in autonomous system territory 👑 This enum says whether an AS path segment is a set or a sequence, and the union picks which one you get 🌸
/* Extended gateway data */
enum as_path_segment_type {
AS_SET = 1, /* Unordered set of ASs */
AS_SEQUENCE = 2 /* Ordered set of ASs */
}
union as_path_type (as_path_segment_type) {
case AS_SET:
unsigned int as_set<>;
case AS_SEQUENCE:
unsigned int as_sequence<>;
}The extended gateway struct holds the AS numbers for the router, the source, and the source peer, plus the AS path to the destination, the communities, and the localpref 🎀 It's a lot, but it's all one main character outfit 🔥
struct extended_gateway {
unsigned int as; /* Autonomous system number of router */
unsigned int src_as; /* Autonomous system number of source */
unsigned int src_peer_as; /* Autonomous system number of source
peer */
as_path_type dst_as_path<>; /* Autonomous system path to the
destination */
unsigned int communities<>; /* Communities associated with this
route */
unsigned int localpref; /* LocalPref associated with this
route */
}/* Extended user data */ 🧚 This one is for the TACACS/RADIUS user info. It stores a user ID for the packet source and one for the packet destination, and that's the whole tea 🫶
/* Extended user data */
struct extended_user {
string src_user<>; /* User ID associated with packet
source */
string dst_user<>; /* User ID associated with packet
destination */
}/* Extended URL data */ 💜 Here we get the URL direction enum, which says whether the URL belongs to the source or the destination 🍓
/* Extended URL data */
enum url_direction {
src = 1, /* URL is associated with source
address */
dst = 2 /* URL is associated with destination
address */
}
struct extended_url {
url_direction direction; /* URL associated with packet source */
string url<>; /* URL associated with the packet flow */
}Next up is the big extended data enum, which lists the five extended info types, and the union that matches each one to its struct 💖 SWITCH, ROUTER, GATEWAY, USER and URL, all serving their own purpose 🌈
/* Extended data */
enum extended_information_type {
SWITCH = 1, /* Extended switch information */
ROUTER = 2, /* Extended router information */
GATEWAY = 3, /* Extended gateway router information */
USER = 4, /* Extended TACACS/RADIUS user information */
URL = 5 /* Extended URL information */
}
union extended_data_type (extended_information_type type) {
case SWITCH:
extended_switch switch;
case ROUTER:
extended_router router;
case GATEWAY:
extended_gateway gateway;
case USER:
extended_user user;
case URL:
extended_url url;
}/* Format of a single flow sample */ 🌸 Now the flow sample itself, which is the sampled packet wrapped up with its sequence number, source ID, sampling rate, pool, drops, interfaces, and extended data 🦋
/* Format of a single flow sample */
struct flow_sample {
unsigned int sequence_number; /* Incremented with each flow sample
generated by this source_id */
unsigned int source_id; /* sFlowDataSource encoded as follows:
The most significant byte of the
source_id is used to indicate the
type of sFlowDataSource
(0 = ifIndex,
1 = smonVlanDataSource,
2 = entPhysicalEntry) and the
lower three bytes contain the
relevant index value.*/
unsigned int sampling_rate; /* sFlowPacketSamplingRate */
unsigned int sample_pool; /* Total number of packets that could
have been sampled (i.e., packets
skipped by sampling process + total
number of samples) */
unsigned int drops; /* Number times a packet was dropped
due to lack of resources */
unsigned int input; /* SNMP ifIndex of input interface.
0 if interface is not known. */
unsigned int output; /* SNMP ifIndex of output interface,
0 if interface is not known.
Set most significant bit to
indicate multiple destination
interfaces (i.e., in case of
broadcast or multicast)
and set lower order bits to
indicate number of destination
interfaces.
Examples:
0x00000002 indicates ifIndex =
2
0x00000000 ifIndex unknown.
0x80000007 indicates a packet
sent to 7
interfaces.
0x80000000 indicates a packet
sent to an unknown
number of interfaces
greater than 1. */
packet_data_type packet_data; /* Information about sampled
packet */
extended_data_type extended_data<>; /* Extended flow information */
}/* Counter types */ 🧁 Time for the counters! The generic interface counters come first, and they're based on RFC 2233 📚
/* Counter types */
/* Generic interface counters - see RFC 2233 */
struct if_counters {
unsigned int ifIndex;
unsigned int ifType;
unsigned hyper ifSpeed;
unsigned int ifDirection; /* derived from MAU MIB (RFC 2668)
0 = unknown, 1=full-duplex,
2=half-duplex, 3 = in, 4=out */
unsigned int ifStatus; /* bit field with the following bits
assigned
bit 0 = ifAdminStatus
(0 = down, 1 = up)
bit 1 = ifOperStatus
(0 = down, 1 = up) */
unsigned hyper ifInOctets;
unsigned int ifInUcastPkts;
unsigned int ifInMulticastPkts;
unsigned int ifInBroadcastPkts;
unsigned int ifInDiscards;
unsigned int ifInErrors;
unsigned int ifInUnknownProtos;
unsigned hyper ifOutOctets;
unsigned int ifOutUcastPkts;
unsigned int ifOutMulticastPkts;
unsigned int ifOutBroadcastPkts;
unsigned int ifOutDiscards;
unsigned int ifOutErrors;
unsigned int ifPromiscuousMode;
}Ethernet counters are next, and they build on the generic set 🎀 This is the Ethernet one, based on RFC 2358 🌈
/* Ethernet interface counters - see RFC 2358 */
struct ethernet_counters {
if_counters generic;
unsigned int dot3StatsAlignmentErrors;
unsigned int dot3StatsFCSErrors;
unsigned int dot3StatsSingleCollisionFrames;
unsigned int dot3StatsMultipleCollisionFrames;
unsigned int dot3StatsSQETestErrors;
unsigned int dot3StatsDeferredTransmissions;
unsigned int dot3StatsLateCollisions;
unsigned int dot3StatsExcessiveCollisions;
unsigned int dot3StatsInternalMacTransmitErrors;
unsigned int dot3StatsCarrierSenseErrors;
unsigned int dot3StatsFrameTooLongs;
unsigned int dot3StatsInternalMacReceiveErrors;
unsigned int dot3StatsSymbolErrors;
}FDDI counters are just the generic set wrapped up again, based on RFC 1512 🫧
/* FDDI interface counters - see RFC 1512 */
struct fddi_counters {
if_counters generic;
}Token ring counters come next, based on RFC 1748, and they've got a LOT of error fields 💀 Respect to whoever counted all of these 😭
/* Token ring counters - see RFC 1748 */
struct tokenring_counters {
if_counters generic;
unsigned int dot5StatsLineErrors;
unsigned int dot5StatsBurstErrors;
unsigned int dot5StatsACErrors;
unsigned int dot5StatsAbortTransErrors;
unsigned int dot5StatsInternalErrors;
unsigned int dot5StatsLostFrameErrors;
unsigned int dot5StatsReceiveCongestions;
unsigned int dot5StatsFrameCopiedErrors;
unsigned int dot5StatsTokenErrors;
unsigned int dot5StatsSoftErrors;
unsigned int dot5StatsHardErrors;
unsigned int dot5StatsSignalLoss;
unsigned int dot5StatsTransmitBeacons;
unsigned int dot5StatsRecoverys;
unsigned int dot5StatsLobeWires;
unsigned int dot5StatsRemoves;
unsigned int dot5StatsSingles;
unsigned int dot5StatsFreqErrors;
}The 100 BaseVG counters come next, based on RFC 2020, and they track priority frames, octets, and errors 🍓
/* 100 BaseVG interface counters - see RFC 2020 */
struct vg_counters {
if_counters generic;
unsigned int dot12InHighPriorityFrames;
unsigned hyper dot12InHighPriorityOctets;
unsigned int dot12InNormPriorityFrames;
unsigned hyper dot12InNormPriorityOctets;
unsigned int dot12InIPMErrors;
unsigned int dot12InOversizeFrameErrors;
unsigned int dot12InDataErrors;
unsigned int dot12InNullAddressedFrames;
unsigned int dot12OutHighPriorityFrames;
unsigned hyper dot12OutHighPriorityOctets;
unsigned int dot12TransitionIntoTrainings;
unsigned hyper dot12HCInHighPriorityOctets;
unsigned hyper dot12HCInNormPriorityOctets;
unsigned hyper dot12HCOutHighPriorityOctets;
}WAN counters are the simplest of the bunch, just the generic set again 🌸
/* WAN counters */
struct wan_counters {
if_counters generic;
}VLAN counters track the VLAN ID along with octets, packets, and discards 💜
/* VLAN counters */
struct vlan_counters {
unsigned int vlan_id;
unsigned hyper octets;
unsigned int ucastPkts;
unsigned int multicastPkts;
unsigned int broadcastPkts;
unsigned int discards;
}/* Counter data */ 👑 Next is the counters version enum, which lists seven versions, and the union that maps each version to its counter struct 🦋
/* Counter data */
enum counters_version {
GENERIC = 1,
ETHERNET = 2,
TOKENRING = 3,
FDDI = 4,
VG = 5,
WAN = 6,
VLAN = 7
}
union counters_type (counters_version version) {
case GENERIC:
if_counters generic;
case ETHERNET:
ethernet_counters ethernet;
case TOKENRING:
tokenring_counters tokenring;
case FDDI:
fddi_counters fddi;
case VG:
vg_counters vg;
case WAN:
wan_counters wan;
case VLAN:
vlan_counters vlan;
}The counter sample struct is the counter version of the flow sample, with a sequence number, source ID, sampling interval, and counters 🌈
/* Format of a single counter sample */
struct counters_sample {
unsigned int sequence_number; /* Incremented with each counter
sample generated by this
source_id */
unsigned int source_id; /* sFlowDataSource encoded as
follows:
The most significant byte of the
source_id is used to indicate the
type of sFlowDataSource
(0 = ifIndex,
1 = smonVlanDataSource,
2 = entPhysicalEntry) and the
lower three
bytes contain the relevant
index value.*/
unsigned int sampling_interval; /* sFlowCounterSamplingInterval*/
counters_type counters;
}Next up is the sample datagram, which bundles samples together 🌈 The sample types enum has two options, flow samples and counter samples, and the union picks between them 🫶
/* Format of a sample datagram */
enum sample_types {
FLOWSAMPLE = 1,
COUNTERSSAMPLE = 2
}
union sample_type (sample_types sampletype) {
case FLOWSAMPLE:
flow_sample flowsample;
case COUNTERSSAMPLE:
counters_sample counterssample;
}The version 4 datagram holds the sampling agent's IP address, a sequence number, the uptime, and an array of samples 🔥
struct sample_datagram_v4 {
address agent_address /* IP address of sampling agent,
sFlowAgentAddress. */
unsigned int sequence_number; /* Incremented with each sample
datagram generated */
unsigned int uptime; /* Current time (in milliseconds since
device last booted). Should be set
as close to datagram transmission
time as possible.*/
sample_type samples<>; /* An array of flow, counter and delay
samples */
}
enum datagram_version {
VERSION4 = 4
}
union sample_datagram_type (datagram_version version) {
case VERSION4:
sample_datagram_v4 datagram;
}
struct sample_datagram {
sample_datagram_type version;
}The sFlow Datagram spec pulls definitions from a bunch of existing RFCs, namely [22], [23], [24], [25], [26], [27] and [28] 📚 Lots of friends in this group chat 🫶💖
5. Security Considerations 🔒
okay so deploying a traffic monitoring system raises a bunch of security issues 😬 sFlow doesn't have its own specific security mechanisms. Instead, it relies on proper deployment and configuration to keep things secure enough 🎀
while deploying traffic monitoring systems does come with some risk, it also gives you a powerful way to detect and trace unauthorized network activity 🕵️♀️ this section is here to help you understand the potential risks and the configuration options for mitigating them ✨
5.1 Control 🎛️
the sFlow MIB is what you use to configure how sFlow samples get generated. SNMP security, with access control lists, is usually considered adequate in an enterprise setting 💼 but there are situations where those measures aren't enough (a WAN router is a good example), and in those cases SNMP configuration control will be disabled 🙅♀️
when SNMP is disabled, a command line interface is typically provided instead. the following arguments are required to configure sFlow sampling on an interface:
-sFlowDataSource <source>
-sFlowPacketSamplingRate <rate>
-sFlowCounterSamplingInterval <interval>
-sFlowMaximumHeaderSize <header size>
-sFlowMaximumDatagramSize <datagram size>
-sFlowCollectorAddress <address>
-sFlowCollectorPort <port>5.2 Transport 🚚
okay this one is a little scary bestie 😭 traffic information gets sent unencrypted across the network from the sFlow Agent to the sFlow Analyzer, which means it's vulnerable to eavesdropping 👀 you can limit this risk by creating a secure measurement network and routing the sFlow Datagrams over that network 🫶 which technology you use to build that network is deployment specific, but it could include VLANs or VPN tunnels 🌈
the sFlow Analyzer is also vulnerable to attacks involving spoofed sFlow Datagrams 💀 to limit this, the sFlow Analyzer should check sequence numbers and verify source addresses ✨ and if a secure measurement network has been built, then only sFlow Datagrams received from that network should be processed 💖
5.3 Confidentiality 🤫
traffic information can reveal confidential information about individual network users 🙈 the amount of application level data that's visible can be controlled by limiting the number of header bytes captured by the sFlow agent 🎀 on top of that, packet sampling makes it virtually impossible to capture sequences of packets from an individual transaction 🦋
the traffic patterns you can figure out by decoding the sFlow Datagrams in the sFlow Analyzer can reveal details about an individual's network related activities, so due care should be taken to secure access to the sFlow Analyzer 🔐
6. References 📚
[1] Sun Microsystems, Inc., "XDR: External Data Representation Standard", RFC 1014, June 1987.
[2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[5] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[12] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[15] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[18] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000.
[19] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999.
[20] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000.
[21] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[22] Smith, A., Flick, J., de Graaf, K., Romanscanu, D., McMaster, D., McCloghrie, K. and S. Roberts, "Definition of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668, August 1999.
[23] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[24] Flick, J. and J. Johnson, "Definition of Managed Objects for the Ethernet-like Interface Types", RFC 2358, June 1998.
[25] Case, J., "FDDI Management Information Base", RFC 1512, September 1993.
[26] McCloghrie, K. and E. Decker, "IEEE 802.5 MIB using SMIv2", RFC 1748, December 1994.
[27] Flick, J., "Definitions of Managed Objects for IEEE 802.12 Interfaces", RFC 2020, October 1996.
[28] Willis, S., Burruss, J. and J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994.
7. Authors' Addresses 🧑💻
Peter Phaal
InMon Corporation
1404 Irving Street
San Francisco, CA 94122
Phone: (415) 661-6343
EMail: peter_phaal@INMON.COMSonia Panchen
InMon Corporation
1404 Irving Street
San Francisco, CA 94122
Phone: (415) 661-6343
EMail: sonia_panchen@INMON.COMNeil McKee
InMon Corporation
1404 Irving Street
San Francisco, CA 94122
Phone: (415) 661-6343
EMail: neil_mckee@INMON.COM8. Intellectual Property Statement ⚖️
the IETF doesn't take a position on whether any intellectual property or other rights that might be claimed to apply to the technology in this document are valid or in scope 🤷♀️ it also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have tried to find any such rights 🙃 if you want the IETF's procedures for rights in standards-track and standards-related documentation, check out BCP-11 📖 copies of claims of rights made available for publication, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use proprietary rights, can be obtained from the IETF Secretariat 📬
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard 🫶 send that info to the IETF Executive Director 💌
9. Full Copyright Statement 🌸
Copyright (C) The Internet Society (2001). All Rights Reserved. 💜
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️
this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏
Acknowledgement 🎉
funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3176 2001-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms