tunneling: Track recursion levels across ARP generation.
authorJesse Gross <jesse@nicira.com>
Wed, 16 Sep 2015 02:37:06 +0000 (19:37 -0700)
committerJesse Gross <jesse@nicira.com>
Fri, 18 Sep 2015 00:03:38 +0000 (17:03 -0700)
commitcdd42edaa30993879ac5c567bd6a43442df5d0d1
tree54fd47c8c36b552ee3aa3dc99946ce8a083b58a6
parent1f9575ca931eb3b54f0c657176da7cad8c90da5d
tunneling: Track recursion levels across ARP generation.

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 <davidjoshuaevans@gmail.com>
Tested-by: David Evans <davidjoshuaevans@gmail.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
ofproto/ofproto-dpif-xlate.c
ofproto/ofproto-dpif-xlate.h
ofproto/ofproto-dpif.c
ofproto/ofproto-dpif.h