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

Daniel Ye daniely at vmware.com
Mon Jul 18 03:18:53 UTC 2016


Hi Ben,

Sorry for replying so late. I agreed with your point and I think using ofp-ports is enough. Because it's not a receiver problem,
users can use virtual_obs_id or different IPFIX configuration on different bridges to differentiate the flows. It's the problem of sender,
it's about the function ipfix_cache_entry_init() and the hash key 'ipfix_flow_key'. In the case with same  IP/mac and protocol,
'ipfix_flow_key' will be the same and packets come from different VM will be hashed in the same entry. However, I haven't figured out a
better way to get the ofp-ports in dpif-ipfix module. One way is to put the map of odp_port and ofp_port in a new hash map, but it looks
weird and it will introduce more overload. Do you have any comments or advices on this? Thanks.

Bests,
Daniel Benli Ye

-----Original Message-----
From: Ben Pfaff [mailto:blp at ovn.org] 
Sent: Tuesday, July 05, 2016 7:43 AM
To: Daniel Ye <daniely at vmware.com>
Cc: Ben Pfaff <bpfaff at vmware.com>; Justin Pettit <jpettit at vmware.com>; Wenyu Zhang <wenyuz at vmware.com>; Wang Qiong <wqiong at vmware.com>; dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2] ipfix: Add ingress and egress interface in exporting flows

The odp_ports aren't meaningful at all outside of OVS, so they're almost worthless.  How do you intend for the receiver to interpret them?

If the IPFIX record doesn't otherwise say what bridge the ofp_ports correspond to, then I suggest adding some way to identify the bridge; for example, you could use the bridge's name, as a string, or its OpenFlow datapath_id (a 64-bit integer).

On Mon, Jul 04, 2016 at 11:35:14PM +0000, Daniel Ye wrote:
> Hi Ben,
> 
> Thanks for review. In my opinion, the ofp_port may be the same on 
> different bridge. If so, we still don’t differentiate the flows in this scenario. That’s why I choose to use odd_port.
> 
> Bests,
> Daniel
> > On Jul 5, 2016, at 5:22 AM, Ben Pfaff <blp at ovn.org> wrote:
> > 
> > On Thu, Jun 30, 2016 at 08:48:43PM -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 odp_port in the OVS 
> >> bridge to differentiate the flows above. Use IPFIX Information 
> >> Element identifiers "ingressInterface" and "egressInterface" in 
> >> rfc5102 to carry the information.
> >> 
> >> Signed-off-by: Benli Ye <daniely at vmware.com>
> >> 
> >> ---
> >> v1 -> v2:
> >> - Use 32bit odp_port instead of ofp_port.
> >> - Fix some "sparse" warnings.
> > 
> > I don't understand why this switches from ofp_port to odp_port.  The 
> > ODP port numbers are not part of the Open vSwitch external 
> > interface; they are only an implementation detail.
> 


More information about the dev mailing list