Open Stack

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>:

>  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> wrote:
>
>   Any one can help?
> 於 2015/5/29 上午10:39，"Wilson Kwok" <leiw324 at gmail.com> 寫道：
>
>> Ok
>> 於 2015/5/28 下午6:24，"Remo Mattei" <Remo at italy1.com> 寫道：
>>
>>>  Nope.
>>>
>>> Inviato da iPhone
>>>
>>> Il giorno 28/mag/2015, alle ore 02:04, Wilson Kwok <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> 寫道：
>>>
>>>> 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>:
>>>>
>>>>> 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> 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>:
>>>>>
>>>>>> Hi,
>>>>>> From 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>   !DSPAM:1,5566da3a317321526615646!
>>>
>>>     _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150610/a2b244ff/attachment.html>