Bug 1265023

Summary:	director should not forward dhcp traffic
Product:	Red Hat OpenStack	Reporter:	Dan Yocum <dyocum>
Component:	rhosp-director	Assignee:	James Slagle <jslagle>
Status:	CLOSED NOTABUG	QA Contact:	Shai Revivo <srevivo>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.0 (Kilo)	CC:	dsneddon, dyocum, ggillies, jcoufal, jslagle, mburns, rhel-osp-director-maint
Target Milestone:	---
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-14 20:47:37 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 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.