Troubleshoot networking - Instances do not get private IP address

Follow

Introduction

Sometimes, you will have issues with instances and networking. Here are some steps to follow to be able to troubleshoot Eucalyptus networking properly.

In this part, we will assume that all services are up and running (ENABLED state) as a basis, and we are using managed modes (MANAGED, MANAGED-NOVLAN).

 

Requirements

In managed modes, it is Eucalyptus which in charge with networking stuff such as Instances public IPs and private addressing.

In Managed mode, Eucalyptus is also going to increase security with L2 separation between instances with VLANs. To use it successfully, you MUST know the VLAN range you can use on the network you are to use correctly. This one needs you to know perfectly how is configured the backend network.

Also, you need to know which interfaces are going to be used for communication between CC and NC. Be careful, the configuration file in /etc/eucalyptus/eucalyptus.conf will probably change depending on your server.

 

ie: CC has eth0 on the public facing network, and eth1 is the one used to communicate with the NC. Then, if your NC is connected to the CC only (not facing public network) then, choose the appropriate NIC to be connected to the CC.

 

- It is the defined "VNET_PRIV" interface which is going to be used for DHCP. Be sure that the NIC defined on NCs are on the same L2 level. 

 

My Instance doesn't get an IP

On start, the cloud will print out that your instance is going to get a private IP. Here, the public IP doesn't really matter to troubleshoot your issue.

Instances get IP addresses via DHCP. The DHCP server is managed by the Cluster Controller (CC).

To know if your instance could get an IP address, first of all is to get the output :

[code]

euca-get-console-output <instance-id>

[/code]

There, you will have this line : 

[code]

Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0

[/code]

This is the line coming after which is going to tell you if this operation failed or succeed.

Then we come to the troubleshooting in case it fails.

Troubleshooting

1 - Managed mode

Most of issues with Managed mode comes from VLAN properties are not correctly set. You probably have Eucalyptus setup onto an existing network. As said previously, you need to know the range of VLANs you can use for your instances.

Assume here, that the IT team dedicated for you, a range for VLANs : 442 to 672

As for the Public IPs, these VLANs are to be used in a global way for the cloud : values will be used by all CCs.

Each time you are going to create a Security Group (SG), Eucalyptus is going to assign a VLAN tag to this one. For example, if we create a SG for web servers, it is going to use VLAN 501 (or 472, as it is random). Now, all instances in this security group will be using this VLAN to communicate.

- REMEMBER - In Eucalyptus 3.X , you can use only 1 SG per instance -

How to say to Eucalyptus that the range of VLANs to use is 442-672 ?

[code]

euca-describe-properties | grep cloud | grep tag

PROPERTY cloud.network.global_max_network_tag 4096
PROPERTY cloud.network.global_min_network_tag 1

euca-modify-property -p cloud.network.global_min_network_tag=442

euca-modify-property -p cloud.network.global_max_network_tag=672

[code]

Now, each security group created will have a VLAN tag in this range.

 

2. Managed-NOVLAN

In Managed-NOVLAN, it is to you to create the original bridge to use. This is mostly where the issues arrive : the configuration done is not correct.

Here are some templates of brigde interfaces configuration file : (change with your own values)

[code]

NAME={{ name }}

DEVICE={{ bridge }}
 
IPADDR={{ conf.ipv4.address }}
NETMASK={{ conf.ipv4.netmask }}
 
GATEWAY={{ gateway }}
DNS1={{ ns1 }}
TYPE=Bridge
DELAY=0
STP=yes
ONBOOT=yes
BOOTPROTO=static

[/code]

NIC used configuration file (ie, /etc/sysconfig/network-scripts/ifcfg-eth0)

[code]

DEVICE={{ NIC }}
BRIDGE={{ bridge }}
ONBOOT=yes

[/code]

If still you cannot get an IP Address for your instance, 

 

For more troubleshooting on this specific issue, use tcpdump to be sure that the DHCP requests are sent on the good L2 network.

 

Have more questions? Submit a request

Comments

Powered by Zendesk