← Back to team overview

openstack team mailing list archive

Re: [Quantum/Neutron] VM cannot get IP address from DHCP server

 

On 07/23/2013 11:41 PM, David Kang wrote:
> 
>  A Redhat manual suggests the following rule to enable forwarding packets
> among VMs and external network.
> https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf
> 
> iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT
> iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT
> iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT
> 
>  But it doesn't work for me.

Can you elaborate on what "it doesn't work" means?

Do any of those rules show increased packet/byte counts, indicating they've been
matched?

Is IP forwarding enabled?

Is there a mis-configuration in your bridge config?  Use 'brctl show' to see
where all the tap and other devices are attached.

Deleting that one FORWARD rule causing all the trouble is going to be a much
quicker solution.

-Brian

> ----- Original Message -----
>> On 07/23/2013 12:22 PM, David Kang wrote:
>>>
>>>  Hi,
>>>
>>>   We are running OpenStack Folsom on CentOS 6.4.
>>> Quantum-linuxbridge-agent is used.
>>> By default, the Quantum node has the following entries in its
>>> /etc/sysconfig/iptables file.
>>>
>>> -A INPUT -j REJECT --reject-with icmp-host-prohibited
>>> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
>>>
>>>  With those two lines, VM cannot get IP address from the DHCP server
>>>  running on the Quantum node.
>>> More specifically, the first line prevents a VM from getting IP
>>> address from DHCP server.
>>> The second line prevents a VM from talking to other VMs and external
>>> worlds.
>>> Is there a better way to make the Quantum network work well
>>> than just commenting them out?
>>
>> Since Quantum isn't adding them, and you want the system to act as a
>> DHCP server
>> and gateway, I think you have two choices:
>>
>> 1. Delete them
>> 2. Craft rules to sit above them (using -I) to allow certain packets
>>
>> #2 gets tricky as you'll need to account for DHCP, metadata, etc. in
>> the INPUT
>> chain, and in the FORWARD chain you could maybe start by allowing all
>> traffic
>> from your bridge. You would need to do some more work there.
>>
>> I believe any DHCP iptables rules will be on the compute hosts, and
>> will be put
>> in place for anti-spoofing. Since this is the network node you won't
>> see them here.
>>
>> -Brian
> 



Follow ups

References