Open Stack

Adding that rule outside of the namespaces seemed to do the trick!

Thanks Lorin.


On Tue, Nov 26, 2013 at 9:21 AM, Lorin Hochstein
<lorin at nimbisservices.com>wrote:

>
>
> On Tue, Nov 26, 2013 at 9:18 AM, Samuel Winchenbach <swinchen at gmail.com>wrote:
>
>> I will give it a shot.  Does it matter that it is inside the namespace?
>>
>
> I believe the iptables rules are local to network namespaces, so it would
> need to be inside of the dhcp namespace.
>
>
>
>>  I noticed this rule outside of all the namespaces:
>>
>> Chain POSTROUTING (policy ACCEPT 166K packets, 50M bytes)
>>  pkts bytes target     prot opt in     out     source
>> destination
>>  176M  224G nova-api-POSTROUTING  all  --  *      *       0.0.0.0/0
>>        0.0.0.0/0
>>     0     0 CHECKSUM   udp  --  *      virbr0  0.0.0.0/0
>> 0.0.0.0/0            udp dpt:68 CHECKSUM fill
>>
>> Thanks!
>>
>>
>
> That rule only applies to the virbr0 bridge, which isn't used by
> OpenStack. That rule would only be in effect if you started up a VM
> directly through libvirt and specified the use of libvirt networking. Since
> OpenStack VMs aren't attached to virbr0, the packets are never going to hit
> that rule.
>
> Lorin
>
>
>
>
>
>
>>
>>
>> On Mon, Nov 25, 2013 at 10:43 PM, Lorin Hochstein <
>> lorin at nimbisservices.com> wrote:
>>
>>>
>>>
>>> On Mon, Nov 25, 2013 at 7:27 PM, Samuel Winchenbach <swinchen at gmail.com>wrote:
>>>
>>>> Hi All,
>>>>
>>>>  So I am experiencing a rather frustrating problem.  I have three
>>>> nodes running quantum dhcp agent (for high availability) and nova-compute.
>>>>  I found that certain VMs do not get an address if all three DHCP agents
>>>> are running.   Here is the output of dhcpdump on the tap interface to one
>>>> of the VMs:
>>>>
>>>> * WITHOUT test2 (worked - using test1 and test3)
>>>> http://pastie.org/pastes/8508325/text
>>>>
>>>>
>>>> * WITH test2 (did not work - using test1, test2, test3)
>>>> http://pastie.org/pastes/8508340/text
>>>>
>>>> The log files look fine, no errors in dnsmasq.log or dhcp-agent.log
>>>>
>>>> Here is what _seems_ to be in common when things do not work:
>>>> * the guest vm is using udhcpc as the DHCP client
>>>> * It is possible this only occurs when the DHCP agent is running on the
>>>> same node as the VM.
>>>>
>>>>
>>> If it's only failing when the DHCP server is on the same host as VM, my
>>> first guess would be the infamous DHCP checksum issue.
>>>
>>> Try adding this rule to the DHCP network namespace on each node that has
>>> a DHCP agent (change <uuid> to the appropriate id):
>>>
>>> ip netns exec qdhcp-<uuid> iptables -A POSTROUTING -t mangle -p udp
>>> --dport 68 -j CHECKSUM --checksum-fill
>>>
>>>
>>> This is happens if your machine is configured for hardware offloading of
>>> the UDP checksum calculations, and your DHCP packets don't get proper
>>> checksums if they don't cross a physical NIC. Certain DHCP clients barf if
>>> the checksum is invalid.
>>>
>>>
>>> Lorin
>>> --
>>> Lorin Hochstein
>>> Lead Architect - Cloud Services
>>> Nimbis Services, Inc.
>>> www.nimbisservices.com
>>>
>>
>>
>
>
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131126/9ffbdba1/attachment.html>