[ovs-dev] [PATCH] sFlow export: include standard tunnel structures (for GRE, VXLAN etc.)

Romain Lenglet rlenglet at vmware.com
Sat Oct 19 00:59:33 UTC 2013


Hi Neil,

Sorry for the long delay to answer.

----- Original Message -----
> From: "Neil Mckee" <neil.mckee at inmon.com>
> To: "Jesse Gross" <jesse at nicira.com>
> Cc: dev at openvswitch.org
> Sent: Wednesday, October 9, 2013 12:33:35 PM
> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel	structures (for GRE, VXLAN etc.)
> 
> 
> On Oct 8, 2013, at 7:38 PM, Jesse Gross <jesse at nicira.com> wrote:
> 
> > I don't think that it's necessarily a given that the collector can see
> > both layers from the transit switches.
> 
> True,  if the tunnel is encrypted then the transit switch will see *only*
> the tunnel.   But the analyzer can still know what that traffic really is
> if it is also getting sFlow from the endpoints -- provided that sFlow
> exports the tunnel details too.
> 
> Cross-layer measurements like these can be very empowering.  When
> it comes to end-to-end performance analysis (sFlow's primary mission)
> the value lies not just in piercing the veil,  but shredding it.   For
> example,
> if the tunnel is causing congestion somewhere in the physical
> network then a policy might kick in to assess which originating
> vports are generating most of that traffic,  and mark only those
> packets to a lower priority using dscp-marking -- even if other
> packets on the same tunnel go out with normal dscp bits.  Other
> control choices might be to migrate one of the VMs;  use OpenFlow
> to override the packet-path for that tunnel;   rate-limit the vport, or even
> tap the vport traffic off for DPI security analysis.   The controller would
> have the information it needs to drive any of those control-decisions.
> In near real time.

I agree that this is use case is very interesting.
However, that's not the only use case for flow monitoring.
There is still a need to export only logical-level packet information without any physical information such as tunnel headers.

That's why we require you to make this feature optional, i.e. to add the ability to turn on/off the sending of tunnel information in sFlow reports.

> 
> > As I mentioned, I see tunnels
> > as form of abstraction and the goal of abstraction is to simplify
> > things by not having to deal with the complexity of multiple layers.
> > 
> 
> That's certainly true for some use-cases -- such as the tenant collector
> scenario you bring up.  I'll discuss that below,  but first consider what
> this option might do to the service-provider's analyzer.  The complexity
> of *not* knowing the tunnels is a bigger problem.   If the tunnel structures
> are omitted then the analyzer might not know whether the IP addresses
> it is seeing should be considered as "outer" addresses that will be acted on
> by routers,  or "inner" addresses from the tenant space -- that may even
> overlap with duplicate address space from other tenants.
> 
> Put another way,  always including the tunnel layer allows a network-aware
> consumer of the sFlow data to maintain a clean abstraction,  by always
> knowing which layer is which.

That's true for your specific use case, but that's not the only use case.

Consider the need to export virtual packet sFlow information to collectors managed by tenants of virtual machines. In this case, NOT exposing physical information such as tunnel headers is a requirement.

I consider the ability to turn this feature on/off as a requirement to accepting this patch.
--
Romain Lenglet

> > What happens if you have a tenant collector? In that case it doesn't
> > seem desirable to see the physical information because it's not
> > relevant and might change (an analogue would be seeing the physical
> > hardware from a VM).
> > 
> 
> If I have understood you correctly,  you are describing a scenario where
> the service-provider collects sFlow from the hypervisors,  separates it into
> separate feeds by tenant ID,  and then forwards those feeds back across
> the divide to a designated tenant-VM that can then run whatever analysis
> tools they want.  So it's a sort of "raw monitoring feed" service,  to
> recreate
> what the tenant would have had if they were running in their own data-center.
> Is that right?    In other words, recreating what the tenant could do today
> by
> running hsflowd+ULOG-sampling on their VMs,  or by paying for the
> Boundary service.  Yes?
> 
> My experience is that service providers like to offer higher-layer services
> that
> add more value.  Such as a portal page with real-time charts,  historical
> reporting and a RESTful query API.    They would want to run something like
> hsflowd on the hypervisors too so that the service can include real-time CPU,
> memory and IO counters per VM,  perhaps even allowing application-layer
> measurements from agents like mod-sflow, jmx-sflow-agent to be spliced in.
> 
> But even if they did want to offer the raw feed as a service too,  it still
> seems
> a lot easier to have the sFlow go first to a central collector.   Then from
> there it's
> quite straightforward to separate out a feed for each tenant that has
> subscribed
> for it.  And at that point they would naturally strip off the tunnel and LAG
> structures,
> and include only the packet samples and counter samples from that tenant's
> vports (along with sFlow-HOST samples for his per-VM CPU/mem/IO stats).
> 
> The ISP could also apply aggregation at the central sFlow collector,  and
> thereby offer (sampled) flow-records in IPFIX format to anyone that wanted
> them.
> Each tenant could dial-up whatever IPFIX template he wanted and it
> would start immediately with no config-change required to any OVS
> (that's really the point of the "RESTFlow" feature in sFlow-RT that I linked
> to before at http://blog.sflow.com/2013/08/restflow.html).
> 
> If the tenant wanted a sampling rate of 1-in-400 and the ISP only wanted
> 1-in-2000
> then it's easy enough to apply sub-sampling too,   so the ISP can get the
> feed it needs for end-to-end performance analysis,  and the tenants can get
> the
> feed they wanted too.   All without exploding the complexity of sFlow config
> in OVS.
> 
> So I guess I just don't see the upside in adding options to OVS.   It only
> seems to be inviting a complexity explosion.   Perhaps I missed something?
> 
> Neil
> 
> 
> 
> 
> > On Mon, Oct 7, 2013 at 10:45 AM, Neil Mckee <neil.mckee at inmon.com> wrote:
> >> Thanks for the prompt reply.
> >> 
> >> If the external sFlow analyzer always knows the difference between the
> >> outer (tunnel) and inner
> >> (tenant) layers, then it can present the appropriate abstraction depending
> >> on the application.  It
> >> can already see both layers from sFlow-enabled transit switches in the
> >> fabric,  so this patch is just
> >> filling out the picture.
> >> 
> >> For example,  (1) a routing application might only care to know the tunnel
> >> flows,   (2) a user-billing
> >> application might want to pull out the tenant traffic matrix and (3) a
> >> congestion-controller might want
> >> both so it can alleviate congestion somewhere (perhaps using selective
> >> dscp-marking).  The
> >> external sFlow analyzer(s) can supply each with the data they need.
> >> 
> >> So I don't see why you would ever want to turn the tunnel info off?   As
> >> soon as there is an option to
> >> turn it off then every consumer of the data would always have to worry
> >> that the outer traffic matrix was
> >> being polluted with tenant address-space, and manage the resulting
> >> state-explosion on both the
> >> configuration and the analysis side.  Better to have no option.
> >> 
> >> Neil
> >> 
> >> 
> >> On Oct 7, 2013, at 9:47 AM, Jesse Gross <jesse at nicira.com> wrote:
> >> 
> >>> On Sun, Oct 6, 2013 at 10:11 PM, Neil Mckee <neil.mckee at inmon.com> wrote:
> >>>> Please comment on this proposed patch.   It adds the standard
> >>>> sFlow-TUNNEL structures to the sFlow export,  which will be helpful
> >>>> for tracing tunneled traffic through a network fabric in real-time.
> >>> 
> >>> Is there a way to turn this off? Since tunnels are designed to provide
> >>> a layer of abstraction, it's not clear that it is always desirable to
> >>> expose this information.
> >> 
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
> 



More information about the dev mailing list