[ovs-dev] Fwd: In OVS2.6 userspace datapath, ARP handling for non-tunnel packet?

Darrell Ball dball at vmware.com
Fri Mar 31 18:12:01 UTC 2017



From: Joo Kim <itsolution at gmail.com>
Date: Thursday, March 30, 2017 at 5:09 PM
To: Darrell Ball <dball at vmware.com>
Cc: "ovs-dev at openvswitch.org" <ovs-dev at 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 <dball at vmware.com<mailto:dball at vmware.com>> wrote:


On 3/23/17, 2:59 PM, "ovs-dev-bounces at openvswitch.org<mailto:ovs-dev-bounces at openvswitch.org> on behalf of Joo Kim" <ovs-dev-bounces at openvswitch.org<mailto:ovs-dev-bounces at openvswitch.org> on behalf of itsolution at gmail.com<mailto:itsolution at gmail.com>> wrote:

    Folks,

    Anybody knows  about this ARP behavior in ovs2.6?   -thanks-


    ---------- Forwarded message ----------
    From: Joo Kim <itsolution at gmail.com<mailto:itsolution at 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 at openvswitch.org<mailto:ovs-dev at 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 at entry=0x7fffffffa160, ofp_port=2,
    xr=xr at entry=0x0,
             check_stp=check_stp at 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 at entry=0x7fffffffa160,
    out_xbundle=out_xbundle at entry=0xd96200,
             vlan=vlan at entry=0) at ofproto/ofproto-dpif-xlate.c:1958
         #4  0x00000000005d81f6 in xlate_normal_flood (ctx=ctx at entry
    =0x7fffffffa160,
             in_xbundle=in_xbundle at entry=0xd9b3e0, vlan=vlan at 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 at entry=0x7fffffffa160, port=<optimized
    out>,
             max_len=<optimized out>, may_packet_in=may_packet_in at entry=true)
             at ofproto/ofproto-dpif-xlate.c:3981
         #7  0x00000000005d51ee in do_xlate_actions (ofpacts=ofpacts at entry=
    0xd99ae8,
             ofpacts_len=ofpacts_len at entry=16, ctx=ctx at entry=0x7fffffffa160)
             at ofproto/ofproto-dpif-xlate.c:4781
         #8  0x00000000005da384 in xlate_actions (xin=xin at entry=0x7fffffffb770,
             xout=xout at 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 at entry=0xd479b0, upcall=upcall at entry=
    0x7fffffffbaa0,
             odp_actions=odp_actions at entry=0x7fffffffc680, wc=wc at entry
    =0x7fffffffce58)
    _______________________________________________
    dev mailing list
    dev at openvswitch.org<mailto:dev at 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=








More information about the dev mailing list