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

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(a)hotmail.com&gt; 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(a)gmail.com&gt; > *Sent:* Tuesday, October 18, 2016 5:21 PM > *To:* Boris Derzhavets; rdo-list(a)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(a)gmail.com&gt; > 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&gt; 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&gt; on >>> behalf of Boris Derzhavets <bderzhavets(a)hotmail.com&gt; >>> *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&gt; on >>> behalf of John Marks <jdmarks75080(a)gmail.com&gt; >>> *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. >>> >> >> > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > -- Brandon James CEO & Founding Member Mobile: 240.476-3922