9:21 a.m.
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(a)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(a)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(a)redhat.com <rdo-list-bounces(a)redhat.com> on
> behalf of Boris Derzhavets <bderzhavets(a)hotmail.com>
> *Sent:* Tuesday, October 18, 2016 4:37 PM
> *To:* John Marks; rdo-list(a)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(a)redhat.com <rdo-list-bounces(a)redhat.com> on
> behalf of John Marks <jdmarks75080(a)gmail.com>
> *Sent:* Tuesday, October 18, 2016 7:32:53 AM
> *To:* rdo-list(a)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.
>