[rdo-list] Adding a vlan to the external network in tripleo

Brandon James brandon.james at sunayu.com
Tue Oct 18 15:08:02 UTC 2016


All,

I truly feel that we should somehow improve the documentation to explain
how to do this in detail(Vlans and external networks). I suspect that many
people who want to tryout Tripleo/RDO Packstack are really struggling with
the networking. I know for myself this alone is the main reason I have not
deployed this into production because our external network is very complex
and I need to be certain I can integrate this without serious pain. It
would be great if users could easily change these settings on the fly
because for most admins, networking is never static.  Just my 2 cents.


Brandon

On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets <bderzhavets at hotmail.com>
wrote:

> > It would seem that all I need to do is create a vlan27 port as shown
> below. The below was generated by the heat OOO heat templates.
>
>
> Doesn't it mean one of  original templates ( which were invoked by
> `openstack overcloud deploy  .... ` )
> should be updated to create vlan27 as separate network or you have some
> other way to add vlan27 ?
>
>
>
>
>
> ------------------------------
> *From:* John Marks <jdmarks75080 at gmail.com>
> *Sent:* Tuesday, October 18, 2016 5:21 PM
> *To:* Boris Derzhavets; rdo-list at redhat.com
>
> *Subject:* Re: [rdo-list] Adding a vlan to the external network in tripleo
>
> I looked over you scenario in your blog and it is close. I have a single
> external port that shares the native VLAN and VLAN27. In my case, I
> configrued the external bridge (br-ex) with the native vlan and am now
> faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I
> used in creating the bridge and vlans under it that carry the storage, etc.
> It would seem that all I need to do is create a vlan27 port as shown below.
> The below was generated by the heat OOO heat templates.
>
> stack: ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
>     link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff
>     inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1
>        valid_lft forever preferred_lft forever
>     inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1
>        valid_lft forever preferred_lft forever
>     inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link
>        valid_lft forever preferred_lft forever
> 3: ens1f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN qlen 1000
>     link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff
> 4: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master
> ovs-system state UP qlen 1000
>     link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link
>        valid_lft forever preferred_lft forever
> 5: ens1f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN qlen 1000
>     link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff
> 6: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master
> ovs-system state UP qlen 1000
>     link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link
>        valid_lft forever preferred_lft forever
> 7: eno4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
> qlen 1000
>     link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff
> 8: eno5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
> qlen 1000
>     link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff
> 9: eno6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
> qlen 1000
>     link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff
> 10: eno7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master ovs-system
> state DOWN qlen 1000
>     link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff
> 11: eno8: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
> DOWN qlen 1000
>     link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff
> 12: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>     link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff
> 13: br-ex1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>     link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff
> 14: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>     link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff
> 15: vlan203: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
>     link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff
>     inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203
>        valid_lft forever preferred_lft forever
>     inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203
>        valid_lft forever preferred_lft forever
>     inet6 fe80::85a:9cff:fe28:45f6/64 scope link
>        valid_lft forever preferred_lft forever
> 16: vlan202: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
>     link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff
>     inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202
>        valid_lft forever preferred_lft forever
>     inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202
>        valid_lft forever preferred_lft forever
>     inet6 fe80::6c3f:59ff:fe63:4189/64 scope link
>        valid_lft forever preferred_lft forever
> 17: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN
>     link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff
>     inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex
>        valid_lft forever preferred_lft forever
>     inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex
>        valid_lft forever preferred_lft forever
>     inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr
> dynamic
>        valid_lft 2591980sec preferred_lft 604780sec
>     inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link
>        valid_lft forever preferred_lft forever
> 18: vlan204: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
>     link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff
>     inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204
>        valid_lft forever preferred_lft forever
>     inet6 fe80::b876:32ff:fe20:c81e/64 scope link
>        valid_lft forever preferred_lft forever
> 19: vlan201: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
>     link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff
>     inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201
>        valid_lft forever preferred_lft forever
>     inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201
>        valid_lft forever preferred_lft forever
>     inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201
>        valid_lft forever preferred_lft forever
>     inet6 fe80::940b:f7ff:fea1:89dc/64 scope link
>        valid_lft forever preferred_lft forever
> 23: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>     link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff
>
> stack: ovs-ctl show
> 75acb2b-1107-419f-9fed-1b80741aa78a
>     Bridge br-ex
>         Port "vlan202"
>             tag: 202
>             Interface "vlan202"
>                 type: internal
>         Port br-ex
>             Interface br-ex
>                 type: internal
>         Port "vlan201"
>             tag: 201
>             Interface "vlan201"
>                 type: internal
>         Port "bond1"
>             Interface "eno2"
>             Interface "eno3"
>         Port phy-br-ex
>             Interface phy-br-ex
>                 type: patch
>                 options: {peer=int-br-ex}
>         Port "vlan204"
>             tag: 204
>             Interface "vlan204"
>                 type: internal
>         Port "vlan203"
>             tag: 203
>             Interface "vlan203"
>                 type: internal
>     Bridge br-int
>         fail_mode: secure
>         Port "tap485f8aa8-86"
>             tag: 2
>             Interface "tap485f8aa8-86"
>                 type: internal
>         Port patch-tun
>             Interface patch-tun
>                 type: patch
>                 options: {peer=patch-int}
>         Port "tap62b75cc5-ef"
>             tag: 3
>             Interface "tap62b75cc5-ef"
>                 type: internal
>         Port br-int
>             Interface br-int
>                 type: internal
>         Port "tap123c52e6-5d"
>             tag: 1
>             Interface "tap123c52e6-5d"
>                 type: internal
>         Port int-br-ex
>             Interface int-br-ex
>                 type: patch
>                 options: {peer=phy-br-ex}
>     Bridge br-tun
>         fail_mode: secure
>         Port br-tun
>             Interface br-tun
>                 type: internal
>         Port "vxlan-ac11000c"
>             Interface "vxlan-ac11000c"
>                 type: vxlan
>                 options: {df_default="true", in_key=flow,
> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"}
>         Port "vxlan-ac11000a"
>             Interface "vxlan-ac11000a"
>                 type: vxlan
>                 options: {df_default="true", in_key=flow,
> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"}
>         Port patch-int
>             Interface patch-int
>                 type: patch
>                 options: {peer=patch-tun}
>         Port "vxlan-ac11000d"
>             Interface "vxlan-ac11000d"
>                 type: vxlan
>                 options: {df_default="true", in_key=flow,
> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"}
>         Port "vxlan-ac11000e"
>             Interface "vxlan-ac11000e"
>                 type: vxlan
>                 options: {df_default="true", in_key=flow,
> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"}
>
>
>
> On Tue, Oct 18, 2016 at 8:50 AM, John Marks <jdmarks75080 at gmail.com>
> wrote:
>
>> Doesn't that make the stack very inflexible? And yes, we have faced this
>> issue before and talked to RH about it and they said exactly the same
>> thing. However, if I redeploy, I have found that modifying the network
>> config does not take affect and I have to delete and redeploy the
>> overcloud. That would really reak havoc if I had to do that in production.
>>
>> Thanks for the reply.
>>
>> On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets <
>> bderzhavets at hotmail.com> wrote:
>>
>>> Sorry for typo
>>>
>>>   If I am not correct stating the above, RH's  technical stuff will
>>> point to my mistake for sure
>>>
>>> I skipped "if" on first place.
>>>
>>>
>>> ------------------------------
>>> *From:* rdo-list-bounces at redhat.com <rdo-list-bounces at redhat.com> on
>>> behalf of Boris Derzhavets <bderzhavets at hotmail.com>
>>> *Sent:* Tuesday, October 18, 2016 4:37 PM
>>> *To:* John Marks; rdo-list at redhat.com
>>> *Subject:* Re: [rdo-list] Adding a vlan to the external network in
>>> tripleo
>>>
>>>
>>> I have a lab situation where there are 2 networks. One is in one DMZ and
>>> the other is a lab isolated network. I need access to both via the external
>>> port. I believe what I need to do is add another port to the bridge on a
>>> vlan to the lab network. I created a new external network in Director and
>>> assigned the vlan to it. However, I am not sure that will add it to the
>>> existing bridge.
>>>
>>> A bigger question around this is why does Openstack not support
>>> modifications after installation to the north/south network?
>>>
>>>    Openstack has no problem with  adding one more external network (or
>>> even 2) of VLAN type .
>>>    See for instance https://www.linux.com/blog/rdo
>>> -mitaka-several-external-networks-vlan-provider-setup
>>>    The problem here is the way which was used for deployment,   it is
>>> TripleO.
>>>    To have the job done you need to update heat stack "overcloud" which
>>> had been built
>>>    on undercloud Node.  So you should be able redeploy overcloud with
>>> specific tripleo-heat-template
>>>    addressing you needs.  I would expect your  br-ex bridges to have IPs
>>> on ctlplane  obtained via DHCP.
>>>    Any manual intervention to overcloud is impossible.  You have
>>> presumably only one
>>>   option , which is to ask vendor for support.
>>>   I am not correct stating the above, RH's  technical stuff will point
>>> to my mistake for sure.
>>>   That is why I am so sorry about regression taken place in packstack
>>> functionality
>>>
>>>   Boris.
>>>
>>>
>>> East/west is easy but North/South has to have a lot of modifications
>>> made to static files (it seems) like plugin.ini and openvswitch.ini.
>>>
>>>
>>> ------------------------------
>>> *From:* rdo-list-bounces at redhat.com <rdo-list-bounces at redhat.com> on
>>> behalf of John Marks <jdmarks75080 at gmail.com>
>>> *Sent:* Tuesday, October 18, 2016 7:32:53 AM
>>> *To:* rdo-list at redhat.com
>>> *Subject:* [rdo-list] Adding a vlan to the external network in tripleo
>>>
>>> I have a lab situation where there are 2 networks. One is in one DMZ and
>>> the other is a lab isolated network. I need access to both via the external
>>> port. I believe what I need to do is add another port to the bridge on a
>>> vlan to the lab network. I created a new external network in Director and
>>> assigned the vlan to it. However, I am not sure that will add it to the
>>> existing bridge.
>>>
>>> A bigger question around this is why does Openstack not support
>>> modifications after installation to the north/south network?  East/west is
>>> easy but North/South has to have a lot of modifications made to static
>>> files (it seems) like plugin.ini and openvswitch.ini.
>>>
>>> Any help would be appreciated.
>>>
>>
>>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>



-- 


Brandon James
CEO & Founding Member
Mobile:   240.476-3922
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20161018/3ff7c430/attachment.html>


More information about the dev mailing list