Open Stack

On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley <brian.haley at hp.com> wrote:
> On 01/20/2015 09:20 AM, Xavier León wrote:
>> Hi all,
>>
>> we've been doing some tests with openstack kilo and found
>> out a problem: iptables routes are not being injected to the
>> router namespace.
>>
>> Scenario:
>> - a private network NOT connected to the outside world.
>> - a router with only one interface connected to the private network.
>> - a vm instance connected to the private network as well.
>>
>> From inside the instance, we try to get some information from the
>> metadata service with curl:
>>
>> $ curl http://169.254.169.254
>> curl: (7) couldn't connect to host
>>
>> With the same set up in juno, there was no such problem and
>> metadata information is shown.
>>
>> The request is not filtered at the instance and hits the router
>> namespace (checked with tcpdump). However, when looking
>> from the controller at the iptables rules at the router, they appear
>> empty.
>>
>> stack at devstack: ~$ sudo ip netns exec
>> qrouter-d4ec737a-c5fb-4f5b-8bd0-1b5353bbade3 iptables-save
> <snip>
>
>> # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015
>> *filter
>> :INPUT ACCEPT [5:914]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [10:868]
>> COMMIT
>
> Are you sure the l3-agent is running?  You should have seen wrapped rules from
> it in most of these tables, for example:
>
> # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015
> *filter
> :INPUT ACCEPT [34:10882]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [1:84]
> :neutron-filter-top - [0:0]
> :neutron-l3-agent-FORWARD - [0:0]
> :neutron-l3-agent-INPUT - [0:0]
> :neutron-l3-agent-OUTPUT - [0:0]
> :neutron-l3-agent-local - [0:0]
> [...]

Yes, the l3-agent is up and running. I see these rules when executing
the same test in juno but not in kilo. FYI, it's a all-in-one devstack
deployment.

>
> I would check the log files for any errors.

There are no errors in the logs.

After digging a bit more, we have seen that setting the config value
of enable_isolated_metadata to True (default: False) in dhcp_agent.ini
solves the problem in our scenario.
However, this change in configuration was not necessary before (our
tests passed in juno for that matter with that setting to False). So
we were wondering if there has been a change in how the metadata
service is accessed in such scenarios, a new issue because of the l3
agent refactoring or any other problem in our setup we haven't
narrowed yet.

Cheers,
Xavi

>
> -Brian
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev