;t working the way you expect it to,
but there is another way to add routes to the Neutron DHCP server. You
can set the routes on the subnet directly:
neutron subnet-update –host-routes type=dict list=true
destination=192.168.0.0/24,nexthop=2.2.2.2
That should work, give it a try.
--
Dan Sneddon
n idea what projects are available, both core and optional.
http://governance.openstack.org/reference/projects/index.html
The official list is the projects.yaml that is linked to from this
page, and it should be up-to-date:
https://wiki.openstack.org/w/index.php?title=Project_Teams
--
Dan Sn
er is
listening for inbound traffic to those IPs. You might send traffic out, but the
return traffic is going to go to the NAT server and not your VM.
None of this has anything to do with OpenStack or private IPs, you just have
local routing issues.
-Dan Sneddon
- Original Message -
>
iated by the host
behind the NAT gateway.
-Dan Sneddon
- Original Message -
> If you have a NAT server that translates public IPs to private IPs, then it
> is
> always going to get the inbound traffic to the public IP.
>
> So, even if the public IPs are routable on the lo
ose URLs
externally. This makes the APIs themselves simpler, but still provides
the advantages of having multiple endpoints. This introduces a
dependency on a proxy, but I've never seen a production deployment that
didn't use a load-balancing proxy. In this case, the Keystone endpoin
s how we'd do it if we had to", but I wrote
> all of the above because I don't really understand what you're saying.
> If the catalog showed only internal API's, how would external clients
> reach you at all?
>
> __
n/listinfo/openstack-operators
>
Kevin,
I'm not sure I'm on board with the three endpoints as listed, but at
the very least I would swap Internal and Provider in your example:
* Public - Available outside. may incur costs to access internally
* Internal - Not exposed to norm
on a large scale yet. If you
end up going the teaming route, can you post your final configuration
back here for the benefit of the group?
[1] - https://github.com/openstack/os-net-config
--
Dan Sneddon | Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
650.254.402
e remote
network, and they will use their default route for everything else.
--
Dan Sneddon | Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
650.254.4025| dsneddon:irc @dxs:twitter
___
OpenStack-operators mail
his RFC, as long as 100.64.0.0/10 were only used
for Tenant networks and not floating IP addresses.
That said, we already have 192.168.X.X, 172.X.X.X, and 10.X.X.X
addresses. If a customer were already using all of these throughout
their network, then I could see using 100.64.0.0/10 in order to have
u
ide the cloud was used to host a self-service portal, so that VM
needs to be able to issue commands against the Public APIs in order to
provision services. In this case, it would have been difficult to
engineer a solution that allowed both the VM and the internal services
to connect to a single API wit
-+--+
>
>
>
> - Christopher T. Hull
> I am presently seeking a new career opportunity Please see career page
> http://chrishull.com/career
> 333 Orchard Ave, Sunnyvale CA. 94085
> (415) 385 48
that is often a sign of an MTU problem.
Especially if you are running VXLAN, you need room for the tunnel
headers. If your MTU is 1500 on the wire, then the VM MTU must be 1450
or smaller to make room for the VXLAN headers. Check
/etc/neutron/dnsmasq-neutron.conf, and make sure this opt
il load balancer plugin.
[1] - http://www.opencontrail.org/rdo-openstack-opencontrail-integration/
The same kind of approach applies to some other 3rd-party Neutron
plugin providers, although there are also some that use ML2 and do the
customization at the mechanism and type driver layer. Does that
On 04/01/2016 02:07 PM, Dan Sneddon wrote:
> On 04/01/2016 01:07 PM, Adam Lawson wrote:
>> The Contrail team that said they are using their network product with
>> OpenStack without requiring a mechanism driver with the ML2 plugin.
>> More specifically, they said they don
reet
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
> On Fri, Apr 1, 2016 at 2:13 PM, Dan Sneddon <mailto:dsned...@redhat.com>> wrote:
>
> On 04/01/2016 02:07
0/ (or HTTPS if
using SSL).
In general, you want to use port 5000 for all remote Keystone
connections, with the exception that if you want to use the API for
creating users or tenants you need to use the admin API. The only
difference between the two is that 35357 can perform admin functions on
te can probably be achieved by simply
using one subnet per network, but using a separate network for each
192.168.10.x, 192.168.11.x, and 192.168.12.x.
--
Dan Sneddon | Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
650.254.4025| dsneddon:irc @dxs:t
stions are
during East Coast business hours, or during business hours of GMT +1
(we have a large development office in Brno, CZ with engineers that
work on TripleO). There is also an RDO-specific mailing list available
here: https://www.redhat.com/mailman/listinfo/rdo-list
--
Dan Sneddon
tunities for
collaboration or code reuse.
Is anyone aware of any tools which will semi-automatically deploy and
configure OpenStack on a routed management network (with routed overlay
and other networks) like the OP is asking for?
--
Dan Sneddon | Senior Principal OpenSt
to
ML2 plugin drivers. More information on ML2 plugins can be found here:
http://docs.openstack.org/developer/neutron/devref/l2_agents.html
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
_
would have
impacts on performance and network traffic. You could get snapshots
for just data by using Cinder volumes for non-boot mount points.
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
- Origin
external network interface:
>
> Replace /|INTERFACE_NAME|/ with the actual interface name. For
> example, /eth2/ or /ens256/.
>
> # ovs-vsctl add-port br-ex /p5p2/
>
> /
> /
> /Regards/
> /Gaurav Goyal/
>
&
ider:physical_network datacentre \
--provider:network_type flat --shared
Of course, remove shared if you don't want tenants directly attaching to
any of the above networks, and add "--router:external" if any of these
are to be used for SNAT/floating IP.
--
Dan Sneddon
, all those choices have the same end result.
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
On 04/19/2017 12:06 PM, Ignazio Cassano wrote:
> Hi Dan, on the physical switch the 567 is not the native vla
Most people use OpenDaylight when connecting Mininet to OpenStack. You
will find many examples here:
https://www.google.com/search?q=mininet+opendaylight+openstack
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc
26 matches
Mail list logo
