DescriptionVincent S. Cojot
2016-04-21 19:40:05 UTC
Description of problem:
Hi,
On OSP-8 undercloud virt setup, whatever the ctlplane is set to, the BOOTSTACK_MASQ chain seems wrong.
Here's my instack VM:
eth0: ctl-plane
eth1: OSP networks with VLAN. Using the default bond-with-vlans.
eth1 carries the IPV4 10.0.0.1 in VLAN10 to act as a GTW for external networks.
eth2: (not used at this time)
eth3: Bridged to the outside world (10.0.128.0/22, my local network)
Here's the routing table on my setup:
[root@instack sysconfig]# ip r
default via 10.0.128.254 dev eth3
10.0.0.0/24 dev bond0.10 proto kernel scope link src 10.0.0.1
10.0.128.0/22 dev eth3 proto kernel scope link src 10.0.128.169
10.20.0.0/24 dev br-ctlplane proto kernel scope link src 10.20.0.2
Here's the undercloud.conf that was used 'openstack undercloud install':
[stack@instack ~]$ egrep -v '^(#|$)' undercloud.conf
[DEFAULT]
image_path = /home/stack/images/
local_ip = 10.20.0.2/24
network_gateway = 10.20.0.1
undercloud_public_vip = 10.20.0.3
undercloud_admin_vip = 10.20.0.4
local_interface = eth0
network_cidr = 10.20.0.0/24
dhcp_start = 10.20.0.6
dhcp_end = 10.20.0.64
inspection_interface = br-ctlplane
inspection_iprange = 10.20.0.200,10.20.0.240
[auth]
Here's the result of a successful deploy for the templates:
stack@instack ~]$ nova list
+--------------------------------------+---------------+--------+------------+-------------+---------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+---------------+--------+------------+-------------+---------------------+
| a0d4b657-57f4-46e3-95b8-7891027c2281 | krynn-ceph-0 | ACTIVE | - | Running | ctlplane=10.20.0.15 |
| f527a41a-267e-4b2a-a67d-35605f563ef4 | krynn-ceph-1 | ACTIVE | - | Running | ctlplane=10.20.0.61 |
| 71ee96a3-c7e6-432a-8356-064e681eb45c | krynn-ceph-2 | ACTIVE | - | Running | ctlplane=10.20.0.10 |
| 7b75bdc1-5827-496e-bdb4-2ed42e8363a6 | krynn-ceph-3 | ACTIVE | - | Running | ctlplane=10.20.0.63 |
| 776a2977-1b8d-425e-be44-0c4861526f35 | krynn-ceph-4 | ACTIVE | - | Running | ctlplane=10.20.0.64 |
| 076af01b-7d18-413a-89f9-29639869d2cd | krynn-cmpt-0 | ACTIVE | - | Running | ctlplane=10.20.0.11 |
| 66f01b76-5228-4a9a-9363-cf5a5f316107 | krynn-ctrl-0 | ACTIVE | - | Running | ctlplane=10.20.0.12 |
| 03dd16ef-0c74-4f8b-b73c-e4173bafa177 | krynn-ctrl-1 | ACTIVE | - | Running | ctlplane=10.20.0.16 |
| b2e36ce1-8768-4249-a06e-e75b65777d2c | krynn-ctrl-2 | ACTIVE | - | Running | ctlplane=10.20.0.14 |
| 219b86a5-dadd-4863-9023-3f86831dddfb | krynn-swift-0 | ACTIVE | - | Running | ctlplane=10.20.0.8 |
| 05a2757a-a399-4803-ac51-a947107c1185 | krynn-swift-1 | ACTIVE | - | Running | ctlplane=10.20.0.7 |
| 6f9d1547-fed7-41ac-85b4-4424f3f798f8 | krynn-swift-2 | ACTIVE | - | Running | ctlplane=10.20.0.9 |
+--------------------------------------+---------------+--------+------------+-------------+---------------------+
As you may notice, 192.* isn't to be seen anywhere.. still, I get this in the iptables chains:
root@instack sysconfig]# iptables-save |grep 192
-A FORWARD -d 192.168.122.0/24 -j ACCEPT
-A FORWARD -d 192.0.2.0/24 -j ACCEPT
-A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE
-A BOOTSTACK_MASQ -s 192.0.2.0/24 -d 192.168.122.1/32 -j RETURN
-A BOOTSTACK_MASQ -s 192.0.2.0/24 ! -d 192.0.2.0/24 -j MASQUERADE
As much as I understand it's convenient to add 192.168.122.0 here for those who use libvirt, I don't understand where 192.0.2.0/24 is coming from and why it's not set to 10.20.0.0/24 in this specific case..
Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-kilo-0.8.14-9.el7ost.noarch
openstack-tripleo-image-elements-0.9.9-2.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.5-1.el7ost.noarch
openstack-tripleo-0.0.7-1.el7ost.noarch
openstack-tripleo-heat-templates-0.8.14-9.el7ost.noarch
openstack-tripleo-common-0.3.1-1.el7ost.noarch
How reproducible:
Everytime I scrap my undercloud and start from scratch.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
It looks like masquerade_network was not set in undercloud.conf, and I believe that's what controls these firewall rules. Can you verify if setting that correctly results in the expected behavior?
Description of problem: Hi, On OSP-8 undercloud virt setup, whatever the ctlplane is set to, the BOOTSTACK_MASQ chain seems wrong. Here's my instack VM: eth0: ctl-plane eth1: OSP networks with VLAN. Using the default bond-with-vlans. eth1 carries the IPV4 10.0.0.1 in VLAN10 to act as a GTW for external networks. eth2: (not used at this time) eth3: Bridged to the outside world (10.0.128.0/22, my local network) Here's the routing table on my setup: [root@instack sysconfig]# ip r default via 10.0.128.254 dev eth3 10.0.0.0/24 dev bond0.10 proto kernel scope link src 10.0.0.1 10.0.128.0/22 dev eth3 proto kernel scope link src 10.0.128.169 10.20.0.0/24 dev br-ctlplane proto kernel scope link src 10.20.0.2 Here's the undercloud.conf that was used 'openstack undercloud install': [stack@instack ~]$ egrep -v '^(#|$)' undercloud.conf [DEFAULT] image_path = /home/stack/images/ local_ip = 10.20.0.2/24 network_gateway = 10.20.0.1 undercloud_public_vip = 10.20.0.3 undercloud_admin_vip = 10.20.0.4 local_interface = eth0 network_cidr = 10.20.0.0/24 dhcp_start = 10.20.0.6 dhcp_end = 10.20.0.64 inspection_interface = br-ctlplane inspection_iprange = 10.20.0.200,10.20.0.240 [auth] Here's the result of a successful deploy for the templates: stack@instack ~]$ nova list +--------------------------------------+---------------+--------+------------+-------------+---------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------------+--------+------------+-------------+---------------------+ | a0d4b657-57f4-46e3-95b8-7891027c2281 | krynn-ceph-0 | ACTIVE | - | Running | ctlplane=10.20.0.15 | | f527a41a-267e-4b2a-a67d-35605f563ef4 | krynn-ceph-1 | ACTIVE | - | Running | ctlplane=10.20.0.61 | | 71ee96a3-c7e6-432a-8356-064e681eb45c | krynn-ceph-2 | ACTIVE | - | Running | ctlplane=10.20.0.10 | | 7b75bdc1-5827-496e-bdb4-2ed42e8363a6 | krynn-ceph-3 | ACTIVE | - | Running | ctlplane=10.20.0.63 | | 776a2977-1b8d-425e-be44-0c4861526f35 | krynn-ceph-4 | ACTIVE | - | Running | ctlplane=10.20.0.64 | | 076af01b-7d18-413a-89f9-29639869d2cd | krynn-cmpt-0 | ACTIVE | - | Running | ctlplane=10.20.0.11 | | 66f01b76-5228-4a9a-9363-cf5a5f316107 | krynn-ctrl-0 | ACTIVE | - | Running | ctlplane=10.20.0.12 | | 03dd16ef-0c74-4f8b-b73c-e4173bafa177 | krynn-ctrl-1 | ACTIVE | - | Running | ctlplane=10.20.0.16 | | b2e36ce1-8768-4249-a06e-e75b65777d2c | krynn-ctrl-2 | ACTIVE | - | Running | ctlplane=10.20.0.14 | | 219b86a5-dadd-4863-9023-3f86831dddfb | krynn-swift-0 | ACTIVE | - | Running | ctlplane=10.20.0.8 | | 05a2757a-a399-4803-ac51-a947107c1185 | krynn-swift-1 | ACTIVE | - | Running | ctlplane=10.20.0.7 | | 6f9d1547-fed7-41ac-85b4-4424f3f798f8 | krynn-swift-2 | ACTIVE | - | Running | ctlplane=10.20.0.9 | +--------------------------------------+---------------+--------+------------+-------------+---------------------+ As you may notice, 192.* isn't to be seen anywhere.. still, I get this in the iptables chains: root@instack sysconfig]# iptables-save |grep 192 -A FORWARD -d 192.168.122.0/24 -j ACCEPT -A FORWARD -d 192.0.2.0/24 -j ACCEPT -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE -A BOOTSTACK_MASQ -s 192.0.2.0/24 -d 192.168.122.1/32 -j RETURN -A BOOTSTACK_MASQ -s 192.0.2.0/24 ! -d 192.0.2.0/24 -j MASQUERADE As much as I understand it's convenient to add 192.168.122.0 here for those who use libvirt, I don't understand where 192.0.2.0/24 is coming from and why it's not set to 10.20.0.0/24 in this specific case.. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-kilo-0.8.14-9.el7ost.noarch openstack-tripleo-image-elements-0.9.9-2.el7ost.noarch openstack-tripleo-puppet-elements-0.0.5-1.el7ost.noarch openstack-tripleo-0.0.7-1.el7ost.noarch openstack-tripleo-heat-templates-0.8.14-9.el7ost.noarch openstack-tripleo-common-0.3.1-1.el7ost.noarch How reproducible: Everytime I scrap my undercloud and start from scratch. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: