Hi Jesse,
I remember you sorted out the recursion issue for ARPs in userspace
tunneling.
This works on the first attempt just fine and the tunneled traffic will
flow.
Then i stop sending, and but after the ARP entry goes stale, OVS will
generate a new ARP, and receives the reply, but the tunnel traffic will not
be sent.
Using ovs-appctl tnl/arp/show i can see the stale entries still
bash-4.3# ovs-appctl tnl/arp/show
IP MAC Bridge
=============================================
192.168.1.1 00:e0:ed:1f:e4:eb eth3
192.168.2.2 00:e0:ed:2c:9e:d4 eth7
192.168.2.1 00:e0:ed:31:89:65 eth7
192.168.3.2 00:e0:ed:2c:9e:d6 eth9
192.168.1.2 00:e0:ed:20:5c:de eth3
192.168.3.1 00:e0:ed:31:89:67 eth9
192.168.0.2 00:e0:ed:20:5c:dc eth1
192.168.0.1 00:e0:ed:1f:e4:e9 eth1
bash-4.3# ip -s neighbor show
192.168.2.2 dev eth7 lladdr 00:e0:ed:2c:9e:d4 used 245764/163/146 probes 0
STALE
192.168.1.2 dev eth3 lladdr 00:e0:ed:20:5c:de used 243611/163/144 probes 1
STALE
192.168.3.2 dev eth9 lladdr 00:e0:ed:2c:9e:d6 used 245757/163/122 probes 0
STALE
192.168.0.2 dev eth1 lladdr 00:e0:ed:20:5c:dc used 245928/163/119 probes 4
STALE
Are there other logs i could collect that would help?
Regards,
Dave
Message: 1
Date: Thu, 17 Sep 2015 17:12:00 -0700
From: Jesse Gross
To: Pravin Shelar
Subject: Re: [ovs-dev] [PATCH] tunneling: Track recursion levels
across ARP generation.
Message-ID:
<CAEP_g=-8NceQ2PT4OYBAMxv3U2rgcObHhqwW96HSCV7dhq=g...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 17, 2015 at 2:42 PM, Pravin Shelar wrote:
> On Tue, Sep 15, 2015 at 8:48 PM, Jesse Gross wrote:
>> If a packet is output to a tunnel port when userspace tunneling is
>> enabled, it will cause an ARP packet to be generated if the destination
>> is unknown. This ARP packet is injected into the physical bridge as
>> a new packet, where it is flooded.
>>
>> If there is a loop (such as if the tunnel destination is the same
bridge),
>> the result will be infinite recursion. Even though we currently track
>> recursion limits, they are not effective here since each ARP packet is
>> considered to be a new translation. This changes the behavior so that
>> each ARP flow translation is initialized with the recursion counter of
>> the previous flow. Note that the problem only applies to ARP - data
>> packets in a loop will hit an existing recursion counter in the datapath.
>>
>> An additional side effect of this change is that ARP packets are no
>> longer unconditionally flooded in the new bridge. They will now follow
any
>> flow rules in the new bridge that might apply to them, the same as with
>> the kernel datapath.
>>
>> Reported-by: David Evans
>> Signed-off-by: Jesse Gross
>
> LGTM
> Acked-by: Pravin B Shelar
Thanks, applied to master. (I only did master because I think there
have been enough things that have come up in the past week that I
think people looking to use userspace tunneling need to be using
master.)
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
