Bug 1236251 - Default route should be on external network when network isolation is used
Summary: Default route should be on external network when network isolation is used
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: beta
: Director
Assignee: Dan Prince
QA Contact: Ofer Blaut
URL:
Whiteboard:
: 1238767 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-27 00:57 UTC by Dan Sneddon
Modified: 2015-08-27 05:52 UTC (History)
8 users (show)

Fixed In Version: openstack-tripleo-heat-templates-0.8.6-22.el7ost
Doc Type: Bug Fix
Doc Text:
The default route was not set on the External network. This meant you could only access Horizon and the Public API from the same subnet as the Controller. This fix updates the Heat templates to include the ExternalInterfaceDefaultRoute parameter. This ensures a default route is available on the External interface.
Clone Of:
Environment:
Last Closed: 2015-08-05 13:57:11 UTC
Target Upstream Version:


Attachments (Terms of Use)
controller.yaml (3.37 KB, text/plain)
2015-07-02 19:33 UTC, Marius Cornea
no flags Details


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 196403 None None None Never
OpenStack gerrit 196732 None None None Never
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Dan Sneddon 2015-06-27 00:57:26 UTC
Description of problem:
The current templates for the network interfaces don't configure a default route explicitly, so it gets configured by DHCP on the provisioning interface.

Version-Release number of selected component (if applicable):
2015-06-26.3 puddle

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud with network isolation enabled.
2.
3.

Actual results:
Default route is on provisioning interface

Expected results:
Default route should be on external network so Horizon and Public API are accessible from outside the cloud.

Additional info:
This is going to require updates to the network interface configuration templates. I'll submit a patch upstream.

Comment 4 Dan Sneddon 2015-06-29 16:26:43 UTC
I have submitted a fix upstream for this issue:

https://review.openstack.org/#/c/196732/

which also depends on this review:

https://review.openstack.org/#/c/196403/1

Comment 5 Dan Sneddon 2015-06-29 17:17:35 UTC
This is closed by this patch:

https://review.openstack.org/#/c/196732/

which depends on this patch:

https://review.openstack.org/#/c/196403/

Comment 6 Dan Prince 2015-06-29 21:01:14 UTC
Using both patches I was able to see the configuration file correctly written for the default route for the external vlan.

Comment 7 Dan Prince 2015-07-02 01:37:49 UTC
Another few updates related to getting the default route onto the external network.

By default the Undercloud neutron pushes a default route to the provisioning network (nic1 in our existing templates). Adding a default route on the external network can conflict with the neutron supplied provisioning network route and as such the external network default route can fail to get added properly.

When dev/testing I think the existing patches could work fine so long as you share the default route for the external network with the provisioning network (something you might try when doing ad-hoc dev/testing testing on this). The new route would fail but so long as it is the same as the old it could be fine.

Here is a patch which allows us to suppress the default route on the provisioning network:

https://review.openstack.org/#/c/197742/

There are also 2 dependent changes which are required by the above patch for the following components:

tripleo-image-elements METADATA_IP_ADDR: https://review.openstack.org/#/c/197739/

os-net-config (dhclient_args): https://review.openstack.org/#/c/197738/

Comment 9 Dan Sneddon 2015-07-02 17:33:05 UTC
*** Bug 1238767 has been marked as a duplicate of this bug. ***

Comment 10 Marius Cornea 2015-07-02 19:33:38 UTC
Created attachment 1045625 [details]
controller.yaml

In regards to BZ#1238767 I was using the puddle from 29th June, openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch.
Attaching controller.yaml. 

Could my issue be related to the fact that I'm running it in virt env thus the overcloud VMs have a single nic ?

Comment 11 Dan Sneddon 2015-07-02 21:34:58 UTC
(In reply to Marius Cornea from comment #10)
> Created attachment 1045625 [details]
> controller.yaml
> 
> In regards to BZ#1238767 I was using the puddle from 29th June,
> openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch.
> Attaching controller.yaml. 
> 
> Could my issue be related to the fact that I'm running it in virt env thus
> the overcloud VMs have a single nic ?

I think that is exactly the issue. Once Dan Prince and I have worked out the details, we will get the single-nic templates working. The thing we are trying to get working is pointing the default route back at the undercloud, so the undercloud can reach the public VIP for postconfig.

Comment 12 Marius Cornea 2015-07-02 22:28:19 UTC
What I do for reaching the public VIP in order to pass postconfig is to add a vlan interface in the external net vlan on the undercloud and assign it an IP address from the external net subnet(outside the range defined the env file and floating IPs range):

ovs-vsctl add-port br-ctlplane vlan10 tag=10 -- set interface vlan10 type=internal
ip l set dev vlan10 up; ip addr add 10.0.0.251/24 dev vlan10   

That works fine for me but if you want to access the external network from other networks(for instance I'm running a VPN tunnel between my laptop and the physical host where I'm running the virt environment) then you need to set the default route through the external network. Otherwise requests reaching the external net interface will get their answers through the provisioning network which I noticed that doesn't work. That's particular to my setup and probably we don't intend to support such things. But my initial bug was about the actual deployed networking settings on the overcloud nodes not reflecting the network template files so I believe we should document if setting the default route through the external network doesn't work only on virt env, it definitely works fine on baremetal env.

Comment 13 Eran Kuris 2015-07-08 06:05:11 UTC
According to comment #7  I cannot verify it on VIRT ENV. I the fix is relevant only in BM ENV. (veified with <mcornea>)

Comment 14 Ofer Blaut 2015-07-09 05:07:51 UTC
Tested 

openstack-tripleo-heat-templates-0.8.6-23.el7ost.noarch

[root@overcloud-controller-2 heat-admin]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.35.180.254   0.0.0.0         UG    0      0        0 vlan195
0.0.0.0         192.0.2.1       0.0.0.0         UG    100    0        0 eth3

Comment 16 errata-xmlrpc 2015-08-05 13:57:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1549


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