[Openstack] Confusion of external network

Wilson Kwok leiw324 at gmail.com
Tue May 26 16:03:00 UTC 2015


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
>
>
> ----- Original Message -----
> From: "Wilson Kwok" <leiw324 at gmail.com>
> To: "Yair Fried" <yfried at redhat.com>
> Cc: openstack at lists.openstack.org
> Sent: Tuesday, May 26, 2015 1:00:58 PM
> Subject: Re: [Openstack] Confusion of external network
>
> Hi Yair,
>
> 1. The new account same project with demo account.
> 2. Yes, the external network shared already, so how can share this network
> if not use it for floating IP?
>
> Thanks
>
> 2015-05-26 13:58 GMT+08:00 Yair Fried <yfried at redhat.com>:
>
> > Hi,
> > Your question is missing some details
> > 1. What tenant does the network belong to?
> > 2. Is it shared? If you want to use it for floating IP it shouldn't be
> > shared. And VMs shouldn't be connected directly to it.
> >
> > Regards,
> > Yair
> >
> > ----- Original Message -----
> > From: "Wilson Kwok" <leiw324 at gmail.com>
> > To: openstack at lists.openstack.org
> > Sent: Tuesday, May 26, 2015 4:38:20 AM
> > Subject: Re: [Openstack] Confusion of external network
> >
> > Can someone help ? thanks!
> >
> > 2015-05-24 11:51 GMT+08:00 Wilson Kwok < leiw324 at gmail.com > :
> >
> >
> >
> > Hello all,
> >
> > I have completed my Openstack via this RDO guideline:
> >
> http://community.redhat.com/blog/2015/01/rdo-quickstart-doing-the-neutron-dance/
> >
> > This guideline help to fix external network that can let my home network
> > can access to instance via floating IP, but needed to use neutron command
> > to remove default external network and then add new external network that
> > subnet match my home network.
> >
> > The new external network shared already, my confusion is why only demo
> > account of external network can access instance, but admin account
> cannot,
> > even I create anther user account with same of demo project.
> >
> > Anyone have been try RDO caused this problem ?
> >
> > Thanks
> >
> >
> > _______________________________________________
> > 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/20150527/9ffb6621/attachment.html>


More information about the Openstack mailing list