Hi Don,
Seems that there is a problem at neutron side, that ML2 refuses to bind the
port.
Can you please share the error you get at neutron server?
I am not sure, but seems that neutron ml2 configuration is not accurate.
With commands you share, I think you should change it as following:
[ovs]
b
It is the expected behavior as its original design.
In Neutron API, if a user has admin role, the user can see all
resources from all tenants.
CLI just sends a request to Neutron API, so the result of net-list
with admin role lists both networks.
In addition, a network with router:external=True (
the vxlan part is definitely working, its the 'flat' part that i've just
added which is not.
and, more specifically, its the ability to attach a nova instance to it.
I'm not sure what i can do for screen shots, the error is the kind of
generic:
[req-d7df11f2-0a13-49e6-acf4-69fff926519f 6f5b7388b
You should send some screen shots I have seen this but it may not be the error
your vxlan may not be working correctly.
Inviato da iPhone ()
> Il giorno 05/ott/2014, alle ore 18:49, Don Waterloo
> ha scritto:
>
> I have a system which is happily using vxlan type driver on icehouse
> on ml2
I have a system which is happily using vxlan type driver on icehouse
on ml2 / ovs.
I would now like to take on of the physical interfaces (eth1) and make
it available in a 'tap' to a specific instance. Imagine running
'snort' here.
So i added the 'type_driver' flat:
[ml2]
type_drivers = vxlan,fla
Hi,
I used devstack to deploy Juno OpenStack.
By default, devstack created 2 users: admin (with role “admin”) and demo.
localadmin@qa4:~/devstack$ source openrc admin admin
localadmin@qa4:~/devstack$ keystone user-list
+--+--+-+-
Hi Simon,
Please check you neuron server configuration.
To support VXLAN networks, you should have the following configuration in the
ml2_conf.ini:
[ml2]
type_drivers = vxlan,local
tenant_network_types = vxlan
mechanism_drivers = openvswitch
[ml2_type_vxlan]
vni_ranges = 65537:6
For the res
the exec needs root perms. just add a sudo and you should be good.
jason@devstack:~$ ip netns list
qdhcp-c6333eca-6fe4-40af-ad61-c1435a4701ef
qrouter-840c0ae7-ef5b-4be2-b496-b8a53080976b
jason@devstack:~$ ip netns exec
qrouter-840c0ae7-ef5b-4be2-b496-b8a53080976b ping 10.0.0.1
seting the ne
On Mon, Oct 6, 2014 at 1:52 AM, Danny Choi (dannchoi)
wrote:
> Hi,
>
> I used devstack to deploy Juno OpenStack.
>
> localadmin@qa4:~/devstack$ nova-manage version
>
> 2015.1
>
>
> By default, router1 is created.
>
> localadmin@qa4:~/devstack$ source openrc admin admin
>
> localadmin@qa4:~/devstac
Has anyone ever set something up so that they use the OpenStack
Horizon login screen as a oauth2 provider for another application?
Not logging into Horizon using external credentials, but using the
django framework to provide the login for other webapps?
Sort of like the 'login w/ google' or 'log
Hi,
I used devstack to deploy Juno OpenStack.
localadmin@qa4:~/devstack$ nova-manage version
2015.1
By default, router1 is created.
localadmin@qa4:~/devstack$ source openrc admin admin
localadmin@qa4:~/devstack$
localadmin@qa4:~/devstack$ neutron router-list
+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
It's with great pleasure that I am announcing the availability of Juno
RC1 in Debian. As of today, it has been fully uploaded to Debian
Experimental (I have just uploaded Trove a few minutes ago, which was
the last package remaining).
I haven't
12 matches
Mail list logo
