diff --git a/doc/admin-guide-network/app_core.xml b/doc/admin-guide-network/app_core.xml deleted file mode 100644 index 62f9d66a44..0000000000 --- a/doc/admin-guide-network/app_core.xml +++ /dev/null @@ -1,1225 +0,0 @@ - - - Core Configuration File Options -
- - neutron.conf - Find the configuration settings for the OpenStack Networking services in - /etc/neutron/neutron.conf. -
- Debugging Options - - - - - - - - - - - - - - - - - - - -
Debugging Options
Configuration option=Default value(Type) Description
debug=False(BoolOpt) Prints debugging output.
verbose=False(BoolOpt) Prints more verbose output. -
-
- -
- Logging Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Logging Options
Configuration option=Default value(Type) Description
log_config= (StrOpt) The logging configuration file. - Overrides any other logging options - specified. See the Python logging module - documentation for details on logging - configuration files.
log_format=%(asctime)s %(levelname)8s - [%(name)s] %(message)s(StrOpt) A logging.Formatter log message - format string that can use any of the - available logging.LogRecord attributes. -
log_date_format=%Y-%m-%d %H:%M:%S(StrOpt) Format string for %(asctime)s in - log records.
log_file=(StrOpt) (Optional) Name of log file to - output to.  If not set, logging goes to - stdout.
log_dir=(StrOpt) (Optional) The directory to keep - log files in (will be prepended to - --logfile).
use_syslog=False(BoolOpt) Uses syslog for logging.
syslog_log_facility=LOG_USER(StrOpt) The syslog facility to receive - log lines.
-
- -
- Authentication Options - The auth_token middleware for keystone now enables you to configure auth_token in - the neutron.conf file. You no longer have to edit the - api-paste.ini file. This change does not break backward - compatibility. The auth_token middleware first tries the configurations in - /etc/neutron/api-paste.ini and then tries the - neutron.conf configuration. If you currently use - api-paste.ini, you do not need to change it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Authentication Options
Configuration option=Default value(Type) Description
auth_host = 127.0.0.1(StrOpt) Authentication listening - host.
auth_port = 35357(IntOpt) Authentication listening - port.
auth_protocol = http(StrOpt) Authentication protocol.
admin_tenant_name =(StrOpt) The administrative tenant - name.
admin_user =(StrOpt) The administrative user - name.
admin_password =(StrOpt) The password for the - administrative user.
signing_dir = /var/lib/neutron/keystone-signing(StrOpt) The signing directory.
-
-
- Service Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Service Options
Configuration option=Default value(Type) Description
bind_host=0.0.0.0(StrOpt) Server listening IP.
bind_port=9696(IntOpt) Server listening port.
api_paste_config=api-paste.ini(StrOpt) The paste configuration file, - which configures the WSGI application. -
api_extensions_path=(StrOpt) Enables custom addition to be - made to the above configuration.
policy_file=policy.json(StrOpt) JSON file representing policies - to access and view data. The usage and - format is discussed in more detail in the - Authentication and Authorization section. -
auth_strategy=keystone(StrOpt) The strategy used for - authentication. The supported values are - ‘keystone’ and ‘noauth’.
core_plugin=neutron.plugins.sample.SamplePlugin.FakePlugin(StrOpt) The plugin to be loaded by the - service.
pagination_max_limit=-1(StrOpt) The maximum number of items - returned in a single response. A value of - 'infinite', or a negative integer means no - limit.
-
- -
- Plugin Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Base Plugin Options
Configuration option=Default value(Type) Description
base_mac=fa:16:3e:00:00:00(StrOpt) MAC addresses for a port are - generated. The first 3 octets will remain - unchanged. If the 4h octet is not 00, it - will also used. The others will be - randomly generated.
mac_generation_retries=16(IntOpt) The number of times the plugin - attempts to generate a unique MAC address. -
allow_bulk=True(BoolOpt) Enables or disables bulk - create/update/delete operations.
allow_overlapping_ips=False(BoolOpt) Enables or disables whether overlapping IPs can be - created for subnets with different - tenants. L3 agent and dhcp agent must - enable use_namespaces for subnets with - overlapping IPs to be created. - -
allow_pagination=False(BoolOpt) Enables or disables - pagination. If plugin doesn't support - native pagination, it will enable - emulated pagination. Please note - native pagination depends on native - sorting. If native pagination is - enabled, native emulated sorting will - be enabled automatically. - - Note: If the plugin supports native pagination, the plugin - returns the maximum limit of items as request. If the plugin - didn't support that, neutron API can emulate the pagination - behavior. The performance of native pagination is better than - emulated pagination. - -
allow_sorting=False(BoolOpt) Enables or disables - sorting. If plugin doesn't support - native sorting, it will enable - emulated sorting. - - If the plugin supports native sorting, the plugin returns - ordered items as request. If the plugin didn't support that, - neutron API can emulate the sorting behavior. The performance of - native sorting is better than emulated sorting. - -
force_gateway_on_subnet = False(BoolOpt) Enables or disables - that a gateway must be configured on a subnet. -
max_dns_nameservers=5(IntOpt) The maximum amount of DNS - nameservers that can be configured per - subnet.
max_subnet_host_routes=20(IntOpt) The maximum amount of host routes - that can be configured per subnet.
state_path=.(StrOpt) Top level directory for - configuration files.
dhcp_lease_duration=120(IntOpt) The default expiration time, in - seconds, for a DHCP address.
-
- - -
- Common RPC Message Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Common RPC Message Options
Configuration option=Default value(Type) Description
control_exchange=neutron(StrOpt) AMQP exchange to connect to if - using RabbitMQ or QPID.
rpc_backend=neutron.openstack.common.rpc.impl_kombu(StrOpt) The messaging module to use, defaults to kombu. For qpid, make - use of neutron.openstack.common.rpc.impl_qpid.
rpc_thread_pool_size=64(IntOpt) Size of RPC thread pool.
rpc_conn_pool_size=30(IntOpt) Size of RPC connection pool. -
rpc_response_timeout=60(IntOpt) Seconds to wait for a response - from call or multi call.
allowed_rpc_exception_modules='neutron.openstack.common.exception', - 'nova.exception'(ListOpt) Modules of exceptions that are - permitted to be recreated upon receiving - exception data from an rpc call.
fake_rabbit=False(BoolOpt) If passed, use a fake RabbitMQ - provider.
-
- -
- Rabbit RPC Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rabbit RPC Options
Configuration option=Default value(Type) Description
kombu_ssl_version=(StrOpt) SSL version to use (valid only if - SSL enabled).
kombu_ssl_keyfile=(StrOpt) SSL key file (valid only if SSL - enabled).
kombu_ssl_certfile=(StrOpt) SSL cert file (valid only if SSL - enabled).
kombu_ssl_ca_certs=(StrOpt) SSL certification authority file - (valid only if SSL enabled).
rabbit_host=localhost(StrOpt) IP address of the RabbitMQ - installation.
rabbit_password=guestPassword of the RabbitMQ server.
rabbit_port=5672(IntOpt) Port where RabbitMQ server is - running/listening.
rabbit_userid=guest(StrOpt) User ID used for RabbitMQ - connections.
rabbit_virtual_host=/(StrOpt) Location of a virtual RabbitMQ - installation.
rabbit_max_retries=0(IntOpt) Maximum retries with trying to - connect to RabbitMQ. The default of 0 - implies an infinite retry count.
rabbit_retry_interval=1(IntOpt) RabbitMQ connection retry - interval.
-
- -
- QPID RPC Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
QPID RPC Options
Configuration option=Default value(Type) Description
qpid_hostname=localhost(StrOpt) Qpid broker hostname.
qpid_port=5672(IntOpt) Qpid broker port.
qpid_username=(StrOpt) Username for qpid connection. -
qpid_password=(StrOpt) Password for qpid connection. -
qpid_sasl_mechanisms=(StrOpt) Space separated list of SASL - mechanisms to use for auth.
qpid_reconnect=True(BoolOpt) Automatically reconnect.
qpid_reconnect_timeout=0(IntOpt) The number of seconds to wait - before deciding that a reconnect attempt - has failed.
qpid_reconnect_limit=0(IntOpt) The limit for the number of times - to reconnect before considering the - connection to be failed.
qpid_reconnect_interval_min=0(IntOpt) Minimum seconds between - reconnection attempts.
qpid_reconnect_interval_max=0(IntOpt) Maximum seconds between - reconnection attempts.
qpid_reconnect_interval=0(IntOpt) Equivalent to setting max and min - to the same value.
qpid_heartbeat=60(IntOpt) Seconds between connection - keepalive heartbeats.
qpid_protocol=tcp(StrOpt) Transport to use, either 'tcp' or - 'ssl.'
qpid_tcp_nodelay=True(BoolOpt) Disable Nagle algorithm.
-
-
- Notification Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Notification Options
Configuration option=Default value(Type) Description
notification_driver=neutron.openstack.common.notifier.list_notifier(MultiStrOpt) Driver or drivers to handle - sending notifications. The default is set - as notifier as the DHCP agent makes use of - the notifications.
default_notification_level=INFO(StrOpt) Default notification level for - outgoing notifications.
default_publisher_id=$host(StrOpt) Default publisher_id for outgoing - notifications.
- list_notifier_drivers='neutron.openstack.common.notifier.no_op_notifier'(MultiStrOpt) List of drivers to send - notifications.
notification_topics='notifications'(ListOpt) AMQP topic used for openstack - notifications.
-
- -
- Quota Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quota Options
Configuration option=Default value(Type) Description
quota_driver=neutron.quota.ConfDriver(StrOpt) Default driver to use for quota checks. If the default driver - is used then the configuration values below are in effect. To limit - quotas per tenant then use: - neutron.db.quota_db.DbQuotaDriver -
quota_items=network,subnet,port(ListOpt) Resource names that are - supported by the Quotas feature.
default_quota=-1(IntOpt) Default number of resources - allowed per tenant, minus for unlimited. -
quota_network=10(IntOpt) Number of networks allowed per - tenant, and minus means unlimited.
quota_subnet=10(IntOpt) Number of subnets allowed per - tenant, and minus means unlimited.
quota_port=50(IntOpt) Number of ports allowed per - tenant, and minus means unlimited.
-
-
-
- - ovs_neutron_plugin.ini - For information about the Open vSwitch plugin - configurations, see http://wiki.openstack.org/ConfigureOpenvswitch. -
- Database Access by Plugin - - - - - - - - - - - - - - - - - - - - - - -
Database Access by Plugin
Configuration option=Default value(Type) Description
sql_connection=sqlite://(StrOpt) The details of the database connection. For example - mysql://root:nova@127.0.0.1:3306/ovs_neutron. Replace 127.0.0.1 - above with the IP address of the database used by the main OpenStack - Networking server. (Leave it as is if the database runs on this - host.). - - Change this line to ensure that - the database values are persistent. - The sqlite is used for testing. -
sql_max_retries=10(IntOpt) The number of database - re-connection retry times. Used if - connectivity is lost with the database. -1 - implies an infinite retry count.
reconnect_interval=2(IntOpt) The database reconnection - interval in seconds. Used if connectivity - is lost.
-
-
- OVS Options - Specify these parameters in the - ovs section. - These OVS options are common to the plugin and - agent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OVS Options Common to Plugin and - Agent
Configuration option=Default value(Type) Description
network_vlan_ranges=default:2000:3999(ListOpt) Comma-separated list of  - <physical_network>:<vlan_min>:<vlan_max> - tuples enumerating ranges of VLAN IDs on - named physical networks that are available - for allocation.
tunnel_id_ranges=(ListOpt) Comma-separated list of - <tun_min>:<tun_max> tuples - enumerating ranges of GRE tunnel IDs that - are available for allocation.
integration_bridge=br-int(StrOpt) The name of the OVS integration - bridge. There is one per hypervisor. The - integration bridge acts as a virtual - "patch port". All VM VIFs are attached to - this bridge and then "patched" according - to their network connectivity. Do not - change this parameter unless you have a - good reason to.
tunnel_bridge=br-tun(StrOpt) The name of the OVS tunnel bridge - used by the agent for GRE tunnels. Only - used if tunnel_id_ranges is not empty. -
bridge_mappings=default:br-eth1(ListOpt) Comma-separated list of - <physical_network>:<bridge> - tuples mapping physical network names to - agent's node-specific OVS bridge names. - Each bridge must exist, and should have - physical network # interface configured as - a port.
local_ip=10.0.0.3(StrOpt) The local IP address of this - hypervisor. Used only when - tunnel_id_ranges are used.
enable_tunneling=False(BoolOpt) A flag indicating if tunneling - is supported. Not all systems that support - Open vSwitch support its GRE tunneling - feature, that is, it is not supported in - the Linux kernel source tree. This applies - to both the server and agent.
-
-
- Agent Options - Specify these options in the - agent section. - - - - - - - - - - - - - - - - - - - - - - - -
Agent Options
Configuration option=Default value(Type) Description
rpc=True(BoolOpt) If True, the agent communicates with the - plugin through the OpenStack RPC, which is configured in - neutron.conf. If False, the - agent polls the database for changes. If False, you - must update the relevant database settings on the agent so that it can - access the database.
polling_interval=2(IntOpt) Agent's polling interval in - seconds.
root_helper=sudo(StrOpt) Limits the commands that can be - run. See the rootwrap section for more - details.
-
-
-
- - linuxbridge_conf.ini -
- Database Access by Plugin - - - - - - - - - - - - - - - - - - - - - - -
Database Access by Plugin
Configuration option=Default - value(Type) Description
sql_connection=sqlite://(StrOpt) The details of the database connection. For example - mysql://root:nova@127.0.0.1:3306/ovs_neutron. Replace 127.0.0.1 - above with the IP address of the database used by the main - OpenStack Networking server. (Leave it as is if the database - runs on this host.). - - This line must be changed to - ensure that the database values are - persistent. The sqlite is used for - testing. -
sql_max_retries=10(IntOpt) Database re-connection retry - times. Used if connectivity is lost - with the database. -1 implies an - infinite retry count.
reconnect_interval=2(IntOpt) Database reconnection - interval in seconds. Used if - connectivity is lost.
- -
-
- VLAN Configurations -   - - - - - - - - - - - - - -
VLAN Configurations
Configuration option=Default - value(Type) Description
network_vlan_ranges=default:1000:2999(ListOpt) Comma-separated list of - <physical_network>:<vlan_min>:<vlan_max> - tuples enumerating ranges of VLAN IDs - on named physical networks that are - available for allocation.
 -
-
- Networking Options on the Agent - - - - - - - - - - - - - - - -
Networking Options on the Agent
Configuration option=Default - value(Type) Description
physical_interface_mappings=default:eth1(ListOpt) Comma-separated list of - <physical_network>:<physical_interface> - tuples mapping physical network names - to agent's node-specific physical - network interfaces. Server uses - physical network names for validation - but ignores interfaces.
 -
-
- Agent Options - - - - - - - - - - - - - - - - - - - - - - - -
Agent Options
Configuration option=Default - value(Type) Description
rpc=True(BoolOpt) If True, the agent communicates with - the plugin through the OpenStack RPC, which is configured in - neutron.conf. If False, - the agent polls the database for changes. If - False, you must update the relevant database - settings on the agent so that it can access the database.
polling_interval=2(IntOpt) Agent's polling interval in - seconds.
root_helper=sudo(StrOpt) Limits the commands that can - be run. See the rootwrap section for - more details.
  -
-
- -
- - dhcp_agent.ini - For device manager options, see . -
- DHCP-Specific Options - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DHCP-Specific Options
Configuration option=Default - value(Type) Description
root_helper=sudo(StrOpt) Limits the commands that can - be run. See the rootwrap section for - more details.
dhcp_driver=neutron.agent.linux.dhcp.Dnsmasq(StrOpt) The driver used to manage the - DHCP server.
- dhcp_lease_relay_socket=$state_path/dhcp/lease_relay(StrOpt) Location to DHCP lease relay - UNIX domain socket.
use_namespaces=True(BoolOpt) Allows overlapping - IP. - - If you run multiple agents - with different IP addresses on the - same host, set this parameter to - True. Otherwise, - routing problems occur. -
-
- -
- dnsmasq Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dnsmasq Options
Configuration option=Default - value(Type) Description
dhcp_confs=$state_path/dhcp(StrOpt) Location to store DHCP server - config files.
dhcp_lease_time=120(IntOpt) Lifetime of a DHCP lease in - seconds.
dhcp_domain=openstacklocal(StrOpt) Domain to use for building - the host names.
dnsmasq_config_file=(StrOpt) Overrides the default dnsmasq - settings with this file.
dnsmasq_dns_server=(StrOpt) Specifies whether to use - another DNS server before any in - /etc/resolv.conf. -
-
-
-
- - l3_agent.ini - For device manager options, see . -
- Specific Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
L3 Specific Options
Configuration option=Default - value(Type) Description
root_helper=sudo(StrOpt) Limits the commands that can - be run. See the rootwrap section for - more details.
external_network_bridge=br-ex(StrOpt) Name of bridge used for - external network traffic.
use_namespaces=True(BoolOpt) Allows overlapping IP. - If you run multiple agents - with different IP addresses on the - same host, set this parameter to - True. Otherwise, - routing problems occur. -
polling_interval=3(IntOpt) The time, in seconds, between - state poll requests.
metadata_port=9697(IntOpt) TCP Port used by metadata namespace proxy.
router_id=(StrOpt) If namespaces is disabled, - the l3 agent can only configure a - router whose ID matches this - parameter.
handle_internal_only_routers=True(BoolOpt) Agent should implement - routers with no gateway.
gateway_external_network_id=(StrOpt) UUID of external network for - routers implemented by the agents. -
-
-
-
- metadata_agent.ini - Use the following options in the metadata_agent.ini file for the - Metadata agent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Metadata Agent Options
Configuration option=Default value(Type) Description
nova_metadata_ip=127.0.0.1(StrOpt) The IP address of the Nova metadata service.
nova_metadata_port=8775(IntOpt) The TCP port of the Nova metadata service.
metadata_proxy_shared_secret=(StrOpt) When proxying metadata requests, Neutron signs the Instance-ID - header with a shared secret to prevent spoofing. You may select any - string for a secret, but it must match here and in the configuration - used by the Nova Metadata Server. NOTE: Nova uses a different key: - neutron_metadata_proxy_shared_secret
admin_user=(StrOpt) The administrative user name for OpenStack Networking, which is - defined in OpenStack Identity - (keystone).
admin_password=(StrOpt) The password for the administrative user.
admin_tenant_name=(StrOpt) The administrative user's tenant name.
auth_url=(StrOpt) The URL used to validate tokens. For example, - `auth_protocol`://`auth_host`:`auth_port`/v2.0.
auth_region=(StrOpt) The authentication region.
 -
-
- Common Device Manager Options - Use the following device manager options in the - dhcp_agent.ini file for the DHCP - agent or the l3_agent.ini file for - the L3 agent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Device Manager Options
Configuration option=Default value(Type) Description
interface_driver=(StrOpt) The driver used to manage the - virtual interface.
ovs_use_veth=False(BoolOpt) Specifies whether to use veth - for an interface. Set to - True for OVS-based - plugins that use Open vSwitch as OpenFlow - switch and check port status.
admin_user=(StrOpt) The administrative user name for - OpenStack Networking, which is defined in - OpenStack Identity (keystone). - Only relevant if using MetaPlugin.
admin_password=(StrOpt) The password for the - administrative user. Only relevant if - using MetaPlugin.
admin_tenant_name=(StrOpt) The administrative user's tenant - name. Only relevant if using - MetaPlugin.
auth_url=(StrOpt) The URL used to validate tokens. - For example, - `auth_protocol`://`auth_host`:`auth_port`/v2.0. - Only relevant if using MetaPlugin.
auth_strategy=keystone(StrOpt) The strategy to use for - authentication. Supports noauth or - keystone. Only relevant if using - MetaPlugin.
auth_region=(StrOpt) The authentication region. Only - relevant if using MetaPlugin.
ovs_integration_bridge=br-int(StrOpt) Name of Open vSwitch bridge to - use. Only relevant if using Open vSwitch. -
network_device_mtu=(StrOpt) MTU setting for device. Only - relevant if using Open vSwitch.
meta_flavor_driver_mappings=(StrOpt). Mappings between flavors and - drivers. Only relevant if using - MetaPlugin.
resync_interval=30(IntOpt) If an exception occurs on the neutron-server service, the DHCP - agent ensures that it syncs with the neutron.conf - configuration. The validation about syncing occurs every - resync_interval seconds.
 -
- - - diff --git a/doc/admin-guide-network/app_demo.xml b/doc/admin-guide-network/app_demo.xml deleted file mode 100644 index c45af8faf3..0000000000 --- a/doc/admin-guide-network/app_demo.xml +++ /dev/null @@ -1,15 +0,0 @@ - - - Demos Setup - This section describes how to configure the OpenStack - Networking service and its components for some typical use - cases. - - - - - - - - diff --git a/doc/admin-guide-network/app_pagination_and_sorting_support.xml b/doc/admin-guide-network/app_pagination_and_sorting_support.xml deleted file mode 100644 index 45e5c629ba..0000000000 --- a/doc/admin-guide-network/app_pagination_and_sorting_support.xml +++ /dev/null @@ -1,31 +0,0 @@ - - - Plugin pagination and sorting support - - - - - - - - - - - - - - - - - - - - - - -
The plugins are supporting native pagination and - sorting
PluginSupport Native PaginationSupport Native Sorting
Open vSwitchTrueTrue
LinuxBridgeTrueTrue
- diff --git a/doc/admin-guide-network/bk-networking-admin-guide.xml b/doc/admin-guide-network/bk-networking-admin-guide.xml index 58bed841c6..66d286f350 100644 --- a/doc/admin-guide-network/bk-networking-admin-guide.xml +++ b/doc/admin-guide-network/bk-networking-admin-guide.xml @@ -50,7 +50,7 @@ - Added . + Added ch_under_the_hood. @@ -131,19 +131,5 @@ - - - - - - - - - - - - - - diff --git a/doc/admin-guide-network/ch_adv_features.xml b/doc/admin-guide-network/ch_adv_features.xml index c2cf836813..177146f752 100644 --- a/doc/admin-guide-network/ch_adv_features.xml +++ b/doc/admin-guide-network/ch_adv_features.xml @@ -202,7 +202,7 @@ extension:provider_network:set action. The default OpenStack Networking API policy configuration authorizes both actions for users with - the admin role. See for + the admin role. See ch_auth for details on policy configuration.
@@ -228,23 +228,9 @@ $ neutron net-create <name> --tenant_id <tenant-id> --provider:network_type gre --provider:segmentation_id <tunnel-id> - When creating flat networks or VLAN networks, - <phys-net-name> must be known to the plugin. See - and for details on - configuring network_vlan_ranges to identify all - physical networks. When creating VLAN networks, - <VID> can fall either within or outside any - configured ranges of VLAN IDs from which tenant - networks are allocated. Similarly, when creating GRE - networks, <tunnel-id> can fall either within or - outside any tunnel ID ranges from which tenant - networks are allocated. - Once provider networks have been created, subnets - can be allocated and they can be used similarly to - other virtual networks, subject to authorization - policy based on the specified - <tenant_id>. + When creating flat networks or VLAN networks, <phys-net-name> must be known to the plugin. See ovs_neutron_plugin and linuxbridge_conf for details on configuring network_vlan_ranges to identify all physical networks. When creating VLAN networks, <VID> can fall either within or outside any configured ranges of VLAN IDs from which tenant networks are allocated. Similarly, when creating GRE networks, <tunnel-id> can fall either within or outside any tunnel ID ranges from which tenant networks are allocated. +Once provider networks have been created, subnets can be allocated and they can be used similarly to other virtual networks, subject to authorization + policy based on the specified <tenant_id>.
@@ -259,8 +245,8 @@ networks, and can also provide a "gateway" that connects one or more private L2 networks to a shared "external" network (e.g., a public network for access to the - Internet). See - and for details + Internet). See use_cases_single_router + and use_cases_tenant_router for details on common models of deploying OpenStack Networking L3 routers. The L3 router provides basic NAT capabilities on @@ -508,27 +494,17 @@ neutron floatingip-associate <floatingip-id> <internal VM port-id> < change is made restart nova-api and nova-compute in order to pick up this change. After this change is made one will be able to use both the OpenStack Compute and OpenStack Network security group API at the same time. - - - To use the OpenStack Compute security group - API with OpenStack Networking, the OpenStack Networking - plugin must implement the security group API. The - following plugins currently implement this: Nicira - NVP, Open vSwitch, Linux Bridge, NEC, and Ryu. - - You must configure the correct firewall driver in the - securitygroup section of the plugin/agent configuration file. - Some plugins and agents, such as Linux Bridge Agent and Open vSwitch Agent, use - the no-operation driver as the default, which results in non-working security - groups. - - When using the security group API through OpenStack - Compute, security groups are applied to all ports on - an instance. The reason for this is that OpenStack - Compute security group APIs are instances based and - not port based as OpenStack Networking. - - + + + To use the OpenStack Compute security group API with OpenStack Networking, the OpenStack Networking plugin must implement the security group API. The + following plugins currently implement this: Nicira NVP, Open vSwitch, Linux Bridge, NEC, and Ryu. + + You must configure the correct firewall driver in the securitygroup section of the plugin/agent configuration file. Some plugins and agents, such as Linux Bridge Agent and Open vSwitch Agent, use the no-operation driver as the default, which results in non-working security groups. + + When using the security group API through OpenStack Compute, security groups are applied to all ports on an instance. The reason for this is that OpenStack Compute security group APIs are instances based and not port based as OpenStack Networking. + + +
Security Group API Abstractions diff --git a/doc/admin-guide-network/ch_auth.xml b/doc/admin-guide-network/ch_auth.xml deleted file mode 100644 index 110e7a69c6..0000000000 --- a/doc/admin-guide-network/ch_auth.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - Authentication and Authorization - OpenStack Networking uses the OpenStack Identity Service - (project name keystone) as the default authentication service. - When OpenStack Identity is enabled, users who submit requests - to the OpenStack Networking service must provide an - authentication token in X-Auth-Token request header. Users get - this token by authenticating with the OpenStack Identity - endpoint. For more information about authentication with - OpenStack Identity Service, see the OpenStack Identity - documentation. - When OpenStack Identity is enabled, it is not mandatory to - specify tenant_id for resources in create requests because the - tenant identifier is derived from the authentication - token. - - The default authorization settings only allow - administrative users to create resources on behalf of a - different tenant. - - OpenStack Networking uses information received from - OpenStack Identity to authorize user requests. OpenStack - Networking handles two kind of authorization policies: - - - Operation-based: - policies specify access criteria for specific - operations, possibly with fine-grained control over - specific attributes; - - - Resource-based: - whether access to specific resource might be granted - or not according to the permissions configured for the - resource (currently available only for the network - resource). The actual authorization policies enforced - in OpenStack Networking might vary from deployment to - deployment. - - - The policy engine reads entries from the policy.json file. The actual - location of this file might vary from distribution to - distribution. Entries can be updated while the system is - running, and no service restart is required. That is to say, - every time the policy file is updated, the policies will be - automatically reloaded. Currently the only way of updating - such policies is to edit the policy file. - In this section, the terms "policy" and "rule" both refer to - objects that are specified in the same way in the policy file; - there are no syntax differences between a rule and a policy. A - policy is something that is matched directly from the - OpenStack Networking policy engine. A rule is a component of - policies, which are then evaluated. For instance in - create_subnet: [["admin_or_network_owner"]], - create_subnet is a - policy, and admin_or_network_owner is a rule. - Policies are triggered by the OpenStack Networking policy - engine whenever one of them matches an OpenStack Networking - API operation or a specific attribute being used in a given - operation. For instance the create_subnet policy - is triggered every time a POST /v2.0/subnets - request is sent to the OpenStack Networking server; on the - other hand create_network:shared is triggered - every time the shared - attribute is explicitly specified (and set to a value - different from its default) in a POST - /v2.0/networks request. It is also worth mentioning - that policies can be also related to specific API extensions; - for instance extension:provider_network:set will - be triggered if the attributes defined by the Provider Network - extensions are specified in an API request. - An authorization policy can be composed by one or more - rules. If more rules are specified, evaluation policy will be - successful if any of the rules evaluates successfully; if an - API operation matches multiple policies, all the policies must - evaluate successfully. Also, authorization rules are - recursive. Once a rule is matched, it can be resolved to - another rule until a terminal rule is reached. - The OpenStack Networking policy engine currently defines the - following kinds of terminal rules: - - - Role-based rules: - evaluate successfully if the user submitting the - request has the specified role. For instance - "role:admin"is successful if the user - submitting the request is an administrator. - - - Field-based rules: - evaluate successfully if a field of the - resource specified in the current request matches a - specific value. For instance - "field:networks:shared=True" is - successful if the attribute shared of the network resource is set to - true. - - - Generic rules: - compare an attribute in the resource with an attribute - extracted from the user's security credentials and - evaluates successfully if the comparison is - successful. For instance - "tenant_id:%(tenant_id)s" is - successful if the tenant identifier in the resource is - equal to the tenant identifier of the user submitting - the request. - - - The following is an extract from the default policy.json - file: - { -[1] "admin_or_owner": [["role:admin"], ["tenant_id:%(tenant_id)s"]], - "admin_or_network_owner": [["role:admin"], ["tenant_id:%(network_tenant_id)s"]], - "admin_only": [["role:admin"]], "regular_user": [], - "shared": [["field:networks:shared=True"]], -[2] "default": [["rule:admin_or_owner"]], - "create_subnet": [["rule:admin_or_network_owner"]], - "get_subnet": [["rule:admin_or_owner"], ["rule:shared"]], - "update_subnet": [["rule:admin_or_network_owner"]], - "delete_subnet": [["rule:admin_or_network_owner"]], - "create_network": [], -[3] "get_network": [["rule:admin_or_owner"], ["rule:shared"]], -[4] "create_network:shared": [["rule:admin_only"]], - "update_network": [["rule:admin_or_owner"]], - "delete_network": [["rule:admin_or_owner"]], - "create_port": [], -[5] "create_port:mac_address": [["rule:admin_or_network_owner"]], - "create_port:fixed_ips": [["rule:admin_or_network_owner"]], - "get_port": [["rule:admin_or_owner"]], - "update_port": [["rule:admin_or_owner"]], - "delete_port": [["rule:admin_or_owner"]] -} - [1] is a rule which evaluates successfully if the current - user is an administrator or the owner of the resource - specified in the request (tenant identifier is equal). - [2] is the default policy which is always evaluated if an - API operation does not match any of the policies in - policy.json. - [3] This policy will evaluate successfully if either - admin_or_owner, or - shared evaluates - successfully. - [4] This policy will restrict the ability of manipulating - the shared attribute for a - network to administrators only. - [5] This policy will restrict the ability of manipulating - the mac_address attribute - for a port only to administrators and the owner of the network - where the port is attached. - In some cases, some operations should be restricted to - administrators only; therefore, as a further example, let us - consider how this sample policy file should be modified in a - scenario where tenants are allowed only to define networks and - see their resources, and all the other operations can be - performed only in an administrative context: - { - "admin_or_owner": [["role:admin"], ["tenant_id:%(tenant_id)s"]], - "admin_only": [["role:admin"]], "regular_user": [], - "default": [["rule:admin_only"]], - "create_subnet": [["rule:admin_only"]], - "get_subnet": [["rule:admin_or_owner"]], - "update_subnet": [["rule:admin_only"]], - "delete_subnet": [["rule:admin_only"]], - "create_network": [], - "get_network": [["rule:admin_or_owner"]], - "create_network:shared": [["rule:admin_only"]], - "update_network": [["rule:admin_or_owner"]], - "delete_network": [["rule:admin_or_owner"]], - "create_port": [["rule:admin_only"]], - "get_port": [["rule:admin_or_owner"]], - "update_port": [["rule:admin_only"]], - "delete_port": [["rule:admin_only"]] -} - diff --git a/doc/admin-guide-network/ch_high_avail.xml b/doc/admin-guide-network/ch_high_avail.xml deleted file mode 100644 index 2f235fb359..0000000000 --- a/doc/admin-guide-network/ch_high_avail.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - High Availability - Several aspects of an OpenStack Networking deployment benefit from high-availabilty to - withstand individual node failures. In general, neutron-server and neutron-dhcp-agent can be - run in an active-active fashion. The neutron-l3-agent service can be run only as - active/passive, to avoid IP conflicts with respect to gateway IP addresses. -
- OpenStack Networking High Availability with - Pacemaker - You can run some OpenStack Networking services into a - cluster (Active / Passive or Active / Active for OpenStack - Networking Server only) with Pacemaker. - Here you can download the latest Resources Agents : - - neutron-server: https://github.com/madkiss/openstack-resource-agents - - - neutron-dhcp-agent : https://github.com/madkiss/openstack-resource-agents   - - - neutron-l3-agent : https://github.com/madkiss/openstack-resource-agents   - - - If you need more informations about "How to build a - cluster", please refer to Pacemaker - documentation. -
- diff --git a/doc/admin-guide-network/ch_limitations.xml b/doc/admin-guide-network/ch_limitations.xml deleted file mode 100644 index a685e8f7dc..0000000000 --- a/doc/admin-guide-network/ch_limitations.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - Limitations - - - - No equivalent for nova-network - --multi_host flag: Nova-network has - a model where the L3, NAT, and DHCP processing - happen on the compute node itself, rather than a - dedicated networking node. OpenStack Networking - now support running multiple l3-agent and dhcp-agents - with load being split across those agents, but the - tight coupling of that scheduling with the location of - the VM is not supported in Grizzly. The Havana release is expected - to include an exact replacement for the --multi_host flag - in nova-network. - - - Linux network namespace required on nodes running neutron-l3-agent - or neutron-dhcp-agent if overlapping IPs are in use: . In order - to support overlapping IP addresses, the OpenStack Networking DHCP and L3 agents - use Linux network namespaces by default. The hosts running these processes must - support network namespaces. To support network namespaces, the following are - required: - - - Linux kernel 2.6.24 or newer (with CONFIG_NET_NS=y in kernel - configuration) and - - - iproute2 utilities ('ip' command) version 3.1.0 (aka 20111117) or - newer - - - To check whether your host supports namespaces try running the following as - root: - ip netns add test-ns -ip netns exec test-ns ifconfig - If the preceding commands do not produce errors, your platform is likely - sufficient to use the dhcp-agent or l3-agent with namespace. In our experience, - Ubuntu 12.04 or later support namespaces as does Fedora 17 and new, but some - older RHEL platforms do not by default. It may be possible to upgrade the - iproute2 package on a platform that does not support namespaces by default. - If you need to disable namespaces, make sure the - neutron.conf used by neutron-server has the following - setting: - allow_overlapping_ips=False - and that the dhcp_agent.ini and l3_agent.ini have the following - setting: - use_namespaces=False - If the host does not support namespaces then the neutron-l3-agent and neutron-dhcp-agent should be run on different hosts. This - is due to the fact that there is no isolation between the IP addresses - created by the L3 agent and by the DHCP agent. By manipulating the routing - the user can ensure that these networks have access to one another. - If you run both L3 + DHCP services on the same node, you should enable - namespaces to avoid conflicts with routes : - use_namespaces=True - - - - No IPv6 support for L3 agent: The neutron-l3-agent, used - by many plugins to implement L3 forwarding, supports only IPv4 forwarding. - Currently, There are no errors provided if you configure IPv6 addresses via the - API. - - - ZeroMQ support is experimental: Some agents, including - neutron-dhcp-agent, neutron-openvswitch-agent, and neutron-linuxbridge-agent use - RPC to communicate. ZeroMQ is an available option in the configuration file, but - has not been tested and should be considered experimental. In particular, there - are believed to be issues with ZeroMQ and the dhcp agent. - - MetaPlugin is experimental: This release includes a - "MetaPlugin" that is intended to support multiple plugins at the same time for - different API requests, based on the content of those API requests. This - functionality has not been widely reviewed or tested by the core team, and - should be considered experimental until further validation is performed. - - - - diff --git a/doc/admin-guide-network/ch_overview.xml b/doc/admin-guide-network/ch_overview.xml deleted file mode 100644 index 537857d988..0000000000 --- a/doc/admin-guide-network/ch_overview.xml +++ /dev/null @@ -1,623 +0,0 @@ - - - Overview - This chapter describes the high-level concepts and - components of an OpenStack Networking deployment. -
- What is OpenStack Networking? - The OpenStack Networking project was created to provide a rich - API for defining network connectivity and - addressing in the cloud. The OpenStack Networking project gives - operators the ability to leverage different networking - technologies to power their cloud networking.   - For a detailed description of the OpenStack Networking API - abstractions and their attributes, see the OpenStack Networking API Guide - (v2.0). -
- OpenStack Networking API: Rich Control over Network Functionality - OpenStack Networking is a virtual network service that provides a - powerful API to define the network connectivity and - addressing used by devices from other services, such - as OpenStack Compute.   - The OpenStack Compute API has a virtual server - abstraction to describe computing resources. Similarly, - the OpenStack Networking API has virtual network, subnet, and port - abstractions to describe networking resources. In more - detail: - - Network. - An isolated L2 - segment, analogous to VLAN in the physical - networking world. - - - Subnet. - A block of v4 or v6 IP addresses and - associated configuration state. - - - Port. A - connection point for attaching a single - device, such as the NIC of a virtual - server, to a virtual network. Also - describes the associated network - configuration, such as the MAC and IP - addresses to be used on that port.   - - - - You can configure rich network - topologies by creating and configuring networks and - subnets, and then instructing other OpenStack services - like OpenStack Compute to attach virtual devices to ports on these - networks.  In particular, OpenStack Networking supports each tenant - having multiple private networks, and allows tenants - to choose their own IP addressing scheme (even if - those IP addresses overlap with those used by other - tenants). The OpenStack Networking service: - - - Enables advanced cloud networking - use cases, such as building multi-tiered web - applications and allowing applications to be migrated - to the cloud without changing IP addresses. - - - - - Offers flexibility for the cloud administrator - to customized network offerings. - - - - Provides a mechanism that lets - cloud administrators expose additional API - capabilities through API extensions.  Commonly, new - capabilities are first introduced as an API extension, - and over time become part of the core OpenStack Networking API. - - - - -
- -
- Plugin Architecture: Flexibility to Choose Different Network - Technologies - Enhancing traditional networking solutions to - provide rich cloud networking is challenging. - Traditional networking is not designed to scale to - cloud proportions nor to handle automatic configuration. - The original OpenStack Compute network implementation assumed a - very basic model of performing all isolation through - Linux VLANs and IP tables. OpenStack Networking introduces the - concept of a plugin, which is a back-end - implementation of the OpenStack Networking API. A plugin can use a - variety of technologies to implement the logical API - requests.  Some OpenStack Networking plugins might use basic Linux - VLANs and IP tables, while others might use more - advanced technologies, such as L2-in-L3 tunneling or - OpenFlow, to provide similar benefits. - The following plugins are currently included in the OpenStack Networking distribution: - - Big Switch Plugin (Floodlight REST Proxy). - http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin - - - - Brocade Plugin. - https://github.com/brocade/brocade - - - - Cisco. - http://wiki.openstack.org/cisco-neutron - - - - Cloudbase Hyper-V Plugin. - http://www.cloudbase.it/quantum-hyper-v-plugin/ - - - - Linux Bridge Plugin. - Documentation included in this guide and at - http://wiki.openstack.org/Neutron-Linux-Bridge-Plugin -   - - - Mellanox Plugin. - https://wiki.openstack.org/wiki/Mellanox-Neutron/ - - - - Midonet Plugin. - - http://www.midokura.com/ - - - - NEC OpenFlow Plugin. - http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin - - - - - Nicira NVP Plugin. - Documentation include in this guide, - - NVP Product Overview , and - NVP Product Support. - - - - Open vSwitch Plugin. - Documentation included in this guide. - - - - PLUMgrid. - https://https://wiki.openstack.org/wiki/PLUMgrid-Neutron - - - - Ryu Plugin. - https://github.com/osrg/ryu/wiki/OpenStack - - - - - Plugins can have different properties for hardware requirements, features, performance, - scale, or operator tools. Because OpenStack Networking supports a large number of plugins, - the cloud administrator is able to weigh different options and decide which networking - technology is right for the deployment. - - - Not all OpenStack networking plugins are compatible with all possible OpenStack compute drivers: - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugin Compatability with OpenStack Compute Drivers
Libvirt (KVM/QEMU)XenServerVMwareHyper-VBare-metalPowerVM
Bigswitch / FloodlightYes
BrocadeYes
CiscoYes
Cloudbase Hyper-VYes
Linux BridgeYes
MellanoxYes
MidonetYes
NEC OpenFlowYes
Nicira NVPYesYesYes
Open vSwitchYes
PlumgridYesYes
RyuYes
-
-
-
- OpenStack Networking Architecture - This section describes the high-level components of an - OpenStack Networking deployment. Before you deploy OpenStack Networking, it is useful to - understand the different components that make up the - solution, and how these components interact with each - other and with other OpenStack services. -
- Overview - - OpenStack Networking is a standalone service, just - like other OpenStack services such as OpenStack - Compute, OpenStack Image service, OpenStack Identity - service, or the OpenStack Dashboard. Like those - services, a deployment of OpenStack Networking often - involves deploying several processes on a variety of - hosts. - The main process of the OpenStack Networking server is - neutron-server, which is a - Python daemon that exposes the OpenStack Networking API and passes - user requests to the configured OpenStack Networking plugin for - additional processing. Typically, the plugin requires - access to a database for persistent storage (also similar - to other OpenStack services). - If your deployment uses a controller host to run centralized - OpenStack Compute components, you can deploy the OpenStack Networking server on - that same host. However, OpenStack Networking is entirely - standalone and can be deployed on its own host as - well. OpenStack Networking also includes additional agents that - might be required, depending on your deployment: - - plugin agent - (neutron-*-agent). - Runs on each hypervisor to perform local - vswitch configuration. The agent to be run will - depend on which plugin you are using, because - some plugins do not actually require an agent. - - - - dhcp agent - (neutron-dhcp-agent). - Provides DHCP services to tenant networks. - This agent is the same for all plugins. - - - - l3 - agent - (neutron-l3-agent). - Provides L3/NAT forwarding to provide - external network access for VMs on tenant - networks. This agent is the same for all plugins. - - - - - The above agents interact with the main Neutron process through RPC (for example, - rabbitmq or qpid) or through the standard OpenStack Networking API. Further: - - - OpenStack Networking relies on the OpenStack - Identity service (keystone) for the authentication and - authorization of all API request.  - - - OpenStack Compute (nova) interacts with OpenStack Networking through calls - to its standard API.  As part of creating a VM, the - nova-compute service communicates with the OpenStack Networking API to plug - each virtual NIC on the VM into a particular network.  -   - - The OpenStack Dashboard (horizon) integrates with the OpenStack Networking - API, allowing administrators and tenant users to create and manage network services - through the Dashboard GUI. - -   -
-
- Place Services on Physical Hosts - Like other OpenStack services, OpenStack Networking provides cloud administrators with - significant flexibility in deciding which individual services should run on - which physical devices. At one extreme, all service daemons can be run on a - single physical host for evaluation purposes. At the other, each service could - have its own physical hosts and, in some cases, be replicated across multiple hosts for - redundancy. For more information, see the chapter on high availability. - In this guide, we focus primarily on a standard - architecture that includes a “cloud controller” host, - a “network gateway” host, and a set of hypervisors for - running VMs.  The "cloud controller" and "network gateway" can be combined - in simple deployments. However, if you expect VMs to send significant amounts of - traffic to or from the Internet, a dedicated network gateway host is recommended - to avoid potential CPU contention between packet forwarding performed by - the neutron-l3-agent and other OpenStack services. -
-
- Network Connectivity for Physical Hosts - - - - - - A standard OpenStack Networking setup has up to four distinct physical data center networks: - - - Management - network. Used for internal - communication between OpenStack Components.   - IP addresses on this network should be - reachable only within the data center.  - - - - Data - network. Used for VM data - communication within the cloud deployment.  - The IP addressing requirements of this network - depend on the OpenStack Networking plugin being used.  - - - External - network. Used to provide VMs - with Internet access in some deployment - scenarios.  IP addresses on this network - should be reachable by anyone on the - Internet.  - - - API - network. Exposes all OpenStack - APIs, including the OpenStack Networking API, to - tenants. IP addresses on this network - should be reachable by anyone on the - Internet. The API network may be the same as - the external network, because it is possible to create - an external-network subnet that is allocated - IP ranges that use less than the full - range of IP addresses in an IP block. - - -
-
- -
- OpenStack Networking Deployment Use Cases - - The following common-use cases for OpenStack Networking are - not exhaustive, but can be combined to create more complex use cases. - -
- Use Case: Single Flat Network - In the simplest use case, a single OpenStack Networking network is created. This is a - "shared" network, meaning it is visible to all tenants via the OpenStack Networking - API. Tenant VMs have a single NIC, and receive - a fixed IP address from the subnet(s) associated with that network. - This use case essentially maps to the FlatManager - and FlatDHCPManager models provided by OpenStack Compute. Floating IPs are not - supported. - This network type is often created by the OpenStack administrator - to map directly to an existing physical network in the data center (called a - "provider network"). This allows the provider to use a physical - router on that data center network as the gateway for VMs to reach - the outside world. For each subnet on an external network, the gateway - configuration on the physical router must be manually configured - outside of OpenStack. - - - - - - - - -
- -
- Use Case: Multiple Flat Network - - This use case is similar to the above Single Flat Network use case, - except that tenants can see multiple shared networks via the OpenStack Networking API - and can choose which network (or networks) to plug into. - - - - - - - - - -
- -
- Use Case: Mixed Flat and Private Network - - This use case is an extension of the above Flat Network use cases. - In addition to being able to see one or more shared networks via - the OpenStack Networking API, tenants can also have access to private per-tenant - networks (only visible to tenant users). - - - Created VMs can have NICs on any of the shared networks and/or any of the private networks - belonging to the tenant. This enables the creation of "multi-tier" - topologies using VMs with multiple NICs. It also supports a model where - a VM acting as a gateway can provide services such as routing, NAT, or - load balancing. - - - - - - - - - -
- -
- Use Case: Provider Router with Private Networks - - This use case provides each tenant with one or more private networks, which - connect to the outside world via an OpenStack Networking router. - When each tenant gets exactly one network, this architecture maps to the same - logical topology as the VlanManager in OpenStack Compute (although of course, OpenStack Networking doesn't - require VLANs). Using the OpenStack Networking API, the tenant can only see a - network for each private network assigned to that tenant. The router - object in the API is created and owned by the cloud administrator. - - - This model supports giving VMs public addresses using - "floating IPs", in which the router maps public addresses from the - external network to fixed IPs on private networks. Hosts without floating - IPs can still create outbound connections to the external network, because - the provider router performs SNAT to the router's external IP. The - IP address of the physical router is used as the gateway_ip of the - external network subnet, so the provider has a default router for - Internet traffic. - - - The router provides L3 connectivity between private networks, meaning - that different tenants can reach each other's instances unless additional - filtering is used (for example, security groups). Because there is only a single - router, tenant networks cannot use overlapping IPs. Thus, it is likely - that the administrator would create the private networks on behalf of the tenants. - - - - - - - - - -
- -
- Use Case: Per-tenant Routers with Private Networks - - This use case represents a more advanced router scenario in which each tenant gets - at least one router, and potentially has access to the OpenStack Networking API to - create additional routers. The tenant can create their own networks, - potentially uplinking those networks to a router. This model enables - tenant-defined, multi-tier applications, with - each tier being a separate network behind the router. Since there are - multiple routers, tenant subnets can overlap without conflicting, - since access to external networks all happens via SNAT or Floating IPs. - Each router uplink and floating IP is allocated from the external network - subnet. - - - - - - - - - - -
-
- diff --git a/doc/admin-guide-network/ch_preface.xml b/doc/admin-guide-network/ch_preface.xml deleted file mode 100644 index 33368cc394..0000000000 --- a/doc/admin-guide-network/ch_preface.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - Preface - OpenStack Networking was created to provide a rich - API for defining network connectivity and addressing in the cloud. - The service, code-named "Neutron" (formerly known as "Quantum"), gives - operators the ability to leverage different networking technologies to - power their cloud networking. - The Board of Directors and Technical Committee members involved in - networking-related development and documentation have decided to change - the code name to "Neutron", as part of a legal agreement with Quantum - Corporation (the owner of the "Quantum" trademark). - Any references to the previous code name have been removed in this guide wherever - possible; all configuration files have been changed in the Havana release and this guide - updated respectively. -
- Intended Audience - This guide assists OpenStack administrators in - leveraging different networking technologies to power - their cloud networking. This document covers how to - install, configure, and run OpenStack Networking. - You must have access to a plugin providing - the implementation of the OpenStack Networking service. Plugins are - distributed both within and externally to the OpenStack Networking distribution. - For more information, see the plugin listing. - - You should also be familiar with running the OpenStack - Compute service as described in the operator's documentation. - -
- -
- Resources - For more information on OpenStack Networking and other network-related projects, - see the project page on the OpenStack wiki (wiki.openstack.org/Neutron). - For information about programming against the OpenStack - Networking API, see the OpenStack Networking API Guide - (v2.0). - We welcome feedback, comments, and bug reports at bugs.launchpad.net/Neutron. -
- - diff --git a/doc/admin-guide-network/ch_using.xml b/doc/admin-guide-network/ch_using.xml deleted file mode 100644 index 915503404a..0000000000 --- a/doc/admin-guide-network/ch_using.xml +++ /dev/null @@ -1,591 +0,0 @@ - - - Using OpenStack Networking - - You can use OpenStack Networking in the following ways: - - Expose the OpenStack Networking API to cloud tenants, - which enables them to build rich network topologies. - - - Have the cloud administrator, or an automated - administrative tool, create network connectivity on behalf of tenants. - - - - - - A tenant or cloud administrator can both perform the following procedures. - -
- Core OpenStack Networking API features - After you install and run OpenStack Networking, tenants - and administrators can perform create-read-update-delete (CRUD) API - networking operations by using either the - neutron CLI tool or the API. - Like other OpenStack CLI tools, the neutron - tool is just a basic wrapper around the OpenStack Networking API. Any - operation that can be performed using the CLI has an equivalent API call - that can be performed programmatically. - - The CLI includes a number of options. For details, refer to the - OpenStack End User Guide. - -
- API Abstractions - The OpenStack Networking v2.0 API provides control over both - L2 network topologies and the IP addresses used on those networks - (IP Address Management or IPAM). There is also an extension to - cover basic L3 forwarding and NAT, which provides capabilities - similar to nova-network. - - In the OpenStack Networking API: - - A 'Network' is an isolated L2 network segment - (similar to a VLAN), which forms the basis for - describing the L2 network topology available in an OpenStack - Networking deployment. - - A 'Subnet' associates a block of IP addresses - and other network configuration (for example, default gateways - or dns-servers) with an OpenStack Networking network. Each - subnet represents an IPv4 or IPv6 address block and, if needed, - each OpenStack Networking network can have multiple subnets. - - A 'Port' represents an attachment port to a L2 - OpenStack Networking network. When a port - is created on the network, by default it is allocated an - available fixed IP address out of one of the designated subnets - for each IP version (if one exists). When the port is destroyed, - its allocated addresses return to the pool of available IPs on - the subnet. Users of the OpenStack Networking API can either - choose a specific IP address from the block, or let OpenStack - Networking choose the first available IP address. - - - - The following table summarizes the attributes available for each - of the previous networking abstractions. For more operations about - API abstraction and operations, please refer to the - Networking API v2.0 Reference. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Attributes
AttributeTypeDefault valueDescription
admin_state_upboolTrueAdministrative state of the network. If specified as - False (down), this network does not forward - packets. -
iduuid-strGeneratedUUID for this network.
namestringNoneHuman-readable name for this network; is not required - to be unique. -
sharedboolFalseSpecifies whether this network resource can - be accessed by any tenant. The default policy setting restricts - usage of this attribute to administrative users only. -
statusstringN/AIndicates whether this network is - currently operational.
subnetslist(uuid-str)Empty listList of subnets associated with this network. -
tenant_iduuid-strN/ATenant owner of the network. Only administrative users - can set the tenant identifier; this cannot be changed - using authorization policies. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Subnet Attributes
AttributeTypeDefault ValueDescription
allocation_poolslist(dict)Every address in cidr, - excluding gateway_ip (if - configured). - List of cidr sub-ranges that are available for dynamic - allocation to ports. Syntax: - [ { "start":"10.0.0.2", - "end": "10.0.0.254"} ] -
cidrstringN/AIP range for this subnet, based on the IP version.
dns_nameserverslist(string)Empty listList of DNS name servers used by hosts in this subnet.
enable_dhcpboolTrueSpecifies whether DHCP is enabled for this subnet.
gateway_ipstringFirst address in cidr - Default gateway used by devices in this subnet.
host_routeslist(dict)Empty listRoutes that should be used by devices with - IPs from this subnet (not including local - subnet route).
iduuid-stringGeneratedUUID representing this subnet.
ip_versionint4IP version.
namestringNoneHuman-readable name for this subnet (might - not be unique). -
network_iduuid-stringN/ANetwork with which this subnet is associated.
tenant_iduuid-stringN/AOwner of network. Only administrative users - can set the tenant identifier; this cannot be changed - using authorization policies. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Port Attributes
AttributeTypeDefault ValueDescription
admin_state_upbooltrueAdministrative state of this port. If specified as False - (down), this port does not forward packets. -
device_idstringNoneIdentifies the device using this port (for example, a - virtual server's ID). -
device_ownerstringNoneIdentifies the entity using this port (for example, a - dhcp agent).
fixed_ipslist(dict)Automatically allocated from poolSpecifies IP addresses for this port; associates - the port with the subnets containing the listed IP - addresses. -
iduuid-stringGeneratedUUID for this port.
mac_addressstringGeneratedMac address to use on this port.
namestringNoneHuman-readable name for this port (might - not be unique). -
network_iduuid-stringN/ANetwork with which this port is associated. -
statusstringN/AIndicates whether the network is currently - operational. -
tenant_iduuid-stringN/AOwner of the network. Only administrative users - can set the tenant identifier; this cannot be changed - using authorization policies. -
-
-
- Basic operations - Before going further, it is highly recommended that you first - read the few pages in the - OpenStack End User Guide that are specific to OpenStack - Networking. OpenStack Networking's CLI has some advanced - capabilities that are described only in that guide. - - The following table provides just a few examples of the - neutron tool usage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic OpenStack Networking operations
ActionCommand
Create a network.$ neutron net-create net1
Create a subnet associated with net1.$ neutron subnet-create net1 10.0.0.0/24
List ports on a tenant.$ neutron port-list
List ports on a tenant, and display the id, fixed_ips, and - device_owner columns.$ neutron port-list -c id -c fixed_ips -c device_owner -
Display details of a particular port.$ neutron port-show port-id
- - - The device_owner field describes who owns the - port. A port whose device_owner begins with: - - "network:" is created by OpenStack - Networking. - "compute:" is created by OpenStack Compute. - - - - -
-
- Administrative operations - The cloud administrator can perform any neutron - call on behalf of tenants by specifying an OpenStack Identity tenant_id in the request, as follows: - - $ neutron net-create --tenant-id=tenant-id network-name - - For example: - - $ neutron net-create --tenant-id=5e4bbe24b67a4410bc4d9fae29ec394e net1 -To view all tenant IDs in OpenStack Identity, run the - following command as an OpenStack Identity (keystone) admin user: - - $ keystone tenant-list - -
-
- Advanced operations - The following table provides a few advanced examples of using the - neutron tool to create and display - networks, subnets, and ports. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Advanced OpenStack Networking operations
ActionCommand
Create a "shared" network (that is, a network that can be used by all tenants).$ neutron net-create --shared public-net
Create a subnet that has a specific gateway IP address.$ neutron subnet-create --gateway 10.0.0.254 net1 10.0.0.0/24
Create a subnet that has no gateway IP address.$ neutron subnet-create --no-gateway net1 10.0.0.0/24
Create a subnet in which DHCP is disabled.$ neutron subnet-create net1 10.0.0.0/24 --enable_dhcp False
Create subnet with a specific set of host routes.$ neutron subnet-create test-net1 40.0.0.0/24 --host_routes type=dict list=true destination=40.0.1.0/24,nexthop=40.0.0.2
Create subnet with a specific set of dns nameservers.$ neutron subnet-create test-net1 40.0.0.0/24 --dns_nameservers list=true 8.8.8.7 8.8.8.8
Display all ports/IPs allocated on a network.$ neutron port-list --network_id net-id
-
-
-
- Using OpenStack Compute with OpenStack Networking -
- Basic Operations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Compute/Networking operations
ActionCommand
Check available networks.$ neutron net-list
Boot a VM with a single NIC on a selected OpenStack Networking network.$ nova boot --image img --flavor flavor --nic net-id=net-id vm-name -
Search for all ports with a device_id corresponding to the OpenStack Compute instance UUID.$ neutron port-list --device_id=vm-id
Search for ports, but limit display to only the port's mac_address.$ neutron port-list -c mac_address --device_id=vm-id
Temporarily disable a port from sending traffic.$ neutron port-update port-id --admin_state_up=False
Delete a VM.$ nova delete --device_id=vm-id
- When you: - - Boot a Compute VM, a port on the network is - automatically created that corresponds to the VM Nic. You may - also need to configure security group rules to allow access to the VM. - Delete a Compute VM, the underlying OpenStack - Networking port is automatically deleted as well. - - -
-
- Advanced VM creation - - - - - - - - - - - - - - - - - - - - - - - - -
VM creation operations
ActionCommand
Boot a VM with multiple NICs.$ nova boot --image img --flavor flavor --nic net-id=net1-id --nic net-id=net2-id vm-name
Boot a VM with a specific IP address: first create an OpenStack - Networking port with a specific IP address, then boot - a VM specifying a port-id rather than a - net-id.$ neutron port-create --fixed-ip subnet_id=subnet-id,ip_address=IP net-id -$ nova boot --image img --flavor flavor --nic port-id=port-id vm-name -
Boot a VM that connects to all networks that are accessible to - the tenant who submits the request (without the - --nic option). - $ nova boot --image img --flavor flavor vm-name
- OpenStack Networking does not currently support the v4-fixed-ip parameter of the --nic option for the nova command. - -
-
- Security Groups (Enabling Ping and SSH on VMs) - You must configure security group rules depending on the type of - plugin you are using. If you are using a plugin that: - - - Implements OpenStack Networking security groups, you can - configure security group rules directly by using - neutron security-group-rule-create. The following example - allows ping and ssh access to - your VMs. - - $ neutron security-group-rule-create --protocol icmp --direction ingress default -$ neutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress default - - - Does not implement OpenStack Networking security groups, you can - configure security group rules by using the - nova secgroup-add-rule or - euca-authorize command. The following - nova commands allow - ping and ssh access to your VMs. - - $ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 -$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0 - - - - If your plugin implements OpenStack Networking security groups, - you can also leverage Compute security groups by setting - security_group_api = neutron in - nova.conf. After setting this option, all Compute - security group commands are proxied to OpenStack Networking. - - -
-
- - - diff --git a/doc/admin-guide-network/figures/UseCase-MixedFlatPrivate.png b/doc/common/figures/UseCase-MixedFlatPrivate.png similarity index 100% rename from doc/admin-guide-network/figures/UseCase-MixedFlatPrivate.png rename to doc/common/figures/UseCase-MixedFlatPrivate.png diff --git a/doc/admin-guide-network/figures/UseCase-MultiFlat.png b/doc/common/figures/UseCase-MultiFlat.png similarity index 100% rename from doc/admin-guide-network/figures/UseCase-MultiFlat.png rename to doc/common/figures/UseCase-MultiFlat.png diff --git a/doc/admin-guide-network/figures/UseCase-MultiRouter.png b/doc/common/figures/UseCase-MultiRouter.png similarity index 100% rename from doc/admin-guide-network/figures/UseCase-MultiRouter.png rename to doc/common/figures/UseCase-MultiRouter.png diff --git a/doc/admin-guide-network/figures/UseCase-SingleFlat.png b/doc/common/figures/UseCase-SingleFlat.png similarity index 100% rename from doc/admin-guide-network/figures/UseCase-SingleFlat.png rename to doc/common/figures/UseCase-SingleFlat.png diff --git a/doc/admin-guide-network/figures/UseCase-SingleRouter.png b/doc/common/figures/UseCase-SingleRouter.png similarity index 100% rename from doc/admin-guide-network/figures/UseCase-SingleRouter.png rename to doc/common/figures/UseCase-SingleRouter.png diff --git a/doc/admin-guide-network/figures/demo_flat_install.png b/doc/common/figures/demo_flat_install.png similarity index 100% rename from doc/admin-guide-network/figures/demo_flat_install.png rename to doc/common/figures/demo_flat_install.png diff --git a/doc/admin-guide-network/figures/demo_install.png b/doc/common/figures/demo_install.png similarity index 100% rename from doc/admin-guide-network/figures/demo_install.png rename to doc/common/figures/demo_install.png diff --git a/doc/admin-guide-network/figures/demo_multiple_dhcp_agents.png b/doc/common/figures/demo_multiple_dhcp_agents.png similarity index 100% rename from doc/admin-guide-network/figures/demo_multiple_dhcp_agents.png rename to doc/common/figures/demo_multiple_dhcp_agents.png diff --git a/doc/admin-guide-network/figures/demo_routers_with_private_networks.png b/doc/common/figures/demo_routers_with_private_networks.png similarity index 100% rename from doc/admin-guide-network/figures/demo_routers_with_private_networks.png rename to doc/common/figures/demo_routers_with_private_networks.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-compute.png b/doc/common/figures/under-the-hood-scenario-1-linuxbridge-compute.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-compute.png rename to doc/common/figures/under-the-hood-scenario-1-linuxbridge-compute.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-netns.png b/doc/common/figures/under-the-hood-scenario-1-linuxbridge-netns.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-netns.png rename to doc/common/figures/under-the-hood-scenario-1-linuxbridge-netns.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-network.png b/doc/common/figures/under-the-hood-scenario-1-linuxbridge-network.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-linuxbridge-network.png rename to doc/common/figures/under-the-hood-scenario-1-linuxbridge-network.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-compute.png b/doc/common/figures/under-the-hood-scenario-1-ovs-compute.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-compute.png rename to doc/common/figures/under-the-hood-scenario-1-ovs-compute.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-netns.png b/doc/common/figures/under-the-hood-scenario-1-ovs-netns.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-netns.png rename to doc/common/figures/under-the-hood-scenario-1-ovs-netns.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-network.png b/doc/common/figures/under-the-hood-scenario-1-ovs-network.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1-ovs-network.png rename to doc/common/figures/under-the-hood-scenario-1-ovs-network.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-1.png b/doc/common/figures/under-the-hood-scenario-1.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-1.png rename to doc/common/figures/under-the-hood-scenario-1.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-compute.png b/doc/common/figures/under-the-hood-scenario-2-linuxbridge-compute.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-compute.png rename to doc/common/figures/under-the-hood-scenario-2-linuxbridge-compute.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-netns.png b/doc/common/figures/under-the-hood-scenario-2-linuxbridge-netns.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-netns.png rename to doc/common/figures/under-the-hood-scenario-2-linuxbridge-netns.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-network.png b/doc/common/figures/under-the-hood-scenario-2-linuxbridge-network.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-linuxbridge-network.png rename to doc/common/figures/under-the-hood-scenario-2-linuxbridge-network.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-compute.png b/doc/common/figures/under-the-hood-scenario-2-ovs-compute.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-compute.png rename to doc/common/figures/under-the-hood-scenario-2-ovs-compute.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-netns.png b/doc/common/figures/under-the-hood-scenario-2-ovs-netns.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-netns.png rename to doc/common/figures/under-the-hood-scenario-2-ovs-netns.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-network.png b/doc/common/figures/under-the-hood-scenario-2-ovs-network.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2-ovs-network.png rename to doc/common/figures/under-the-hood-scenario-2-ovs-network.png diff --git a/doc/admin-guide-network/figures/under-the-hood-scenario-2.png b/doc/common/figures/under-the-hood-scenario-2.png similarity index 100% rename from doc/admin-guide-network/figures/under-the-hood-scenario-2.png rename to doc/common/figures/under-the-hood-scenario-2.png diff --git a/doc/admin-guide-network/ch_adv_operational_features.xml b/doc/common/section_networking-quotas.xml similarity index 54% rename from doc/admin-guide-network/ch_adv_operational_features.xml rename to doc/common/section_networking-quotas.xml index 67ffe403ee..b1f84d138e 100644 --- a/doc/admin-guide-network/ch_adv_operational_features.xml +++ b/doc/common/section_networking-quotas.xml @@ -1,193 +1,25 @@ - - Advanced Operational Features -
- Logging Configuration - OpenStack Networking components use a Python logging module for logging. You can - configure logging using any of the following: - - - - Update settings in the /etc/neutron/neutron.conf file. For - example: - [DEFAULT] -# Default log level is INFO -# verbose and debug has the same result. -# One of them will set DEBUG log level output -debug = False -verbose = True - -# Where to store Neutron state files. This directory must be writable by the -# user executing the agent. -# state_path = /var/lib/neutron - -# Where to store lock files -lock_path = $state_path/lock - -# log_format = %(asctime)s %(levelname)8s [%(name)s] %(message)s -# log_date_format = %Y-%m-%d %H:%M:%S - -# use_syslog -> syslog -# log_file and log_dir -> log_dir/log_file -# (not log_file) and log_dir -> log_dir/{binary_name}.log -# use_stderr -> stderr -# (not user_stderr) and (not log_file) -> stdout -# publish_errors -> notification system - -# use_syslog = False -# syslog_log_facility = LOG_USER - -# use_stderr = True -# log_file = -log_dir =/var/log/neutron - - - Use command-line options. For example, use the --debug - option when using the neutron command-line tool (see the - OpenStack End User Guide for more information). - Command-line options override options specified in - neutron.conf. - - - Use a python logging configuration file (see Python Logging HOWTO for - more information). - - - -
-
- Notifications -
- Notification Options - You can send notifications when creating, updating, or deleting OpenStack Networking - resources. To support a DHCP agent, you must set up an rpc_notifier - driver. - To configure notifications, update settings in the - /etc/neutron/neutron.conf file. For example: - ============ Notification System Options ===================== - -# Notifications can be sent when network/subnet/port are create, updated or deleted. -# There are three methods of sending notifications: logging (via the -# log_file directive), rpc (via a message queue) and -# noop (no notifications sent, the default) - -# Notification_driver can be defined multiple times -# Do nothing driver -# notification_driver = neutron.openstack.common.notifier.no_op_notifier -# Logging driver -# notification_driver = neutron.openstack.common.notifier.log_notifier -# RPC driver -notification_driver = neutron.openstack.common.notifier.rpc_notifier - -# default_notification_level is used to form actual topic names or to set logging level -# default_notification_level = INFO - -# default_publisher_id is a part of the notification payload -# host = myhost.com -# default_publisher_id = $host - -# Defined in rpc_notifier for rpc way, can be comma separated values. -# The actual topic names will be %s.%(default_notification_level)s -notification_topics = notifications -
-
- Notification Use Cases -
- Logging and RPC - To make the OpenStack Networking server send notifications using logging and RPC, use - the following configuration in the neutron.conf file. - RPC notifications are sent to the notifications.info queue - binded to a topic exchange defined by control_exchange (also - defined in neutron.conf). Logging options are described in Logging Settings. - # ============ Notification System Options ===================== - -# Notifications can be sent when network/subnet/port are create, updated or deleted. -# There are three methods of sending notifications: logging (via the -# log_file directive), rpc (via a message queue) and -# noop (no notifications sent, the default) - -# Notification_driver can be defined multiple times -# Do nothing driver -# notification_driver = neutron.openstack.common.notifier.no_op_notifier -# Logging driver -notification_driver = neutron.openstack.common.notifier.log_notifier -# RPC driver -notification_driver = neutron.openstack.common.notifier.rpc_notifier - -# default_notification_level is used to form actual topic names or to set logging level -default_notification_level = INFO - -# default_publisher_id is a part of the notification payload -# host = myhost.com -# default_publisher_id = $host - -# Defined in rpc_notifier for rpc way, can be comma separated values. -# The actual topic names will be %s.%(default_notification_level)s -notification_topics = notifications -
-
- Multiple RPC Topics - To make the OpenStack Networking server send notifications to multiple RPC topics, use - the following configuration in the neutron.conf file. - RPC notifications are sent to the notifications_one.info and - notifications_two.info queues, that are binded to a topic - exchange defined by control_exchange (also defined in - neutron.conf). Logging options are described in Logging Settings. - # ============ Notification System Options ===================== - -# Notifications can be sent when network/subnet/port are create, updated or deleted. -# There are three methods of sending notifications: logging (via the -# log_file directive), rpc (via a message queue) and -# noop (no notifications sent, the default) - -# Notification_driver can be defined multiple times -# Do nothing driver -# notification_driver = neutron.openstack.common.notifier.no_op_notifier -# Logging driver -# notification_driver = neutron.openstack.common.notifier.log_notifier -# RPC driver -notification_driver = neutron.openstack.common.notifier.rabbit_notifier - -# default_notification_level is used to form actual topic names or to set logging level -default_notification_level = INFO - -# default_publisher_id is a part of the notification payload -# host = myhost.com -# default_publisher_id = $host - -# Defined in rpc_notifier for rpc way, can be comma separated values. -# The actual topic names will be %s.%(default_notification_level)s -notification_topics = notifications_one,notifications_two -
-
-
-
+
Quotas - Quota is a function to limit number of resources. You can enforce default quota for all - tenants. You will get error when you try to create more resources than the limit. - $ neutron net-create test_net -Quota exceeded for resources: ['network'] - - Per-tenant quota configuration is also supported by quota - extension API. See - Per-tenant quota configuration for details. - + Quota is a function used to limit the number of resources. A default quota may be + enforced for all tenants. Attempting to create resources over the limit triggers an + error. + $ neutron net-create test_net +Quota exceeded for resources: ['network'] + Per-tenant quota configuration is also supported by the quota extension API. See Per-tenant quota configuration for details.
Basic quota configuration - In OpenStack Networking default quota mechanism, all - tenants have a same quota value, i.e., a number of resources - that a tenant can create. This is enabled by default. - The value of quota is defined in the OpenStack Networking configuration file - (neutron.conf). If you want to disable quotas for a specific resource - (e.g., network, subnet, port), remove a corresponding item from - quota_items. Each of the quota values in the example below is the - default value. + In the Networking default quota mechanism, all tenants have the same quota value, such + as the number of resources that a tenant can create. This is enabled by default. + The quota value is defined in the OpenStack Networking configuration file + (neutron.conf). If you want to disable quotas for a specific resource + (e.g., network, subnet, port), remove a corresponding item from + quota_items. Each of the quota values in the example below is the default + value. [quotas] # resource name(s) that are supported in quota features quota_items = network,subnet,port @@ -393,5 +225,4 @@ quota_security_group_rule = 100 | subnet | 10 | +------------+-------+
-
- +
diff --git a/doc/config-reference/ch_networkingconfigure.xml b/doc/config-reference/ch_networkingconfigure.xml index 4111c843f0..053064cb3f 100644 --- a/doc/config-reference/ch_networkingconfigure.xml +++ b/doc/config-reference/ch_networkingconfigure.xml @@ -8,5 +8,12 @@ xmlns:ns3="http://www.w3.org/1998/Math/MathML" xmlns:ns="http://docbook.org/ns/docbook"> OpenStack Networking - + This chapter explains the configuration options and scenarios for OpenStack Networking. + For installation prerequisites, steps, and use cases, refer to corresponding chapter in the + OpenStack Installation Guide. + + + + + diff --git a/doc/admin-guide-network/ch_adv_config.xml b/doc/config-reference/networking/section_networking-adv-config.xml similarity index 70% rename from doc/admin-guide-network/ch_adv_config.xml rename to doc/config-reference/networking/section_networking-adv-config.xml index 7954d19ce7..6087bb8450 100644 --- a/doc/admin-guide-network/ch_adv_config.xml +++ b/doc/config-reference/networking/section_networking-adv-config.xml @@ -1,11 +1,13 @@ - +
Advanced Configuration Options This section describes advanced configurations options for various system components (i.e. config options where the default is usually ok, but that the user may want to tweak). After installing from packages, $NEUTRON_CONF_DIR is /etc/neutron. -
+
OpenStack Networking Server with Plugin This is the web server that runs the OpenStack Networking API Web Server. It is responsible for loading a plugin and passing the API calls to the plugin for processing. @@ -103,7 +105,7 @@ mysql> grant all on <database-name>.* to '<user-name>'@'%';All of the plugin configuration files options can be found in the Appendix - Configuration File Options.
-
+
DHCP Agent There is an option to run a DHCP server that will allocate IP addresses to virtual machines running on the network. When a subnet is created, by default, the @@ -143,13 +145,11 @@ mysql> grant all on <database-name>.* to '<user-name>'@'%'; - All of the DHCP agent configuration options can be found in the Appendix - Configuration File Options.
Namespace By default the DHCP agent makes use of Linux network namespaces in order to support overlapping IP addresses. Requirements for network namespaces support are - described in the Limitation section. + described in the Limitations section. If the Linux installation does not support network namespace, you must disable using network namespace in the DHCP agent config @@ -157,7 +157,7 @@ mysql> grant all on <database-name>.* to '<user-name>'@'%';use_namespaces = False
-
+
L3 Agent There is an option to run a L3 agent that will give enable layer 3 forwarding and floating IP support. The node that runs the L3 agent should run: @@ -219,13 +219,11 @@ admin_password $SERVICE_PASSWORD - All of the L3 agent configuration options can be found in the Appendix - Configuration File Options.
Namespace By default the L3 agent makes use of Linux network namespaces in order to support overlapping IP addresses. Requirements for network namespaces support are described - in the Limitation section. + in the Limitation section. If the Linux installation does not support network namespace, you must disable using network namespace in the L3 agent config file @@ -290,4 +288,93 @@ gateway_external_network_id = e828e54c-850a-4e74-80a8-8b79c6a285d8 external_network_bridge = br-ex-2
- +
+ Limitations + + + + No equivalent for nova-network + --multi_host flag: Nova-network has + a model where the L3, NAT, and DHCP processing + happen on the compute node itself, rather than a + dedicated networking node. OpenStack Networking + now support running multiple l3-agent and dhcp-agents + with load being split across those agents, but the + tight coupling of that scheduling with the location of + the VM is not supported in Grizzly. The Havana release is expected + to include an exact replacement for the --multi_host flag + in nova-network. + + + Linux network namespace required on nodes running neutron-l3-agent + or neutron-dhcp-agent if overlapping IPs are in use: . In order + to support overlapping IP addresses, the OpenStack Networking DHCP and L3 agents + use Linux network namespaces by default. The hosts running these processes must + support network namespaces. To support network namespaces, the following are + required: + + + Linux kernel 2.6.24 or newer (with CONFIG_NET_NS=y in kernel + configuration) and + + + iproute2 utilities ('ip' command) version 3.1.0 (aka 20111117) or + newer + + + To check whether your host supports namespaces try running the following as + root: + # ip netns add test-ns +# ip netns exec test-ns ifconfig + If the preceding commands do not produce errors, your platform is likely + sufficient to use the dhcp-agent or l3-agent with namespace. In our experience, + Ubuntu 12.04 or later support namespaces as does Fedora 17 and new, but some + older RHEL platforms do not by default. It may be possible to upgrade the + iproute2 package on a platform that does not support namespaces by default. + If you need to disable namespaces, make sure the + neutron.conf used by neutron-server has the following + setting: + allow_overlapping_ips=False + and that the dhcp_agent.ini and l3_agent.ini have the following + setting: + use_namespaces=False + If the host does not support namespaces then the neutron-l3-agent and neutron-dhcp-agent should be run on different hosts. This + is due to the fact that there is no isolation between the IP addresses + created by the L3 agent and by the DHCP agent. By manipulating the routing + the user can ensure that these networks have access to one another. + If you run both L3 and DHCP services on the same node, you should enable + namespaces to avoid conflicts with routes: + use_namespaces=True + + + + No IPv6 support for L3 agent: The neutron-l3-agent, used + by many plugins to implement L3 forwarding, supports only IPv4 forwarding. + Currently, there are no errors provided if you configure IPv6 addresses via the + API. + + + ZeroMQ support is experimental: Some agents, including + neutron-dhcp-agent, neutron-openvswitch-agent, and neutron-linuxbridge-agent use + RPC to communicate. ZeroMQ is an available option in the configuration file, but + has not been tested and should be considered experimental. In particular, there + are believed to be issues with ZeroMQ and the dhcp agent. + + MetaPlugin is experimental: This release includes a + "MetaPlugin" that is intended to support multiple plugins at the same time for + different API requests, based on the content of those API requests. This + functionality has not been widely reviewed or tested by the core team, and + should be considered experimental until further validation is performed. + + + +
+
diff --git a/doc/admin-guide-network/ch_config.xml b/doc/config-reference/networking/section_networking-config-identity.xml similarity index 97% rename from doc/admin-guide-network/ch_config.xml rename to doc/config-reference/networking/section_networking-config-identity.xml index d6d99b7a47..e3fa406988 100644 --- a/doc/admin-guide-network/ch_config.xml +++ b/doc/config-reference/networking/section_networking-config-identity.xml @@ -1,11 +1,8 @@ - - Required Configuration for OpenStack Identity & Compute - - To work with OpenStack Networking, you must configure and set up the OpenStack Identity - Service and the OpenStack Compute Service. -
+
OpenStack Identity To configure the OpenStack Identity Service for use with OpenStack @@ -109,8 +106,8 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696 <para>See the OpenStack Installation Guides for more details about creating service entries and service users. </para> - </section> - <section xml:id="nova_with_neutron"> + +<section xml:id="nova_with_neutron"> <title>OpenStack Compute If OpenStack Networking is used, you must not run OpenStack Compute's nova-network @@ -158,7 +155,8 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696 you must adjust settings in the nova.conf configuration file. -
+
+
Networking API & and Credential Configuration Each time a VM is provisioned or deprovisioned in OpenStack Compute, nova-* @@ -436,4 +434,3 @@ libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
- diff --git a/doc/admin-guide-network/app_demo_multi_dhcp_agents.xml b/doc/config-reference/networking/section_networking-multi-dhcp-agents.xml similarity index 99% rename from doc/admin-guide-network/app_demo_multi_dhcp_agents.xml rename to doc/config-reference/networking/section_networking-multi-dhcp-agents.xml index 192fde4e37..ab2af12288 100644 --- a/doc/admin-guide-network/app_demo_multi_dhcp_agents.xml +++ b/doc/config-reference/networking/section_networking-multi-dhcp-agents.xml @@ -56,7 +56,7 @@ format="PNG" /> - + diff --git a/doc/config-reference/networking/section_networking-options-reference.xml b/doc/config-reference/networking/section_networking-options-reference.xml index 36664d53f0..0cb6e21916 100644 --- a/doc/config-reference/networking/section_networking-options-reference.xml +++ b/doc/config-reference/networking/section_networking-options-reference.xml @@ -1,8 +1,8 @@ - -
+ +
Networking Configuration Options These options and descriptions were generated from the code in the Networking service project which provides software defined networking diff --git a/doc/config-reference/networking/section_networking-plugins.xml b/doc/config-reference/networking/section_networking-plugins.xml index bf995fd04b..bf7489ab56 100644 --- a/doc/config-reference/networking/section_networking-plugins.xml +++ b/doc/config-reference/networking/section_networking-plugins.xml @@ -8,20 +8,15 @@ xmlns:ns3="http://www.w3.org/1998/Math/MathML" xmlns:ns="http://docbook.org/ns/docbook" version="5.0"> -Networking Plugins - -OpenStack Networking introduces the concept of a plugin, which is a -back-end implementation of the OpenStack Networking API. A plugin -can use a variety of technologies to implement the logical API -requests. Some OpenStack Networking plugins might use basic Linux -VLANs and IP tables, while others might use more advanced technologies, -such as L2-in-L3 tunneling or OpenFlow. - -The follow sections detail the configuration options for the various -plugins available. - +Networking plugins +OpenStack Networking introduces the concept of a plugin, which is a back-end implementation of + the OpenStack Networking API. A plugin can use a variety of technologies to + implement the logical API requests. Some OpenStack Networking plugins might use + basic Linux VLANs and IP tables, while others might use more advanced + technologies, such as L2-in-L3 tunneling or OpenFlow. The following sections + detail the configuration options for the various plugins available.
-BigSwitch Configuration Options +BigSwitch configuration options
@@ -33,11 +28,11 @@ plugins available.
-CloudBase Hyper-V Configuration Options +CloudBase Hyper-V configuration options
-Linux Bridge Configuration Options +Linux bridge configuration options
@@ -45,7 +40,7 @@ plugins available.
-Meta Plugin Configuration Options +Meta Plugin configuration options The Meta Plugin allows you to use multiple plugins at the same time.
@@ -54,27 +49,27 @@ plugins available.
-MidoNet Configuration Options +MidoNet configuration options
-NEC Configuration Options +NEC configuration options
-Nicira NVP Configuration Options +Nicira NVP configuration options
-Open vSwitch Configuration Options +Open vSwitch configuration options
-PLUMgrid Configuration Options +PLUMgrid configuration options
-Ryu Configuration Options +Ryu configuration options
diff --git a/doc/admin-guide-network/ch_under_the_hood.xml b/doc/config-reference/networking/section_networking-scenarios.xml similarity index 92% rename from doc/admin-guide-network/ch_under_the_hood.xml rename to doc/config-reference/networking/section_networking-scenarios.xml index ace6ab375d..8bc5a11e45 100644 --- a/doc/admin-guide-network/ch_under_the_hood.xml +++ b/doc/config-reference/networking/section_networking-scenarios.xml @@ -1,11 +1,15 @@ - - Under the Hood - This chapter describes two networking scenarios and how the Open vSwitch plugin and - the Linux bridging plugin implement these scenarios. + +
+ Networking scenarios + This chapter describes two networking scenarios and how the Open vSwitch plug-in and the + Linux bridging plug-in implement these scenarios.
Open vSwitch - This section describes how the Open vSwitch plugin implements the OpenStack + This section describes how the Open vSwitch plug-in implements the OpenStack Networking abstractions.
Configuration @@ -31,7 +35,7 @@ bridge_mappings = physnet2:br-eth1 - + Under the service tenant, create the shared router, define the @@ -72,7 +76,7 @@ bridge_mappings = physnet2:br-eth1 - + @@ -166,7 +170,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 The following figure shows the network devices on the network host: - + As on the compute host, there is an Open vSwitch integration bridge @@ -272,7 +276,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 - + @@ -288,7 +292,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 - + Under the service tenant, define the public @@ -330,7 +334,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 - + The Compute host configuration resembles the @@ -345,7 +349,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 scenario. - + In this configuration, the network namespaces are @@ -354,7 +358,7 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1 - + In this scenario, there are four network namespaces @@ -369,11 +373,9 @@ bridge_mappings = physnet1:br-ex,physnet2:br-eth1
Linux bridge - This section describes how the Linux bridge plugin - implements the OpenStack Networking abstractions. For - information about DHCP and L3 agents, see - . - + This section describes how the Linux bridge plug-in implements the OpenStack + Networking abstractions. For information about DHCP and L3 agents, see .
Configuration This example uses VLAN isolation on the switches to isolate tenant networks. This configuration labels the physical @@ -398,7 +400,7 @@ physical_interface_mappings = physnet2:eth1 - + Under the service tenant, create the shared router, define the @@ -438,7 +440,7 @@ physical_interface_mappings = physnet2:eth1 - + @@ -476,14 +478,14 @@ physical_interface_mappings = physnet2:eth1 The following figure shows the network devices on the network host. - + - The following figure shows how the Linux bridge plugin uses network namespaces to - provide isolation.veth pairs form connections between the + The following figure shows how the Linux bridge plug-in uses network namespaces to + provide isolation.veth pairs form connections between the Linux bridges and the network namespaces. - +
@@ -495,7 +497,7 @@ physical_interface_mappings = physnet2:eth1 Internet. - + Under the service tenant, define the public @@ -538,7 +540,7 @@ physical_interface_mappings = physnet2:eth1 - + The configuration on the compute host is very similar to the configuration in scenario 1. The @@ -551,7 +553,7 @@ physical_interface_mappings = physnet2:eth1 scenario. - + The main difference between the configuration in this scenario and the previous one @@ -559,7 +561,7 @@ physical_interface_mappings = physnet2:eth1 across the two subnets, as shown in the following figure. - + In this scenario, there are four network namespaces @@ -572,4 +574,4 @@ physical_interface_mappings = physnet2:eth1
- +
diff --git a/doc/admin-guide-network/ch_install.xml b/doc/install-guide/ch_installnetworking.xml similarity index 84% rename from doc/admin-guide-network/ch_install.xml rename to doc/install-guide/ch_installnetworking.xml index ac276e1e6a..e1d92308bc 100644 --- a/doc/admin-guide-network/ch_install.xml +++ b/doc/install-guide/ch_installnetworking.xml @@ -1,13 +1,11 @@ - OpenStack Networking Installation - Learn how to install and get the OpenStack Networking service - up and running. -
- Initial Prerequisites + xmlns:xi="http://www.w3.org/2001/XInclude" + xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" + xml:id="ch_installing-openstack-networking"> + Installing OpenStack Networking Service +
+ Initial prerequisites @@ -24,8 +22,8 @@
-
- Install Packages (Ubuntu) +
+ Install packages (Ubuntu) This procedure uses the Cloud Archive for Ubuntu. You can read more about it at /etc/neutron directory.
-
+
Installing Packages (Fedora) You can retrieve the OpenStack packages for Fedora from: /etc/neutron directory.
- +
+ Set up for deployment use cases + This section describes how to configure the OpenStack + Networking service and its components for some typical use + cases. + + + +
+
+ OpenStack Networking Deployment Use Cases + + The following common-use cases for OpenStack Networking are + not exhaustive, but can be combined to create more complex use cases. + +
+ Use Case: Single Flat Network + In the simplest use case, a single OpenStack Networking network is created. This is a + "shared" network, meaning it is visible to all tenants via the OpenStack Networking + API. Tenant VMs have a single NIC, and receive + a fixed IP address from the subnet(s) associated with that network. + This use case essentially maps to the FlatManager + and FlatDHCPManager models provided by OpenStack Compute. Floating IPs are not + supported. + This network type is often created by the OpenStack administrator + to map directly to an existing physical network in the data center (called a + "provider network"). This allows the provider to use a physical + router on that data center network as the gateway for VMs to reach + the outside world. For each subnet on an external network, the gateway + configuration on the physical router must be manually configured + outside of OpenStack. + + + + + + + + +
+ +
+ Use Case: Multiple Flat Network + + This use case is similar to the above Single Flat Network use case, + except that tenants can see multiple shared networks via the OpenStack Networking API + and can choose which network (or networks) to plug into. + + + + + + + + + +
+ +
+ Use Case: Mixed Flat and Private Network + + This use case is an extension of the above Flat Network use cases. + In addition to being able to see one or more shared networks via + the OpenStack Networking API, tenants can also have access to private per-tenant + networks (only visible to tenant users). + + + Created VMs can have NICs on any of the shared networks and/or any of the private networks + belonging to the tenant. This enables the creation of "multi-tier" + topologies using VMs with multiple NICs. It also supports a model where + a VM acting as a gateway can provide services such as routing, NAT, or + load balancing. + + + + + + + + + +
+ +
+ Use Case: Provider Router with Private Networks + + This use case provides each tenant with one or more private networks, which + connect to the outside world via an OpenStack Networking router. + When each tenant gets exactly one network, this architecture maps to the same + logical topology as the VlanManager in OpenStack Compute (although of course, OpenStack Networking doesn't + require VLANs). Using the OpenStack Networking API, the tenant can only see a + network for each private network assigned to that tenant. The router + object in the API is created and owned by the cloud administrator. + + + This model supports giving VMs public addresses using + "floating IPs", in which the router maps public addresses from the + external network to fixed IPs on private networks. Hosts without floating + IPs can still create outbound connections to the external network, because + the provider router performs SNAT to the router's external IP. The + IP address of the physical router is used as the gateway_ip of the + external network subnet, so the provider has a default router for + Internet traffic. + + + The router provides L3 connectivity between private networks, meaning + that different tenants can reach each other's instances unless additional + filtering is used (for example, security groups). Because there is only a single + router, tenant networks cannot use overlapping IPs. Thus, it is likely + that the administrator would create the private networks on behalf of the tenants. + + + + + + + + + +
+ +
+ Use Case: Per-tenant Routers with Private Networks + + This use case represents a more advanced router scenario in which each tenant gets + at least one router, and potentially has access to the OpenStack Networking API to + create additional routers. The tenant can create their own networks, + potentially uplinking those networks to a router. This model enables + tenant-defined, multi-tier applications, with + each tier being a separate network behind the router. Since there are + multiple routers, tenant subnets can overlap without conflicting, + since access to external networks all happens via SNAT or Floating IPs. + Each router uplink and floating IP is allocated from the external network + subnet. + + + + + + + + + +
+
+ diff --git a/doc/admin-guide-network/app_demo_routers_with_private_networks.xml b/doc/install-guide/section_networking-pertenant-routers-with-private-networks.xml similarity index 98% rename from doc/admin-guide-network/app_demo_routers_with_private_networks.xml rename to doc/install-guide/section_networking-pertenant-routers-with-private-networks.xml index 6f5719ead8..39b5542396 100644 --- a/doc/admin-guide-network/app_demo_routers_with_private_networks.xml +++ b/doc/install-guide/section_networking-pertenant-routers-with-private-networks.xml @@ -1,15 +1,16 @@
+ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" + xml:id="section_networking-routers-with-private-networks"> Per-tenant Routers with Private Networks This section describes how to install the OpenStack Networking service and its components for the "Use Case: Per-tenant Routers with Private Networks + linkend="section_use-cases-tenant-router">Use Case: Per-tenant Routers with Private Networks ". - + @@ -20,7 +21,7 @@ - + @@ -43,9 +44,8 @@ Because this example runs a DHCP agent and L3 agent on one node, the - use_namespace option must be set to True in - the configuration file for each agent. The default is - True. See . + use_namespace option must be set to True in + the configuration file for each agent. The default is True. Below is a description of the nodes in the setup: @@ -152,8 +152,8 @@ Create database ovs_neutron. - See the section on the Core - Plugins for the exact details. + Refer back Initial + prerequisites to get started. Update the OpenStack Networking configuration file, diff --git a/doc/admin-guide-network/app_demo_single_router.xml b/doc/install-guide/section_networking-provider-router-with-private_networks.xml similarity index 98% rename from doc/admin-guide-network/app_demo_single_router.xml rename to doc/install-guide/section_networking-provider-router-with-private_networks.xml index 2e6e6136e8..dbc2de7ee2 100644 --- a/doc/admin-guide-network/app_demo_single_router.xml +++ b/doc/install-guide/section_networking-provider-router-with-private_networks.xml @@ -2,11 +2,12 @@
+ xml:id="section_networking-provider-router_with-provate-networks"> Provider Router with Private Networks This section describes how to install the OpenStack - Networking service and its components for the "Use Case: - Provider Router with Private Networks." + Networking service and its components for the "Use Case: + Provider Router with Private Networks. We will follow the Basic Install Guide except for the Neutron, @@ -17,11 +18,9 @@ separation instead. The following figure shows the setup: - Because you run the DHCP agent and L3 agent on one node, - you must set use_namespaces to - True (which is the default) in both - agents' configuration files. See Limitations. + Because you run the DHCP agent and L3 agent on one node, you must set + use_namespaces to True (which is the default) + in both agents' configuration files. diff --git a/doc/admin-guide-network/app_demo_flat.xml b/doc/install-guide/section_networking-single-flat.xml similarity index 97% rename from doc/admin-guide-network/app_demo_flat.xml rename to doc/install-guide/section_networking-single-flat.xml index 9a8e6f81ce..81b56d7df5 100644 --- a/doc/admin-guide-network/app_demo_flat.xml +++ b/doc/install-guide/section_networking-single-flat.xml @@ -1,11 +1,11 @@
+ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" + xml:id="section_network-single-flat"> Single Flat Network - This section describes how to install the OpenStack Networking service - and its components for the "Use Case: Single Flat Network - ". + This section describes how to install the OpenStack Networking service and its components + for the Use + Case: Single Flat Network. The diagram below shows the setup. For simplicity all of the nodes should have one interface for management traffic and one or more interfaces for traffic to and from VMs. The management @@ -15,7 +15,7 @@ supported plugin and its agent. - + Here are some nodes in the setup. @@ -122,8 +122,8 @@ Create database ovs_neutron. - See the section on the Core - Plugins for the exact details. + Refer back to the Initial prerequisites to get started. Update the OpenStack Networking configuration file, diff --git a/doc/user-guide-admin/section_keystone_cli_set_quotas.xml b/doc/user-guide-admin/section_keystone_cli_set_quotas.xml index 1c7e2b1ef4..74ec29b94f 100644 --- a/doc/user-guide-admin/section_keystone_cli_set_quotas.xml +++ b/doc/user-guide-admin/section_keystone_cli_set_quotas.xml @@ -37,4 +37,5 @@ +