Bug 1265023 - director should not forward dhcp traffic
director should not forward dhcp traffic
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity unspecified
: ---
: 10.0 (Newton)
Assigned To: James Slagle
Shai Revivo
Depends On:
  Show dependency treegraph
Reported: 2015-09-21 18:32 EDT by Dan Yocum
Modified: 2016-10-14 16:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-10-14 16:47:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Yocum 2015-09-21 18:32:32 EDT
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:


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.
Comment 2 James Slagle 2015-09-22 12:10:52 EDT
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.
Comment 3 Graeme Gillies 2015-09-23 21:53:07 EDT
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



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


Comment 7 Mike Burns 2016-04-07 16:50:54 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 9 Dan Sneddon 2016-10-14 16:47:37 EDT
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 to 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.

Note You need to log in before you can comment on or make changes to this bug.