Open Stack

Ok can you try this:

ip netns 
show the router then do
ip netns exec qrouter-xxxxxx ifconfig
then select the external nic and do
ip netns exec qrouter-xxxx ping -I externalinterface to your default gw
also 
ip netns exec qrouter-xxxx ping yourdhcp server

Let me know. 
> On Jun 9, 2015, at 18:36, Wilson Kwok <leiw324 at gmail.com> wrote:
> 
> Hi James,
> 
> 1. Yes
> 2. Internal instance can ping router internal gateway.
> 3. Were can check it?
> 4. Yes
> 5. Can't ping to outside
> 
> Thanks
> 
> 2015-06-06 8:25 GMT+08:00 James Denton <james.denton at rackspace.com <mailto:james.denton at rackspace.com>>:
> Hi Wilson,
> 
> Can you clarify a couple of things here?
> 
> - Does each tenant have their own router in front of their respective instance?
> 
> - have you confirmed connectivity to the admin instance from the router namespace? 
> 
> - can you verify the dnat/snat entries for the admin instance exist in iptables in the router namespace?
> 
> - have you verified the instance got its fixed up from dhcp?
> 
> - have you tried consoling to the instance and verifying outbound connectivity?
> 
> If you can, start with some simple connectivity verifications with the namespaces and work your way out from there. Also, your screenshots didn't come through, so if you can post the Cli output somewhere that would be helpful.
> 
> James
> 
> Sent from my iPhone
> 
> On Jun 4, 2015, at 10:18 PM, Wilson Kwok <leiw324 at gmail.com <mailto:leiw324 at gmail.com>> wrote:
> 
>> Any one can help?
>> 
>> 於 2015/5/29 上午10:39，"Wilson Kwok" <leiw324 at gmail.com <mailto:leiw324 at gmail.com>> 寫道：
>> Ok
>> 
>> 於 2015/5/28 下午6:24，"Remo Mattei" <Remo at italy1.com <mailto:Remo at italy1.com>> 寫道：
>> Nope. 
>> 
>> Inviato da iPhone
>> 
>> Il giorno 28/mag/2015, alle ore 02:04, Wilson Kwok <leiw324 at gmail.com <mailto:leiw324 at gmail.com>> ha scritto:
>> 
>>> Hello all,
>>> 
>>> Have some see my attached screenshots?
>>> 
>>> Thanks
>>> 
>>> 於 2015/5/27 上午11:14，"Wilson Kwok" <leiw324 at gmail.com <mailto:leiw324 at gmail.com>> 寫道：
>>> Hello all,
>>> 
>>> Please see attached Zip screenshots, you will know what is my problem.
>>> 
>>> Thanks for your help!
>>> 
>>> 2015-05-27 1:15 GMT+08:00 Remo Mattei <remo at italy1.com <mailto:remo at italy1.com>>:
>>> Just a quick note, each tenant has it’s own default security group rules. So I would double check and make sure your admin does have those rules set. If it works with Demo it has to work with admin.
>>> 
>>> Remo 
>>> 
>>>> On May 26, 2015, at 09:03, Wilson Kwok <leiw324 at gmail.com <mailto:leiw324 at gmail.com>> wrote:
>>>> 
>>>> Hi Yair,
>>>>  
>>>> I just tried something:
>>>>  
>>>> 1. I created Peter account and added into Demo project, I can access Peter's VM from external network PC via floating IP.
>>>> 2. Admin account router account floating IP is 172.28.0.163, I can ping it, but I can't access Admin's VM floating IP 172.128.0.164 from external network PC (Securty Group allow ICMP and SSH)
>>>> 3. Demo account with no problem.
>>>>  
>>>> I created public network with keystone admin, please see below result with neutron net-show public:
>>>>  
>>>> [root at localhost ~(keystone_admin)]# neutron net-show public
>>>> +---------------------------+--------------------------------------+
>>>> | Field                     | Value                                |
>>>> +---------------------------+--------------------------------------+
>>>> | admin_state_up            | True                                 |
>>>> | id                        | 6145669e-4688-40a6-b878-aaa2f9cb26c6 |
>>>> | mtu                       | 0                                    |
>>>> | name                      | public                               |
>>>> | provider:network_type     | vxlan                                |
>>>> | provider:physical_network |                                      |
>>>> | provider:segmentation_id  | 10                                   |
>>>> | router:external           | True                                 |
>>>> | shared                    | True                                 |
>>>> | status                    | ACTIVE                               |
>>>> | subnets                   | 65c1896c-0bc6-4b00-b89b-57f2677b3219 |
>>>> | tenant_id                 | e67ef147ee074f83bdab0da903f0cdd3     |
>>>> +---------------------------+--------------------------------------+
>>>> and keystone tenant-list command:
>>>>  
>>>> [root at localhost ~(keystone_admin)]# keystone tenant-list
>>>> /usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient.
>>>>   'python-keystoneclient.', DeprecationWarning)
>>>> +----------------------------------+----------+---------+
>>>> |                id                |   name   | enabled |
>>>> +----------------------------------+----------+---------+
>>>> | e67ef147ee074f83bdab0da903f0cdd3 |  admin   |   True  |
>>>> | 24f9a6c52a1d471a8e7dc0f8fde32ced |   demo   |   True  |
>>>> | 64c18def585e45e39b5e4ec161e18633 | services |   True  |
>>>> | 80f0de3f19bf4c699938b54288d1ede8 |   test   |   True  |
>>>> +----------------------------------+----------+---------+
>>>> Thanks for your help!
>>>> 
>>>>  
>>>> 2015-05-26 18:32 GMT+08:00 Yair Fried <yfried at redhat.com <mailto:yfried at redhat.com>>:
>>>> Hi,
>>>> From https://bugzilla.redhat.com/show_bug.cgi?id=1163726#c3 <https://bugzilla.redhat.com/show_bug.cgi?id=1163726#c3>
>>>> 
>>>> <snip>
>>>> By marking a network as "external" you are actually sharing it among all other tenants to be used as default GW and a source for floating IPs.
>>>> 
>>>> Marking a network as "shared" is allowing other tenants to connect VMs (and not router GWs) directly to the network.
>>>> 
>>>> Marking an external network as "shared" would allow VMs of all tenants to connect to a network as well as pull floating ips from it (via router GW). While this is possible in Neutron, it is also redundant, as with the case above - There isn't much sense in pulling a floating IP from a network that you can connect to directly.
>>>> </snip>
>>>> 
>>>> please provide the relevant output from:
>>>> $ neutron net-show <external net>
>>>> $ keystone tenant-list
>>>> 
>>>> Without this output it seems like the network was created by non-admin tenant/user which shouldn't allow its floating IPs to be consumed by other tenants. I've never tried to do that, so I'm not sure if this is a legitimate operation and if so, how such network should behave.
>>>> 
>>>> The ideal flow is:
>>>> 1. Admin creates an external network (usually called "public") in its own tenant.
>>>> 2. Users (in their own tenants) create private networks and VMs attached to them.
>>>> 3. Users create routers connecting their private networks ( router-interface-add") to the external ("public") network ("router-gateway-set").
>>>> *** At this point, VMs should be able to access the outside world via NAT.
>>>> 4. Now users can allocate floating IPs to their VMs (only those VMs that are connected to the external network via routers).
>>>> 
>>>> Please let me know if this is unclear
>>>> Regards
>>>> Yair
>>> 
>>> 
>>> 
>>> 
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
>> Post to     : openstack at lists.openstack.org <mailto:openstack at lists.openstack.org>
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
> 
> !DSPAM:1,55771632275051166010735!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150609/83e9131f/attachment.html>