diff --git a/doc/admin-guide-cloud/ch_networking.xml b/doc/admin-guide-cloud/ch_networking.xml index 6057f8b08e..4cb5becd0c 100644 --- a/doc/admin-guide-cloud/ch_networking.xml +++ b/doc/admin-guide-cloud/ch_networking.xml @@ -140,16 +140,20 @@ Mellanox Plug-in. - https://wiki.openstack.org/wiki/Mellanox-Neutron/ + >https://wiki.openstack.org/wiki/Mellanox-Neutron/ Midonet - Plug-in. - http://www.midokura.com/ - + Plug-in. + http://www.midokura.com/ + + + ML2 (Modular Layer 2) + Plug-in. + https://wiki.openstack.org/wiki/Neutron/ML2 NEC OpenFlow @@ -188,12 +192,24 @@ - Plug-ins can have different properties for hardware - requirements, features, performance, scale, or - operator tools. Because Networking supports a large - number of plug-ins, the cloud administrator is able to - weigh different options and decide which networking - technology is right for the deployment. + Plug-ins can have different properties for hardware requirements, features, + performance, scale, or operator tools. Because Networking supports a large number of + plug-ins, the cloud administrator can weigh options to decide on the right + networking technology for the deployment. + In the Havana release, OpenStack Networking provides the Modular + Layer 2 (ML2) plug-in that can concurrently use multiple layer 2 + networking technologies that are found in real-world data centers. It currently + works with the existing Open vSwitch, Linux Bridge, and Hyper-v L2 agents. The ML2 + framework simplifies the addition of support for new L2 technologies and reduces the + effort that is required to add and maintain them compared to monolithic + plug-ins. + + Plugins Deprecation Notice: + The Open vSwitch and Linux Bridge plug-ins are deprecated in the Havana + release and will be removed in the Icehouse release. All features have been + ported to the ML2 plug-in in the form of mechanism drivers. ML2 currently + provides Linux Bridge, Open vSwitch and Hyper-v mechanism drivers. + Not all Networking plug-ins are compatible with all possible Compute drivers: @@ -275,6 +291,15 @@ + + + + + @@ -338,7 +363,7 @@ deploying several processes on a variety of hosts.The Networking server uses the neutron-server daemon + class="service">neutron-server daemon to expose the Networking API and to pass user requests to the configured Networking plug-in for additional processing. Typically, the plug-in requires access to @@ -364,15 +389,15 @@ dhcp agent (neutron-dhcp-agent). - Provides DHCP services to tenant networks. All - plug-ins use this agent. + Provides DHCP services to tenant networks. + Some plug-ins use this agent. l3 agent (neutron-l3-agent). Provides L3/NAT forwarding to provide external - network access for VMs on tenant networks. All - plug-ins use this agent. + network access for VMs on tenant networks. + Some plug-ins use this agent. These agents interact with the main neutron process @@ -506,7 +531,7 @@ The CLI includes a number of options. For details, refer to the OpenStack End User + >OpenStack End User Guide.
API abstractions @@ -1034,8 +1059,8 @@ VM NIC is automatically created and associated with the default security group. You can configure security group rules to + linkend="enabling_ping_and_ssh" + >security group rules to enable users to access the VM. @@ -1157,7 +1182,7 @@ Service endpoint. For more information about authentication with the Identity Service, see OpenStack Identity Service API v2.0 + >OpenStack Identity Service API v2.0 Reference. When the Identity Service is enabled, it is not mandatory to specify the tenant ID for resources in create requests because the @@ -1205,7 +1230,7 @@ a policy, which is evaluated. For instance in create_subnet: [["admin_or_network_owner"]], create_subnet is a policy, + role="italic">create_subnet is a policy, and admin_or_network_owner is a rule. Policies are triggered by the Networking policy engine @@ -1338,7 +1363,7 @@ helps prevent individual node failures. In general, you can run neutron-server and neutron-dhcp-agent in an + class="service">neutron-dhcp-agent in an active-active fashion. You can run the neutron-l3-agent service as active/passive, which avoids IP conflicts with respect @@ -1352,18 +1377,18 @@ neutron-server: https://github.com/madkiss/openstack-resource-agents + xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-server" + >https://github.com/madkiss/openstack-resource-agents neutron-dhcp-agent : https://github.com/madkiss/openstack-resource-agents + xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-dhcp" + >https://github.com/madkiss/openstack-resource-agents neutron-l3-agent : https://github.com/madkiss/openstack-resource-agents + xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-l3" + >https://github.com/madkiss/openstack-resource-agents @@ -1387,6 +1412,11 @@
+ + + + + diff --git a/doc/admin-guide-cloud/section_networking_adv_features.xml b/doc/admin-guide-cloud/section_networking_adv_features.xml index 02e34c30dc..61050c28d6 100644 --- a/doc/admin-guide-cloud/section_networking_adv_features.xml +++ b/doc/admin-guide-cloud/section_networking_adv_features.xml @@ -27,8 +27,8 @@ additional provider attributes on all virtual networks, and are able to specify these attributes in order to create provider networks. - The provider extension is supported by the openvswitch - and linuxbridge plug-ins. Configuration of these plug-ins + The provider extension is supported by the Open vSwitch + and Linux Bridge plug-ins. Configuration of these plug-ins requires familiarity with this extension.
Terminology @@ -42,7 +42,7 @@ network (identified by a UUID and optional name) whose ports can be attached as vNICs to Compute instances and to various Networking - agents. The openvswitch and linuxbridge + agents. The Open vSwitch and Linux Bridge plug-ins each support several different mechanisms to realize virtual networks. @@ -114,13 +114,23 @@ are not associated by Networking with specific physical networks. + + Virtual Extensible LAN + (VXLAN) network. VXLAN is a proposed + encapsulation protocol for running an overlay + network on existing Layer 3 infrastructure. An + overlay network is a virtual network that is + built on top of existing network Layer 2 and + Layer 3 technologies to support elastic compute + architectures. + - Both the openvswitch and linuxbridge plug-ins - support VLAN networks, flat networks, and local - networks. Only the openvswitch plug-in currently - supports GRE networks, provided that the host's Linux - kernel supports the required Open vSwitch - features. + The ML2, Open vSwitch and Linux Bridge plug-ins support + VLAN networks, flat networks, and local networks. Only + the ML2 and Open vSwitch plug-ins currently support GRE + and VXLAN networks, provided that the required features + exist in the hosts Linux kernel, Open vSwitch and iproute2 + packages.
Provider attributes @@ -688,11 +698,9 @@ - To use the Compute security group API with - Networking, the Networking plug-in must - implement the security group API. The - following plug-ins currently implement this: - Nicira NVP, Open vSwitch, Linux Bridge, NEC, + To use the Compute security group API with Networking, the Networking + plug-in must implement the security group API. The following plug-ins + currently implement this: ML2, Nicira NVP, Open vSwitch, Linux Bridge, NEC, and Ryu. @@ -1402,8 +1410,8 @@ two instances to enable fast data plane failover. The allowed-address-pairs extension is currently - only supported by the following plug-ins: Nicira NVP, - OpenvSwitch, and ML2. + only supported by the following plug-ins: ML2, Nicira + NVP, and OpenvSwitch.
Basic allowed address pairs operations diff --git a/doc/common/ch_getstart.xml b/doc/common/ch_getstart.xml index dd1612620c..09eeefc642 100644 --- a/doc/common/ch_getstart.xml +++ b/doc/common/ch_getstart.xml @@ -573,19 +573,22 @@ for action. - OpenStack Networking plug-ins and agents. Plugs and - unplugs ports, creates networks or subnets, and provides - IP addressing. These plug-ins and agents differ depending - on the vendor and technologies used in the particular - cloud. OpenStack Networking ships with plug-ins and agents - for Cisco virtual and physical switches, Nicira NVP - product, NEC OpenFlow products, Open vSwitch, Linux - bridging, and the Ryu Network Operating System. + OpenStack Networking Plug-ins and Agents. + Plug and unplug ports, create networks or subnets, and + provide IP addressing. These plug-ins and agents differ + depending on the vendor and technologies used in the Cloud + System. OpenStack Networking ships with plug-ins and agents + for Arista, Brocade, Cisco NXOS as well as Nexus 1000V and + Mellanox switches, Linux bridging, Nicira NVP product, NEC + OpenFlow, Open vSwitch, PLUMgrid Platform, and the Ryu + Network Operating System. The common agents are L3 (layer 3), DHCP (dynamic host IP addressing), and a plug-in agent. - Messaging queue. Most OpenStack Networking + Messaging Queue. Most OpenStack Networking installations make use of a messaging queue to route information between the neutron-server and various agents as well as a database to store networking state for
ML2Yes + + Yes + +
NEC OpenFlow Yes
ML2TrueTrue
Open vSwitch True