Description of problem: When the director is configured as a nat gateway, it should *NOT* forward dhcp requests outside of the overcloud network. The potential exists for overlcloud systems to acquire an IP from the network that the Director is bridged to, if another DHCP server is listening on that network. Version-Release number of selected component (if applicable): RHEL 7.1 + OSP 7 How reproducible: Always Steps to Reproduce: 1. Configure the director node with 2 interfaces - one for the overcloud network, one for the routable network, and enable nat forwarding. 2. Install a DHCP server on the routable network 3. Be amazed as the overcloud nodes acquire IPs from the wrong network Actual results: overcloud node acquires IP from the wrong network Expected results: overlcloud node should NOT acquire IP from the wrong network Additional info: In actuality, I saw this where the Director bridged between the IPMI and routable network in the new OS1 Public' cloud.
how did you enable nat forwarding and what was the reason for doing so? just want to make sure we address the actual underlying issue while fixing this one.
I think by default it order to guarantee that the nodes on the ctlplane network have a default route to the outside world, we globally enable ip forwarding (and setup some iptables MASQ rules) on the undercloud node as part of openstack undercloud install e.g. /usr/share/instack-undercloud/instack-vm/install.d/50-ip-forward /usr/share/instack-undercloud/undercloud-post-config/os-refresh-config/post-configure.d/98-undercloud-setup What needs to happen instead is that instead of globally enabling ip forward for all interfaces, we should only enable it for the interface serving the ctlplane network. For example, if eth2 is being used for ctlplane, then the kernel option that should be set would be net.ipv4.conf.eth2.forwarding = 1 Likewise the iptables rules for masquerading the traffic should only affect traffic outbound from the ctlplane network Regards, Graeme
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
This bug doesn't make a whole lot of sense to me. I don't think this had anything to do with IP Masquerade, and must have been because two networks were actually bridged. DHCP requests are made from 0.0.0.0 to 255.255.255.255. Neither the source nor the destination match the IP Maquerade network or a route on the uplink of the Undercloud. I test in baremetal all the time where I have the Undercloud configured for IP masquerade and I have a DHCP server on the Undercloud uplink, and I've never seen this behavior. I've also done tcpdump's and I know that I don't see the DHCP requests forwarded from the ctlplane to the Undercloud uplink. So I think in this case perhaps both the uplink and provisioning interface were added to br-ctlplane, creating a bridge between the two, or something else was fishy at the network level. I'm going to close this, but feel free to reopen if you have a reproducer that you can let me log into or can run some troubleshooting commands on.