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

Darrell Ball dball at vmware.com
Tue Mar 28 01:14:59 UTC 2017



On 3/23/17, 2:59 PM, "ovs-dev-bounces at openvswitch.org on behalf of Joo Kim" <ovs-dev-bounces at openvswitch.org on behalf of 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>
    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
    
    
    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
    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