Google Cloud Compute – Setting /20 Subnet Mask for Internal Interface

google-cloud-platformgoogle-compute-engine

Google cloud uses DHCP for assigning IP's to an instance. For some reason, they assign the address with a /32 netmask even though you're on your own /20 network. I have found that if I set the instances public IP to static I can then go into /etc/syconfig/network-scripts/ifcfg-eth0, change BOOTPROTO from DHCP to STATIC then manually set the IP settings and use a /20 or /24 subnet and it will survive reboots. However, after doing this, I lose the ability to communicate with that host on the internal network. If the instance is using DHCP parameters, I can communicate between hosts on the LAN without issue.

After reading around online, I found this article https://cloud.google.com/compute/docs/networking has a section talking about making changes to DNS and resolv.conf and to use the dhcp.lease config to do so. When I look in this file, I see that it has the 'option subnet-mask 255.255.255.255;' setting. If I change the netmask and restart the network, the changes are reverted.

Just for reference:

instance-2 is using default DHCP and has the IP 10.128.0.5
instance-4 is using my custom static config and has the IP 10.128.0.6

I have also compared the route table between an instance with a default DHCP address and an instance with my static IP settings.

instance-2 (DHCP):

[root@instance-2 network-scripts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
10.128.0.5      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
169.254.169.254 10.128.0.1      255.255.255.255 UGH   100    0        0 eth0

instance-4 (Custom Static):

[root@instance-4 NetworkManager]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.255.240.0   U     100    0        0 eth0

I then manually added the different routes to instance-4:

[root@instance-4 NetworkManager]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.128.0.1      0.0.0.0         UG    100    0        0 eth0
10.128.0.0      0.0.0.0         255.255.240.0   U     100    0        0 eth0
10.128.0.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
10.128.0.6      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.169.254 10.128.0.1      255.255.255.255 UGH   0      0        0 eth0

But that didn't resolve the issue either.

instance-4 network script:

TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
UUID=cde7258f-6857-4015-86de-6bb520fcd550
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
MTU=1460
PERSISTENT_DHCLIENT="y"
NETMASK=255.255.240.0
IPADDR=10.128.0.6
DNS1=169.254.169.254
GATEWAY=10.128.0.1

instance-2 network script

TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
UUID=cde7258f-6857-4015-86de-6bb520fcd550
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
MTU=1460
PERSISTENT_DHCLIENT="y"

How can I properly get the interface to use a netmask other than /32 and still be able to communicate with other instances on the LAN?

The OS is CentOS 7

I'm needing a netmask other than /32 so that I can install FreeIPA. It will not install if the netmask is /32.

Best Answer

I haven't found a way around the netmask issue on google cloud, but I did find that the IPA project has addressed this issue and released an update just to make it compatible with GCloud. ipa version 4.4.2 and later will not have this issue. however, as of this moment, that version is not backported to centos.

here is the patch information to resolve manually.

https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=dee950d88ec969b36c1271a3ef9fe4e4f5b48b01

Here is the actual bug report at ipa project website.

https://fedorahosted.org/freeipa/ticket/5814

Here is the bug that I filed with google regarding the network connectivity aspect.

https://code.google.com/p/google-compute-engine/issues/detail?id=522&sort=stars&colspec=ID%20Type%20Component%20Resource%20Service%20Status%20Stars%20Summary%20Log

Just putting all this out there so anyone else having this problem can find some answers.