| Message ID | 1467344923-357-1-git-send-email-daniely@vmware.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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@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.
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@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@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.
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@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@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. >
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@ovn.org] Sent: Tuesday, July 05, 2016 7:43 AM To: Daniel Ye <daniely@vmware.com> Cc: Ben Pfaff <bpfaff@vmware.com>; Justin Pettit <jpettit@vmware.com>; Wenyu Zhang <wenyuz@vmware.com>; Wang Qiong <wqiong@vmware.com>; dev@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@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@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. >
diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipfix.c index 5744abb..4858ed5 100644 --- a/ofproto/ofproto-dpif-ipfix.c +++ b/ofproto/ofproto-dpif-ipfix.c @@ -253,8 +253,10 @@ struct ipfix_data_record_flow_key_common { struct eth_addr destination_mac_address; /* DESTINATION_MAC_ADDRESS */ ovs_be16 ethernet_type; /* ETHERNET_TYPE */ uint8_t ethernet_header_length; /* ETHERNET_HEADER_LENGTH */ + ovs_be32 ingress_interface; /* INGRESS_INTERFACE */ + ovs_be32 egress_interface; /* EGRESS_INTERFACE */ }); -BUILD_ASSERT_DECL(sizeof(struct ipfix_data_record_flow_key_common) == 20); +BUILD_ASSERT_DECL(sizeof(struct ipfix_data_record_flow_key_common) == 28); /* Part of data record flow key for VLAN entities. */ OVS_PACKED( @@ -1156,6 +1158,8 @@ ipfix_define_template_fields(enum ipfix_proto_l2 l2, enum ipfix_proto_l3 l3, DEF(DESTINATION_MAC_ADDRESS); DEF(ETHERNET_TYPE); DEF(ETHERNET_HEADER_LENGTH); + DEF(INGRESS_INTERFACE); + DEF(EGRESS_INTERFACE); if (l2 == IPFIX_PROTO_L2_VLAN) { DEF(VLAN_ID); @@ -1576,7 +1580,8 @@ static enum ipfix_sampled_packet_type ipfix_cache_entry_init(struct ipfix_flow_cache_entry *entry, const struct dp_packet *packet, const struct flow *flow, uint64_t packet_delta_count, uint32_t obs_domain_id, - uint32_t obs_point_id, odp_port_t output_odp_port, + uint32_t obs_point_id, odp_port_t input_odp_port, + odp_port_t output_odp_port, const struct dpif_ipfix_port *tunnel_port, const struct flow_tnl *tunnel_key) { @@ -1668,6 +1673,8 @@ ipfix_cache_entry_init(struct ipfix_flow_cache_entry *entry, data_common->destination_mac_address = flow->dl_dst; data_common->ethernet_type = flow->dl_type; data_common->ethernet_header_length = ethernet_header_length; + data_common->ingress_interface = htonl(odp_to_u32(input_odp_port)); + data_common->egress_interface = htonl(odp_to_u32(output_odp_port)); } if (l2 == IPFIX_PROTO_L2_VLAN) { @@ -1904,7 +1911,8 @@ static void dpif_ipfix_sample(struct dpif_ipfix_exporter *exporter, const struct dp_packet *packet, const struct flow *flow, uint64_t packet_delta_count, uint32_t obs_domain_id, - uint32_t obs_point_id, odp_port_t output_odp_port, + uint32_t obs_point_id, odp_port_t input_odp_port, + odp_port_t output_odp_port, const struct dpif_ipfix_port *tunnel_port, const struct flow_tnl *tunnel_key) { @@ -1916,8 +1924,8 @@ dpif_ipfix_sample(struct dpif_ipfix_exporter *exporter, sampled_packet_type = ipfix_cache_entry_init(entry, packet, flow, packet_delta_count, obs_domain_id, obs_point_id, - output_odp_port, tunnel_port, - tunnel_key); + input_odp_port, output_odp_port, + tunnel_port, tunnel_key); ipfix_cache_update(exporter, entry, sampled_packet_type); } @@ -1980,7 +1988,8 @@ dpif_ipfix_bridge_sample(struct dpif_ipfix *di, const struct dp_packet *packet, packet_delta_count, di->bridge_exporter.options->obs_domain_id, di->bridge_exporter.options->obs_point_id, - output_odp_port, tunnel_port, tunnel_key); + input_odp_port, output_odp_port, + tunnel_port, tunnel_key); ovs_mutex_unlock(&mutex); } @@ -2023,7 +2032,8 @@ dpif_ipfix_flow_sample(struct dpif_ipfix *di, const struct dp_packet *packet, packet_delta_count, cookie->flow_sample.obs_domain_id, cookie->flow_sample.obs_point_id, - output_odp_port, tunnel_port, tunnel_key); + input_odp_port, output_odp_port, + tunnel_port, tunnel_key); } ovs_mutex_unlock(&mutex); }
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@vmware.com> --- v1 -> v2: - Use 32bit odp_port instead of ofp_port. - Fix some "sparse" warnings. --- --- ofproto/ofproto-dpif-ipfix.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-)