Bug 1329392

Summary: BOOTSTACK_MASQ not set properly (several 192.0.2.0/24 seen in the chains)
Product: Red Hat OpenStack Reporter: Vincent S. Cojot <vcojot>
Component: instack-undercloudAssignee: RHOS Maint <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Arik Chernetsky <achernet>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0 (Liberty)CC: aschultz, bdobreli, bnemec, emacchi, hbrock, jslagle, mburns, mcornea, rhel-osp-director-maint, sbaker, vcojot
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-16 20:35:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vincent 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:

Comment 2 Ben Nemec 2017-03-21 20:17:00 UTC
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?

Comment 3 Vincent S. Cojot 2017-04-17 13:16:53 UTC
Hi Ben,
I don't have an OSP8 environment at this time. I will build a reproducer later this week. Thank you for your patience,
Vincent

Comment 4 Steve Baker 2018-04-16 20:35:30 UTC
Looks like nobody has an environment affected by this anymore.