----- Original Message ----- > From: "Jesse Gross" <je...@nicira.com> > To: "Romain Lenglet" <rleng...@vmware.com> > Cc: "Neil Mckee" <neil.mc...@inmon.com>, dev@openvswitch.org > Sent: Friday, October 18, 2013 6:23:23 PM > Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel > structures (for GRE, VXLAN etc.) > > On Fri, Oct 18, 2013 at 5:58 PM, Romain Lenglet <rleng...@vmware.com> wrote: > > ----- Original Message ----- > >> From: "Jesse Gross" <je...@nicira.com> > >> To: "Romain Lenglet" <rleng...@vmware.com> > >> Cc: "Neil Mckee" <neil.mc...@inmon.com>, dev@openvswitch.org > >> Sent: Friday, October 18, 2013 5:50:05 PM > >> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel > >> structures (for GRE, VXLAN etc.) > >> > >> On Fri, Oct 18, 2013 at 5:43 PM, Romain Lenglet <rleng...@vmware.com> > >> wrote: > >> > ----- Original Message ----- > >> >> From: "Romain Lenglet" <rleng...@vmware.com> > >> >> To: "Neil Mckee" <neil.mc...@inmon.com> > >> >> Cc: dev@openvswitch.org > >> >> Sent: Wednesday, October 9, 2013 10:30:17 AM > >> >> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel > >> >> structures (for GRE, VXLAN etc.) > >> >> > >> >> On Oct 8, 2013, at 10:09 PM, Neil Mckee <neil.mc...@inmon.com> wrote: > >> >> > + /* Indicate 0==unknown for the src_port. It may be set to a > >> >> > random > >> >> > + number on a flow-by-flow basis to increase entropy for ECMP > >> >> > fabrics. > >> >> > + The assumption being made here is that it is not so important > >> >> > to > >> >> > + report this. At least not important enough to justify the > >> >> > effort > >> >> > + of making it accessible here. */ > >> >> > >> >> Exporting the source UDP source port is essential. > >> >> You also have to export the tunnel key: GRE key (32- or 64-bit), VNI > >> >> (24-bit), etc. > >> >> I don't see how this feature could be useful without the UDP source > >> >> port > >> >> and > >> >> tunnel key. > >> > > >> > I thought more about this. Exporting the source UDP port is really > >> > important. Since the source port is calculated in the tunnel port at > >> > egress during encapsulation and is lost at ingress during decapsulation, > >> > and the sampling here is done before encapsulation or after > >> > decapsulation, > >> > the easiest way I can imagine to determine the source port is to redo > >> > the > >> > hashing here. This would require factorizing the hashing code into a > >> > function that can be used in userspace in this code. > >> > >> I don't think that it's really viable to regenerate the hash used to > >> compute the source port. In the best case, we are the ones generating > >> it but the kernel hash function might change or the hash might come > >> from the NIC. In the worst case, when we receive a packet the hash > >> could have been generated by a non-OVS device with an unknown hash > >> algorithm > >> > > > > Yes, agreed, that's a problem. > > The only other alternative I can imagine to get the source UDP port is to > > do > > the sampling in the port (esp. in the tunnel port) in the datapath. > > This would be quite intrusive and complicated, as it would require the > > ports > > to do sampling and upcalls. > > I'd prefer to avoid that. > > Do you see any other alternative? > > I guess it's not entirely clear to me at this point why it's important > to record the UDP source port. Can you explain?
Identifying all the flows for a tunnel in the network is useful to detect changes in the routing of tunnel flows, which can e.g. be due to network failures (e.g. a link went down, and the flows are rerouted), and might impact the tunnel as a whole. This is useful for root cause analysis. If we didn't get all the tunnel flow headers from the hosts, we would lose some of the information. -- Romain Lenglet _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
