[ovs-discuss] Getting kernel panic on vxlan tunnel setup

[Jesse Gross]

On Wed, Jul 27, 2016 at 1:48 PM, Hasan H. Gürsoy
<zend at hhg-multistore.com> wrote:
>
> Hi there,
>
> I'm trying to get a three node setup working with vxlan setup,  but every
> try with different configuration options fail after setup of the vxlan
> ports.
>
> Node0:
>
> # ovs-vsctl show
> 1c34bd9e-f6cd-4d8c-8096-c087f42a9b24
>     Bridge "br0"
>         Port "eth0"
>             Interface "eth0"
>         Port "br0"
>             Interface "br0"
>                 type: internal
>     Bridge "br1"
>         Port "patch1-2"
>             Interface "patch1-2"
>                 type: patch
>                 options: {peer="patch2-1"}
>         Port "eth1"
>             Interface "eth1"
>         Port "vxlan-10.0.5.11"
>             Interface "vxlan-10.0.5.11"
>                 type: vxlan
>                 options: {key=flow, remote_ip="10.0.5.11"}
>         Port "vxlan-10.0.5.12"
>             Interface "vxlan-10.0.5.12"
>                 type: vxlan
>                 options: {key=flow, remote_ip="10.0.5.12"}
>         Port "br1"
>             Interface "br1"
>                 type: internal
>     Bridge "br2"
>         Port "br2"
>             Interface "br2"
>                 type: internal
>         Port "patch2-1"
>             Interface "patch2-1"
>                 type: patch
>                 options: {peer="patch1-2"}
>     ovs_version: "2.5.0"
>
> Both other nodes get both vxlan interfaces with each two other node ip.
>
>
> node0
> # ip  addr show br1
> 9: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN group default qlen 1
>     link/ether xx:xx:xx:xx:xx:x0 brd ff:ff:ff:ff:ff:ff
>     inet 10.0.5.10/24 brd 10.0.5.255 scope global br1
>        valid_lft forever preferred_lft forever

It looks like you have a loop in your routing configuration. The route
to br1 is in the same subnet as the destination for your tunnels. As a
result, when a packet is transmitted from the tunnel, it will go back
to the bridge interface which will encapsulate it in a tunnel again
and so on.

Most likely eth1 should not be in the bridge and the IP address should
be on that instead. The underlay and overlay networks are logically
separate and shouldn't be bridged together.