<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;color:#666666">Thank you Mark for taking the time to reply to me and provide me with this information. It's been a big help. I'll check this tomorrow. </div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#666666"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#666666">Thanks again. Have a great day and stay safe. </div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#666666"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#666666">Regards,</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Tony Pearce<br></div><div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 7 Oct 2020 at 18:13, Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 7 Oct 2020 at 10:20, Tony Pearce <<a href="mailto:tonyppe@gmail.com" target="_blank">tonyppe@gmail.com</a>> wrote:<br>
><br>
> Hi Mark et al, thank you for your help the other day. I'm still a bit stuck with this one and I am trying to test the octavia network by deploying a regular openstack instance onto it (CentOS7) which is failing. In fact, my other and currently "working" external network is also failing to deploy instances directly onto this neetwork also. So I am wondering if there's some other step which I am missing here. Completely forgetting about the octavia network, I'm curious to understand why deploying instances to an external network has always failed for me. I have a network like this:<br>
><br>
> Real network switch VLAN 20 ----> openstack external network "br-ex" (<a href="http://192.168.20.0/24)----openstack" rel="noreferrer" target="_blank">192.168.20.0/24)----openstack</a> router----- openstack vxlan local network (<a href="http://172.16.1.0/24" rel="noreferrer" target="_blank">172.16.1.0/24</a>)<br>
><br>
> I can successfully deploy instances onto <a href="http://172.16.1.0/24" rel="noreferrer" target="_blank">172.16.1.0/24</a> but always fail when attempting to deploy to <a href="http://192.168.20.0/24" rel="noreferrer" target="_blank">192.168.20.0/24</a>.<br>
><br>
> The octavia network is almost a mirror of the above except that the controller also has an IP address / ip interface onto the same. But forgetting about this, would you happen to have any ideas or pointers that I could check that could help me with regards to why I am unable to deploy an instance to <a href="http://192.168.20.0/24" rel="noreferrer" target="_blank">192.168.20.0/24</a> network? There is a DHCP agent on this network. When I try and deploy an instance using Horizon, the dashboard shows that the instance has an ip on this network for a brief moment, but then it disappears and soon after, fails with an error that it cannot plug into it. The understanding / expectation I have is that the instance will run on the compute node and tunnel the network back to the network node where it will be presented onto <a href="http://192.168.20.0/24" rel="noreferrer" target="_blank">192.168.20.0/24</a>. Does the compute node also need an ip interface within this network to work? I ask this because  the octavia network did indeed have this but it was too failing with the same error.<br>
><br>
> Any pointers appreciated so I can try and keep my hair. Thank you :)<br>
<br>
For instances to be attached to provider networks (VLAN or flat), you<br>
need to set kolla_enable_neutron_provider_networks to true in<br>
kolla.yml. The compute hosts will need to be connected to the physical<br>
network in the same way as controllers, i.e. they will have an<br>
interface on the networks in the external_net_names list. To apply the<br>
change, you'll need to run host configure, then service deploy for<br>
openvswitch and neutron.<br>
Mark<br>
<br>
><br>
> Tony Pearce<br>
><br>
><br>
><br>
> On Mon, 5 Oct 2020 at 16:20, Mark Goddard <<a href="mailto:mark@stackhpc.com" target="_blank">mark@stackhpc.com</a>> wrote:<br>
>><br>
>> Following up in IRC:<br>
>> <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2020-10-05.log.html#t2020-10-05T06:44:47" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2020-10-05.log.html#t2020-10-05T06:44:47</a><br>
>><br>
>> On Mon, 5 Oct 2020 at 08:50, Tony Pearce <<a href="mailto:tonyppe@gmail.com" target="_blank">tonyppe@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi all,<br>
>> ><br>
>> > Openstack version is Train<br>
>> > Deployed via Kayobe<br>
>> ><br>
>> > I am trying to deploy octavia lbaas but hitting some blockers with regards to how this should be set up. I think the current issue is the lack of neutron bridge for the octavia network and I cannot locate how to achieve this from the documentation.<br>
>> ><br>
>> > I have this setup at the moment which I've added another layer 2 network provisioned to the controller and compute node, for running octavia lbaas:<br>
>> ><br>
>> > [Controller node]------------octavia network-----------[Compute node]<br>
>> ><br>
>> > However as there's no bridge, the octavia instance cannot connect to it. The exact error from the logs:<br>
>> ><br>
>> > 2020-10-05 14:37:34.070 6 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Mapping physical network physnet3 to bridge broct<br>
>> > 2020-10-05 14:37:34.070 6 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Bridge broct for physical network physnet3 does not<br>
>> ><br>
>> > Bridge "broct" does exist but it's not a neutron bridge:<br>
>> ><br>
>> > [root@juc-kocon1-prd kolla]# brctl show<br>
>> > bridge name     bridge id               STP enabled     interfaces<br>
>> > brext           8000.001a4a16019a       no              eth5<br>
>> >                                                         p-brext-phy<br>
>> > broct           8000.001a4a160173       no              eth6<br>
>> > docker0         8000.0242f5ed2aac       no<br>
>> > [root@juc-kocon1-prd kolla]#<br>
>> ><br>
>> ><br>
>> > I've been through the docs a few times but I am unable to locate this info. Most likely the information is there but I am unsure what I need to look for, hence missing it.<br>
>> ><br>
>> > Would any of you be able to help shed light on this or point me to the documentation?<br>
>> ><br>
>> > Thank you<br>
>> ><br>
>> > Tony Pearce<br>
>> ><br>
</blockquote></div>