Hi Neil,
Thanks a lot for your prompt reply.
We are glad that ovs 2.5.0 report outer tunnel information which can help
us to locate physical node of the flows, by which we can pin down network
problems easily, that's why we are evaluating it, thanks a lot for the work
of you and community.
Regar
I have submitted a patch to fix this. Sorry for the trouble.
You are right that it is not essential for OVS to report the tunnel
type. Just the fact that there was a tunnel at all is the most
important information because it tells you the source/destination
addresses you see in the sampled packe
Hi Neil,
There is another question regarding the issue, seems dpif_sflow_add_port
will call dpif_sflow_del_port port every time, does this is intended to
remove previously added dsp since dp_port might be same for different
tunnel port?
2016-08-29 11:16 GMT+08:00 张东亚 :
> Hi Neil,
>
> Seems that
Hi Neil,
Seems that's a possible fix because in most case, there might not be mixed
tunnel types, set tunnel type to unknown will not affect analysis much.
However, seems this patch is also present on master branch, I am wondering
the stability and test coverity of sFlow feature of OVS.
Since we
I think it would be OK to do this:
tnlInProto = in_dsp ? dpif_sflow_tunnel_proto(in_dsp->tunnel_type) : 0;
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Aug 26, 2016 at 2:30 AM, 张东亚 wrote:
> Hi List,
>
> Recently we are testing sFlow on OVS 2.5.0, since OVS decide whether d
Hi List,
Recently we are testing sFlow on OVS 2.5.0, since OVS decide whether do
sample based on ingress bridge, we then enable sFlow on br-tun, and
encounter following crash:
#0 0x00434ca8 in dpif_sflow_received (ds=0x4266100,
packet=packet@entry=0x7f3cb3fc8e18, flow=flow@entry=0x7f3cb3
