[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