On Mon, Sep 14, 2015 at 9:57 PM, David Evans <[email protected]> wrote: > Hi OVS. > > i am using rev 2.3.2+29bae5412ea3c6a1e20d79afd25c11b968dffa05-r0 > > As you can see from my gdb backtrace 13K frames deep below we get an arp > request because build_tunnel_send (frame 13659 below) decided we're starting > to use a gre tunnel on a bridge and there's no arp cache for the destination > yet. > > so what follows is xlate_flood_packet -> ofproto_dpif_execute_actions -> > xlate_actions -> do_xlate_actions -> xlate_output_action -> flood_packet > -> compose_output_action -> compose_output_action__ -> xlate_table_action -> > xlate_recusively > -> do_xlate_actions (* a few actions) then we get back to > compose_output_action__ and build_tunnel_send again. > > So infinitely the code will generate arp packets, but never deliver any of > the arps out to the linux stack and keeps re-entering till it exhausts the > stack > > How do i stop this?
OVS should protect itself better but fundamentally the issue is that there is a loop somewhere in your configuration. Most likely the remote_ip on your GRE port is pointing back into br0. Another possibility is that a patch port is bridging packets between br0 and breth1. In both of these cases, ARP packets from the IP stack are re-entering the inside of the tunnel, which causes another ARP packet and so on. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
