Bug 1265023 - director should not forward dhcp traffic
Summary: director should not forward dhcp traffic
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
: 10.0 (Newton)
Assignee: James Slagle
QA Contact: Shai Revivo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-21 22:32 UTC by Dan Yocum
Modified: 2016-10-14 20:47 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-14 20:47:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dan Yocum 2015-09-21 22:32:32 UTC
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.

Comment 2 James Slagle 2015-09-22 16:10:52 UTC
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-24 01:53:07 UTC
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

Comment 7 Mike Burns 2016-04-07 20:50:54 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 9 Dan Sneddon 2016-10-14 20:47:37 UTC
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.


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