[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] flow-based tunnel installs arp drop rule in datapath
From:       jesse () nicira ! com (Jesse Gross)
Date:       2014-08-21 21:54:42
Message-ID: CAEP_g=-hzoqVJffHNnk5vguJA_z0-ZJyvNzjncESBRYt7vFcPw () mail ! gmail ! com
[Download RAW message or body]

This is not related to the port being shared in the kernel.

I don't know what you are really trying to do but if you say it works
correctly with port based tunnels, I guess the problem is that you
trying to send a flow from a tunnel back out to another tunnel.
OpenFlow explicitly disallows sending a packet out the original port
unless you use the special inport 'port'.

On Thu, Aug 21, 2014 at 1:19 PM, Sam Hague <shague86 at gmail.com> wrote:
> Thanks Jesse. I guess that is because down in the datapath that tunnel port
> is shared between the two bridges, right? Looks like the vxlan_sys_4789 is
> the only port created. Changing the dst_port creates a different port, but
> you would still end up sharing that port since you have to add the dst_port
> to both sides of the tunnel.
> 
> Is there any config to get around this issue? I tried changing the in_key,
> out_key, local_ip, remote_ip options and still had the same failure since
> all the permutations still ended up with the shared datapath tunnel port.
> 
> Thought I could outsmart ovs and added arp responder rules to return the
> arp; got past the arp issue, but then ip drop rules were installed.
> 
> Thanks, Sam
> 
> 
> On Wed, Aug 20, 2014 at 5:36 PM, Jesse Gross <jesse at nicira.com> wrote:
> > 
> > On Wed, Aug 20, 2014 at 2:58 PM, Sam Hague <shague86 at gmail.com> wrote:
> > > Hi,
> > > 
> > > why is an arp drop rule added in the datapath when two bridges are
> > > connected
> > > via a flow-based tunnel and both bridges are on the same host?
> > > 
> > > In the example picture I am attempting a ping from the client to the
> > > ws1.
> > > Two bridges, sff1 and 2, ports listed also. Flows programmed are below
> > > the
> > > picture. So arps from the client go into sff1(LOCAL), hit the broadcast
> > > rule
> > > and arp sent out the tunnel. In the datapath, though, is the arp drop
> > > rule
> > > so the arp request/response never completes.
> > > 
> > > If I put the sff2 bridge on a different host then everything works well.
> > > 
> > > I am guessing it is an issue with the shared datapath for both bridges
> > > when
> > > on the same host and using flow-based tunnels. If I switch to port-based
> > > tunnels then it works fine also. Is there some other config that can be
> > > added to the bridges or different flows that can be used?
> > > 
> > > sudo ovs-dpctl dump-flows
> > > 
> > > skb_priority(0),in_port(1),eth(src=f6:00:00:00:00:01/00:00:00:00:00:00,dst=ff:ff:ff:ff:ff:ff/01:00:00:00:00:00),eth_type(0x0806),
> > >  packets:0, bytes:0, used:never,
> > > 
> > > actions:set(tunnel(tun_id=0xa,src=192.168.120.45,dst=192.168.120.46,tos=0x0,ttl=64,flags(df,key))),2
> > >  
> > > skb_priority(0),tunnel(tun_id=0xa,src=192.168.120.45,dst=192.168.120.46,tos=0x0, \
> > > ttl=64,flags(key)),in_port(2),skb_mark(0),eth(src=f6:00:00:00:00:01/00:00:00:00:00:00,dst=ff:ff:ff:ff:ff:ff/01:00:00:00:00:00),eth_type(0x0806),
> > >  packets:0, bytes:0, used:never, actions:drop
> > 
> > I think this is hitting this flow:
> > sudo ovs-ofctl add-flow sff1
> > 
> > "dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=set_field:10->tun_id,set_field:192.168.120.46->tun_dst,set_field:192.168.120.45->tun_src,output:5"
> >  
> > Since this will send it back out the input port, it is dropped instead.
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]