I think that you might be encountering a perhaps surprising property of
the "learn" action.  If I recall correctly, the way we implemented
"learn", the change that it makes are only visible to packets that
traverse the OVS pipeline *after* the current packet finishes its
traversal.  This works fine for the leading use case, which is MAC
learning.  If you want the learned table entry to be used in the same
trip through the pipeline, then you'll probably have to add some special
cases to the pipeline to make OVS act as if that were the case.

Probably, we should document this.  The behavior has actually changed
over time, so that before OVS 2.2 or so (at a guess), the behavior was
different.

On Wed, Apr 05, 2017 at 01:11:13PM -0400, satish kondapalli wrote:
> Hi,
> 
> I have ixia setup with two ports and ports are connected to two 10G Nic
> cards. On server, NIC interfaces are added to ovs bridge.
> 
> In Ixia setup, configured http client on first port and second port runs
> http server. With this setup, i can simulate multiple http concurrent
> connections.
> 
> 
> These are the rules i wrote to create a flow for every connection. These
> rules doesn't make any sense but for my testing purpose it creates the flow
> for each connection.
> 
> ovs-vsctl add-br br0
> ovs-vsctl add-port br0 eth0 -- set interface eth0 ofport=1
> ovs-vsctl add-port br0 eth1 -- set interface eth1 ofport=2
> ifconfig eth0 up
> ifconfig eth1 up
> 
> ovs-ofctl mod-port br0 br0 noflood
> ovs-ofctl del-flows br0
> 
> 
> #table 0, redirect the traffic to right tables.
> ovs-ofctl add-flow br0 "table=0, priority=10,in_port=1,tcp,
> actions=resubmit(,10)"
> ovs-ofctl add-flow br0 "table=0, priority=1,arp,actions=normal"
> 
> #table 2,learns the flow from the packet and adds the flow to TABLE 10.
> next time this packet is seen, will directly hit that learned flow
> ovs-ofctl add-flow br0 \
>                 "table=2,priority=10,in_port=1,tcp,actions=learn(table=10,
> priority=10, hard_timeout=60000, \
>                              eth_type=0x800,  nw_proto=6, \
>                              NXM_OF_ETH_SRC[]=NXM_OF_ETH_SRC[], \
>                              NXM_OF_ETH_DST[]=NXM_OF_ETH_DST[], \
>                              NXM_OF_IP_DST[]=NXM_OF_IP_DST[],
> NXM_OF_IP_SRC[]=NXM_OF_IP_SRC[],\
>                              NXM_OF_TCP_DST[]=NXM_OF_TCP_DST[],
> NXM_OF_TCP_SRC[]=NXM_OF_TCP_SRC[], \
>                              output:NXM_NX_REG2[]),\
>                                 resubmit(,10)"
> 
> ##Add a low priority action to redirect to table 2. Here lerned actions are
> processed first. if no learned flows are present, will hit this
> #flow to redirect to table 2, which will learn the flow and add to table 10
> ovs-ofctl add-flow br0 "table=10, priority=1,in_port=1,tcp,
> actions=load:2->NXM_NX_REG2[],resubmit(,2)"
> 
> ovs-ofctl add-flow br0 "table=0, in_port=2, tcp, action=1"
> 
> When i am testing with above configured rules i found some mismatch between
> dpctl dump-flows and ofctl dump-flows.  For some connections dpctl
> dump-flows showing action as a drop but ofctl dump-flows showing action as
> forward to port 2. I am assuming beacuse of  the drop action, we are seeing
> very low connection rate with OVS.
> Here is difference:
> dpctl dump-flows:
> *recirc_id(0),in_port(2),eth(src=00:01:00:00:01:00,dst=00:01:0a:00:01:00),eth_type(0x0800),ipv4(src=1.0.0.1,dst=1.10.0.1,proto=6,frag=no),tcp(src=13824,dst=80),
> packets:1, bytes:70, used:0.172s, flags:S, actions:drop*
> recirc_id(0),in_port(2),eth(src=00:01:00:00:01:00,dst=00:
> 01:0a:00:01:00),eth_type(0x0800),ipv4(src=1.0.0.1,dst=
> 1.10.0.1,proto=6,frag=no),tcp(src=9988,dst=80), packets:5, bytes:531,
> used:9.772s, flags:SFP., actions:3
> recirc_id(0),in_port(2),eth(src=00:01:00:00:01:00,dst=00:
> 01:0a:00:01:00),eth_type(0x0800),ipv4(src=1.0.0.1,dst=
> 1.10.0.1,proto=6,frag=no),tcp(src=10321,dst=80), packets:6, bytes:601,
> used:6.764s, flags:SFP., actions:3
> ofctl dump-flows:
> *cookie=0x0, duration=46.951s, table=10, n_packets=7, n_bytes=671,
> hard_timeout=60000, idle_age=46,
> priority=10,tcp,dl_src=00:01:00:00:01:00,dl_dst=00:01:0a:00:01:00,nw_src=1.0.0.1,nw_dst=1.10.0.1,tp_src=13824,tp_dst=80
> actions=output:2*
>  cookie=0x0, duration=46.951s, table=10, n_packets=7, n_bytes=671,
> hard_timeout=60000, idle_age=46, priority=10,tcp,dl_src=00:01:
> 00:00:01:00,dl_dst=00:01:0a:00:01:00,nw_src=1.0.0.1,nw_
> dst=1.10.0.1,tp_src=14280,tp_dst=80 actions=output:2
>  cookie=0x0, duration=46.951s, table=10, n_packets=7, n_bytes=671,
> hard_timeout=60000, idle_age=46, priority=10,tcp,dl_src=00:01:
> 00:00:01:00,dl_dst=00:01:0a:00:01:00,nw_src=1.0.0.1,nw_
> dst=1.10.0.1,tp_src=15087,tp_dst=80 actions=output:2
> 
> In above highlighted dumps,
> 
> *for same tuple action is different.*
> 
> *Is it a bug in OVS or something to do with my rules?*
> 
> 
> Sateesh

> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to