[openstack-dev] [kolla] Vxlan and OVS issues post deployment.

Eduardo Gonzalez dabarren at gmail.com
Thu Nov 30 10:32:37 UTC 2017


Hi Goutham,

VXLAN tunnels are created between network/compute hosts in expected
interface (ens3):

df_default="true", in_key=flow, local_ip="192.168.122.215",
out_key=flow, remote_ip="192.168.122.177"

Where is exactly failing? Instances not get IP, DHCP does not work,
vm-to-vm traffic issues, public traffic issues?

Regards


2017-11-30 11:26 GMT+01:00 Goutham Pratapa <pratapagoutham at gmail.com>:

> Hi Eduardo,
>
> I am trying to deploy self-service network topology.
>
> I think then I shouldn't be bothered about the `ens8` because I'm not
> dealing with provider networks
>
> and attached are the outputs requested...
>
> Ps: Controller and the network node are both same in my setup.
>
> Thanks in advance
>
> Goutham
>
> On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez <dabarren at gmail.com>
> wrote:
>
>> Hi,
>>
>> In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
>> which defaults to ``network_interface``, ``neutron_external_interface`` is
>> used for public floating IPs in neutron.
>>
>> Please share your globals.yml, ``ip a`` output in compute/network hosts
>> and ``ovs-vsctl show`` from openvswitch daemon containers.
>>
>> What network topology are you trying to deploy? Self-service, provider
>> networks, etc?
>>
>> Regards
>>
>>
>> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang <zhang.lei.fly at gmail.com>:
>>
>>> i guess you didn't enabled one of following[0]
>>>
>>>   enable_neutron_dvr: yes
>>>   enable_neutron_provider_networks: yes
>>>
>>> I hit this recently. i am thinking we should remove this or make
>>> enable_neutron_provider_network=yes in default.
>>>
>>> [0] https://github.com/openstack/kolla-ansible/blob/master/a
>>> nsible/group_vars/all.yml#L607
>>>
>>>
>>> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa <
>>> pratapagoutham at gmail.com> wrote:
>>>
>>>> Hi Kolla Team,
>>>>
>>>> I have tried deploying Kolla OpenStack multinode and I am facing this
>>>> issue vxlan_peers_not_created
>>>> <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/>
>>>> in every deployment and I* tried the workaround* i.e restart the
>>>> network  containers to get the vxlan peers
>>>>
>>>> But when I see *ip addr show *in my compute node.
>>>>
>>>> *P.S:* "ens8"  is the interface I specified as
>>>> *neutron_external_interface** in globals.yml*
>>>>
>>>>
>>>> *---- Globals.yml-----*
>>>>
>>>>
>>>>
>>>>
>>>> *# This is the raw interface given to neutron as its external network
>>>> port. Even# though an IP address can exist on this interface, it will be
>>>> unusable in most# configurations. It is recommended this interface not be
>>>> configured with any IP# addresses for that reason.*
>>>>
>>>> *neutron_external_interface: "ens8"*3: ens8:
>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>> group default qlen 1000
>>>>     link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
>>>>     inet 192.168.122.218/24 scope global ens8
>>>>        valid_lft forever preferred_lft forever
>>>>     inet6 fe80::5054:ff:fe54:b350/64 scope link
>>>>        valid_lft forever preferred_lft forever
>>>>
>>>> Which should be something like the below (as per my understanding) for
>>>> the Vms to be up and running.
>>>>
>>>> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast *master
>>>> ovs-system* state UP group default qlen 1000
>>>>     link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
>>>>     inet 192.168.122.165/32 scope global ens8
>>>>        valid_lft forever preferred_lft forever
>>>>     inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>>>>        valid_lft forever preferred_lft forever
>>>>
>>>> Is this a known issue ??
>>>>
>>>> If yes any workaround to solve??
>>>>
>>>> Thanks in advance.
>>>> --
>>>> Thanks!!!
>>>> Goutham Pratapa
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Cheers !!!
> Goutham Pratapa
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171130/dd320678/attachment.html>


More information about the OpenStack-dev mailing list