diff --git a/doc/admin-guide-cloud/ch_networking.xml b/doc/admin-guide-cloud/ch_networking.xml index 165286f770..e8e88427d0 100644 --- a/doc/admin-guide-cloud/ch_networking.xml +++ b/doc/admin-guide-cloud/ch_networking.xml @@ -13,7 +13,6 @@ - diff --git a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml index 76ec648f08..596f8bbf3b 100644 --- a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml +++ b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml @@ -7,123 +7,6 @@ example, configuration options where the default works but that the user wants to customize options. After installing from packages, $NEUTRON_CONF_DIR is /etc/neutron. -
- L3 agent - You can run an L3 agent that enables layer-3 forwarding and floating IP support. - The node that runs the L3 agent should run: - neutron-l3-agent --config-file NEUTRON_CONFIG_FILE --config-file L3_CONFIG_FILE - You must configure a driver that matches the plug-in that runs on the service. This - driver creates the routing interface. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Settings
OptionValue
Open vSwitch -
interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)br-ex
Linux Bridge -
interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)neutron.agent.linux.interface.BridgeInterfaceDriver
external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)This field must be empty (or the bridge name for the external network).
-
- Namespace - By default, the L3 agent uses Linux network namespaces to support overlapping IP - addresses. - If the Linux installation does not support network namespaces, you must disable - network namespaces in the L3 agent configuration file. The default value of - is True. - use_namespaces = False - When you set to False, only one - router ID is supported per node. - Use the configuration option to configure the - router: - # If use_namespaces is set to False then the agent can only configure one router. -# This is done by setting the specific router_id. -router_id = 1064ad16-36b7-4c2f-86f0-daa2bcbd6b2a - To configure it, you must run the OpenStack Networking service, create a router, - and set the router ID value to the value in the L3 agent - configuration file. - $ neutron router-create myrouter1 -Created a new router: -+-----------------------+--------------------------------------+ -| Field | Value | -+-----------------------+--------------------------------------+ -| admin_state_up | True | -| external_gateway_info | | -| id | 338d42d7-b22e-42c5-9df6-f3674768fe75 | -| name | myrouter1 | -| status | ACTIVE | -| tenant_id | 0c236f65baa04e6f9b4236b996555d56 | -+-----------------------+--------------------------------------+ -
-
- Multiple external networks - Use one of these methods to support multiple external networks: - - - Assign multiple subnets to an external network. - - - Use multiple floating IP pools. - - - The following sections describe these options. -
- Assign multiple subnets to an external network - This approach leverages the addition of on-link routes, which enables a router - to host floating IPs from any subnet on an external network regardless of which - subnet the primary router IP address comes from. This method does not require - the creation of multiple external networks. - To add a subnet to the external network, use the following command - template: - $ neutron subnet-create EXT_NETWORK_NAME CIDR - For example: - $ neutron subnet-create my-ext_network 10.0.0.0/29 -
-
- Multiple floating IP pools - The L3 API in OpenStack Networking supports multiple - floating IP pools. In OpenStack Networking, a floating - IP pool is represented as an external network, and a - floating IP is allocated from a subnet associated with - the external network. You can associate a L3 agent - with multiple external networks. - Before starting a L3 agent, you must update the - configuration files with the UUID of the external network. - To enable the L3 agent to support multiple external - networks, edit the l3_agent.ini file - and leave the - and options unset: - handle_internal_only_routers = True -gateway_external_network_id = -external_network_bridge = -
-
-
L3 metering agent You can run an L3 metering agent that enables layer-3 traffic metering. In general, diff --git a/doc/admin-guide-cloud/networking/section_networking-scenarios.xml b/doc/admin-guide-cloud/networking/section_networking-scenarios.xml deleted file mode 100644 index d6b2032328..0000000000 --- a/doc/admin-guide-cloud/networking/section_networking-scenarios.xml +++ /dev/null @@ -1,791 +0,0 @@ - -
- Networking scenarios - This chapter describes two networking scenarios and how the Open vSwitch plug-in and the - Linux Bridge plug-in implement these scenarios. -
- - Open vSwitch - This section describes how the Open vSwitch plug-in implements the Networking - abstractions. -
- Configuration - This example uses VLAN segmentation on the switches to isolate tenant networks. - This configuration labels the physical network associated with the public network as - physnet1, and the physical network associated with the data - network as physnet2, which leads to the following configuration - options in ovs_neutron_plugin.ini: - [ovs] -tenant_network_type = vlan -network_vlan_ranges = physnet1,physnet2:100:110 -integration_bridge = br-int -bridge_mappings = physnet2:br-eth1 -
-
- Scenario 1: one tenant, two networks, one router - The first scenario has two private networks (net01, and - net02), each with one subnet - (net01_subnet01: 192.168.101.0/24, - net02_subnet01, 192.168.102.0/24). Both private networks are - attached to a router that connects them to the public network - (10.64.201.0/24). - - - - - - Under the service tenant, create the shared router, define the - public network, and set it as the default gateway of the - router$ tenant=$(keystone tenant-list | awk '/service/ {print $2}') -$ neutron router-create router01 -$ neutron net-create --tenant-id $tenant public01 \ - --provider:network_type flat \ - --provider:physical_network physnet1 \ - --router:external True -$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \ - --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp -$ neutron router-gateway-set router01 public01 - Under the demo user tenant, create the private network - net01 and corresponding subnet, and connect it to the - router01 router. Configure it to use VLAN ID 101 on the - physical - switch.$ tenant=$(keystone tenant-list|awk '/demo/ {print $2}') -$ neutron net-create --tenant-id $tenant net01 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 101 -$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24 -$ neutron router-interface-add router01 net01_subnet01 - Similarly, for net02, using VLAN ID 102 on the physical - switch:$ neutron net-create --tenant-id $tenant net02 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 102 -$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24 -$ neutron router-interface-add router01 net02_subnet01 -
- Scenario 1: Compute host config - The following figure shows how to configure various Linux networking devices - on the compute host: - - - - - - - Types of network devices - - There are four distinct type of virtual networking devices: TAP - devices, veth pairs, Linux bridges, and Open vSwitch bridges. For an - Ethernet frame to travel from eth0 of virtual machine - vm01 to the physical network, it must pass - through nine devices inside of the host: TAP vnet0, - Linux bridge qbrNNN, veth - pair (qvbNNN, - qvoNNN), Open vSwitch - bridge br-int, veth pair (int-br-eth1, - phy-br-eth1), and, finally, the physical network interface - card eth1. - - A TAP device, such as - vnet0 is how hypervisors such as KVM and Xen - implement a virtual network interface card (typically called a VIF or vNIC). - An Ethernet frame sent to a TAP device is received by the guest operating - system. - A veth pair is a pair of directly - connected virtual network interfaces. An Ethernet frame sent to one end of a - veth pair is received by the other end of a veth pair. Networking uses veth - pairs as virtual patch cables to make connections between virtual - bridges. - A Linux bridge behaves like a simple - MAC learning switch: you can connect multiple (physical or virtual) network - interfaces devices to a Linux bridge. The Linux bridge uses a MAC caching - table to record which interface on the bridge is used to communicate with a - host on the link. For any Ethernet frames that come in from one interface - attached to the bridge, the host MAC address and port on which the frame was - received is recorded in the MAC caching table for a limited time. When the - bridge needs to forward a frame, it will check to see if the frame's - destination MAC address is recorded in the table. If so, the Linux bridge - forwards the frame through only that port. If not, the frame is flooded to - all network ports in the bridge, with the exception of the port where the - frame was received. - An Open vSwitch bridge behaves like a - virtual switch: network interface devices connect to Open vSwitch bridge's - ports, and the ports can be configured much like a physical switch's ports, - including VLAN configurations. - - - Integration bridge - The br-int Open vSwitch bridge is the integration - bridge: all guests running on the compute host connect to this bridge. - Networking implements isolation across these guests by configuring the - br-int ports. - - - Physical connectivity bridge - The br-eth1 bridge provides connectivity to the - physical network interface card, eth1. It connects to the - integration bridge by a veth pair: (int-br-eth1, - phy-br-eth1). - - - VLAN translation - In this example, net01 and net02 have VLAN ids of 1 and 2, respectively. - However, the physical network in our example only supports VLAN IDs in the - range 101 through 110. The Open vSwitch agent is responsible for configuring - flow rules on br-int and br-eth1 to do - VLAN translation. When br-eth1 receives a frame marked - with VLAN ID 1 on the port associated with phy-br-eth1, - it modifies the VLAN ID in the frame to 101. Similarly, when - br-int receives a frame marked with VLAN ID 101 on - the port associated with int-br-eth1, it modifies the - VLAN ID in the frame to 1. - - - Security groups: iptables and Linux bridges - Ideally, the TAP device vnet0 would be connected - directly to the integration bridge, br-int. - Unfortunately, this isn't possible because of how OpenStack security groups - are currently implemented. OpenStack uses iptables rules on the TAP devices - such as vnet0 to implement security groups, and Open - vSwitch is not compatible with iptables rules that are applied directly on - TAP devices that are connected to an Open vSwitch port. - Networking uses an extra Linux bridge and a veth pair as a workaround for - this issue. Instead of connecting vnet0 to an Open - vSwitch bridge, it is connected to a Linux bridge, - qbrXXX. This bridge is - connected to the integration bridge, br-int, through the - (qvbXXX, - qvoXXX) veth pair. - -
-
- Scenario 1: Network host config - The network host runs the neutron-openvswitch-plugin-agent, the - neutron-dhcp-agent, neutron-l3-agent, and neutron-metadata-agent - services. - On the network host, assume that eth0 is connected to the external network, - and eth1 is connected to the data network, which leads to the following - configuration in the ovs_neutron_plugin.ini file: - [ovs] -tenant_network_type = vlan -network_vlan_ranges = physnet1,physnet2:101:110 -integration_bridge = br-int -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 - (br-int) and an Open vSwitch bridge connected to the data - network (br-eth1), and the two are connected by a veth pair, - and the neutron-openvswitch-plugin-agent configures the ports on both switches - to do VLAN translation. - An additional Open vSwitch bridge, br-ex, connects to the - physical interface that is connected to the external network. In this example, - that physical interface is eth0. - - While the integration bridge and the external bridge are connected by a - veth pair (int-br-ex, phy-br-ex), this example uses layer - 3 connectivity to route packets from the internal networks to the public - network: no packets traverse that veth pair in this example. - - - Open vSwitch internal ports - The network host uses Open vSwitch internal - ports. Internal ports enable you to assign one or more IP - addresses to an Open vSwitch bridge. In previous example, the - br-int bridge has four internal ports: - tapXXX, - qr-YYY, - qr-ZZZ, and - tapWWW. Each internal - port has a separate IP address associated with it. An internal port, - qg-VVV, is on the - br-ex bridge. - - - DHCP agent - By default, the Networking DHCP agent uses a process called dnsmasq to - provide DHCP services to guests. Networking must create an internal port for - each network that requires DHCP services and attach a dnsmasq process to - that port. In the previous example, the - tapXXX interface is on - net01_subnet01, and the - tapWWW interface is on - net02_subnet01. - - - L3 agent (routing) - The Networking L3 agent uses Open vSwitch internal ports to implement - routing and relies on the network host to route the packets across the - interfaces. In this example, the - qr-YYY interface is on - net01_subnet01 and has the IP address - 192.168.101.1/24. The qr-ZZZ, - interface is on net02_subnet01 and has the IP address - 192.168.102.1/24. The - qg-VVV interface has - the IP address 10.64.201.254/24. Because each of these - interfaces is visible to the network host operating system, the network host - routes the packets across the interfaces, as long as an administrator has - enabled IP forwarding. - The L3 agent uses iptables to implement floating IPs to do the network - address translation (NAT). - - - Overlapping subnets and network namespaces - One problem with using the host to implement routing is that one of the - Networking subnets might overlap with one of the physical networks that the - host uses. For example, if the management network is implemented on - eth2 and also happens to be on the - 192.168.101.0/24 subnet, routing problems will occur - because the host can't determine whether to send a packet on this subnet to - qr-YYY or - eth2. If end users are permitted to create their own - logical networks and subnets, you must design the system so that such - collisions do not occur. - Networking uses Linux network namespaces - to prevent collisions between the physical networks on the - network host, and the logical networks used by the virtual machines. It also - prevents collisions across different logical networks that are not routed to - each other, as the following scenario shows. - A network namespace is an isolated environment with its own networking - stack. A network namespace has its own network interfaces, routes, and - iptables rules. Consider it a chroot jail, except for networking instead of - for a file system. LXC (Linux containers) use network namespaces to - implement networking virtualization. - Networking creates network namespaces on the network host to avoid subnet - collisions. - - - - - - In this example, there are three network namespaces, as shown in the - figure above: - - qdhcp-AAA: - contains the - tapXXX - interface and the dnsmasq process that listens on that interface - to provide DHCP services for net01_subnet01. - This allows overlapping IPs between - net01_subnet01 and any other subnets on - the network host. - - - qrouter-BBBB: - contains the - qr-YYY, - qr-ZZZ, - and qg-VVV - interfaces, and the corresponding routes. This namespace - implements router01 in our example. - - - qdhcp-CCC: - contains the - tapWWW - interface and the dnsmasq process that listens on that - interface, to provide DHCP services for - net02_subnet01. This allows overlapping - IPs between net02_subnet01 and any other - subnets on the network host. - - - -
-
-
- Scenario 2: two tenants, two networks, two routers - In this scenario, tenant A and tenant B each have a network with one subnet and - one router that connects the tenants to the public Internet. - - - - - - Under the service tenant, define the public - network:$ tenant=$(keystone tenant-list | awk '/service/ {print $2}') -$ neutron net-create --tenant-id $tenant public01 \ - --provider:network_type flat \ - --provider:physical_network physnet1 \ - --router:external True -$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \ - --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp - Under the tenantA user tenant, create the tenant router and set - its gateway for the public - network.$ tenant=$(keystone tenant-list|awk '/tenantA/ {print $2}') -$ neutron router-create --tenant-id $tenant router01 -$ neutron router-gateway-set router01 public01 - Then, define private network net01 using VLAN ID 101 on the - physical switch, along with its subnet, and connect it to the router. - $ neutron net-create --tenant-id $tenant net01 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 101 -$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24 -$ neutron router-interface-add router01 net01_subnet01 - Similarly, for tenantB, create a router and another network, - using VLAN ID 102 on the physical - switch:$ tenant=$(keystone tenant-list|awk '/tenantB/ {print $2}') -$ neutron router-create --tenant-id $tenant router02 -$ neutron router-gateway-set router02 public01 -$ neutron net-create --tenant-id $tenant net02 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 102 -$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24 -$ neutron router-interface-add router02 net02_subnet01 -
- Scenario 2: Compute host config - The following figure shows how to configure Linux networking devices on the - compute host: - - - - - - - The compute host configuration resembles the configuration in scenario 1. - However, in scenario 1, a guest connects to two subnets while in this - scenario, the subnets belong to different tenants. - -
-
- Scenario 2: Network host config - The following figure shows the network devices on the network host for the - second scenario. - - - - - - In this configuration, the network namespaces are organized to isolate the two - subnets from each other as shown in the following figure. - - - - - - In this scenario, there are four network namespaces - (qdhcp-AAA, - qrouter-BBBB, - qrouter-CCCC, and - qdhcp-DDDD), instead of - three. Because there is no connectivity between the two networks, each router is - implemented by a separate namespace. -
-
-
- Configure Open vSwitch tunneling - Tunneling encapsulates network traffic between physical Networking hosts and - allows VLANs to span multiple physical hosts. Instances communicate as if they share - the same layer 2 network. Open vSwitch supports tunneling with the VXLAN and GRE - encapsulation protocols. -
- Example VXLAN tunnel - - - - - - Example VXLAN tunnel - - -
- This diagram shows two instances running on separate hosts connected by a VXLAN - tunnel. The required physical and virtual components are also illustrated. The - following procedure creates a VXLAN or GRE tunnel between two Open vSwitches running - on separate Networking hosts: - - Example tunnel configuration - - Create a virtual bridge named OVS-BR0 on each participating host: - ovs-vsctl add-br OVS-BR0 - - - Create a tunnel to link the OVS-BR0 virtual bridges. Run the ovs-vsctl - command on HOST1 to create the tunnel and link it to the bridge on - HOST2: - GRE tunnel command: - ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.11 - VXLAN tunnel command: - ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.11 - - - Run the ovs-vsctl command on HOST2 to create the tunnel and link it to the - bridge on HOST1. - GRE tunnel command: - -ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.10 - - VXLAN tunnel command: - -ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.10 - - - - Successful completion of these steps results in the two instances sharing a layer - 2 network. -
-
-
- Linux Bridge - This section describes how the Linux Bridge plug-in implements the 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 network associated with the public network as - physnet1, and the physical network associated with the data - network as physnet2, which leads to the following configuration - options in linuxbridge_conf.ini: - [vlans] -tenant_network_type = vlan -network_vlan_ranges = physnet1,physnet2:100:110 - -[linux_bridge] -physical_interface_mappings = physnet2:eth1 - - In this configuration there isn't a bridge mapping for physnet1 as it is only needed on - the network host, which maps it to the Open vSwitch bridge br-ex connected to - the external network as seen below. - -
-
- Scenario 1: one tenant, two networks, one router - The first scenario has two private networks (net01, and - net02), each with one subnet - (net01_subnet01: 192.168.101.0/24, - net02_subnet01, 192.168.102.0/24). Both private networks are - attached to a router that connects them to the public network - (10.64.201.0/24). - - - - - - - Under the service tenant, create the shared router, define the - public network, and set it as the default gateway of the - router$ tenant=$(keystone tenant-list | awk '/service/ {print $2}') -$ neutron router-create router01 -$ neutron net-create --tenant-id $tenant public01 \ - --provider:network_type flat \ - --provider:physical_network physnet1 \ - --router:external True -$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \ - --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp -$ neutron router-gateway-set router01 public01 - Under the demo user tenant, create the private network - net01 and corresponding subnet, and connect it to the - router01 router. Configure it to use VLAN ID 101 on the - physical - switch.$ tenant=$(keystone tenant-list|awk '/demo/ {print $2}') -$ neutron net-create --tenant-id $tenant net01 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 101 -$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24 -$ neutron router-interface-add router01 net01_subnet01 - Similarly, for net02, using VLAN ID 102 on the physical - switch:$ neutron net-create --tenant-id $tenant net02 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 102 -$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24 -$ neutron router-interface-add router01 net02_subnet01 - -
- Scenario 1: Compute host config - The following figure shows how to configure the various Linux networking - devices on the compute host. - - - - - - - - Types of network devices - - There are three distinct type of virtual networking devices: TAP - devices, VLAN devices, and Linux bridges. For an Ethernet frame to - travel from eth0 of virtual machine - vm01, to the physical network, it must pass - through four devices inside of the host: TAP vnet0, - Linux bridge brqXXX, VLAN - eth1.101), and, finally, the physical network - interface card eth1. - - A TAP device, such as - vnet0 is how hypervisors such as KVM and Xen - implement a virtual network interface card (typically called a VIF or vNIC). - An Ethernet frame sent to a TAP device is received by the guest operating - system. - A VLAN device is associated with a VLAN - tag attaches to an existing interface device and adds or removes VLAN tags. - In the preceding example, VLAN device eth1.101 is - associated with VLAN ID 101 and is attached to interface - eth1. Packets received from the outside by - eth1 with VLAN tag 101 will be passed to device - eth1.101, which will then strip the tag. In the other - direction, any Ethernet frame sent directly to eth1.101 will have VLAN tag - 101 added and will be forward to eth1 for sending out to - the network. - A Linux bridge behaves like a hub: you - can connect multiple (physical or virtual) network interfaces devices to a - Linux bridge. Any Ethernet frames that come in from one interface attached - to the bridge is transmitted to all of the other devices. - -
-
- Scenario 1: Network host config - The following figure shows the network devices on the network host. - - - - - - 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. - - - - - - -
-
-
- Scenario 2: two tenants, two networks, two routers - The second scenario has two tenants (A, B). Each tenant has a network with one - subnet, and each one has a router that connects them to the public Internet. - - - - - - Under the service tenant, define the public - network:$ tenant=$(keystone tenant-list | awk '/service/ {print $2}') -$ neutron net-create --tenant-id $tenant public01 \ - --provider:network_type flat \ - --provider:physical_network physnet1 \ - --router:external True -$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \ - --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp - Under the tenantA user tenant, create the tenant router and set - its gateway for the public - network.$ tenant=$(keystone tenant-list|awk '/tenantA/ {print $2}') -$ neutron router-create --tenant-id $tenant router01 -$ neutron router-gateway-set router01 public01 - Then, define private network net01 using VLAN ID 102 on the - physical switch, along with its subnet, and connect it to the router. - $ neutron net-create --tenant-id $tenant net01 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 101 -$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24 -$ neutron router-interface-add router01 net01_subnet01 - Similarly, for tenantB, create a router and another network, - using VLAN ID 102 on the physical - switch:$ tenant=$(keystone tenant-list|awk '/tenantB/ {print $2}') -$ neutron router-create --tenant-id $tenant router02 -$ neutron router-gateway-set router02 public01 -$ neutron net-create --tenant-id $tenant net02 \ - --provider:network_type vlan \ - --provider:physical_network physnet2 \ - --provider:segmentation_id 102 -$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net01 192.168.101.0/24 -$ neutron router-interface-add router02 net02_subnet01 - -
- Scenario 2: Compute host config - The following figure shows how the various Linux networking devices would be - configured on the compute host under this scenario. - - - - - - - The configuration on the compute host is very similar to the configuration - in scenario 1. The only real difference is that scenario 1 had a guest - connected to two subnets, and in this scenario the subnets belong to - different tenants. - -
-
- Scenario 2: Network host config - The following figure shows the network devices on the network host for the - second scenario. - - - - - - The main difference between the configuration in this scenario and the - previous one is the organization of the network namespaces, in order to provide - isolation across the two subnets, as shown in the following figure. - - - - - - In this scenario, there are four network namespaces - (qdhcp-AAA, - qrouter-BBBB, - qrouter-CCCC, and - qdhcp-DDDD), instead of - three. Each router is implemented by a separate namespace, since there is no - connectivity between the two networks. -
-
-
-
- ML2 - The Modular Layer 2 plug-in allows OpenStack Networking to simultaneously utilize the - variety of layer 2 networking technologies found in complex real-world data centers. It - currently includes drivers for the local, flat, VLAN, GRE and VXLAN network types and - works with the existing Open vSwitch, Linux Bridge - , and HyperV L2 agents. The ML2 - plug-in can be extended through mechanism drivers, allowing multiple mechanisms to be - used simultaneously. This section describes different ML2 plug-in - and agent configurations with different type drivers and mechanism drivers. - - Currently, there is no need to define SEGMENTATION_ID - network provider attribute for GRE and VXLAN network types. The choice can be - delegated to Networking, in such case ML2 plug-in tries to find a network - in tenant network pools which respects specified provider network attributes. - - - Previously, Networking deployments were only able to use the plug-in that had been - selected at implementation time. For example, a deployment running the Open vSwitch - plug-in was only able to use Open vSwitch exclusively; it wasn't possible to - simultaneously run another plug-in such as Linux Bridge. This was found to be a - limitation in environments with heterogeneous requirements. - - Disabling a ML2 type driver and re-enabling it later may lead to database - inconsistencies if ML2 is reconfigured without support for that type. - -
- ML2 with L2 population mechanism driver - The L2 Population driver enables broadcast, multicast, and unicast traffic to - scale out on large overlay networks. This traffic is sent to the relevant agent via - encapsulation as a targeted unicast. - Current Open vSwitch and Linux Bridge - tunneling implementations broadcast to every agent, even if they don't host the - corresponding network as illustrated below. - - - - - - As broadcast emulation on overlay is costly, it may be better to avoid its use for - MAC learning and ARP resolution. This supposes the use of proxy ARP on the agent to - answer VM requests, and to populate forwarding table. Currently only the - Linux Bridge Agent implements an ARP proxy. The - pre-population limits L2 broadcasts in overlay, however it may anyway be necessary - to provide broadcast emulation. This is achieved by broadcasting packets via unicast - only to the relevant agents as illustrated below. - - - - The partial-mesh is available with the Open - vSwitch and Linux Bridge agents. The following - scenarios will use the L2 population mechanism driver with an Open - vSwitch agent and a Linux Bridge agent. Enable - the l2 population driver by adding it to the list of mechanism drivers. In addition, - a tunneling driver must be selected. Supported options are GRE, VXLAN, or a - combination of both. Configuration settings are enabled in - ml2_conf.ini: - [ml2] -type_drivers = local,flat,vlan,gre,vxlan -mechanism_drivers = openvswitch,linuxbridge,l2population -
-
- Scenario 1: L2 population with Open vSwitch agent - Enable the l2 population extension in the Open vSwitch agent, - and configure the and - parameters in the ml2_conf.ini file: - [ovs] -local_ip = 192.168.1.10 - -[agent] -tunnel_types = GRE,VXLAN -l2_population = True -
-
- Scenario 2: L2 population with <emphasis>Linux Bridge</emphasis> agent - Enable the l2 population extension on the Linux Bridge agent. - Enable VXLAN and configure the local_ip parameter in - ml2_conf.ini. - [vxlan] -enable_vxlan = True -local_ip = 192.168.1.10 -l2_population = True -
-
- Enable security group API - The ML2 plug-in can concurrently support different L2 agents (or other - mechanisms) with different configuration files, so each L2 agent - configuration file (such as - ovs_neutron_plugin.ini or - linuxbridge_conf.ini) should contain the appropriate - value for that - agent in addition to setting to - True (which is the default). - - The value in the API server's ml2_conf.ini file - does not matter. - - To disable the securitygroup API, edit the ml2_conf.ini file - on the API server, and ovs_neutron_plugin.ini, - linuxbridge_conf.ini or other L2 agent -configuration files on the agent servers : - [securitygroup] -enable_security_group = False -firewall_driver = neutron.agent.firewall.NoopFirewallDriver -
-
-
diff --git a/doc/admin-guide-cloud/networking/section_networking_adv_features.xml b/doc/admin-guide-cloud/networking/section_networking_adv_features.xml index d04bd3ac5a..e0c2a649fb 100644 --- a/doc/admin-guide-cloud/networking/section_networking_adv_features.xml +++ b/doc/admin-guide-cloud/networking/section_networking_adv_features.xml @@ -178,50 +178,6 @@ and set the provider extended attributes through Networking API calls. See for details on policy configuration.
-
- Provider extension API operations - To use the provider extension with the default policy settings, you must have the - administrative role. - This list shows example neutron commands that enable you to complete basic - provider extension API operations: - - - Shows all attributes of a network, including provider attributes: - $ neutron net-show NAME_OR_NET_ID - - - Creates a local provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type local - - - When you create flat networks, PHYS_NET_NAME - must be known to the plug-in. See the OpenStack Configuration - Reference for details. Creates a flat provider - network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type flat --provider:physical_network PHYS_NET_NAME - - - When you create VLAN networks, PHYS_NET_NAME - must be known to the plug-in. See the OpenStack Configuration - Reference for details on configuring network_vlan_ranges to - identify all physical networks. When you create VLAN networks, - VID can fall either within or outside any - configured ranges of VLAN IDs from which tenant networks are allocated. - Creates a VLAN provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type vlan --provider:physical_network PHYS_NET_NAME --provider:segmentation_id VID - - - When you create GRE networks, TUNNEL_ID can be - either inside or outside any tunnel ID ranges from which tenant networks are - allocated. - After you create provider networks, you can allocate subnets, which you - can use in the same way as other virtual networks, subject to authorization - policy based on the specified TENANT_ID. Creates - a GRE provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type gre --provider:segmentation_id TUNNEL_ID - - -
L3 routing and NAT @@ -241,136 +197,6 @@ (and often to all hosts on the Internet). You can allocate and map floating IPs from one port to another, as needed. -
- L3 API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Router
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the router.
nameStringNoneHuman-readable name for the router. Might not be unique.
admin_state_upBoolTrueThe administrative state of router. If false (down), the router does not - forward packets.
statusStringN/A - Indicates whether router is currently operational. -
tenant_iduuid-strN/AOwner of the router. Only admin users can specify a tenant_id other than - its own.
external_gateway_infodict contain 'network_id' key-value pairNullExternal network that this router connects to for gateway services (for - example, NAT)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Floating IP
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the floating IP.
floating_ip_addressstring (IP address)allocated by NetworkingThe external network IP address available to be mapped to an internal IP - address.
floating_network_iduuid-strN/A - The network indicating the set of subnets from which the floating - IP should be allocated -
router_iduuid-strN/ARead-only value indicating the router that connects the external network - to the associated internal port, if a port is associated.
port_iduuid-strNullIndicates the internal Networking port associated with the external - floating IP.
fixed_ip_addressstring (IP address)NullIndicates the IP address on the internal port that is mapped to by the - floating IP (since an Networking port might have more than one IP - address).
tenant_iduuid-strN/AOwner of the Floating IP. Only admin users can specify a tenant_id other - than its own.
-
-
Basic L3 operations External networks are visible to all users. However, the default policy settings @@ -599,130 +425,6 @@ -
- Security group API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security group attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group.
nameStringNoneHuman-readable name for the security group. Might not be unique. Cannot - be named default as that is automatically created for a tenant.
descriptionStringNoneHuman-readable description of a security group.
tenant_iduuid-strN/AOwner of the security group. Only admin users can specify a tenant_id - other than their own.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security group rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group rule.
security_group_iduuid-str or Integerallocated by NetworkingThe security group to associate rule with.
directionStringN/AThe direction the traffic is allow (ingress/egress) from a VM.
protocolStringNoneIP Protocol (icmp, tcp, udp, and so on).
port_range_minIntegerNonePort at start of range
port_range_maxIntegerNonePort at end of range
ethertypeStringNoneethertype in L2 packet (IPv4, IPv6, and so on)
remote_ip_prefixstring (IP cidr)NoneCIDR for address range
remote_group_iduuid-str or Integerallocated by Networking or ComputeSource security group to apply to rule.
tenant_iduuid-strN/AOwner of the security group rule. Only admin users can specify a - tenant_id other than its own.
-
Basic security group operations This table shows example neutron commands that enable you to complete basic @@ -850,292 +552,6 @@
-
- Firewall-as-a-Service - The Firewall-as-a-Service (FWaaS) API is an experimental API that enables early - adopters and vendors to test their networking implementations. -
- Firewall-as-a-Service API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewall rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall rule.
tenant_iduuid-strN/AOwner of the firewall rule. Only admin users can specify a tenant_id - other than its own.
nameStringNoneHuman readable name for the firewall rule (255 characters limit).
descriptionStringNoneHuman-readable description for the firewall rule (1024 characters - limit).
firewall_policy_iduuid-str or Noneallocated by NetworkingThis is a read-only attribute that gets populated with the uuid of the - firewall policy when this firewall rule is associated with a firewall - policy. A firewall rule can be associated with only one firewall policy - at a time. However, the association can be changed to a different - firewall policy.
sharedBooleanFalseWhen set to True makes this firewall rule visible to tenants other than - its owner and it can be used in firewall policies not owned by its - tenant.
protocolStringNoneIP protocol (icmp, tcp, udp, None).
ip_versionInteger or String4IP version (4, 6).
source_ip_addressString (IP address or CIDR)NoneSource IP address or CIDR.
destination_ip_addressString (IP address or CIDR)NoneDestination IP address or CIDR.
source_portInteger or String (either as a single port number or in the format of a - ':' separated range)NoneSource port number or a range.
destination_portInteger or String (either as a single port number or in the format of a - ':' separated range)NoneDestination port number or a range.
positionIntegerNoneThis is a read-only attribute that gets assigned to this rule when the - rule is associated with a firewall policy. It indicates the position of - this rule in that firewall policy.
actionStringdenyAction to be performed on the traffic matching the rule (allow, - deny).
enabledBooleanTrueWhen set to False, disables this rule in the firewall - policy. Facilitates selectively turning off rules without having to - disassociate the rule from the firewall policy.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewall policies
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall policy.
tenant_iduuid-strN/AOwner of the firewall policy. Only admin users can specify a tenant_id - other their own.
nameStringNoneHuman readable name for the firewall policy (255 characters limit).
descriptionStringNoneHuman readable description for the firewall policy (1024 characters - limit).
sharedBooleanFalseWhen set to True makes this firewall policy visible to tenants other - than its owner and can be used to associate with firewalls not owned by - its tenant.
firewall_rulesList of uuid-str or NoneNoneThis is an ordered list of firewall rule uuids. The firewall applies the - rules in the order in which they appear in this list.
auditedBooleanFalseWhen set to True by the policy owner indicates that the firewall policy - has been audited. This attribute is meant to aid in the firewall policy - audit work flows. Each time the firewall policy or the associated - firewall rules are changed, this attribute is set to False and must be - explicitly set to True through an update operation.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewalls
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall.
tenant_iduuid-strN/AOwner of the firewall. Only admin users can specify a tenant_id other - than its own.
nameStringNoneHuman readable name for the firewall (255 characters limit).
descriptionStringNoneHuman readable description for the firewall (1024 characters - limit).
admin_state_upBooleanTrueThe administrative state of the firewall. If False (down), the firewall - does not forward any packets.
statusStringN/A - Indicates whether the firewall is currently operational. Possible - values include: - - - ACTIVE - - - DOWN - - - PENDING_CREATE - - - PENDING_UPDATE - - - PENDING_DELETE - - - ERROR - - -
firewall_policy_iduuid-str or NoneNoneThe firewall policy uuid that this firewall is associated with. This - firewall implements the rules contained in the firewall policy - represented by this uuid.
-
-
-
Plug-in specific extensions @@ -1165,76 +581,6 @@ rxtx scaling factor. Note that after a network or default queue is specified, queues are added to ports that are subsequently created but are not added to existing ports. -
- VMware NSX QoS API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VMware NSX QoS attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the QoS queue.
defaultBooleanFalse by defaultIf True, ports are created with this queue size unless the - network port is created or associated with a queue at port - creation time.
nameStringNoneName for QoS queue.
minInteger0Minimum Bandwidth Rate (kbps).
maxIntegerN/AMaximum Bandwidth Rate (kbps).
qos_markingStringuntrusted by defaultWhether QoS marking should be trusted or untrusted.
dscpInteger0DSCP Marking value.
tenant_iduuid-strN/AThe owner of the QoS queue.
-
Basic VMware NSX QoS operations This table shows example neutron commands that enable you to complete @@ -1569,104 +915,6 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny measurement. Two abstractions have been added: One is the metering label that can contain metering rules. Because a metering label is associated with a tenant, all virtual routers in this tenant are associated with this label. -
- L3 metering API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Label
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering label.
nameStringNoneHuman-readable name for the metering label. Might not be unique.
descriptionStringNoneThe optional description for the metering label.
tenant_iduuid-strN/AOwner of the metering label.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering rule.
directionString (Either ingress or egress)ingressThe direction in which metering rule is applied, either ingress or - egress.
metering_label_iduuid-strN/A - The metering label ID to associate with this metering rule. -
excludedBooleanFalseSpecify whether the remote_ip_prefix will be excluded or not from - traffic counters of the metering label (for example, to not count the - traffic of a specific IP address of a range).
remote_ip_prefixString (CIDR)N/AIndicates remote IP prefix to be associated with this metering - rule.
-
-
Basic L3 metering operations Only administrators can manage the L3 metering labels and rules.