The current update of Oracle OpenStack for Oracle Solaris updates existing
features to the OpenStack Juno release and adds the following new features:
Finally, Juno provides feature parity between IPv4 and IPv6. The Juno release
allows tenants to create networks and associate IPv6 subnets with these networks
such that the VM instances that connect to these networks can get their IPv6
addresses in either of the following ways:
- Stateful address configuration
- Stateless address configuration
Stateful or DHCPv6 address configuration is facilitated through the dnsmasq(8)
daemon.
Stateless address configuration is facilitated in either of the following ways:
- Through the provider (physical) router in the data center networks.
- Through the Neutron router and Solaris IPv6 neighbor discovery daemon
(in.ndpd(1M)). The Neutron L3 agent sets the AdvSendAdvertisements parameter to
true in ndpd.conf(4) for an interface that hosts the IPv6 subnet of the tenant
and refreshes the SMF service (svc:/network/routing/ndp:default) associated with
the daemon.
This IPv6 support adds the following two new attributes to Neutron Subnet:
ipv6_address_mode and ipv6_ra_mode. Possible values for these attributes are:
slaac, dhcpv6-stateful, and dhcpv6-stateless. The two Neutron agents - Neutron
DHCP agent and Neutron L3 agent - work together to provide IPv6 support.
For most cases, these new attributes are set to the same value. For one use
case, only ipv6_address_mode is set. The following table provides more
information:
The floating IPs feature in OpenStack Neutron provides external connectivity to
VMs by performing a one-to-one NAT of a the internal IP address of a VM to the
external floating IP address.
The SNAT feature provides external connectivity to all of the VMs through the
gateway public IP. The gateway public IP is the IP address of the gateway port
that gets created when you execute the following command: neutron
router-gateway-set router_uuid external_network_uuid
This external connectivity setup is similar to wireless network setup at home
where you have a single public IP from the ISP configured on the router, and all
our personal devices are behind this IP on an internal network. These internal
devices can reach out to anywhere on the internet through SNAT; however, the
external entities cannot reach these internal devices.
Example:
- Create a Public network
# neutron net-create --router:external=True --provider:network_type=flat public_net
neutron Created a new network:
|-----------------------+--------------------------------------|
| Field | Value |
|-----------------------+--------------------------------------|
| admin_state_up | True |
| network_id | 3c9c4bdf-2d6d-40a2-883b-a86076def1fb |
| name | public_net |
| provider:network_type | flat |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | dab8af7f10504d3db582ce54a0ce6baa |
|-----------------------+--------------------------------------|
# neutron subnet-create --name public_subnet --disable-dhcp \
--allocation-pool start=10.134.67.241,end=10.134.67.241 \
--allocation-pool start=10.134.67.243,end=10.134.67.245 \
public_net 10.134.67.0/24
Created a new subnet:
|-------------------+----------------------------------------------------|
| Field | Value |
|-------------------+----------------------------------------------------|
| allocation_pools | {"start": "10.134.67.241", "end": "10.134.67.241"} |
| | {"start": "10.134.67.243", "end": "10.134.67.245"} |
| cidr | 10.134.67.0/24 |
| dns_nameservers | |
| enable_dhcp | False |
| gateway_ip | 10.134.67.1 |
| host_routes | |
| subnet_id | 6063613c-1008-4826-ae17-ce6a58511b2f |
| ip_version | 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | public_subnet |
| network_id | 3c9c4bdf-2d6d-40a2-883b-a86076def1fb |
| tenant_id | dab8af7f10504d3db582ce54a0ce6baa |
|-------------------+----------------------------------------------------|
- Create a private network
# neutron net-create private_net
# neutron subnet-create --name private_sunbet private_net 192.168.109.0/24
- Create a router
# neutron router-create provider_router
Created a new router:
|-----------------------|--------------------------------------+
| Field | Value |
|-----------------------|--------------------------------------+
| admin_state_up | True |
| external_gateway_info | |
| router_id | b48fd525-2519-4501-99d9-9c2d51a543f1 |
| name | provider_router |
| status | ACTIVE |
| tenant_id | dab8af7f10504d3db582ce54a0ce6baa |
|-----------------------|--------------------------------------+
Note: Update /etc/neutron/l3_agent.ini file with following entry and
restart neutron-l3-agent SMF service (svcadm restart neutron-l3-agent)
router_id = b48fd525-2519-4501-99d9-9c2d51a543f1
- Add external network to router
# neutron router-gateway-set provider_router public_net
Set gateway for router provider_router
# neutron router-show provider_router
|-----------------------|------------------------------------------------------------------------------|
| Field | Value |
|-----------------------|------------------------------------------------------------------------------|
| admin_state_up | True |
| external_gateway_info | {"network_id": "3c9c4bdf-2d6d-40a2-883b-a86076def1fb", |
| | "enable_snat": true, |
| | "external_fixed_ips": [{"subnet_id": "6063613c-1008-4826-ae17-ce6a58511b2f", |
| | "ip_address": "10.134.67.241"}]} |
| router_id | b48fd525-2519-4501-99d9-9c2d51a543f1 |
| name | provider_router |
| status | ACTIVE |
| tenant_id | dab8af7f10504d3db582ce54a0ce6baa |
|-----------------------|------------------------------------------------------------------------------|
Note: By default, SNAT is enabled on the gateway interface of the Neutron router. To
disable this feature, specify the --disable-snat option to the neutron
router-gateway-set subcommand.
- Add internal network to router
# neutron router-interface-add provider_router private_subnet
Added interface 9bcfd21a-c751-40bb-99b0-d9274523e151 to router provider_router.
# neutron router-port-list provider_router
|--------------------------------------+-------------------+-----------------------------------------|
| id | mac_address | fixed_ips |
|--------------------------------------+-------------------+-----------------------------------------|
| 4b2f5e3d-0608-4627-b93d-f48afa86c347 | fa:16:3e:84:30:e4 | {"subnet_id": |
| | | "6063613c-1008-4826-ae17-ce6a58511b2f", |
| | | "ip_address": "10.134.67.241"} |
| | | |
| 9bcfd21a-c751-40bb-99b0-d9274523e151 | fa:16:3e:df:c1:0f | {"subnet_id": |
| | | "c7f99141-25f0-47af-8efb-f5639bcf6181", |
| | | "ip_address": "192.168.109.1"} |
|--------------------------------------+-------------------+-----------------------------------------|
Now all of the VMs that are in the internal network can reach outside through SNAT through 10.134.67.241
A metadata service provides an OpenStack VM instance with information such as the
following:
-- The public IP/hostname
-- A random seed
-- The metadata that the tenant provided at install time
-- and much more
The metadata requests are made by the VM instance at the well known address of
169.254.169.254, port 80. All such requests arrive at the Neutron L3 agent,
which forwards the requests to a Neutron proxy server running at port 9697. The
proxy server was spawned by the Neutron L3 agent. The Neutron proxy server
forwards the requests to the Neutron metadata agent through a UNIX socket. The
Neutron metadata agent interacts with the Neutron Server service to determine
the instance UUID that is making the requests. After the Neutron metadata agent
gets the instance UUID, it makes a call into the Nova API metadata server to
fetch the information for the VM instance. The fetched information is then
passed back to the instance that made the request.
Flat OpenStack Network is used to place all the VM instances on the same segment
without VLAN or VXLAN. This means that the VM instances will share the same
network.
In the flat l2-type there is no VLAN tagging or other network segregation taking
place, i.e., all the VNICs (and thus VM instances) that connect to a flat
l2-type network are created with VLAN ID set to 0. It follows that flat l2-type
cannot be used to achieve multi-tenancy. Instead, it will be used by data center
admins to map directly to the existing physical networks in the data center.
One use of Flat network type is in the configuration of floating IPs. If
available floating IPs are subset of the existing physical network's IP subnet,
then you would need to create flat network with subnet set to physical networks
IP subnet and allocation pool set to available floating IPs. So, the flat
network contains part of the existing physical network's IP subnet. See the
examples in previous section.
With this Solaris OpenStack Juno release, you can run multiple instances of
neutron-dhcp-agent, each instance running on a separate network node. Using the
dhcp-agent-network-add neutron subcommand, you can manually select which agent
should serve a DHCP enabled subnet. By default, the Neutron server automatically
load balances the work among various DHCP agents.
The following table shows the new subcommands that have been added as part of
the Solaris OpenStack Juno release.
|---------------------------+-----------------------------------------|
| neutron subcommands | Comments |
|---------------------------+-----------------------------------------|
| agent-delete | Delete a given agent. |
| agent-list | List agents. |
| agent-show | Show information for a specified agent. |
| agent-update | Update the admin status and |
| | description for a specified agent. |
| dhcp-agent-list- | List DHCP agents hosting a network. |
| hosting-net | |
| net-list-on-dhcp-agent | List the networks on a DHCP agent. |
| dhcp-agent-network-add | Add a network to a DHCP agent. |
| dhcp-agent-network-remove | Remove a network from a DHCP agent. |
|---------------------------+-----------------------------------------|