<div dir="ltr">Hi Marius,<div><br></div><div>I've tried to configure InternalAPI VLAN on the first interface that doesn't use a bridge, however it only seems to work if I define the physical device "<b>enp1s0f0"</b> like this:</div><div><br></div><div><div><b> network_config:</b></div><div><b>            -</b></div><div><b>              type: interface</b></div><div><b>              name: nic1</b></div><div><b>              use_dhcp: false</b></div><div><b>              addresses:</b></div><div><b>                -</b></div><div><b>                  ip_netmask:</b></div><div><b>                    list_join:</b></div><div><b>                      - '/'</b></div><div><b>                      - - {get_param: ControlPlaneIp}</b></div><div><b>                        - {get_param: ControlPlaneSubnetCidr}</b></div><div><b>              routes:</b></div><div><b>                -</b></div><div><b>                  ip_netmask: <a href="http://169.254.169.254/32">169.254.169.254/32</a></b></div><div><b>                  next_hop: {get_param: EC2MetadataIp}</b></div><div><b>            -</b></div><div><b>              type: vlan</b></div><div><b>              device: enp1s0f0</b></div><div><b>              vlan_id: {get_param: InternalApiNetworkVlanID}</b></div><div><b>              addresses:</b></div><div><b>              -</b></div><div><b>                ip_netmask: {get_param: InternalApiIpSubnet}</b></div></div><div><br></div><div><br></div><div>So my question is if it's possible to create a VLAN attached to interface without using a bridge and specifying the physical device? </div><div><br></div><div>My understanding is that you only require bridges when you use Tenant or Floating networks, or is it supposed to work that way?</div><div><br></div><div>Thanks,</div><div>Pedro Sousa</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 12:32 PM, Marius Cornea <span dir="ltr"><<a href="mailto:marius@remote-lab.net" target="_blank">marius@remote-lab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's an adjusted controller.yaml which disables DHCP on the first<br>
nic: enp1s0f0 so it doesn't get an IP address<br>
<a href="http://paste.openstack.org/show/476981/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/476981/</a><br>
<br>
Please note that this assumes that your overcloud nodes are PXE<br>
booting on the 2nd NIC(basically disabling the 1st nic)<br>
<br>
Given your setup(I'm doing some assumptions here so I might be wrong)<br>
I would use the 1st nic for PXE booting and provisioning network and<br>
2nd nic for running the isolated networks with this kind of template:<br>
<a href="http://paste.openstack.org/show/476986/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/476986/</a><br>
<br>
Let me know if it works for you.<br>
<br>
Thanks,<br>
Marius<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Oct 21, 2015 at 1:16 PM, Pedro Sousa <<a href="mailto:pgsousa@gmail.com">pgsousa@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> here you go.<br>
><br>
> Regards,<br>
> Pedro Sousa<br>
><br>
> On Wed, Oct 21, 2015 at 12:05 PM, Marius Cornea <<a href="mailto:marius@remote-lab.net">marius@remote-lab.net</a>><br>
> wrote:<br>
>><br>
>> Hi Pedro,<br>
>><br>
>> One issue I can quickly see is that br-ex has assigned the same IP<br>
>> address as enp1s0f0. Can you post the nic templates you used for<br>
>> deployment?<br>
>><br>
>> 2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state<br>
>> UP qlen 1000<br>
>>     link/ether 7c:a2:3e:fb:25:55 brd ff:ff:ff:ff:ff:ff<br>
>>     inet <a href="http://192.168.21.60/24" rel="noreferrer" target="_blank">192.168.21.60/24</a> brd 192.168.21.255 scope global dynamic enp1s0f0<br>
>> 9: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state<br>
>> UNKNOWN<br>
>>     link/ether 7c:a2:3e:fb:25:56 brd ff:ff:ff:ff:ff:ff<br>
>>     inet <a href="http://192.168.21.60/24" rel="noreferrer" target="_blank">192.168.21.60/24</a> brd 192.168.21.255 scope global br-ex<br>
>><br>
>> Thanks,<br>
>> Marius<br>
>><br>
>> On Wed, Oct 21, 2015 at 12:39 PM, Pedro Sousa <<a href="mailto:pgsousa@gmail.com">pgsousa@gmail.com</a>> wrote:<br>
>> > Hi Marius,<br>
>> ><br>
>> > I've followed your howto and managed to get overcloud deployed in HA,<br>
>> > thanks. However I cannot login to it (via CLI or Horizon) :<br>
>> ><br>
>> > ERROR (Unauthorized): The request you have made requires authentication.<br>
>> > (HTTP 401) (Request-ID: req-96310dfa-3d64-4f05-966f-f4d92702e2b1)<br>
>> ><br>
>> > So I rebooted the controllers and now I cannot login through<br>
>> > Provisioning<br>
>> > network, seems some openvswitch bridge conf problem, heres my conf:<br>
>> ><br>
>> > # ip a<br>
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN<br>
>> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>
>> >     inet <a href="http://127.0.0.1/8" rel="noreferrer" target="_blank">127.0.0.1/8</a> scope host lo<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 ::1/128 scope host<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state<br>
>> > UP<br>
>> > qlen 1000<br>
>> >     link/ether 7c:a2:3e:fb:25:55 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.21.60/24" rel="noreferrer" target="_blank">192.168.21.60/24</a> brd 192.168.21.255 scope global dynamic<br>
>> > enp1s0f0<br>
>> >        valid_lft 84562sec preferred_lft 84562sec<br>
>> >     inet6 fe80::7ea2:3eff:fefb:2555/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 3: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master<br>
>> > ovs-system state UP qlen 1000<br>
>> >     link/ether 7c:a2:3e:fb:25:56 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet6 fe80::7ea2:3eff:fefb:2556/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN<br>
>> >     link/ether c2:15:45:c8:b3:04 brd ff:ff:ff:ff:ff:ff<br>
>> > 5: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN<br>
>> >     link/ether e6:df:8e:fb:f0:42 brd ff:ff:ff:ff:ff:ff<br>
>> > 6: vlan20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
>> > state<br>
>> > UNKNOWN<br>
>> >     link/ether e6:79:56:5d:07:f2 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.100.12/24" rel="noreferrer" target="_blank">192.168.100.12/24</a> brd 192.168.100.255 scope global vlan20<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet <a href="http://192.168.100.10/32" rel="noreferrer" target="_blank">192.168.100.10/32</a> brd 192.168.100.255 scope global vlan20<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::e479:56ff:fe5d:7f2/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 7: vlan40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
>> > state<br>
>> > UNKNOWN<br>
>> >     link/ether ea:43:69:c3:bf:a2 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.102.11/24" rel="noreferrer" target="_blank">192.168.102.11/24</a> brd 192.168.102.255 scope global vlan40<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::e843:69ff:fec3:bfa2/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 8: vlan174: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
>> > state<br>
>> > UNKNOWN<br>
>> >     link/ether 16:bf:9e:e0:9c:e0 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.174.36/24" rel="noreferrer" target="_blank">192.168.174.36/24</a> brd 192.168.174.255 scope global vlan174<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet <a href="http://192.168.174.35/32" rel="noreferrer" target="_blank">192.168.174.35/32</a> brd 192.168.174.255 scope global vlan174<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::14bf:9eff:fee0:9ce0/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 9: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state<br>
>> > UNKNOWN<br>
>> >     link/ether 7c:a2:3e:fb:25:56 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.21.60/24" rel="noreferrer" target="_blank">192.168.21.60/24</a> brd 192.168.21.255 scope global br-ex<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::7ea2:3eff:fefb:2556/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 10: vlan50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
>> > state<br>
>> > UNKNOWN<br>
>> >     link/ether da:15:7f:b9:72:4b brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://10.0.20.10/24" rel="noreferrer" target="_blank">10.0.20.10/24</a> brd 10.0.20.255 scope global vlan50<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::d815:7fff:feb9:724b/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 11: vlan30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
>> > state<br>
>> > UNKNOWN<br>
>> >     link/ether 7a:b3:4d:ad:f1:72 brd ff:ff:ff:ff:ff:ff<br>
>> >     inet <a href="http://192.168.101.11/24" rel="noreferrer" target="_blank">192.168.101.11/24</a> brd 192.168.101.255 scope global vlan30<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet <a href="http://192.168.101.10/32" rel="noreferrer" target="_blank">192.168.101.10/32</a> brd 192.168.101.255 scope global vlan30<br>
>> >        valid_lft forever preferred_lft forever<br>
>> >     inet6 fe80::78b3:4dff:fead:f172/64 scope link<br>
>> >        valid_lft forever preferred_lft forever<br>
>> > 12: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN<br>
>> >     link/ether b6:88:6b:d7:3a:4c brd ff:ff:ff:ff:ff:ff<br>
>> ><br>
>> ><br>
>> > # ovs-vsctl show<br>
>> > 3ee4adeb-4a5a-49a6-a16e-1e5f6e22f101<br>
>> > Bridge br-ex<br>
>> > Port br-ex<br>
>> > Interface br-ex<br>
>> > type: internal<br>
>> > Port "enp1s0f1"<br>
>> > Interface "enp1s0f1"<br>
>> > Port "vlan40"<br>
>> > tag: 40<br>
>> > Interface "vlan40"<br>
>> > type: internal<br>
>> > Port "vlan20"<br>
>> > tag: 20<br>
>> > Interface "vlan20"<br>
>> > type: internal<br>
>> > Port phy-br-ex<br>
>> > Interface phy-br-ex<br>
>> > type: patch<br>
>> > options: {peer=int-br-ex}<br>
>> > Port "vlan50"<br>
>> > tag: 50<br>
>> > Interface "vlan50"<br>
>> > type: internal<br>
>> > Port "vlan30"<br>
>> > tag: 30<br>
>> > Interface "vlan30"<br>
>> > type: internal<br>
>> > Port "vlan174"<br>
>> > tag: 174<br>
>> > Interface "vlan174"<br>
>> > type: internal<br>
>> > Bridge br-int<br>
>> > fail_mode: secure<br>
>> > Port br-int<br>
>> > Interface br-int<br>
>> > type: internal<br>
>> > Port patch-tun<br>
>> > Interface patch-tun<br>
>> > type: patch<br>
>> > options: {peer=patch-int}<br>
>> > Port int-br-ex<br>
>> > Interface int-br-ex<br>
>> > type: patch<br>
>> > options: {peer=phy-br-ex}<br>
>> > Bridge br-tun<br>
>> > fail_mode: secure<br>
>> > Port "gre-0a00140b"<br>
>> > Interface "gre-0a00140b"<br>
>> > type: gre<br>
>> > options: {df_default="true", in_key=flow, local_ip="10.0.20.10",<br>
>> > out_key=flow, remote_ip="10.0.20.11"}<br>
>> > Port patch-int<br>
>> > Interface patch-int<br>
>> > type: patch<br>
>> > options: {peer=patch-tun}<br>
>> > Port "gre-0a00140d"<br>
>> > Interface "gre-0a00140d"<br>
>> > type: gre<br>
>> > options: {df_default="true", in_key=flow, local_ip="10.0.20.10",<br>
>> > out_key=flow, remote_ip="10.0.20.13"}<br>
>> > Port "gre-0a00140c"<br>
>> > Interface "gre-0a00140c"<br>
>> > type: gre<br>
>> > options: {df_default="true", in_key=flow, local_ip="10.0.20.10",<br>
>> > out_key=flow, remote_ip="10.0.20.12"}<br>
>> > Port br-tun<br>
>> > Interface br-tun<br>
>> > type: internal<br>
>> > ovs_version: "2.4.0"<br>
>> ><br>
>> > Regards,<br>
>> > Pedro Sousa<br>
>> ><br>
>> ><br>
>> > On Sun, Oct 18, 2015 at 11:13 AM, Marius Cornea <<a href="mailto:marius@remote-lab.net">marius@remote-lab.net</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi everyone,<br>
>> >><br>
>> >> I wrote a blog post about how to deploy a HA with network isolation<br>
>> >> overcloud on top of the virtual environment. I tried to provide some<br>
>> >> insights into what instack-virt-setup creates and how to use the<br>
>> >> network isolation templates in the virtual environment. I hope you<br>
>> >> find it useful.<br>
>> >><br>
>> >> <a href="https://remote-lab.net/rdo-manager-ha-openstack-deployment/" rel="noreferrer" target="_blank">https://remote-lab.net/rdo-manager-ha-openstack-deployment/</a><br>
>> >><br>
>> >> Thanks,<br>
>> >> Marius<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Rdo-list mailing list<br>
>> >> <a href="mailto:Rdo-list@redhat.com">Rdo-list@redhat.com</a><br>
>> >> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>> >><br>
>> >> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>