sFlow.org Peter Phaal http://www.sFlow.org/ InMon Corp. info@sflow.org Marc Lavine Foundry Networks July 2004 sFlow Version 5 Copyright Notice Copyright (C) sFlow.org (2004). All Rights Reserved. Abstract This memo defines sFlow.org's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the traffic sampling mechanisms implemented in sFlow Agents, the sFlow MIB for configuring sFlow Agents, and the format of the sFlow Datagram that carries traffic measurement data from sFlow Agents to an sFlow Collector. Table of Contents 1. Overview ...................................................... 2 2. Terminology and Architecture .................................. 2 2.1 Terminology ............................................... 2 2.2 sFlow Reference Model ..................................... 4 3. Sampling Mechanisms ........................................... 6 3.1 Packet Flow Sampling ...................................... 6 3.2 Counter Sampling .......................................... 7 4. sFlow MIB ..................................................... 8 4.1 The SNMP Management Framework ............................. 8 4.2 Structure of the sFlow MIB Module ......................... 9 4.2.1 The Receiver Group .................................. 9 4.2.2 The Flow Sampling Group ............................. 9 4.2.3 The Counter Polling Group ........................... 10 4.3 Definitions ............................................... 11 5. sFlow Datagram Format ......................................... 23 6. Security Considerations ....................................... 43 6.1 Configuration ............................................. 44 6.2 Transport ................................................. 44 6.3 Confidentiality ........................................... 44 v1.00 sFlow.org [Page 1] FINAL sFlow Version 5 July 2004 7. References .................................................... 45 8. Author's Addresses ............................................ 47 Appendix A: Differences Between sFlow Versions 4 and 5 ........ 49 Appendix B: Random Number Generation .......................... 50 1. Overview sFlow is a technology for monitoring traffic in data networks containing switches and routers. The sFlow monitoring system consists of an sFlow Agent (embedded in a switch or router or in a standalone probe) and a central sFlow Collector. The architecture and sampling techniques used in the sFlow monitoring system were designed for providing continuous site- wide (and enterprise-wide) traffic monitoring of high speed switched and routed networks. This design specifically addresses issues associated with: o Accurately monitoring network traffic at Gigabit speeds and higher. o Scaling to monitor tens of thousands of agents from a single sFlow Collector. o Extremely low cost sFlow Agent implementation. The sFlow Agent uses sampling technology to capture traffic statistics from the device it is monitoring. sFlow Datagrams are used to immediately forward the sampled traffic statistics to an sFlow Collector for analysis. This document describes the sampling mechanisms used by the sFlow Agent, the SFLOW MIB used by the sFlow Collector to control the sFlow Agent, and the sFlow Datagram Format used by the sFlow Agent to send traffic data to the sFlow Collector. This memo describes sFlow version 5. It replaces sFlow version 4 described in RFC 3176 [1]. The differences between sFlow versions 4 and 5 are described in Appendix A. 2. Terminology and Architecture This section defines the elements of the sFlow system. 2.1 Terminology v1.00 sFlow.org [Page 2] FINAL sFlow Version 5 July 2004 The terms used to specify the sFlow architecture are defined here for reference. o Network Device: A piece of network equipment, such as a switch or router, that forwards data packets. o Data Source: A Data Source refers to a location within a Network Device that can make traffic measurements. Possible Data Sources include interfaces, physical entities within the device such as the backplane and VLANs. Each Data Source has access to a subset of the traffic flowing through the device. The type and number of Data Sources needed to completely monitor a device will depend on the internal architecture of that device. Typically a Data Source is defined for each physical interface on the device since this ensures that every packet transiting the device to be observed. o Packet Flow: A Packet Flow is defined as the path or trajectory that a packet takes through a Network Device (i.e. the path that a packet takes as it is received on one interface, is subject to a switching/routing decision and is then sent on another interface. In the case of a one-armed router, the source and destination interface could be the same. In the case of a broadcast or multicast packet there may be multiple destination interfaces). o Packet Flow Sampling: Packet Flow Sampling refers to the random selection of a fraction of the Packet Flows observed at a Data Source. o Sampling Rate: The Sampling Rate specifies the ratio of packets observed at the Data Source to the samples generated. For example a sampling rate of 100 specifies that, on average, 1 sample will be generated for every 100 packets observed. o Packet Flow Record: A Packet Flow Record describes the attributes of a Packet Flow. There are two types of information in a flow record: 1 Information on the packet itself, typically a packet header, packet length and packet encapsulation. 2 Information about the path the packet took through the device, including information relating to the selection of the forwarding path. o Counter Sampling: Periodic sampling or polling of counters associated with a Data Source. v1.00 sFlow.org [Page 3] FINAL sFlow Version 5 July 2004 o Sampling Interval: The time period between successive Counter Samples. o Counter Record: A record containing counter values associated with a Data Source at the end of a Sampling Interval. o sFlow Instance: An sFlow Instance refers to a measurement process associated with a Data Source. There may be one or more sFlow Instances associated with a single Data Source. Each sFlow Instance operates independently of other sFlow Instances, for example if Packet Flow Sampling instances each have their own Sampling Rates and Counter Sampling instaces have their own Sampling Interval. o sFlow Agent: The sFlow Agent provides an interface for configuring the sFlow Instances within a device. The sFlow Agent may support command line and/or SNMP based configuration. The agent is also responsible for maintaining measurement sessions with sFlow Collectors. It marshals data into sFlow Datagrams to send to sFlow Collectors. The sFlow Agent frees resources when a session expires. o sFlow Sub-Agent: In the case where sFlow is implemented on a distributed device architecture it may be desireable to distribute the sFlow Agent functionality. Each sFlow Sub-Agent is responsible for a particular subset of Data Sources. o sFlow Collector: An sFlow Collector receives sFlow Datagrams from one or more sFlow Agents. The sFlow Collector may also configure sFlow Instances using the configuration mechanisms provided by the sFlow Agent. o sFlow Datagram: The sFlow Datagram is a UDP datagram that contains the measurement data, and information about the measurement source and process. The format of the sFlow Datagram is defined in this document. 2.2 sFlow Reference Model The figure below shows the relationships between the different entities within an sFlow system. v1.00 sFlow.org [Page 4] FINAL sFlow Version 5 July 2004 +--------------------------------------+ | Network Device | | | | +--------------------------------+ | | | Agent | | | | | | | | +--------------------------+ | | +-------------+ | | | Sub-agent | | | SNMP | | | | | | +<-+------------>+ | | | | +--------------------+ | | | | Collector | | | | | Data Source | | | | Datagram | | | | | | | | +--+------------>+ | | | | | +-------------+ | | | | | | | | | | | Instance | | | | | +-------------+ | | | | +-------------+ | | | | . | | | | . | | | | . | | | | . | | | | +-------------+ | | | | +-------------+ | | | | SNMP | | | | | | | Instance | | | +<-+--+--------->+ | | | | | +-------------+ | | | | | | Collector | | | | +--------------------+ | | | | Datagram | | | | | . | +--+--+--+------>+ | | | | . | | | | | | | | | | +--------------------+ | | | | | +-------------+ | | | | Data Source | | | | | | | | | +--------------------+ | | | | | | | +--------------------------+ | | | | | | . | | | | | | . | | | | | | +--------------------------+ | | | | | | | Sub-agent | | | | | | | +--------------------------+ | | | | | +--------------------------------+ | | | +--------------------------------------+ | | . | | . | | +--------------------------------------+ | | | Network Device | | | | +--------------------------------+ | | | | | +<-+--+ | | | Agent | | | | | +--+-----+ | +--------------------------------+ | +--------------------------------------+ An sFlow Collector makes use of SNMP to communicate with an sFlow Agent in order to configure sFlow monitoring on a Network Device. The sFlow MIB describes the managed objects needed to configure an sFlow v1.00 sFlow.org [Page 5] FINAL sFlow Version 5 July 2004 Agent. Packet Flow Sampling and Counter Sampling is performed by sFlow Instances associated with individual Data Sources within the sFlow Agent. In order to perform Packet Flow Sampling, an sFlow Instance is configured with a Sampling Rate. The Packet Flow sampling process results in the generation of Packet Flow Records. In order to perform Counter Sampling, an sFlow Instance is configured with a Sampling Interval. The Counter Sampling process results in the generation of Counter Records. The sFlow Agent collects Counter Records and Packet Flow Records and sends them in the form of sFlow Datagrams to sFlow Collectors. 3. Sampling Mechanisms The sFlow Agent uses two forms of sampling: statistical packet-based sampling of switched or routed Packet Flows, and time-based sampling of counters. 3.1 Packet Flow Sampling The Packet Flow Sampling mechanism carried out by each sFlow Instance must ensure that any packet observed at a Data Source has an equal chance of being sampled, irrespective of the Packet Flow(s) to which it belongs. Packet Flow Sampling is accomplished as follows: When a packet arrives on an interface, the Network Device makes a filtering decision to determines whether the packet should be dropped. If the packet is not filtered a destination interface is assigned by the switching/routing function. At this point a decision is made on whether or not to sample the packet. The mechanism involves a counter that is decremented with each packet. When the counter reaches zero a sample is taken. Whether or not a sample is taken, the counter Total_Packets is incremented. Total_Packets is a count of all the packets that could have been sampled. Taking a sample involves either copying the packet's header, or extracting features from the packet. See sFlow Datagram Format for a description of the different forms of sample. Every time a sample is taken, the counter Total_Samples, is incremented. Total_Samples is a count of the number of samples generated. Samples are sent by the sFlow Instance to the sFlow Agent for processing. The sample includes the packet information, and the values of the Total_Packets and Total_Samples counters. The sFlow Agent may then use the samples to obtain additional information about the packet's trajectory through the device. Such information depends on the forwarding functions of the device. Examples of trajectory information provided are source and destination interface, source and v1.00 sFlow.org [Page 6] FINAL sFlow Version 5 July 2004 destination VLAN, next hop subnet, full AS path. Details of the forwarding information are given in the sFlow Datagram Format. When a sample is taken, the counter indicating how many packets to skip before taking the next sample should be reset. The value of the counter should be set to a random integer where the sequence of random integers used over time should be such that: (1) Total_Packets/Total_Samples = Sampling Rate An alternative strategy for Packet Flow Sampling is to generate a random number for each packet, compare the random number to a preset threshold and take a sample whenever the random number is smaller than the threshold value. Calculation of an appropriate threshold value depends on the characteristics of the random number generator, however, the resulting sample stream must still satisfy (1). Appendix B further discusses the requirements for the random number generator. 3.2 Counter Sampling The primary objective of the Counter Sampling is to efficiently, periodically export counters associated with Data Sources. Typically a Data Source will be associated with each interface on the device that can be an ingress or egress interface for Packet Flows. These interface Data Sources will then be used to export counters relating to the interfaces. A maximum Sampling Interval is assigned to each sFlow Instance associated with an interface Data Source, but the sFlow Agent is free to schedule polling in order maximize internal efficiency. Packet Flow Sampling and Counter Sampling are designed as part of an integrated system. Both types of sample are combined in sFlow Datagrams. Since Packet Flow Sampling will cause a steady, but random, stream of sFlow Datagrams to be sent to the sFlow Collector, counter samples may be taken opportunistically in order to fill these datagrams. One strategy for counter sampling has the sFlow Agent keep a list of counter sources being sampled. When a Packet Flow Sample is generated the sFlow Agent examines the list and adds counters to the sample datagram, least recently sampled first. Counters are only added to the datagram if the sources are within a short period, 5 seconds say, of failing to meet the required Sampling Interval (see sFlowCounterSamplingInterval in SFLOW MIB). Whenever a counter v1.00 sFlow.org [Page 7] FINAL sFlow Version 5 July 2004 source's statistics are added to a sample datagram, the time the counter source was last sampled is updated and the counter source is placed at the end of the list. Periodically, say every second, the sFlow Agent examines the list of counter sources and sends any counters that need to be sent to meet the sampling interval requirement. If the sFlow Agent chooses to regularly schedule counter sampling, then it should schedule each counter source at a different start time (preferably randomly) so that counter sampling is not synchronised within an agent or between agents. 4. sFlow MIB The sFlow MIB provides a standard mechanism for remotely controlling and configuring an sFlow Agent. 4.1 The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [2]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Man- agement 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]. o 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 proto- col, 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]. o 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 opera- tions and associated PDU formats is described in RFC 1905 [14]. o A set of fundamental applications described in RFC 2573 [15] and the view-based access control mechanism described in RFC 2575 [16]. A more detailed introduction to the current SNMP Management Framework v1.00 sFlow.org [Page 8] FINAL sFlow Version 5 July 2004 can be found in RFC 2570 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. 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. 4.2 Structure of the SFLOW MIB Module The MIB consists of three groups of objects: the receiver group, the flow sampling group and the counter polling group. 4.2.1 The Receiver Group The receiver group defines the set of objects used to maintain an sFlow session between an sFlow Agent and an sFlow Collector. Before making any configuration changes, an sFlow Collector must first find a free row in the receiver table and then claim it by writing its owner string and a reservation time into a free row in the receiver table. A session will automatically time out, and the associated resources freed, unless it is periodically refreshed by the the collector. By periodically refreshing its receiver table entry, an sFlow Collector ensures that its address is learned by any bridges on the path to the sFlow Agent, minimizing the chances that the sFlow Datagrams will be flooded by a bridge. Entries cannot be added to or removed from the receiver group table. An sFlow Agent implementor should limit the number of entries to ensure that the number of concurrent sFlow sessions is limited to a number that will not exceed that capacity of the device. Having acquired a row in the receiver table, the sFlow Collector specifies an address and port that it will use to receive sFlow Datagrams. The maximum size of sFlow Datagrams can be configured in order to prevent packet fragmentation. 4.2.2 The Flow Sampling Group v1.00 sFlow.org [Page 9] FINAL sFlow Version 5 July 2004 The flow sampling group defines a set of locations, or Data Sources, in the device that are capable of Packet Flow sampling. Data Sources may correspond to interfaces, VLANs or other entities within the device. The set of Data Sources advertised by an sFlow Agent depends on the device architecture. For example, a device may have packet sampling integrated into its interface ASICs, in which case it will advertise Data Sources for each interface. Alternatively, a software router may simply have one Data Source associated with the routing module. Each Data Source may be capable of supporting more than one independent sampling process, in which case there will be multiple sFlow Instances associated with each Data Source. Each sFlow Instance can have its own independent sampling rate. Even if the Data Source hardware is only capable of generating a single stream of packet samples, it is possible for the sFlow Agent to use sub-sampling to create multiple sFlow Instances for the Data Source. For example, suppose there are two sFlow Instances, one configured with a Sampling Rate of 512 and the other with a rate of 1024. The hardware can be configured to sample at a rate of 512 and then these samples can be sub-sampled in software using a sampling rate of 2 to achieve the 1024 rate. Only allowing Sampling Rates that are powers of two is attractive since it allows the smallest configured Sampling Rate to be set in hardware and all other sampling rates can be obtained in software by sub-sampling. A Flow Sampling Instance may have a minimum allowable Sampling Rate. Setting a conservative value that ensures that the sFlow Agent can never become overloaded with Packet Flow Samples under worst case traffic loads is not advisable. This yields minimum Sampling Rate values that are very high and don't reflect typical traffic levels. The Agent may implement an automated one-way backoff of the Sampling Rate that triggers whenever an excessive number of samples per second is generated. When the triggered the Agent can double the Sampling Rate. If the threshold is exceeded again, the Sampling Rate is doubled again. The Sampling Rate will quickly reach a value that is sustainable. The sampling rate must stay at its new value and never automatically return to the originally configured value. The value may be changed back manually through the command line interface or via the sFlow MIB. This scheme protects against poorly chosen Sampling Rates or unexpected changes in peak traffic rates, but still allows low Sampling Rates to be safely selected where appropriate. 4.2.3 The Counter Polling Group The counter polling group defines a set of locations, or Data Sources, in the device that can provide counter information. v1.00 sFlow.org [Page 10] FINAL sFlow Version 5 July 2004 Typically the Data Sources will be the interfaces on the device. Each Data Source may be capable of supporting more than one independent polling process, in which case there will be multiple counter polling instances associated with each data source. Each counter polling instance can have its own independent polling interval. 4.3 Definitions SFLOW-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC 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 "200309240000Z" -- September 24, 2003 ORGANIZATION "sFlow.org" CONTACT-INFO "Peter Phaal sFlow.org http://www.sflow.org/ Tel: +1-415-283-3260 Email: peter.phaal@sflow.org" DESCRIPTION "The MIB module for managing the generation and transportation of sFlow data records." -- -- Revision History -- REVISION "200310180000Z" -- November 18, 2003 DESCRIPTION "Version 1.3 (draft 5) v1.00 sFlow.org [Page 11] FINAL sFlow Version 5 July 2004 Allow set to SFlowReceiver if it doesn't change value." REVISION "200309240000Z" -- September 24, 2003 DESCRIPTION "Version 1.3 (draft 4) Default value of sFlowRcvrAddress should be '00000000' h. Default value of sFlowCpReceiver should be 0." REVISION "200304080000Z" -- April 8, 2003 DESCRIPTION "Version 1.3 (draft 3) Clarify semantics of counter polling interval, sFlowCpInterval." REVISION "200209170000Z" -- September 17, 2002 DESCRIPTION "Version 1.3 (draft 2) Adds support for multiple sFlow samplers per sFlowDataSource. Moved to sflow.org enterprise number. Splits flow sampling, counter polling and receiver specification into separate tables." REVISION "200107310000Z" -- July 31, 2001 DESCRIPTION "Version 1.2 Brings MIB into SMI v2 compliance." REVISION "200105010000Z" -- May 1, 2001 DESCRIPTION "Version 1.1 Adds sfDatagramVersion." ::= { enterprises sflow(14706) 1 } sFlowAgent OBJECT IDENTIFIER ::= { sFlowMIB 1 } SFlowDataSource ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a source of sFlow data. The following data source types are currently defined: v1.00 sFlow.org [Page 12] FINAL sFlow Version 5 July 2004 - ifIndex. SFlowDataSources 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 allows 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. - sFlowFsPacketSamplingRate applies to all ports on the device capable of packet sampling. - smonVlanDataSource. An SFlowDataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource. 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. An SFlowDataSource 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 SFlowDataSource operates independently a packet that crosses multiple DataSources may generate multiple flow records." SYNTAX OBJECT IDENTIFIER SFlowInstance ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "If more than one sFlow sampler is available for this SFlowDataSource then individual samplers are distinguished using the SFlowInstance variable. The value of SFlowInstance ranges from 1..n where n is the number of samplers associated with this SFlowDataSource. v1.00 sFlow.org [Page 13] FINAL sFlow Version 5 July 2004 Note: Each sFlow sampler instance must operate independently of all other instances. Setting an attribute of one sampler must not alter the the behavior and settings of other sampler instances." SYNTAX Integer32 (1..65535) SFlowReceiver ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identify the sFlow receiver associated with this resource. A value of zero indicates that this resource is available. If non-zero the value must correspond to a valid, active sFlowRcvrIndex. If the value is currently zero it may be set to any active entry in the sFlowRcvrTable. If the value is not zero then a set to anything other than zero or its current value will result in an SNMP error (bad value). Setting to zero frees the resource and returns all the values in this entry to their default values. If an entry in the sFlowRcvrTable expires, either because the sFlowRcvrOwner is set to the empty string or because the sFlowRcvrTimeout reaches zero, then the agent must mark all associated resources as available (by setting the associated SFlowReceiver entry to zero) and all values in these records must be restored to their default values. This mechanism provides no enforcement and relies on the cooperation of management entities in order to ensure that competition for a resource is fairly resolved. A management entity should not make any changes to a resource without first aquiring it by successfully writing its sFlowRcvrIndex value as the SFlowReceiver for the resource." SYNTAX Integer32 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: ;; v1.00 sFlow.org [Page 14] FINAL sFlow Version 5 July 2004 where: must be '1.3', the version of this MIB. the name of the organization responsible for the agent implementation. the specific software build of this agent. As an example, the string '1.3;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 . applies to the structure and semantics of the SFLOW MIB only." DEFVAL { "1.3;;" } ::= { 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." v1.00 sFlow.org [Page 15] FINAL sFlow Version 5 July 2004 ::= { sFlowAgent 3 } -- -- Receiver Table -- sFlowRcvrTable OBJECT-TYPE SYNTAX SEQUENCE OF SFlowRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the receivers of sFlow information." ::= { sFlowAgent 4 } sFlowRcvrEntry OBJECT-TYPE SYNTAX SFlowRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of an sFlow Receiver." INDEX { sFlowRcvrIndex } ::= { sFlowRcvrTable 1 } SFlowRcvrEntry ::= SEQUENCE { sFlowRcvrIndex Integer32, sFlowRcvrOwner OwnerString, sFlowRcvrTimeout Integer32, sFlowRcvrMaximumDatagramSize Integer32, sFlowRcvrAddressType InetAddressType, sFlowRcvrAddress InetAddress, sFlowRcvrPort Integer32, sFlowRcvrDatagramVersion Integer32 } sFlowRcvrIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index into sFlowReceiverTable." ::= { sFlowRcvrEntry 1 } sFlowRcvrOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity making use of this sFlowRcvrTable entry. The empty v1.00 sFlow.org [Page 16] FINAL sFlow Version 5 July 2004 string indicates that the entry is currently unclaimed. An entity wishing to claim an sFlowRcvrTable entry must ensure that the entry is unclaimed before trying to claim it. The entry is claimed by setting the owner string. The entry 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 sFlowRcvrTimeout in the same SNMP set request. When a management entity is finished using the sampler, it should set the value of sFlowRcvrOwner back to unclaimed. The agent must restore all other entities this row to their default values when the owner is set to unclaimed. It must also free all other resources associated with this sFlowRcvrTable entry. This mechanism provides no enforcement and relies on the cooperation of management entities in order to ensure that competition for a receiver entry is fairly resolved." DEFVAL { "" } ::= { sFlowRcvrEntry 2 } sFlowRcvrTimeout 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. It must also free all other resources associated with this sFlowRcvrTable entry." DEFVAL { 0 } ::= { sFlowRcvrEntry 3 } sFlowRcvrMaximumDatagramSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write v1.00 sFlow.org [Page 17] FINAL sFlow Version 5 July 2004 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 } ::= { sFlowRcvrEntry 4 } sFlowRcvrAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "The type of sFlowRcvrCollectorAddress." DEFVAL { ipv4 } ::= { sFlowRcvrEntry 5 } sFlowRcvrAddress 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 not sFlow datagrams will be sent." DEFVAL { '00000000'h } -- 0.0.0.0 ::= { sFlowRcvrEntry 6 } sFlowRcvrPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The destination port for sFlow datagrams." DEFVAL { 6343 } ::= { sFlowRcvrEntry 7 } sFlowRcvrDatagramVersion 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 SNMP bad value error if no such value exists." DEFVAL { 5 } v1.00 sFlow.org [Page 18] FINAL sFlow Version 5 July 2004 ::= { sFlowRcvrEntry 8 } -- -- Flow Sampling Table -- sFlowFsTable OBJECT-TYPE SYNTAX SEQUENCE OF SFlowFsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the flow samplers within a device." ::= { sFlowAgent 5 } sFlowFsEntry OBJECT-TYPE SYNTAX SFlowFsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a flow sampler." INDEX { sFlowFsDataSource, sFlowFsInstance } ::= { sFlowFsTable 1 } SFlowFsEntry ::= SEQUENCE { sFlowFsDataSource SFlowDataSource, sFlowFsInstance SFlowInstance, sFlowFsReceiver SFlowReceiver, sFlowFsPacketSamplingRate Integer32, sFlowFsMaximumHeaderSize Integer32 } sFlowFsDataSource OBJECT-TYPE SYNTAX SFlowDataSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "sFlowDataSource for this flow sampler." ::= { sFlowFsEntry 1 } sFlowFsInstance OBJECT-TYPE SYNTAX SFlowInstance MAX-ACCESS not-accessible STATUS current DESCRIPTION "The sFlow instance for this flow sampler." ::= { sFlowFsEntry 2 } sFlowFsReceiver OBJECT-TYPE v1.00 sFlow.org [Page 19] FINAL sFlow Version 5 July 2004 SYNTAX SFlowReceiver MAX-ACCESS read-write STATUS current DESCRIPTION "The SFlowReceiver for this flow sampler." DEFVAL { 0 } ::= { sFlowFsEntry 3 } sFlowFsPacketSamplingRate 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 to 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 } ::= { sFlowFsEntry 4 } sFlowFsMaximumHeaderSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of bytes that should be copied from a v1.00 sFlow.org [Page 20] FINAL sFlow Version 5 July 2004 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 } ::= { sFlowFsEntry 5 } -- -- Counter Polling Table -- sFlowCpTable OBJECT-TYPE SYNTAX SEQUENCE OF SFlowCpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of the counter pollers within a device." ::= { sFlowAgent 6 } sFlowCpEntry OBJECT-TYPE SYNTAX SFlowCpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Attributes of a counter poller." INDEX { sFlowCpDataSource, sFlowCpInstance } ::= { sFlowCpTable 1 } SFlowCpEntry ::= SEQUENCE { sFlowCpDataSource SFlowDataSource, sFlowCpInstance SFlowInstance, sFlowCpReceiver SFlowReceiver, sFlowCpInterval Integer32 } sFlowCpDataSource OBJECT-TYPE SYNTAX SFlowDataSource MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies the source of the data for the counter poller." ::= { sFlowCpEntry 1 } sFlowCpInstance OBJECT-TYPE SYNTAX SFlowInstance MAX-ACCESS not-accessible STATUS current v1.00 sFlow.org [Page 21] FINAL sFlow Version 5 July 2004 DESCRIPTION "The sFlowInstance for this counter poller." ::= { sFlowCpEntry 2 } sFlowCpReceiver OBJECT-TYPE SYNTAX SFlowReceiver MAX-ACCESS read-write STATUS current DESCRIPTION "The SFlowReciever associated with this counter poller." DEFVAL { 0 } ::= { sFlowCpEntry 3 } sFlowCpInterval 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. The agent is permitted to have minimum and maximum allowable values for the counter polling interval. A minimum interval lets the agent designer set an upper bound on the overhead associated with polling, and a maximum interval may be the result of implementation restrictions (such as counter size). In addition not all values between the maximum and minimum may be realizable as the sampling interval (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 interval 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 } ::= { sFlowCpEntry 4 } -- -- Compliance Statements -- sFlowMIBConformance OBJECT IDENTIFIER ::= { sFlowMIB 2 } v1.00 sFlow.org [Page 22] FINAL sFlow Version 5 July 2004 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 sFlowRcvrAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "Agents need only support ipv4." ::= { sFlowMIBCompliances 1 } sFlowAgentGroup OBJECT-GROUP OBJECTS { sFlowVersion, sFlowAgentAddressType, sFlowAgentAddress, sFlowRcvrOwner, sFlowRcvrTimeout, sFlowRcvrMaximumDatagramSize, sFlowRcvrAddressType, sFlowRcvrAddress, sFlowRcvrPort, sFlowRcvrDatagramVersion, sFlowFsReceiver, sFlowFsPacketSamplingRate, sFlowFsMaximumHeaderSize, sFlowCpReceiver, sFlowCpInterval } STATUS current DESCRIPTION "A collection of objects for managing the generation and transportation of sFlow data records." ::= { sFlowMIBGroups 1 } END The sFlow MIB references definitions from a number of existing RFCs [18], [19], [20] and [21]. 5. sFlow Datagram Format The sFlow Datagram format specifies a standard format for the sFlow Agent to send sampled data to a remote sFlow Collector. v1.00 sFlow.org [Page 23] FINAL sFlow Version 5 July 2004 The format of the sFlow datagram is specified using the XDR standard [32]. XDR is more compact than ASN.1 and simpler for the sFlow Agent to encode and the sFlow Collector to decode. Samples are sent as UDP packets to the host and port specified in the SFLOW MIB. The assigned port for sFlow (and the default specified in the SFLOW MIB) is port 6343. All sFlow Agents and applications should default to using UDP port 6343. A standard sFlow port helps eliminate configuration problems between sFlow Agents and sFlow Collectors, sFlow traffic will be easier to identify, and it should make it easier to configure forwarding through intermediate devices such as firewalls. The lack of reliability in the UDP transport mechanism does not significantly affect the accuracy of the measurements obtained from an sFlow Agent. o If counter samples are lost then new values will be sent during the next polling interval. The chance of an undetected counter wrap is negligible. The sFlow Datagram specifies 64 bit octet counters, and with typical counter polling intervals between 20 to 120 sec- onds the chance of a long enough sequence of sFlow Datagrams being lost to hide a counter wrap is very small. o The net effect of lost Packet Flow Samples is a slight reduction in the effective sampling rate. The use of UDP reduces the amount of memory required to buffer data. UDP also provides a robust means of delivering timely traffic information during periods of intense traffic (such as a denial of service attack). UDP is more robust than a reliable transport mechanism because under overload the only effect on overall system performance is a slight increase in transmission delay and a greater number of lost packets, neither of which has a significant effect on an sFlow-based monitoring sytem. If a reliable transport mechanism were used then an overload would introduce long transmission delays and require large amounts of buffer memory on the agent. While the sFlow Datagram structure permits multiple samples to be included in each datagram, the sFlow Agent must not wait for a buffer to fill with samples before sending the sFlow Datagram. sFlow is intended to provide timely information on traffic. The sFlow Agent may at most delay a sample by 1 second before it is required to send the datagram. The sFlow Agent should try to piggyback counter samples on the datagram stream resulting from Packet Flow Sampling. Before sending out a datagram the remaining space in the buffer can be filled with v1.00 sFlow.org [Page 24] FINAL sFlow Version 5 July 2004 counter samples. The sFlow Agent has discretion in the timing of its counter polling, the specified counter sampling interval sFlowCounterSamplingInterval is a maximum, so the sFlow Agent is free to sample counters early if it has space in a datagram. If counters must be sent in order to satisfy the maximum sampling interval then a datagram must be sent containing the outstanding counters. The following is the XDR description of the sFlow Datagram: /* Proposed sFlow Datagram Version 5 (draft 10) */ /* Revision History - version 5 adds support for: Adds expanded encodings for flow_sample and counter_sample Adds unknown address type; Adds sub-agent support. Adds Packet discard information. Adds support for vendor specific extensions. Adds length information to data fields. Adds length information to sample types. Define reset semantics for flow_sample,counter_sample sequence no. Splits sFlow datagram definition from flow/counter data definitions. Note: Revision history for sFlow data definitions is now part of data definition document. */ /* Address types */ typedef opaque ip_v4[4]; typedef opaque ip_v6[16]; enum address_type { UNKNOWN = 0, IP_V4 = 1, IP_V6 = 2 } union address (address_type type) { case UNKNOWN: void; case IP_V4: ip_v4; case IP_V6: ip_v6; } /* Data Format The data_format uniquely identifies the format of an opaque structure in the sFlow specification. A data_format is contructed as follows: v1.00 sFlow.org [Page 25] FINAL sFlow Version 5 July 2004 - The most significant 20 bits correspond to the SMI Private Enterprise Code of the entity responsible for the structure definition. A value of zero is used to denote standard structures defined by sflow.org. - The least significant 12 bits are a structure format number assigned by the enterprise that should uniquely identify the the format of the structure. There are currently three opaque structures where which data_formats are used: 1. sample_data 2. counter_data 3. flow_data Structure format numbers may be re-used within each of these contexts. For example, an (inmon,1) data_format could identify a particular set of counters when used to describe counter_data, but refer to a set of flow attributes when used to describe flow_data. An sFlow implementor should use the standard structures where possible, even if they can only be partially populated. Vendor specific structures are allowed, but should only be used to supplement the existing structures, or to carry information that hasn't yet been standardized. Enterprises are encouraged to publish structure definitions in XDR format to www.sflow.org. A structure description document should contain an XDR structure definition immediately preceded by a comment listing the structure to which it applies, the enterprise number, and the structure number. See the definitions of counter_sample and flow_sample for examples. Note: An enterprise which has defined sFlow structures is permitted to extend those structure definitions at the end without changing structure numbers. Any changes that would alter or invalidate fields in published structure definitions must be implemented using a new structure number. This policy allows additional data to be added to structures while still maintaining backward compatibility. Applications receiving sFlow data must always use the opaque length information when decoding opaque<> structures so that encountering extended structures will not cause decoding errors. Note that these rules apply to the standard structures as well. */ typedef unsigned int data_format; /* sFlowDataSource encoded as follows: v1.00 sFlow.org [Page 26] FINAL sFlow Version 5 July 2004 The most significant byte of the source_id is used to indicate the type of sFlowDataSource: 0 = ifIndex 1 = smonVlanDataSource 2 = entPhysicalEntry The lower three bytes contain the relevant index value. */ typedef unsigned int sflow_data_source; /* Input/output port information Encoding of interface(s) involved in the packet's path through the device. 0 if interface is not known. The most significant 2 bits are used to indicate the format of the 30 bit value. - format = 0 single interface value is ifIndex of the interface. The maximum value, 0x3FFFFFFF, indicates that there is no input or output interface (according to which field it appears in). This is used in describing traffic which is not bridged, routed, or otherwise sent through the device being monitored by the agent, but which rather originates or terminates in the device itself. In the input field, this value is used to indicate packets for which the origin was the device itself (e.g. a RIP request packet sent by the device, if it is acting as an IP router). In the output field, this value is used to indicate packets for which the destination was the device itself (e.g. a RIP response packet (whether unicast or not) received by the device, if it is acting as an IP router). - format = 1 packet discarded value is a reason code. Currently the following codes are defined: 0 - 255 use ICMP Destination Unreachable codes See www.iana.org for authoritative list. RFC 1812, section 5.2.7.1 describes the current codes. Note that the use of these codes does not imply that the packet to which they refer is an IP packet, or if it is, that an ICMP message of any kind was generated for it. Current value are: 0 Net Unreachable 1 Host Unreachable v1.00 sFlow.org [Page 27] FINAL sFlow Version 5 July 2004 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed and Don't Fragment was Set 5 Source Route Failed 6 Destination Network Unknown 7 Destination Host Unknown 8 Source Host Isolated 9 Communication with Destination Network is Administratively Prohibited 10 Communication with Destination Host is Administratively Prohibited 11 Destination Network Unreachable for Type of Service 12 Destination Host Unreachable for Type of Service 13 Communication Administratively Prohibited 14 Host Precedence Violation 15 Precedence cutoff in effect 256 = unknown 257 = ttl exceeded 258 = ACL 259 = no buffer space 260 = RED 261 = traffic shaping/rate limiting 262 = packet too big (for protocols that don't support fragmentation) Note: Additional reason codes may be published over time. An application receiving sFlow must be prepared to accept additional reason codes. The authoritative list of reason codes will be maintained at www.sflow.org - format = 2 multiple destination interfaces value is the number of interfaces. A value of 0 indicates an unknown number greater than 1. Note: Formats 1 & 2 apply only to an output interface and never to an input interface. A packet is always received on a single (possibly unknown) interface. Examples: 0x00000002 indicates ifIndex = 2 0x00000000 ifIndex unknown. 0x40000001 packet discarded because of ACL. v1.00 sFlow.org [Page 28] FINAL sFlow Version 5 July 2004 0x80000007 indicates a packet sent to 7 interfaces. 0x80000000 indicates a packet sent to an unknown number of interfaces greater than 1. */ typedef unsigned int interface; /* Counter and Flow sample formats Compact and expand forms of counter and flow samples are defined. An agent must not mix compact/expanded encodings. If an agent will never use ifIndex numbers >= 2^24 then it must use compact encodings for all interfaces. Otherwise the expanded formats must be used for all interfaces. While the theoretical range of ifIndex numbers is 2^32, RFC 2863 recommends that ifIndex numbers are allocated using small integer values starting at 1. For most agent implementations the 2^24 range of values for ifIndex supported by the compact encoding is more than adequate and its use saves bandwidth. The expanded encodings are provided to support the maximum possible values for ifIndex, even though large ifIndex values are not encouraged. */ struct flow_record { data_format flow_format; /* The format of sflow_data */ opaque flow_data<>; /* Flow data uniquely defined by the flow_format. */ } struct counter_record { data_format counter_format; /* The format of counter_data */ opaque counter_data<>; /* A block of counters uniquely defined by the counter_format. */ } /* Compact Format Flow/Counter samples If ifIndex numbers are always < 2^24 then the compact must be used. */ /* Format of a single flow sample */ /* opaque = sample_data; enterprise = 0; format = 1 */ struct flow_sample { unsigned int sequence_number; /* Incremented with each flow sample generated by this source_id. Note: If the agent resets the sample_pool then it must also reset the sequence_number.*/ sflow_data_source source_id; /* sFlowDataSource */ v1.00 sFlow.org [Page 29] FINAL sFlow Version 5 July 2004 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 of times that the sFlow agent detected that a packet marked to be sampled was dropped due to lack of resources. The drops counter reports the total number of drops detected since the agent was last reset. A high drop rate indicates that the management agent is unable to process samples as fast as they are being generated by hardware. Increasing sampling_rate will reduce the drop rate. Note: An agent that cannot detect drops will always report zero. */ interface input; /* Interface packet was received on. */ interface output; /* Interface packet was sent on. */ flow_record flow_records<>; /* Information about a sampled packet */ } /* Format of a single counter sample */ /* opaque = sample_data; enterprise = 0; format = 2 */ struct counters_sample { unsigned int sequence_number; /* Incremented with each counter sample generated by this source_id Note: If the agent resets any of the counters then it must also reset the sequence_number. In the case of ifIndex-based source_id's the sequence number must be reset each time ifCounterDiscontinuityTime changes. */ sflow_data_source source_id; /* sFlowDataSource */ counter_record counters<>; /* Counters polled for this source */ } /* Expanded Format Flow/Counter samples If ifIndex numbers may be >= 2^24 then the expanded must be used. */ v1.00 sFlow.org [Page 30] FINAL sFlow Version 5 July 2004 struct sflow_data_source_expanded { unsigned int source_id_type; /* sFlowDataSource type */ unsigned int source_id_index; /* sFlowDataSource index */ } struct interface_expanded { unsigned int format; /* interface format */ unsigned int value; /* interface value */ } /* Format of a single expanded flow sample */ /* opaque = sample_data; enterprise = 0; format = 3 */ struct flow_sample_expanded { unsigned int sequence_number; /* Incremented with each flow sample generated by this source_id. Note: If the agent resets the sample_pool then it must also reset the sequence_number.*/ sflow_data_source_expanded source_id; /* sFlowDataSource */ 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 of times that the sFlow agent detected that a packet marked to be sampled was dropped due to lack of resources. The drops counter reports the total number of drops detected since the agent was last reset. A high drop rate indicates that the management agent is unable to process samples as fast as they are being generated by hardware. Increasing sampling_rate will reduce the drop rate. Note: An agent that cannot detect drops will always report zero. */ interface_expanded input; /* Interface packet was received on. */ interface_expanded output; /* Interface packet was sent on. */ flow_record flow_records<>; /* Information about a sampled packet */ } /* Format of a single expanded counter sample */ /* opaque = sample_data; enterprise = 0; format = 4 */ v1.00 sFlow.org [Page 31] FINAL sFlow Version 5 July 2004 struct counters_sample_expanded { unsigned int sequence_number; /* Incremented with each counter sample generated by this source_id Note: If the agent resets any of the counters then it must also reset the sequence_number. In the case of ifIndex-based source_id's the sequence number must be reset each time ifCounterDiscontinuityTime changes. */ sflow_data_source_expanded source_id; /* sFlowDataSource */ counter_record counters<>; /* Counters polled for this source */ } /* Format of a sample datagram */ struct sample_record { data_format sample_type; /* Specifies the type of sample data */ opaque sample_data<>; /* A structure corresponding to the sample_type */ } /* Header information for sFlow version 5 datagrams The sub-agent field is used when an sFlow agent is implemented on a distributed architecture and where it is impractical to bring the samples to a single point for transmission. However, it is strongly recommended that wherever possible the sub-agent mechanism not be used. If multiple processors are available within a device the various tasks associated with creating flow and counter samples can be distributed among the processors. However, the agent should be architected so that all the samples are marshalled into a single datagram stream. The final marshalling task involved very little processing, but has important benefits in making the overall sFlow system scalable. By reducing the number of UDP packets and packet streams, the protocol overheads associated with sFlow are significantly reduced at the receiver. Each sFlowDataSource must be associated with only one sub-agent. The association between sFlowDataSource and sub-agent must remain constant for the entire duration of an sFlow session. */ struct sample_datagram_v5 { address agent_address /* IP address of sampling agent, sFlowAgentAddress. */ unsigned int sub_agent_id; /* Used to distinguishing between datagram streams from separate agent sub entities v1.00 sFlow.org [Page 32] FINAL sFlow Version 5 July 2004 within an device. */ unsigned int sequence_number; /* Incremented with each sample datagram generated by a sub-agent within an agent. */ unsigned int uptime; /* Current time (in milliseconds since device last booted). Should be set as close to datagram transmission time as possible. Note: While a sub-agents should try and track the global sysUptime value a receiver of sFlow packets must not assume that values are synchronised between sub-agents. */ sample_record samples<>; /* An array of sample records */ } enum datagram_version { VERSION5 = 5 } union sample_datagram_type (datagram_version version) { case VERSION5: sample_datagram_v5 datagram; } struct sample_datagram { sample_datagram_type version; } An sFlow Datagram contains lists of Packet Flow Records and counter records. The format of each Packet Flow Record is identified by a data_format value. The data_format name space is extensible, allowing for the addition of standard record types as well as vendor specific extensions. A number of standard record types have been defined. However, an sFlow Agent is not required to support all the different record types, only those applicable to its treatment of the particular packet being reporting on. For example, a layer 2 switch will not report on subnet information since it is not performing a routing function. A layer 2/3 switch will report layer 2 information for packets it switches, and layer 2 and 3 information for packets it routes. The following is an XDR description of the standard set of data records that can be carried in sFlow Datagrams: /* Proposed standard sFlow data formats (draft 14) */ v1.00 sFlow.org [Page 33] FINAL sFlow Version 5 July 2004 /* Revision History - version 5 Clarified extended_switch definitions for untagged ports Added CPU, memory utilization information Added mpls tunnel, virtual circuit and fec information Clarified next_hop definitions Added stripped count to sampled_header Added POS header_protocol Added BGP next hop router Clarify definition of packet length Remove limit on packet header size Adds host field to URL extension and clarifies url_direction Define url as http request-line Adds character set information to user data Adds NAT support Adds MPLS information - version 4 adds support for BGP communities - version 3 adds support for extended_url information */ /* Enterprise = 0 refers to standard sFlow structures. An sFlow implementor should use the standard structures where possible, even if they can only be partially populated. Vendor specific structures are allowed, but should only be used to supplement the existing structures, or to carry information that hasn't yet been standardized. The following values should be used for fields that are unknown (unless otherwise indicated in the structure definitions). - Unknown integer value. Use a value of 0 to indicate that a value is unknown. - Unknown counter. Use the maximum counter value to indicate that the counter is not available. Within any given sFlow session a particular counter must be always available, or always unavailable. An available counter may temporarily have the max value just before it rolls to zero. This is permitted. - Unknown string. Use the zero length empty string. */ /* Flow Data Types A flow_sample must contain packet header information. The prefered format for reporting packet header information is the sampled_header. However, if the packet header is not available to the sampling process then one or more of sampled_ethernet, sampled_ipv4, sampled_ipv6 may be used. */ v1.00 sFlow.org [Page 34] FINAL sFlow Version 5 July 2004 /* Packet Header Data */ /* The header_protocol enumeration may be expanded over time. Applications receiving sFlow must be prepared to receive sampled_header structures with unknown sampled_header values. The authoritative list of protocol numbers will be maintained at www.sflow.org */ enum header_protocol { ETHERNET-ISO88023 = 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, POS = 14 /* RFC 1662, 2615 */ } /* Raw Packet Header */ /* opaque = flow_data; enterprise = 0; format = 1 */ struct sampled_header { header_protocol protocol; /* Format of sampled header */ unsigned int frame_length; /* Original length of packet before sampling. Note: For a layer 2 header_protocol, length is total number of octets of data received on the network (excluding framing bits but including FCS octets). Hardware limitations may prevent an exact reporting of the underlying frame length, but an agent should attempt to be as accurate as possible. Any octets added to the frame_length to compensate for encapsulations removed by the underlying hardware must also be added to the stripped count. */ v1.00 sFlow.org [Page 35] FINAL sFlow Version 5 July 2004 unsigned int stripped; /* The number of octets removed from the packet before extracting the header<> octets. Trailing encapsulation data corresponding to any leading encapsulations that were stripped must also be stripped. Trailing encapsulation data for the outermost protocol layer included in the sampled header must be stripped. In the case of a non-encapsulated 802.3 packet stripped >= 4 since VLAN tag information might have been stripped off in addition to the FCS. Outer encapsulations that are ambiguous, or not one of the standard header_protocol must be stripped. */ opaque header<>; /* Header bytes */ } typedef opaque mac[6]; /* Ethernet Frame Data */ /* opaque = flow_data; enterprise = 0; format = 2 */ struct sampled_ethernet { unsigned int length; /* The length of the MAC packet received on the network, excluding lower layer encapsulations and framing bits but including FCS octets */ mac src_mac; /* Source MAC address */ mac dst_mac; /* Destination MAC address */ unsigned int type; /* Ethernet packet type */ } /* Packet IP version 4 data */ /* opaque = flow_data; enterprise = 0; format = 3 */ 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 */ v1.00 sFlow.org [Page 36] FINAL sFlow Version 5 July 2004 unsigned int tos; /* IP type of service */ } /* Packet IP Version 6 Data */ /* opaque = flow_data; enterprise = 0; format = 4 */ 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 */ } /* Extended Flow Data Extended data types provide supplimentary information about the sampled packet. All applicable extended flow records should be included with each flow sample. */ /* Extended Switch Data */ /* opaque = flow_data; enterprise = 0; format = 1001 */ /* Note: For untagged ingress ports, use the assigned vlan and priority of the port for the src_vlan and src_priority values. For untagged egress ports, use the values for dst_vlan and dst_priority that would have been placed in the 802.Q tag had the egress port been a tagged member of the VLAN instead of an untagged member. */ 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 */ } /* IP Route Next Hop ipForwardNextHop (RFC 2096) for IPv4 routes. ipv6RouteNextHop (RFC 2465) for IPv6 routes. */ typedef next_hop address; v1.00 sFlow.org [Page 37] FINAL sFlow Version 5 July 2004 /* Extended Router Data */ /* opaque = flow_data; enterprise = 0; format = 1002 */ struct extended_router { next_hop nexthop; /* IP address of next hop router */ unsigned int src_mask_len; /* Source address prefix mask (expressed as number of bits) */ unsigned int dst_mask_len; /* Destination address prefix mask (expressed as number of bits) */ } 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<>; } /* Extended Gateway Data */ /* opaque = flow_data; enterprise = 0; format = 1003 */ struct extended_gateway { next_hop nexthop; /* Address of the border router that should be used for the destination network */ 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 */ } /* Character Set MIBEnum value of character set used to encode a string - See RFC 2978 Where possible UTF-8 encoding (MIBEnum=106) should be used. A value of zero indicates an unknown encoding. */ typedef unsigned int charset; /* Extended User Data */ /* opaque = flow_data; enterprise = 0; format = 1004 */ struct extended_user { v1.00 sFlow.org [Page 38] FINAL sFlow Version 5 July 2004 charset src_charset; /* Character set for src_user */ opaque src_user<>; /* User ID associated with packet source */ charset dst_charset; /* Character set for dst_user */ opaque dst_user<>; /* User ID associated with packet destination */ } enum url_direction { src = 1, /* Source address is server */ dst = 2 /* Destination address is server */ } /* Extended URL Data */ /* opaque = flow_data; enterprise = 0; format = 1005 */ struct extended_url { url_direction direction; /* Direction of connection */ string url<>; /* The HTTP request-line (see RFC 2616) */ string host<>; /* The host field from the HTTP header */ } /* MPLS label stack - Empty stack may be returned if values unknown - If only innermost label is known then stack may contain single entry - See RFC 3032 for label encoding - Labels in network order */ typedef int label_stack<>; /* Extended MPLS Data */ /* opaque = flow_data; enterprise = 0; format = 1006 */ struct extended_mpls { next_hop nexthop; /* Address of the next hop */ label_stack in_stack; /* Label stack of received packet */ label_stack out_stack; /* Label stack for transmitted packet */ } /* Extended NAT Data Packet header records report addresses as seen at the sFlowDataSource. The extended_nat structure reports on translated source and/or destination addesses for this packet. If an address was not translated it should be equal to that reported for the header. */ /* opaque = flow_data; enterprise = 0; format = 1007 */ struct extended_nat { address src_address; /* Source address */ address dst_address; /* Destination address */ } v1.00 sFlow.org [Page 39] FINAL sFlow Version 5 July 2004 /* Extended MPLS Tunnel */ /* opaque = flow_data; enterprise = 0; format = 1008 */ struct extended_mpls_tunnel { string tunnel_lsp_name<>; /* Tunnel name */ unsigned int tunnel_id; /* Tunnel ID */ unsigned int tunnel_cos; /* Tunnel COS value */ } /* Extended MPLS VC */ /* opaque = flow_data; enterprise = 0; format = 1009 */ struct extended_mpls_vc { string vc_instance_name<>; /* VC instance name */ unsigned int vll_vc_id; /* VLL/VC instance ID */ unsigned int vc_label_cos; /* VC Label COS value */ } /* Extended MPLS FEC - Definitions from MPLS-FTN-STD-MIB mplsFTNTable */ /* opaque = flow_data; enterprise = 0; format = 1010 */ struct extended_mpls_FTN { string mplsFTNDescr<>; unsigned int mplsFTNMask; } /* Extended MPLS LVP FEC - Definition from MPLS-LDP-STD-MIB mplsFecTable Note: mplsFecAddrType, mplsFecAddr information available from packet header */ /* opaque = flow_data; enterprise = 0; format = 1011 */ struct extended_mpls_LDP_FEC { unsigned int mplsFecAddrPrefixLength; } /* Extended VLAN tunnel information Record outer VLAN encapsulations that have been stripped. extended_vlantunnel information should only be reported if all the following conditions are satisfied: 1. The packet has nested vlan tags, AND 2. The reporting device is VLAN aware, AND 3. One or more VLAN tags have been stripped, either because they represent proprietary encapsulations, or because switch hardware automatically strips the outer VLAN encapsulation. Reporting extended_vlantunnel information is not a substitute for v1.00 sFlow.org [Page 40] FINAL sFlow Version 5 July 2004 reporting extended_switch information. extended_switch data must always be reported to describe the ingress/egress VLAN information for the packet. The extended_vlantunnel information only applies to nested VLAN tags, and then only when one or more tags has been stripped. */ /* opaque = flow_data; enterprise = 0; format = 1012 */ extended_vlantunnel { unsigned int stack<>; /* List of stripped 802.1Q TPID/TCI layers. Each TPID,TCI pair is represented as a single 32 bit integer. Layers listed from outermost to innermost. */ } /* Counter Data Types Wherever possible, the if_counters block should be included. Media specific counters can be included as well. */ /* Generic Interface Counters - see RFC 2233 */ /* opaque = counter_data; enterprise = 0; format = 1 */ struct if_counters { unsigned int ifIndex; unsigned int ifType; unsigned hyper ifSpeed; unsigned int ifDirection; /* derived from MAU MIB (RFC 2668) 0 = unkown, 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 Interface Counters - see RFC 2358 */ v1.00 sFlow.org [Page 41] FINAL sFlow Version 5 July 2004 /* opaque = counter_data; enterprise = 0; format = 2 */ struct ethernet_counters { 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; } /* Token Ring Counters - see RFC 1748 */ /* opaque = counter_data; enterprise = 0; format = 3 */ struct tokenring_counters { 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; } /* 100 BaseVG interface counters - see RFC 2020 */ /* opaque = counter_data; enterprise = 0; format = 4 */ struct vg_counters { unsigned int dot12InHighPriorityFrames; unsigned hyper dot12InHighPriorityOctets; v1.00 sFlow.org [Page 42] FINAL sFlow Version 5 July 2004 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; } /* VLAN Counters */ /* opaque = counter_data; enterprise = 0; format = 5 */ struct vlan_counters { unsigned int vlan_id; unsigned hyper octets; unsigned int ucastPkts; unsigned int multicastPkts; unsigned int broadcastPkts; unsigned int discards; } /* Percentage expressed in hundredths of a percent (e.g. 100 = 1%). If a percentage value is unknown then use the value -1. */ typedef int percentage; /* Processor Information */ /* opaque = counter_data; enterprise = 0; format = 1001 */ struct processor { percentage 5s_cpu; /* 5 second average CPU utilization */ percentage 1m_cpu; /* 1 minute average CPU utilization */ percentage 5m_cpu; /* 5 minute average CPU utilization */ unsigned hyper total_memory /* total memory (in bytes) */ unsigned hyper free_memory /* free memory (in bytes) */ } The sFlow Datagram and data record specifications make use of definitions from a number of existing RFCs [22], [23], [24], [25], [26], [27], [28], [29], [30] and [31]. 6. Security Considerations v1.00 sFlow.org [Page 43] FINAL sFlow Version 5 July 2004 Deploying a traffic monitoring system raises a number of security related issues. sFlow does not provide specific security mechanisms, relying instead on proper deployment and configuration to maintain an adequate level of security. While the deployment of traffic monitoring systems does create some risk, it also provides a powerful means of detecting and tracing unauthorized network activity. This section is intended to provide information that will help understand potential risks and configuration options for mitigating those risks. 6.1 Configuration The sFlow MIB is used to configure the sFlow Agent. The security of SNMP, with access control lists, is usually considered adequate in an enterprise setting. However, there are situations when these security measures are insufficient (for example when configuring a core Internet router) and SNMP configuration control will be disabled. When SNMP is disabled, a command line interface is typically provided. The following arguments are required to configure sFlow sampling on an interface. -SFlowDataSource -sFlowFsPacketSamplingRate -sFlowFsMaximumHeaderSize
-sFlowCpInterval -sFlowRcvrMaximumDatagramSize -sFlowRcvrCollectorAddress
-sFlowRcvrCollectorPort If command line and SNMP control of the sFlow Agent coexist then an agent developer should either ensure that the two mechanisms operate independently or ensure that command line changes are reflected via the sFlow MIB. Typically command line changes will have priority over changes made via SNMP. Entries made through the command line should not be alterable via SNMP. Rows in each of the SNMP tables will then either belong to the command line (and not be alterable via SNMP), or belong to the SNMP agent, in which case they can be controlled using SNMP. 6.2 Transport Traffic information is sent unencrypted across the network from the sFlow Agent to the sFlow Collector and is thus vulnerable to evesdropping. This risk can be limited by creating a secure v1.00 sFlow.org [Page 44] FINAL sFlow Version 5 July 2004 measurement network and routing the sFlow Datagrams over this network. The choice of technology for creating the secure measurement network is deployment specific, but could include the use of VLANs and/or VPN tunnels. The sFlow Collector is vulnerable to attacks involving spoofed sFlow Datagrams. To limit this vulnerability the sFlow Collector should check sequence numbers and verify source addresses. If a secure measurement network has been constructed then only sFlow Datagrams received from that network should be processed. 6.3 Confidentiality Traffic information can reveal confidential information about individual network users. The degree of visibility of application level data can be controlled by limiting the number of header bytes captured by the sFlow Agent. In addition, packet sampling makes it virtually impossible to capture sequences of packets from an individual transaction. The traffic patterns discernable by decoding the sFlow Datagrams in the sFlow Collector can reveal details of an individuals network related activities and due care should be taken to secure access to the sFlow Collector. 7. References [1] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks", RFC 3176, September 2001. [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 Man- agement 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. v1.00 sFlow.org [Page 45] FINAL sFlow Version 5 July 2004 [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, "Introduc- tion 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 Pro- cessing 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 Con- trol 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] S. Waldbusser, "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. v1.00 sFlow.org [Page 46] FINAL sFlow Version 5 July 2004 [20] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. [21] N. Brownlee, "Traffic Flow Measurement: Meter MIB", RFC 2720, Octo- ber 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", RFC 2863, June 2000. [24] Flick, J., and J. Johnson, "Definition of Managed Objects for the Ethernet-like Interface Types", RFC 2358, June 1998. [25] J. Case, "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] J. Flick, "Definitions of Managed Objects for IEEE 802.12 Inter- faces", 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. [29] Baker, F. (Editor), "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [30] F. Baker, "IP Forwarding Table MIB", RFC 2096, January 1997. [31] D. Haskin and S. Onishi, "Management Information Base for IP Ver- sion 6", RFC 2465, December 1998. [32] R. Srinivasan, "XDR: External Data Representation Standard", RFC 1832, August 1995. 8. Author's Address Peter Phaal InMon Corp. 580 California Street, 5th Floor San Francisco, CA 94104 v1.00 sFlow.org [Page 47] FINAL sFlow Version 5 July 2004 Phone: (415) 283-3263 EMail: peter.phaal@inmon.com Marc Lavine Foundry Networks 2100 Gold Street P.O. Box 649100 San Jose, CA 95164-9100 Phone: (408) 586-1700 EMail: mlavine@foundrynet.com v1.00 sFlow.org [Page 48] FINAL sFlow Version 5 July 2004 Appendix A: Differences Between sFlow Versions 4 and 5 While the overall sFlow architecture has not changed, there have been numerous changes to the sFlow MIB and Datagram formats. These changes are described in detail in the revision histories contained in each of these specifications. The major difference in the sFlow version 5 MIB is the division of the sFlowTable into three separate tables: o sFlowRcvrTable, for maintaining a session with an sFlow collector. o sFlowFsTable, for configuring a packet sampling. o sFlowCpTable, for configuring interface counter polling. The major changes in the sFlow Datagram specification revolve around vendor extensibility. Records within the datagram now have tag, length and value information. A global name space is defined for record types, allowing implementors to add their own record types. Extensibility also permits the addition of new record types without requiring changes to the published sFlow protocol. v1.00 sFlow.org [Page 49] FINAL sFlow Version 5 July 2004 Appendix B: Random Number Generation The essential property of the random number generator is that the mean value of the numbers it generates converges to the required sampling rate. A uniform distribution random number generator is very effective. The range of skip counts (the variance) does not significantly affect results; even small random perturbations are sufficient to ensure that the sampling process will not synchronize with periodicity within the packet stream. The random number generator must ensure that all numbers in the range between its maximum and minimum values of the distribution are possible; a random number generator only capable of generating even numbers, or numbers with any common divisor is unsuitable. A new skip value is only required every time a sample is taken. v1.00 sFlow.org [Page 50]