Sign up to save your podcasts
Or
Share sFlow, with Peter Phaal from InMon
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
sFlow, with Peter Phaal from InMon
Interview with Peter Phaal of InMon,
about sFlow monitoring and how it is
used with Open vSwitch. In summary, an sFlow agent in a switch (such as
Open vSwitch or a hardware switch) selects a specified statistical sample
of packets that pass through it, along with information on how the packet
was treated (e.g. a FIB entry in a conventional switch or OpenFlow
actions in Open vSwitch) and sends them across the network to an sFlow
collector. sFlow agents also periodically gather up interface counters
and other statistics and send them to collectors. Data collected from
one or more switches can then be analyzed to learn useful properties of
the network.
Peter begins with a description of the history of sFlow, including its
pre-history in network monitoring products that Peter was involved in at
HP Labs in Bristol. At the time, network monitoring did not require a
special protocol such as sFlow, because networks were based on a shared
medium to which any station could listen. With the advent of switched
networks, the crossbar inside each switch effectively became the shared
medium and required a protocol such as sFlow to look inside.
Peter compares the data collected by sFlow to a “ship in a bottle,” a
shrunken model of the network on which one can later explore route
analytics, load balancing, volumetric billing, load balancing, and more.
He says that SDN has empowered users of sFlow by providing a control
plane in which one can better act on the information obtained from
analytics:
“If you see a DDoS attack, you drop a filter in and it's removed from
the network. If you see a large elephant flow taking a path that's
congested, you apply a rule to move it to an alternative path. So it
really unlocks the value of the analytics, having a control plan that's
programmable, and so I think the analytics and control really go
hand-in-hand.”
sFlow can be used in real time or for post-facto analysis. The latter is
more common historically, but Peter thinks that the potential for
real-time control are exciting current developments.
In contrast to NetFlow and IPFIX, sFlow exports relatively raw data for
later analysis. Data collected by sFlow can be later converted,
approximately, into NetFlow or IPFIX formats.
Other topics:
Use of sFlow for making elephant flows
coexist with mice, as demonstrated
at ONS 2014.
How sFlow has managed to gain such wide hardware support. (Peter gives
credit to Cisco for this.)
sFlow implementation in P4. P4 can
make it easier to add new statistics reporting to sFlow, such as the
ability to report the total latency that a packet observed in passing
through a switch or the queuing delay or queue depth that it
experienced, statistics similar to those which P4 has already been
applied for In-Band Network
Telemetry. Peter describes some of the pros and cons of in-band
and out-of-band monitoring.
How Open vSwitch came to InMon's attention back in 2010 and prompted
them to contribute an sFlow implementation.
Mininet with sFlow and Open
vSwitch.
sFlow for
microservices and Docker.
Host sFlow for monitoring entire
hosts instead of just (physical or virtual) switches.
How to choose an appropriate sampling rate.
Why sampling rates based on time (e.g. sampling N packets per second)
instead of event-based sampling (e.g. N packets out of 1000) is
horribly biased.
Why sampling can be more accurate than capturing every packet, due to
bias on overrun.
Why loss due to use of UDP is not a problem for sFlow.
Why sFlow is more future-proof than techniques that require the switch
itself or the agent to more deeply analyze packets. “Software-Defined
Analytics.”
Using hardware and software implementations of sFlow together in a
single network.
Why sFlow is cheaper to implement in hardware (and software!) than
IPFIX or NetFlow.
Future directions for sFlow.
Prime pitfall for sFlow in Open vSwitch: setting a 100% sampling rate.
What should OVN
do to support sFlow? (Answer: nothing is needed.) For this, see also
the presentation that Peter gave at the Open vSwitch 2015
Fall Conference. Slides
and video
from the presentation are both available. Peter also made a related blog
post.
Further resources on sFlow include sflow.org for the sFlow protocol, sflow.net for the sFlow host agent, and
Peter's blog at blog.sflow.com.
You can find Peter on Twitter as @sFlow.
OVS Orbit is produced by Ben Pfaff. The
intro and bumper music is Electro
Deluxe, featuring Gurdonack, copyright 2014 by My Free Mickey. The
outro music is Girls like
you, featuring Thespinwires, copyright 2014 by Stefan Kartenberg.
All content is licensed under a Creative Commons Attribution 3.0
Unported (CC BY 3.0) license.
View all episodes
By Ben Pfaff
5
11 ratings
Interview with Peter Phaal of InMon,
about sFlow monitoring and how it is
used with Open vSwitch. In summary, an sFlow agent in a switch (such as
Open vSwitch or a hardware switch) selects a specified statistical sample
of packets that pass through it, along with information on how the packet
was treated (e.g. a FIB entry in a conventional switch or OpenFlow
actions in Open vSwitch) and sends them across the network to an sFlow
collector. sFlow agents also periodically gather up interface counters
and other statistics and send them to collectors. Data collected from
one or more switches can then be analyzed to learn useful properties of
the network.
Peter begins with a description of the history of sFlow, including its
pre-history in network monitoring products that Peter was involved in at
HP Labs in Bristol. At the time, network monitoring did not require a
special protocol such as sFlow, because networks were based on a shared
medium to which any station could listen. With the advent of switched
networks, the crossbar inside each switch effectively became the shared
medium and required a protocol such as sFlow to look inside.
Peter compares the data collected by sFlow to a “ship in a bottle,” a
shrunken model of the network on which one can later explore route
analytics, load balancing, volumetric billing, load balancing, and more.
He says that SDN has empowered users of sFlow by providing a control
plane in which one can better act on the information obtained from
analytics:
“If you see a DDoS attack, you drop a filter in and it's removed from
the network. If you see a large elephant flow taking a path that's
congested, you apply a rule to move it to an alternative path. So it
really unlocks the value of the analytics, having a control plan that's
programmable, and so I think the analytics and control really go
hand-in-hand.”
sFlow can be used in real time or for post-facto analysis. The latter is
more common historically, but Peter thinks that the potential for
real-time control are exciting current developments.
In contrast to NetFlow and IPFIX, sFlow exports relatively raw data for
later analysis. Data collected by sFlow can be later converted,
approximately, into NetFlow or IPFIX formats.
Other topics:
Use of sFlow for making elephant flows
coexist with mice, as demonstrated
at ONS 2014.
How sFlow has managed to gain such wide hardware support. (Peter gives
credit to Cisco for this.)
sFlow implementation in P4. P4 can
make it easier to add new statistics reporting to sFlow, such as the
ability to report the total latency that a packet observed in passing
through a switch or the queuing delay or queue depth that it
experienced, statistics similar to those which P4 has already been
applied for In-Band Network
Telemetry. Peter describes some of the pros and cons of in-band
and out-of-band monitoring.
How Open vSwitch came to InMon's attention back in 2010 and prompted
them to contribute an sFlow implementation.
Mininet with sFlow and Open
vSwitch.
sFlow for
microservices and Docker.
Host sFlow for monitoring entire
hosts instead of just (physical or virtual) switches.
How to choose an appropriate sampling rate.
Why sampling rates based on time (e.g. sampling N packets per second)
instead of event-based sampling (e.g. N packets out of 1000) is
horribly biased.
Why sampling can be more accurate than capturing every packet, due to
bias on overrun.
Why loss due to use of UDP is not a problem for sFlow.
Why sFlow is more future-proof than techniques that require the switch
itself or the agent to more deeply analyze packets. “Software-Defined
Analytics.”
Using hardware and software implementations of sFlow together in a
single network.
Why sFlow is cheaper to implement in hardware (and software!) than
IPFIX or NetFlow.
Future directions for sFlow.
Prime pitfall for sFlow in Open vSwitch: setting a 100% sampling rate.
What should OVN
do to support sFlow? (Answer: nothing is needed.) For this, see also
the presentation that Peter gave at the Open vSwitch 2015
Fall Conference. Slides
and video
from the presentation are both available. Peter also made a related blog
post.
Further resources on sFlow include sflow.org for the sFlow protocol, sflow.net for the sFlow host agent, and
Peter's blog at blog.sflow.com.
You can find Peter on Twitter as @sFlow.
OVS Orbit is produced by Ben Pfaff. The
intro and bumper music is Electro
Deluxe, featuring Gurdonack, copyright 2014 by My Free Mickey. The
outro music is Girls like
you, featuring Thespinwires, copyright 2014 by Stefan Kartenberg.
All content is licensed under a Creative Commons Attribution 3.0
Unported (CC BY 3.0) license.