[ovs-dev] ARP reply does not lead to revalidate

[László Sürü]

Thanks! It looks working for the first tests.
In plus I propose to add some more printouts to the error cases in build_tunnel_send() which helped me to understand the root cause.
What would be the next step for the correction?

Best regards
Laszlo

-----Original Message-----
From: Ben Pfaff [mailto:blp at ovn.org] 
Sent: Thursday, January 19, 2017 6:35 PM
To: László Sürü <laszlo.suru at ericsson.com>
Cc: ovs-dev at openvswitch.org
Subject: Re: [ovs-dev] ARP reply does not lead to revalidate

On Thu, Jan 19, 2017 at 04:04:10PM +0000, László Sürü wrote:
> Hi,
> 
> We are using OVS 2.6.1 to connect VMs via GRE tunneling in OpenStack environment.
> The bridge configuration is similar to proposed userspace tunneling at 
> https://github.com/openvswitch/ovs/blob/master/Documentation/howto/use
> rspace-tunneling.rst The 2 bridges are of netdev type as below.
> - br-int contains OF rules to forward packets from VM to GRE tunnel and vice-versa.
> - br-phy is MAC learning switch.
> 
> In the tunnel configuration local and remote IPs are in different IP subnets:
> The use case is about to ping from one VM to another one using MPLS encapsulated in GRE tunnel in between 2 computes via a gateway.
> The expected packet path is
> VM ->  br-int ->br-phy LOCAL ->out
> 
> However, for the first ping this doesn't work in case the tunnel encapsulation cannot lookup the destination IP in the ARP cache.
> ofproto-dpif-xlate.c: build_tunnel_send();
>     "neighbor cache miss for 10.85.59.49 on bridge br-phy, sending ARP request"
> As a consequence, the tunnel_push action cannot be added to the flow, 
> instead the dpif flow will be truncated missing the tnl_push action.
> The ARP reply to the previous request arrives normally, but it doesn't lead to revalidation in datapath.
> 
> This results no packet out from the VM for some random number of 
> minutes, when finally dpif revalidation takes place for some other 
> reason
> 
> Have you experienced similar behavior?
> How the tunnel push supposed to work in such configuration?
> I expect the ARP reply to revalidate dpif flows in this case.

Thanks for the report.

Does the following patch fix the problem?

diff --git a/lib/tnl-neigh-cache.c b/lib/tnl-neigh-cache.c index 499efff..1f2b599 100644
--- a/lib/tnl-neigh-cache.c
+++ b/lib/tnl-neigh-cache.c
@@ -126,8 +126,8 @@ tnl_neigh_set__(const char name[IFNAMSIZ], const struct in6_addr *dst,
             return;
         }
         tnl_neigh_delete(neigh);
-        seq_change(tnl_conf_seq);
     }
+    seq_change(tnl_conf_seq);
 
     neigh = xmalloc(sizeof *neigh);
 

Thanks,

Ben.