On Fri, May 13, 2016 at 01:46:50AM -0700, Daniel Benli Ye wrote:
> In virtual evironment, IPFIX is unable to differentiate flows
> between pair of VMs on different virtual network if their IP/mac
> are same.
>
> Network:
> VM1 <---- VNI1 ----> VM3
> VM2 <---- VNI2 ----> VM4
>
> In terms of IP/mac:
> VM1 == VM2
> VM3 == VM4
>
> Send 10 packets each from VM1 - VM3 and VM2 - VM4
> Expectation:
> - Normal IPFIX record for 10 packets from VM1-VM3
> - Tunnel IPFIX record for 10 packets from VM1-VM3
> - Normal IPFIX record for 10 packets from VM2-VM4
> - Tunnel IPFIX record for 10 packets from VM2-VM4
> What really is:
> - Normal IPFIX record for 20 packets from VM1-VM3 (or VM2-VM4)
> - Tunnel IPFIX record for 10 packets from VM1-VM3
> - Tunnel IPFIX record for 10 packets from VM2-VM4
> IPFIX is unable to differentiate that VM1-VM3 and VM2-VM4 are actually
> 2 different flows for normal record.
>
> Add ingress and egress interface which are the ofp_port in the OVS
> bridge to differentiate the flows above.
>
> Signed-off-by: Daniel Benli Ye <dani...@vmware.com>
This introduces several warnings from "sparse":
../ofproto/ofproto-dpif-ipfix.c:1453:49: warning: cast to restricted
ovs_be32
../ofproto/ofproto-dpif-ipfix.c:1453:49: warning: cast from restricted
ofp_port_t
../ofproto/ofproto-dpif-ipfix.c:1453:49: warning: incorrect type in
argument 1 (different base types)
../ofproto/ofproto-dpif-ipfix.c:1453:49: expected unsigned int
[unsigned] [usertype] x
../ofproto/ofproto-dpif-ipfix.c:1453:49: got restricted ovs_be32
[usertype] <noident>
../ofproto/ofproto-dpif-ipfix.c:1454:48: warning: cast to restricted
ovs_be32
../ofproto/ofproto-dpif-ipfix.c:1454:48: warning: cast from restricted
ofp_port_t
../ofproto/ofproto-dpif-ipfix.c:1454:48: warning: incorrect type in
argument 1 (different base types)
../ofproto/ofproto-dpif-ipfix.c:1454:48: expected unsigned int
[unsigned] [usertype] x
../ofproto/ofproto-dpif-ipfix.c:1454:48: got restricted ovs_be32
[usertype] <noident>
Probably, you should use ofp_to_u16 instead of a bare cast:
> + data_common->ingress_interface =
> htonl((ovs_be32)flow->in_port.ofp_port);
> + data_common->egress_interface = htonl((ovs_be32)flow->actset_output);
Looking at the logic here, the use of the in_port makes sense; I can see
why the ingress interface would be of interest. However, actset_output
probably does not make sense, because most ways to output a packet to a
port do not set actset_output. You probably need to figure out some
other way to determine the output port (and what if the packet is output
to multiple ports?).
I do not understand IPFIX very well, so here is another question: when
we add new fields to a template, does existing software that understood
the previous template remain compatible with the new one?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
