From: Joo Kim <itsolut...@gmail.com> Date: Thursday, March 30, 2017 at 5:09 PM To: Darrell Ball <db...@vmware.com> Cc: "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org> Subject: Re: [ovs-dev] Fwd: In OVS2.6 userspace datapath, ARP handling for non-tunnel packet?
Thanks for reply Darrell. BTW, why we don't try to send ARP request for the non-tunnel traffic by default? If the mechanism(ARP handling via controller) you are describing is not installed, then in current OVS-2.6 userspace datapath, non-tunnel traffic is just dropped? In general, an Openflow switch supports routing with added rule configuration. MAC binding rules must be specifically added. This can be done statically as well, where the controller knows the MAC binding, from a CMS, which is statically configured and distributes this information -> controller -> switch. BTW, in the case of tunnels, there is both overlay and underlay mac bindings. Applications sitting on top of OVS, like OVN (for NFV), should provide support for mac bindings. Take a look at OVN (tests in ovn.at and system-ovn.at). On Mon, Mar 27, 2017 at 6:14 PM, Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>> wrote: On 3/23/17, 2:59 PM, "ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> on behalf of Joo Kim" <ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> on behalf of itsolut...@gmail.com<mailto:itsolut...@gmail.com>> wrote: Folks, Anybody knows about this ARP behavior in ovs2.6? -thanks- ---------- Forwarded message ---------- From: Joo Kim <itsolut...@gmail.com<mailto:itsolut...@gmail.com>> Date: Wed, Mar 22, 2017 at 3:58 AM Subject: In OVS2.6 userspace datapath, ARP handling for non-tunnel packet? To: ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org> Hello, Looks like build_tunnel_send() (which, I understand, is for tunnel packet) sends ARP request on the fly (using tnl_send_arp_request() ) when there is no ARP cache. Then, how about ARP handling for NON-tunnel packet (=> which does not call build_tunnel_send () )? Does it send arp request? Not by default (In the code, I don't find that kind of code) I think you are referring to resolving the hop b/w HVs, without using tunnels to connect said HVs, while using routing forwarding. In this case, the expected use is for there to be a rule installed to send the original packet to a controller, which would construct the arp request, send it back down to the switch, have the arp reply (another rule) sent to it and later installing the binding rule. This involves packet-ins/outs. #0 build_tunnel_send (xport=0xdbab10, tunnel_odp_port=3, flow=0x7fffffffb778, ctx=0x7fffffff9ac0) at ofproto/ofproto-dpif-xlate.c:2946 #1 compose_output_action__ (ctx=ctx@entry=0x7fffffffa160, ofp_port=2, xr=xr@entry=0x0, check_stp=check_stp@entry=true) at ofproto/ofproto-dpif-xlate.c: 3243 #2 0x00000000005d7bb2 in compose_output_action (xr=0x0, ofp_port=<optimized out>, ctx=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:3308 #3 output_normal (ctx=ctx@entry=0x7fffffffa160, out_xbundle=out_xbundle@entry=0xd96200, vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:1958 #4 0x00000000005d81f6 in xlate_normal_flood (ctx=ctx@entry =0x7fffffffa160, in_xbundle=in_xbundle@entry=0xd9b3e0, vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:2401 #5 0x00000000005d89ad in xlate_normal (ctx=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:2604 #6 xlate_output_action (ctx=ctx@entry=0x7fffffffa160, port=<optimized out>, max_len=<optimized out>, may_packet_in=may_packet_in@entry=true) at ofproto/ofproto-dpif-xlate.c:3981 #7 0x00000000005d51ee in do_xlate_actions (ofpacts=ofpacts@entry= 0xd99ae8, ofpacts_len=ofpacts_len@entry=16, ctx=ctx@entry=0x7fffffffa160) at ofproto/ofproto-dpif-xlate.c:4781 #8 0x00000000005da384 in xlate_actions (xin=xin@entry=0x7fffffffb770, xout=xout@entry=0x7fffffffbb00) at ofproto/ofproto-dpif-xlate.c: 5618 #9 0x00000000005cec3c in upcall_xlate (wc=0x7fffffffce58, odp_actions=0x7fffffffc680, upcall=0x7fffffffbaa0, udpif=0xd479b0) at ofproto/ofproto-dpif-upcall.c:1102 #10 process_upcall (udpif=udpif@entry=0xd479b0, upcall=upcall@entry= 0x7fffffffbaa0, odp_actions=odp_actions@entry=0x7fffffffc680, wc=wc@entry =0x7fffffffce58) _______________________________________________ dev mailing list d...@openvswitch.org<mailto:d...@openvswitch.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=grsVZ3eXMxJ9_ta4SIIRRhFhYcRMDJ0x3XzWaI7xSV8&s=DP1FHEMujvEevhithC2uOnBMI0o8ph5_C1xrAoKJQ2E&e= _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
