| 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-undercloud | Assignee: | 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: | |
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? 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 Looks like nobody has an environment affected by this anymore. |
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: