Fuel Admin network DHCP gateway not set Cobbler

Bug #1434707 reported by Kashif Ali
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Released
Low
Matthew Mosesohn
7.0.x
Fix Released
Low
Matthew Mosesohn

Bug Description

Ive noticed that even if you set the network via the showmenu (fuel setup text user interface) - the cobbler installer never picks up the default gateway and always points the fuel node as the gateway.

For example

192.168.20.0/24 (subnet)
192.168.20.2 - Fuel Node
192.168.20.254 - Gateway

However in the cobbler DNS masq config file it puts the router as 192.168.20.2 - this causes issues when trying to SSH to the servers and they dont know how to get back to the client as the network gateway (192.168.20.254) is different to the node built (192.168.20.2).

I am not sure if this is as intended but I cant see why it would be.

Tags: admin dhcp fuel pxe
Kashif Ali (snake007uk)
summary: - FuelAdmin network DHCP gateway not set Cobbler
+ Fuel Admin network DHCP gateway not set Cobbler
Kashif Ali (snake007uk)
affects: fuel → mos
Revision history for this message
Kashif Ali (snake007uk) wrote :

I found that issue isn't related to the DHCP - its actually - although this does set the router to the Fuel Master node IP address.

The issue is when Openstack is installed it changes the default gateway to the public interface GW.

The issue it seems is that if you have three network cards

ETH0 - admin
ETH1 - Priv/Pub/Mgmt
ETH2 - Storage

I believe in this configuration you get issues with the GW from the public overriding the admin GW - I am now testing

ETH0 - admin
ETH1 - Pub/Mgmt/Storage
ETH2 - Private

This is using the VLAN segmentation (http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#id33)

Its not clear from the documentation why you cant do it the other way, however I will confirm that the first configuration caused the issue.

Revision history for this message
Kashif Ali (snake007uk) wrote :

It seems the new configuration did not work either:

Below is the controller router -n output

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.254 0.0.0.0 UG 100 0 0 br-ex
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-ex
192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 br-fw-admin
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 br-mgmt
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 br-storage

As you can see gateway is set to public interface

192.168.10.0/24 - Public
192.168.20.0/24 - Admin
192.168.30.0/24 - Private
192.168.40.0/24 - Management
192.168.50.0/24 - Storage

192.168.1.0/24 - Corp LAN

id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id
---|--------|------------------|---------|--------------|-------------------|------------------------------|---------------|--------|---------
3 | ready | Untitled (91:86) | 1 | 192.168.20.4 | c2:91:81:e2:96:4c | ceph-osd, cinder, controller | | True | 1
2 | ready | Untitled (d6:7a) | 1 | 192.168.20.3 | 6a:bb:89:6e:3e:40 | compute | | True | 1
1 | ready | Untitled (d7:7d) | 1 | 192.168.20.5 | 82:a9:df:df:86:4f | compute | | True | 1

I can reach the compute nodes from the CORP 192.168.1.0/24 Lan to the 192.168.20....3 and 5 but cannot reach .4 the controller

Here is the route -n output from the compute nodes:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.20.2 0.0.0.0 UG 100 0 0 br-fw-admin
192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 br-fw-admin
192.168.40.0 0.0.0.0 255.255.255.0 U 0 0 0 br-mgmt
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 br-storage
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0

affects: mos → fuel
Changed in fuel:
importance: Undecided → Low
status: New → Confirmed
assignee: nobody → Matthew Mosesohn (raytrac3r)
Changed in fuel:
milestone: none → 6.1
Revision history for this message
Aleksey Kasatkin (alekseyk-ru) wrote :

Kashif, please provide Fuel version info.

Revision history for this message
Ihor Kalnytskyi (ikalnytskyi) wrote :

Kashif, it would be great if you provide diagnostic snapshot.

Revision history for this message
Kashif Ali (snake007uk) wrote :

Hi,

Fuel version 6.0

diagnostic snapshot can be found here: https://dl.dropboxusercontent.com/u/833212/fuel-snapshot-2015-03-25_11-27-47.tgz

Please note - I have been told by Mirantis support that this is expected behaviour, all nodes in the admin network should point the Fuel master as their gateway and the Fuel Master points to the real Gateway.

Changed in fuel:
status: Confirmed → Won't Fix
Revision history for this message
Kashif Ali (snake007uk) wrote :

Can you confirm the reason for not fixing so its clear around why the decision was made.

Thanks

Revision history for this message
Matthew Mosesohn (raytrac3r) wrote :

Kashif, are you trying to deploy through a DHCP relay? in 6.0 we only support deploying to nodes that are the same subnet as Fuel Master.

Revision history for this message
Kashif Ali (snake007uk) wrote :

No. I setup as recommended, the DHCP server is the FUEL master, however when you install FUEL you can setup the DHCP/PXE network - in my case I provided these details. However I also provided a gateway, but the cobbler ignores this.

Revision history for this message
Matthew Mosesohn (raytrac3r) wrote :

This was fixed in this commit:
https://review.openstack.org/#/c/161916/

And we no longer support classic provisioning via Cobbler + preseed. Now we only use image based provisioning.

Revision history for this message
Sergii Golovatiuk (sgolovatiuk) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.