Peter Phaal's guest appearances

Peter Phaal

The Full Feed - All of the Packet Pushers Podcasts

Packet Pushers - Community Show

OVS Orbit

Neil Moore

Tim Martin

Ramzi Marjaba

Anthony Sequeira

Bruce Davie

Orhan Ergun

Dana Iskoldski

Jeff Doyle

Beau Williamson

Josh Bailey

James Holland

Denise Fishburne

Chris Wahl

William Lam

Brian O'Connor

OwlTail

      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.    

Interview with Peter Phaal of <a href="http://www.inmon.com/" rel="nofollow" target="_blank">InMon</a>, about <a href="http://www.sflow.org" rel="nofollow" target="_blank">sFlow</a> 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: <blockquote> “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.” </blockquote> 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: <ul> <li> Use of sFlow for making <a href="https://en.wikipedia.org/wiki/Elephant_flow" rel="nofollow" target="_blank">elephant flows</a> coexist with mice, as <a href="http://opennetsummit.org/archives/mar14/site/pdf/2014/sdn-idol/Brocade-SDN-Idol-Proposal.pdf" rel="nofollow" target="_blank">demonstrated at ONS 2014</a>. </li> <li> How sFlow has managed to gain such wide hardware support. (Peter gives credit to Cisco for this.) </li> <li> sFlow implementation in <a href="http://www.p4.org" rel="nofollow" target="_blank">P4</a>. 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 <a href="http://p4.org/p4/inband-network-telemetry/" rel="nofollow" target="_blank">In-Band Network Telemetry</a>. Peter describes some of the pros and cons of in-band and out-of-band monitoring. </li> <li> How Open vSwitch came to InMon's attention back in 2010 and prompted them to contribute an sFlow implementation. </li> <li> <a href="http://mininet.org/overview/" rel="nofollow" target="_blank">Mininet</a> with sFlow and Open vSwitch. </li> <li> <a href="http://blog.sflow.com/2016/03/microservices.html" rel="nofollow" target="_blank">sFlow for microservices</a> and <a href="http://blog.sflow.com/2016/04/network-visibility-with-docker.html" rel="nofollow" target="_blank">Docker</a>. </li> <li> <a href="http://www.sflow.net/" rel="nofollow" target="_blank">Host sFlow</a> for monitoring entire hosts instead of just (physical or virtual) switches. </li> <li> How to choose an appropriate sampling rate. </li> <li> 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. </li> <li> Why sampling can be more accurate than capturing every packet, due to bias on overrun. </li> <li> Why loss due to use of UDP is not a problem for sFlow. </li> <li> Why sFlow is more future-proof than techniques that require the switch itself or the agent to more deeply analyze packets. “Software-Defined Analytics.” </li> <li> Using hardware and software implementations of sFlow together in a single network. </li> <li> Why sFlow is cheaper to implement in hardware (and software!) than IPFIX or NetFlow. </li> <li> Future directions for sFlow. </li> <li> Prime pitfall for sFlow in Open vSwitch: setting a 100% sampling rate. </li> <li> What should <a href="https://networkheresy.com/2015/01/13/ovn-bringing-native-virtual-networking-to-ovs/" rel="nofollow" target="_blank">OVN</a> do to support sFlow? (Answer: nothing is needed.) For this, see also the presentation that Peter gave at the <a href="http://openvswitch.org/support/ovscon2015/" rel="nofollow" target="_blank">Open vSwitch 2015 Fall Conference</a>. <a href="http://openvswitch.org/support/ovscon2015/16/1530-phaal.pdf" rel="nofollow" target="_blank">Slides</a> and <a href="https://www.youtube.com/watch?v=bkPNnrqeGjg" rel="nofollow" target="_blank">video</a> from the presentation are both available. Peter also made a related <a href="http://blog.sflow.com/2015/11/network-virtualization-visibility-demo.html" rel="nofollow" target="_blank">blog post</a>. </li> </ul> Further resources on sFlow include <a href="http://www.sflow.org" rel="nofollow" target="_blank">sflow.org</a> for the sFlow protocol, <a href="http://www.sflow.net" rel="nofollow" target="_blank">sflow.net</a> for the sFlow host agent, and Peter's blog at <a href="http://blog.sflow.com" rel="nofollow" target="_blank">blog.sflow.com</a>. You can find Peter on Twitter as <a href="https://twitter.com/sFlow" rel="nofollow" target="_blank">@sFlow</a>. OVS Orbit is produced by <a href="mailto:blp@ovn.org">Ben Pfaff</a>. The intro and bumper music is <a href="http://dig.ccmixter.org/files/myfreemickey/48180" rel="nofollow" target="_blank">Electro Deluxe</a>, featuring Gurdonack, copyright 2014 by My Free Mickey. The outro music is <a href="http://dig.ccmixter.org/files/JeffSpeed68/44932" rel="nofollow" target="_blank">Girls like you</a>, featuring Thespinwires, copyright 2014 by Stefan Kartenberg. All content is licensed under a Creative Commons <a href="http://creativecommons.org/licenses/by/3.0/" rel="nofollow" target="_blank">Attribution 3.0 Unported (CC BY 3.0)</a> license.

sFlow, with Peter Phaal from InMon

The inaugural "Non-Blocking" podcast for ForwardingPlane.net. We discuss sFlow with one if its creators, Peter Phaal of InMon.Discuss sFlow, the protocol, it's uses, similarities to other management frameworks, how it is dissimilar from netflow and why it is worth while to take some time to learn it.  The post Non-Blocking 1: sFlow with Peter Phaal of InMon and sFlow.org appeared first on Packet Pushers.

The inaugural "Non-Blocking" podcast for <a href="http://ForwardingPlane.net" rel="nofollow" target="_blank">ForwardingPlane.net</a>. We discuss sFlow with one if its creators, Peter Phaal of InMon.Discuss sFlow, the protocol, it's uses, similarities to other management frameworks, how it is dissimilar from netflow and why it is worth while to take some time to learn it. The post <a href="https://packetpushers.net/podcast/non-blocking-1-sflow-peter-phaal-inmon-sflow-org-2/" rel="nofollow" target="_blank">Non-Blocking 1: sFlow with Peter Phaal of InMon and sFlow.org</a> appeared first on <a href="https://packetpushers.net" rel="nofollow" target="_blank">Packet Pushers</a>.

Non-Blocking 1: sFlow with Peter Phaal of InMon and sFlow.org