[ovs-dev] [PATCH v1] ipfix: Add ingress and egress interface in exporting flows

Wenyu Zhang wenyuz at vmware.com
Thu May 19 03:54:37 UTC 2016



On 5/17/16, 3:43 AM, "Ben Pfaff" <blp at ovn.org> wrote:

>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 <daniely at 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?

Wenyu: According RFC(7011), IPFIX export need send templates to the
collector periodically, and the collector should decode the data according
the newest templates received.
       So the templates can be changed dynamically, the collector should
decode all fields, including the new field correctly.

       And considering that the new field is an enterprise element, not a
standard element. The existing software may not know the meaning of the
new field, but it should know the existing fields which are in both the
old templates and new templates.




More information about the dev mailing list