diff --git a/.gitignore b/.gitignore index 522294d46a..484cb64fad 100644 --- a/.gitignore +++ b/.gitignore @@ -21,3 +21,4 @@ boxes/* *~ .*.swp .bak +/.project 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 9f9f12a231..c5c6354660 100644 --- a/doc/admin-guide-cloud/networking/section_networking_adv_features.xml +++ b/doc/admin-guide-cloud/networking/section_networking_adv_features.xml @@ -1,12 +1,10 @@ -
Advanced features through API extensions - Several plug-ins implement API extensions that provide - capabilities similar to what was available in nova-network: - These plug-ins are likely to be of interest to the OpenStack + Several plug-ins implement API extensions that provide capabilities similar to what was + available in nova-network: These plug-ins are likely to be of interest to the OpenStack community.
Provider networks @@ -21,22 +19,17 @@ might also be used to integrate with VLANs in the network that already have a defined meaning (for example, enable a VM from the "marketing" department to be placed on the same VLAN as bare-metal marketing hosts in the same data center). - The provider extension allows administrators to - explicitly manage the relationship between Networking - virtual networks and underlying physical mechanisms such - as VLANs and tunnels. When this extension is supported, - Networking client users with administrative privileges see - 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 Open vSwitch - and Linux Bridge plug-ins. Configuration of these plug-ins - requires familiarity with this extension. + The provider extension allows administrators to explicitly manage the relationship + between Networking virtual networks and underlying physical mechanisms such as VLANs and + tunnels. When this extension is supported, Networking client users with administrative + privileges see 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 Open vSwitch and Linux Bridge plug-ins. + Configuration of these plug-ins requires familiarity with this extension.
Terminology - A number of terms are used in the provider extension - and in the configuration of plug-ins supporting the - provider extension: + A number of terms are used in the provider extension and in the configuration of + plug-ins supporting the provider extension: @@ -49,116 +42,81 @@ - - + + - - + - - + + - - + + - - + + - - + + - - + + - - + - - + +
Provider extension terminology
virtual - networkAn Networking L2 network (identified by a - UUID and optional name) whose ports can be - attached as vNICs to Compute instances and - to various Networking agents. The Open - vSwitch and Linux Bridge plug-ins each - support several different mechanisms to - realize virtual networks.virtual networkAn Networking L2 network (identified by a UUID and optional name) whose + ports can be attached as vNICs to Compute instances and to various + Networking agents. The Open vSwitch and Linux Bridge plug-ins each + support several different mechanisms to realize virtual networks.
physical - networkA network connecting virtualization hosts - (such as compute nodes) with each other - and with other network resources. Each - physical network might support multiple - virtual networks. The provider extension - and the plug-in configurations identify - physical networks using simple string + physical networkA network connecting virtualization hosts (such as compute nodes) with + each other and with other network resources. Each physical network might + support multiple virtual networks. The provider extension and the + plug-in configurations identify physical networks using simple string names.
tenant - networkA virtual network that a tenant or an - administrator creates. The physical - details of the network are not exposed to - the tenant.tenant networkA virtual network that a tenant or an administrator creates. The + physical details of the network are not exposed to the tenant.
provider - networkA virtual network administratively created - to map to a specific network in the data - center, typically to enable direct access - to non-OpenStack resources on that - network. Tenants can be given access to - provider networks.provider networkA virtual network administratively created to map to a specific network + in the data center, typically to enable direct access to non-OpenStack + resources on that network. Tenants can be given access to provider + networks.
VLAN - networkA virtual network implemented as packets - on a specific physical network containing - IEEE 802.1Q headers with a specific VID - field value. VLAN networks sharing the - same physical network are isolated from - each other at L2, and can even have - overlapping IP address spaces. Each - distinct physical network supporting VLAN - networks is treated as a separate VLAN - trunk, with a distinct space of VID - values. Valid VID values are 1 through - 4094.VLAN networkA virtual network implemented as packets on a specific physical network + containing IEEE 802.1Q headers with a specific VID field value. VLAN + networks sharing the same physical network are isolated from each other + at L2, and can even have overlapping IP address spaces. Each distinct + physical network supporting VLAN networks is treated as a separate VLAN + trunk, with a distinct space of VID values. Valid VID values are 1 + through 4094.
flat - networkA virtual network implemented as packets - on a specific physical network containing - no IEEE 802.1Q header. Each physical - network can realize at most one flat - network.flat networkA virtual network implemented as packets on a specific physical network + containing no IEEE 802.1Q header. Each physical network can realize at + most one flat network.
local - networkA virtual network that allows - communication within each host, but not - across a network. Local networks are - intended mainly for single-node test - scenarios, but can have other uses.local networkA virtual network that allows communication within each host, but not + across a network. Local networks are intended mainly for single-node + test scenarios, but can have other uses.
GRE - networkA virtual network implemented as network - packets encapsulated using GRE. GRE - networks are also referred to as tunnels. GRE - tunnel packets are routed by the IP - routing table for the host, so GRE - networks are not associated by Networking + GRE networkA virtual network implemented as network packets encapsulated using GRE. + GRE networks are also referred to as tunnels. GRE tunnel packets are routed by the IP routing + table for the host, so GRE networks are not associated by Networking with specific physical networks.
Virtual Extensible - LAN (VXLAN) networkVXLAN 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.Virtual Extensible LAN (VXLAN) + networkVXLAN 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.
- 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. + 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 - The provider extension extends the Networking - network resource with these attributes: + The provider extension extends the Networking network resource with these + attributes: @@ -178,77 +136,55 @@ - + - - + - +
Provider network attributes
provider:network_type String N/AThe physical mechanism by which the - virtual network is implemented. Possible - values are flat, - vlan, - local, and - gre, corresponding - to flat networks, VLAN networks, local - networks, and GRE networks as defined - above. All types of provider networks can - be created by administrators, while tenant - networks can be implemented as - vlan, - gre, or - local network types - depending on plug-in configuration.The physical mechanism by which the virtual network is implemented. + Possible values are flat, vlan, + local, and gre, corresponding + to flat networks, VLAN networks, local networks, and GRE networks as + defined above. All types of provider networks can be created by + administrators, while tenant networks can be implemented as + vlan, gre, or + local network types depending on plug-in + configuration.
provider:physical_network StringIf a physical network named "default" has - been configured, and if - provider:network_type is - flat or - vlan, then - "default" is used.The name of the physical network over - which the virtual network is implemented - for flat and VLAN networks. Not applicable - to the local or - gre network + If a physical network named "default" has been configured, and if + provider:network_type is flat or + vlan, then "default" is used.The name of the physical network over which the virtual network is + implemented for flat and VLAN networks. Not applicable to the + local or gre network types.
provider:segmentation_id Integer N/AFor VLAN networks, the VLAN VID on the - physical network that realizes the virtual - network. Valid VLAN VIDs are 1 through - 4094. For GRE networks, the tunnel ID. - Valid tunnel IDs are any 32 bit unsigned - integer. Not applicable to the - flat or - local network - types.For VLAN networks, the VLAN VID on the physical network that realizes + the virtual network. Valid VLAN VIDs are 1 through 4094. For GRE + networks, the tunnel ID. Valid tunnel IDs are any 32 bit unsigned + integer. Not applicable to the flat or + local network types.
- To view or set provider extended attributes, a - client must be authorized for the + To view or set provider extended attributes, a client must be authorized for the extension:provider_network:view and - extension:provider_network:set - actions in the Networking policy configuration. The - default Networking configuration authorizes both - actions for users with the admin role. An authorized - client or an administrative user can view and set the - provider extended attributes through Networking API - calls. See - for details on policy configuration. + extension:provider_network:set actions in the Networking policy + configuration. The default Networking configuration authorizes both actions for + users with the admin role. An authorized client or an administrative user can view + 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 table shows example neutron commands that - enable you to complete basic provider extension API - operations: + To use the provider extension with the default policy settings, you must have the + administrative role. + This table shows example neutron commands that enable you to complete basic + provider extension API operations: - + @@ -260,72 +196,59 @@ + Shows all attributes of a network, including provider + attributes. + + Creates a local provider network. + + Creates a flat provider network. When you create flat networks, + <phys-net-name> must be known to the plug-in. See the + OpenStack + Configuration Reference for details. + + Creates a VLAN provider network. 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 GRE provider network. 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>. + @@ -336,29 +259,22 @@
L3 routing and NAT - The Networking API provides abstract L2 network segments - that are decoupled from the technology used to implement - the L2 network. Networking includes an API extension that - provides abstract L3 routers that API users can - dynamically provision and configure. These Networking - routers can connect multiple L2 Networking networks, and - can also provide a gateway that connects one or more - private L2 networks to a shared external network. For - example, a public network for access to the Internet. See - the OpenStack - Configuration Reference for details on - common models of deploying Networking L3 routers. - The L3 router provides basic NAT capabilities on gateway - ports that uplink the router to external networks. This - router SNATs all traffic by default, and supports floating - IPs, which creates a static one-to-one mapping from a - public IP on the external network to a private IP on one - of the other subnets attached to the router. This allows a - tenant to selectively expose VMs on private networks to - other hosts on the external network (and often to all - hosts on the Internet). You can allocate and map floating - IPs from one port to another, as needed. + The Networking API provides abstract L2 network segments that are decoupled from the + technology used to implement the L2 network. Networking includes an API extension that + provides abstract L3 routers that API users can dynamically provision and configure. + These Networking routers can connect multiple L2 Networking networks, and can also + provide a gateway that connects one or more private L2 networks to a shared external + network. For example, a public network for access to the Internet. See the OpenStack Configuration Reference for details on common models of + deploying Networking L3 routers. + The L3 router provides basic NAT capabilities on gateway ports that uplink the router + to external networks. This router SNATs all traffic by default, and supports floating + IPs, which creates a static one-to-one mapping from a public IP on the external network + to a private IP on one of the other subnets attached to the router. This allows a tenant + to selectively expose VMs on private networks to other hosts on the external network + (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 @@ -387,40 +303,36 @@
- + - + - + - + - + - +
Basic provider extension API - operationsBasic 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
- Creates a flat provider network. - When you create flat networks, - <phys-net-name> must be known to - the plug-in. See the OpenStack Configuration - Reference for - details. $ neutron net-create <name> --tenant_id <tenant-id> --provider:network_type flat --provider:physical_network <phys-net-name>
- Creates a VLAN provider network. - 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. $ neutron net-create <name> --tenant_id <tenant-id> --provider:network_type vlan --provider:physical_network <phys-net-name> --provider:segmentation_id <VID>
- Creates a GRE provider network. 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>. $ neutron net-create <name> --tenant_id <tenant-id> --provider:network_type gre --provider:segmentation_id <tunnel-id> name String NoneHuman-readable name for the router. Might - not be unique.Human-readable name for the router. Might not be unique.
admin_state_up Bool TrueThe administrative state of router. If - false (down), the router does not forward - packets.The administrative state of router. If false (down), the router does not + forward packets.
status String N/AIndicates whether router is - currently operational. + Indicates whether router is currently operational. +
tenant_id uuid-str N/AOwner of the router. Only admin users can - specify a tenant_id other than its - own.Owner of the router. Only admin users can specify a tenant_id other than + its own.
external_gateway_infodict contain 'network_id' key-value - pairdict contain 'network_id' key-value pair NullExternal network that this router connects - to for gateway services (for example, - NAT)External network that this router connects to for gateway services (for + example, NAT)
@@ -449,51 +361,46 @@ floating_ip_address string (IP address) allocated by Networking - The external network IP address available - to be mapped to an internal IP + The external network IP address available to be mapped to an internal IP address. floating_network_id uuid-str N/A - The network indicating the set of - subnets from which the floating IP - should be allocated + + The network indicating the set of subnets from which the floating + IP should be allocated + router_id uuid-str N/A - Read-only value indicating the router that - connects the external network to the - associated internal port, if a port is - associated. + Read-only value indicating the router that connects the external network + to the associated internal port, if a port is associated. port_id uuid-str Null - Indicates the internal Networking port - associated with the external floating - IP. + Indicates the internal Networking port associated with the external + floating IP. fixed_ip_address string (IP address) Null - Indicates 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). + Indicates 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_id uuid-str N/A - Owner of the Floating IP. Only admin users - can specify a tenant_id other than its - own. + Owner of the Floating IP. Only admin users can specify a tenant_id other + than its own. @@ -501,12 +408,11 @@
Basic L3 operations - External networks are visible to all users. However, - the default policy settings enable only administrative - users to create, update, and delete external + External networks are visible to all users. However, the default policy settings + enable only administrative users to create, update, and delete external networks. - This table shows example neutron commands that - enable you to complete basic L3 operations: + This table shows example neutron commands that enable you to complete basic L3 + operations: @@ -520,8 +426,8 @@ + Creates external networks. + + Lists external networks. + - + + Connects a router to an external network, which enables that + router to act as a NAT gateway for external connectivity. + + Lists routers. + + Shows information for a specified router. + + Identifies the port-id that represents the VM + NIC to which the floating IP should map. + + Creates a floating IP address and associates it with a + port. + + Creates a floating IP address and associates it with a port, in a + single step. + + Lists floating IPs. + + Finds floating IP for a specified VM port. + + Disassociates a floating IP address. + + Deletes the floating IP address. + + Clears the gateway. + + Removes the interfaces from the router. + + Deletes the router. + @@ -692,56 +591,42 @@
Security groups - Security groups and security group rules allows - administrators and tenants the ability to specify the type - of traffic and direction (ingress/egress) that is allowed - to pass through a port. A security group is a container - for security group rules. - When a port is created in Networking it is associated - with a security group. If a security group is not - specified the port is associated with a 'default' security - group. By default, this group drops all ingress traffic - and allows all egress. Rules can be added to this group in - order to change the behaviour. - To use the Compute security group APIs or use Compute to - orchestrate the creation of ports for instances on - specific security groups, you must complete additional - configuration. You must configure the - /etc/nova/nova.conf file and set - the security_group_api=neutron option on - every node that runs nova-compute and nova-api. After you make - this change, restart nova-api and nova-compute to pick up this change. - Then, you can use both the Compute and OpenStack Network - security group APIs at the same time. + Security groups and security group rules allows administrators and tenants the ability + to specify the type of traffic and direction (ingress/egress) that is allowed to pass + through a port. A security group is a container for security group rules. + When a port is created in Networking it is associated with a security group. If a + security group is not specified the port is associated with a 'default' security group. + By default, this group drops all ingress traffic and allows all egress. Rules can be + added to this group in order to change the behaviour. + To use the Compute security group APIs or use Compute to orchestrate the creation of + ports for instances on specific security groups, you must complete additional + configuration. You must configure the /etc/nova/nova.conf file and + set the security_group_api=neutron option on every node that runs + nova-compute and nova-api. After you make this change, restart + nova-api and nova-compute to pick up this change. Then, you can use both the + Compute and OpenStack Network security group APIs at the same time. - 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, Open vSwitch, Linux Bridge, - NEC, Ryu, and VMware NSX. + 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, Open vSwitch, Linux Bridge, NEC, Ryu, and + VMware NSX. - You must configure the correct firewall - driver in the securitygroup - section of the plug-in/agent configuration - file. Some plug-ins and agents, such as Linux - Bridge Agent and Open vSwitch Agent, use the - no-operation driver as the default, which + You must configure the correct firewall driver in the + securitygroup section of the plug-in/agent + configuration file. Some plug-ins 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 - Compute, security groups are applied to all - ports on an instance. The reason for this is - that Compute security group APIs are instances - based and not port based as Networking. + When using the security group API through Compute, security groups are + applied to all ports on an instance. The reason for this is that Compute + security group APIs are instances based and not port based as + Networking. @@ -772,25 +657,21 @@
- + - + - +
Basic L3 operations
- Creates external - networks. # neutron net-create public --router:external=True $ neutron subnet-create public 172.16.1.0/24 @@ -529,15 +435,17 @@
- Lists external networks. $ neutron net-list -- --router:external=True
Creates an internal-only router that - connects to multiple L2 networks - privately. + Creates an internal-only router that connects to multiple L2 + networks privately. + $ neutron net-create net1 $ neutron subnet-create net1 10.0.0.0/24 @@ -550,74 +458,62 @@
- Connects a router to an external - network, which enables that router to - act as a NAT gateway for external - connectivity. $ neutron router-gateway-set router1 <ext-net-id> - The router obtains an interface with - the gateway_ip address of the subnet, - and this interface is attached to a - port on the L2 Networking network - associated with the subnet. The router - also gets a gateway interface to the - specified external network. This - provides SNAT connectivity to the - external network as well as support - for floating IPs allocated on that - external networks. Commonly an - external network maps to a network in - the provider + The router obtains an interface with the gateway_ip address of the + subnet, and this interface is attached to a port on the L2 + Networking network associated with the subnet. The router also gets + a gateway interface to the specified external network. This provides + SNAT connectivity to the external network as well as support for + floating IPs allocated on that external networks. Commonly an + external network maps to a network in the provider
- Lists routers. $ neutron router-list
- Shows information for a specified - router. $ neutron router-show <router_id>
- Shows all internal interfaces for a - router. + Shows all internal interfaces for a router.
- Identifies the - port-id that - represents the VM NIC to which the - floating IP should map. $ neutron port-list -c id -c fixed_ips -- --device_id=<instance_id> - This port must be on an Networking - subnet that is attached to a router - uplinked to the external network used - to create the floating IP. - Conceptually, this is because the - router must be able to perform the - Destination NAT (DNAT) rewriting of - packets from the Floating IP address - (chosen from a subnet on the external - network) to the internal Fixed IP - (chosen from a private subnet that is - behind the router). + This port must be on an Networking subnet that is attached to a + router uplinked to the external network used to create the floating + IP. Conceptually, this is because the router must be able to perform + the Destination NAT (DNAT) rewriting of packets from the Floating IP + address (chosen from a subnet on the external network) to the + internal Fixed IP (chosen from a private subnet that is behind the + router).
- Creates a floating IP address and - associates it with a port. $ neutron floatingip-create <ext-net-id> $ neutron floatingip-associate <floatingip-id> <internal VM port-id> @@ -625,62 +521,65 @@
- Creates a floating IP address and - associates it with a port, in a single - step. $ neutron floatingip-create --port_id <internal VM port-id> <ext-net-id>
- Lists floating IPs. $ neutron floatingip-list
- Finds floating IP for a specified VM - port. $ neutron floatingip-list -- --port_id=ZZZ
- Disassociates a floating IP - address. $ neutron floatingip-disassociate <floatingip-id>
- Deletes the floating IP - address. $ neutron floatingip-delete <floatingip-id>
- Clears the gateway. $ neutron router-gateway-clear router1
- Removes the interfaces from the - router. $ neutron router-interface-delete router1 <subnet-id>
- Deletes the router. $ neutron router-delete router1 name String NoneHuman-readable name for the security - group. Might not be unique. Cannot be - named default as that is automatically - created for a tenant.Human-readable name for the security group. Might not be unique. Cannot + be named default as that is automatically created for a tenant.
description String NoneHuman-readable description of a security - group.Human-readable description of a security group.
tenant_id uuid-str N/AOwner of the security group. Only admin - users can specify a tenant_id other than - their own.Owner of the security group. Only admin users can specify a tenant_id + other than their own.
@@ -819,22 +700,19 @@ security_group_id uuid-str or Integer allocated by Networking - The security group to associate rule - with. + The security group to associate rule with. direction String N/A - The direction the traffic is allow - (ingress/egress) from a VM. + The direction the traffic is allow (ingress/egress) from a VM. protocol String None - IP Protocol (icmp, tcp, udp, and so - on). + IP Protocol (icmp, tcp, udp, and so on). port_range_min @@ -852,8 +730,7 @@ ethertype String None - ethertype in L2 packet (IPv4, IPv6, and so - on) + ethertype in L2 packet (IPv4, IPv6, and so on) remote_ip_prefix @@ -865,25 +742,22 @@ remote_group_id uuid-str or Integer allocated by Networking or Compute - Source security group to apply to - rule. + Source security group to apply to rule. tenant_id uuid-str N/A - Owner of the security group rule. Only - admin users can specify a tenant_id other - than its own. + Owner 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 security group - operations: + This table shows example neutron commands that enable you to complete basic + security group operations: @@ -897,54 +771,66 @@ + Creates a security group for our web servers. + - - - - - + - - - - - - - - - - - + + + + + + + + + + + + + @@ -955,13 +841,12 @@
Basic Load-Balancer-as-a-Service operations - The Load-Balancer-as-a-Service (LBaaS) API - provisions and configures load balancers. The Havana - release offers a reference implementation that is - based on the HAProxy software load balancer. + The Load-Balancer-as-a-Service (LBaaS) API provisions and configures load + balancers. The Havana release offers a reference implementation that is based on the + HAProxy software load balancer. - This table shows example neutron commands that enable - you to complete basic LBaaS operations: + This table shows example neutron commands that enable you to complete basic LBaaS + operations:
Basic security group operations
- Creates a security group for our web - servers. - $ neutron security-group-create webservers --description "security group for webservers"
Lists security groups.$ neutron security-group-list + $ neutron security-group-create webservers --description "security group for webservers"
- Creates a security group rule to - allow port 80 ingress.$ neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 80 --port_range_max 80 <security_group_uuid> + Lists security groups. + + $ neutron security-group-list
- Lists security group - rules.$ neutron security-group-rule-list + Creates a security group rule to allow port 80 ingress.
Deletes a security group - rule.$ neutron security-group-rule-delete <security_group_rule_uuid> + + $ neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 80 --port_range_max 80 <security_group_uuid>
- Deletes a security - group.$ neutron security-group-delete <security_group_uuid> + Lists security group rules.
Creates a port and associates two - security groups.$ neutron port-create --security-group <security_group_id1> --security-group <security_group_id2> <network_id> + + $ neutron security-group-rule-list
- Removes security groups from a - port.$ neutron port-update --no-security-groups <port_id> + Deletes a security group rule. + + $ neutron security-group-rule-delete <security_group_rule_uuid> +
+ Deletes a security group. + + $ neutron security-group-delete <security_group_uuid> +
+ Creates a port and associates two security groups. + + $ neutron port-create --security-group <security_group_id1> --security-group <security_group_id2> <network_id> +
+ Removes security groups from a port. + + $ neutron port-update --no-security-groups <port_id>
@@ -975,53 +860,50 @@ + Creates a load balancer pool by using specific provider. + --provider is an optional argument. If not + used, the pool is created with default provider for LBaaS service. You + should configure the default provider in the + [service_providers] section of + neutron.conf file. If no default provider is + specified for LBaaS, the --provider option is + required for pool creation. + + $ neutron lb-pool-create --lb-method ROUND_ROBIN --name mypool --protocol HTTP --subnet-id <subnet-uuid> --provider <provider_name> + + Associates two web servers with pool. + - - - - - - - - + Creates a health monitor which checks to make sure our instances are + still running on the specified protocol-port. + + + + + + + + + @@ -1032,34 +914,8 @@
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. - The FWaaS is backed by a reference - implementation that works with the - Networking OVS plug-in and provides perimeter firewall - functionality. It leverages the footprint of the - Networking OVS L3 agent and an IPTables driver to apply - the firewall rules contained in a particular firewall - policy. This reference implementation supports one - firewall policy and consequently one logical firewall - instance for each tenant. This is not a constraint of the - resource model, but of the current reference - implementation. The firewall is present on a Networking - virtual router. If a tenant has multiple routers, the - firewall is present on all the routers. If a tenant does - not have any router, the firewall is in - PENDING_CREATE state until a router is - created and the first interface is added to the router. At - that point the firewall policy is immediately applied to - the router and the firewall changes to ACTIVE - state. - - Because this is the first iteration of this - implementation, it should probably not be run in - production environments without adequate - testing. - + 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
Basic LBaaS operations
- Creates a load balancer pool by using - specific provider. - --provider is an - optional argument. If not used, the pool - is created with default provider for LBaaS - service. You should configure the default - provider in the - [service_providers] - section of - neutron.conf - file. If no default provider is specified - for LBaaS, the - --provider - option is required for pool - creation. - $ neutron lb-pool-create --lb-method ROUND_ROBIN --name mypool --protocol HTTP --subnet-id <subnet-uuid> --provider <provider_name>
- Associates two web servers with - pool. $ neutron lb-member-create --address <webserver one IP> --protocol-port 80 mypool -$ neutron lb-member-create --address <webserver two IP> --protocol-port 80 mypool
- Creates a health monitor which checks to - make sure our instances are still running - on the specified - protocol-port.$ neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3 -
Associates a health monitor with - pool.$ neutron lb-healthmonitor-associate <healthmonitor-uuid> mypool +$ neutron lb-member-create --address <webserver two IP> --protocol-port 80 mypool
- Creates a virtual IP (VIP) address that, - when accessed through the load balancer, - directs the requests to one of the pool - members. + $ neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3 +
+ Associates a health monitor with pool. + + $ neutron lb-healthmonitor-associate <healthmonitor-uuid> mypool +
+ Creates a virtual IP (VIP) address that, when accessed through the + load balancer, directs the requests to one of the pool members. + $ neutron lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-uuid> mypool
@@ -1087,46 +943,39 @@ - + - + - - + - + @@ -1154,17 +1003,15 @@ - + - + @@ -1172,28 +1019,24 @@ - + - + - +
tenant_id uuid-str N/AOwner of the firewall rule. Only admin - users can specify a tenant_id other than - its own.Owner of the firewall rule. Only admin users can specify a tenant_id + other than its own.
name String NoneHuman readable name for the firewall rule - (255 characters limit).Human readable name for the firewall rule (255 characters limit).
description String NoneHuman readable description for the - firewall rule (1024 characters + Human readable description for the firewall rule (1024 characters limit).
firewall_policy_id uuid-str or None allocated 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.This 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.
shared Boolean FalseWhen 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.When 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.
protocol
source_portInteger or String (either as a single port - number or in the format of a ':' separated - range)Integer or String (either as a single port number or in the format of a + ':' separated range) None Source port number or a range.
destination_portInteger or String (either as a single port - number or in the format of a ':' separated - range)Integer or String (either as a single port number or in the format of a + ':' separated range) None Destination port number or a range.
position Integer NoneThis 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.This 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.
action String denyAction to be performed on the traffic - matching the rule (allow, deny).Action to be performed on the traffic matching the rule (allow, + deny).
enabled Boolean TrueWhen 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.When 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.
@@ -1222,56 +1065,46 @@ tenant_id uuid-str N/A - Owner of the firewall policy. Only admin - users can specify a tenant_id other their - own. + Owner of the firewall policy. Only admin users can specify a tenant_id + other their own. name String None - Human readable name for the firewall - policy (255 characters limit). + Human readable name for the firewall policy (255 characters limit). description String None - Human readable description for the - firewall policy (1024 characters + Human readable description for the firewall policy (1024 characters limit). shared Boolean False - When 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. + When 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_rules List of uuid-str or None None - This is an ordered list of firewall rule - uuids. The firewall applies the rules in - the order in which they appear in this - list. + This is an ordered list of firewall rule uuids. The firewall applies the + rules in the order in which they appear in this list. audited Boolean False - When 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 - workflows. 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. + When 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 workflows. 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. @@ -1300,57 +1133,54 @@ tenant_id uuid-str N/A - Owner of the firewall. Only admin users - can specify a tenant_id other than its - own. + Owner of the firewall. Only admin users can specify a tenant_id other + than its own. name String None - Human readable name for the firewall (255 - characters limit). + Human readable name for the firewall (255 characters limit). description String None - Human readable description for the - firewall (1024 characters limit). + Human readable description for the firewall (1024 characters + limit). admin_state_up Boolean True - The administrative state of the firewall. - If False (down), the firewall does not - forward any packets. + The administrative state of the firewall. If False (down), the firewall + does not forward any packets. status String N/A - Indicates whether the firewall is - currently operational. Possible values - include: + + Indicates whether the firewall is currently operational. Possible + values include: - ACTIVE + ACTIVE - DOWN + DOWN - PENDING_CREATE + PENDING_CREATE - PENDING_UPDATE + PENDING_UPDATE - PENDING_DELETE + PENDING_DELETE - ERROR + ERROR @@ -1359,158 +1189,45 @@ firewall_policy_id uuid-str or None None - The firewall policy uuid that this - firewall is associated with. This firewall - implements the rules contained in the - firewall policy represented by this uuid. - + The firewall policy uuid that this firewall is associated with. This + firewall implements the rules contained in the firewall policy + represented by this uuid.
-
- Basic Firewall-as-a-Service operations - - - Create a firewall rule: - $ neutron firewall-rule-create --protocol <tcp|udp|icmp|any> --destination-port <port-range> --action <allow|deny> - The CLI requires that a protocol value be - provided. If the rule is protocol agnostic, - the 'any' value can be used. - In addition to the protocol attribute, other - attributes can be specified in the firewall - rule. See the previous section for the - supported attributes. - - - Create a firewall policy: - $ neutron firewall-policy-create --firewall-rules "<firewall-rule ids or names separated by space>" myfirewallpolicy - The order of the rules specified above is - important. A firewall policy can be created - without any rules and rules can be added later - either via the update operation (if adding - multiple rules) or via the insert-rule - operation (if adding a single rule). Please - check the CLI help for more details on these - operations. - - The reference implementation always adds - a default deny all rule at the end of each - policy. This implies that if a firewall - policy is created without any rules and is - associated with a firewall, that firewall - blocks all traffic. - - - - Create a firewall: - $ neutron firewall-create <firewall-policy-uuid> - - - - The FWaaS features and the above workflow can - also be accessed from the Horizon user interface. - This support is disabled by default, but can be - enabled by configuring - #HORIZON_DIR/openstack_dashboard/local/local_settings.py - and setting: - 'enable_firewall' = True - -
-
- -
- Allowed-address-pairs - Allowed-address-pairs is an API extension that extends - the port attribute. This extension allows one to specify - arbitrary mac_address/ip_address(cidr) pairs that are - allowed to pass through a port regardless of subnet. The - main use case for this is to enable the ability to use - protocols such as VRRP which floats an ip address between - two instances to enable fast data plane failover. - - The allowed-address-pairs extension is currently - only supported by these plug-ins: ML2, Open vSwitch, - and VMware NSX. - -
- Basic allowed address pairs operations - - - Create a port with a specific - allowed-address-pairs: - $ neutron port-create net1 --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr> - - - Update a port adding - allowed-address-pairs: - $ neutron port-update <port-uuid> --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr> - - - - Setting an allowed-address-pair that matches the - mac_address and ip_address of a port is prevented. - This is because that would have no effect since - traffic matching the mac_address and ip_address is - already allowed to pass through the port. - - - If your plug-in implements the port-security - extension port-security-enabled must be set to - True on the port in order to have - allowed-address-pairs on a port. The reason for - this is because if port-security-enabled is set to - False this allows all traffic to be passed through - the port thus having allowed-address-pairs would - have no effect. - -
Plug-in specific extensions - Each vendor can choose to implement additional API - extensions to the core API. This section describes the - extensions for each plug-in. + Each vendor can choose to implement additional API extensions to the core API. This + section describes the extensions for each plug-in.
VMware NSX extensions - These sections explain NSX plug-in - extensions. + These sections explain NSX plug-in extensions.
VMware NSX QoS extension - The VMware NSX QoS extension rate-limits network - ports to guarantee a specific amount of bandwidth - for each port. This extension, by default, is only - accessible by a tenant with an admin role but is - configurable through the - policy.json file. To use - this extension, create a queue and specify the - min/max bandwidth rates (kbps) and optionally set - the QoS Marking and DSCP value (if your network - fabric uses these values to make forwarding - decisions). Once created, you can associate a - queue with a network. Then, when ports are created - on that network they are automatically created and - associated with the specific queue size that was - associated with the network. Because one size - queue for a every port on a network might not be - optimal, a scaling factor from the Nova flavor - 'rxtx_factor' is passed in from Compute when + The VMware NSX QoS extension rate-limits network ports to guarantee a specific + amount of bandwidth for each port. This extension, by default, is only + accessible by a tenant with an admin role but is configurable through the + policy.json file. To use this extension, create a queue + and specify the min/max bandwidth rates (kbps) and optionally set the QoS + Marking and DSCP value (if your network fabric uses these values to make + forwarding decisions). Once created, you can associate a queue with a network. + Then, when ports are created on that network they are automatically created and + associated with the specific queue size that was associated with the network. + Because one size queue for a every port on a network might not be optimal, a + scaling factor from the Nova flavor 'rxtx_factor' is passed in from Compute when creating the port to scale the queue. - Lastly, if you want to set a specific baseline - QoS policy for the amount of bandwidth a single - port can use (unless a network queue is specified - with the network a port is created on) a default - queue can be created in Networking which then - causes ports created to be associated with a queue - of that size times the 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. -
+ Lastly, if you want to set a specific baseline QoS policy for the amount of + bandwidth a single port can use (unless a network queue is specified with the + network a port is created on) a default queue can be created in Networking which + then causes ports created to be associated with a queue of that size times the + 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 @@ -1537,10 +1254,9 @@ - + @@ -1552,22 +1268,19 @@ - + - + - + @@ -1586,12 +1299,10 @@
Basic VMware NSX QoS operations - This table shows example neutron commands - that enable you to complete basic queue - operations: + This table shows example neutron commands that enable you to complete + basic queue operations:
VMware NSX QoS attributes
default Boolean False 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.If True, ports are created with this queue size unless the + network port is created or associated with a queue at port + creation time.
namemin Integer 0Minimum Bandwidth Rate (kbps). - Minimum Bandwidth Rate (kbps).
max Integer N/AMaximum Bandwidth Rate (kbps). - Maximum Bandwidth Rate (kbps).
qos_marking String untrusted by defaultWhether QoS marking should be - trusted or untrusted.Whether QoS marking should be trusted or untrusted.
dscp
- + @@ -1603,39 +1314,42 @@ + Creates QoS Queue (admin-only). + + Associates a queue with a network. + - - - - - + Lists QoS queues. + + + + + @@ -1644,27 +1358,19 @@
VMware NSX provider networks extension - Provider networks can be implemented in - different ways by the underlying NSX + Provider networks can be implemented in different ways by the underlying NSX platform. - The FLAT and - VLAN network types use - bridged transport connectors. These network types - enable the attachment of large number of ports. To - handle the increased scale, the NSX plug-in can - back a single OpenStack Network with a chain of - NSX logical switches. You can specify the maximum - number of ports on each logical switch in this - chain on the - max_lp_per_bridged_ls - parameter, which has a default value of - 5,000. - The recommended value for this parameter varies - with the NSX version running in the back-end, as - shown in the following table. + The FLAT and VLAN network types use + bridged transport connectors. These network types enable the attachment of large + number of ports. To handle the increased scale, the NSX plug-in can back a + single OpenStack Network with a chain of NSX logical switches. You can specify + the maximum number of ports on each logical switch in this chain on the + max_lp_per_bridged_ls parameter, which has a default + value of 5,000. + The recommended value for this parameter varies with the NSX version running + in the back-end, as shown in the following table.
Basic VMware NSX QoS - operationsBasic VMware NSX QoS operations
- Creates QoS Queue - (admin-only). - $ neutron queue-create--min 10 --max 1000 myqueue + $ neutron queue-create--min 10 --max 1000 myqueue
- Associates a queue with a - network. - $ neutron net-create network --queue_id=<queue_id> + $ neutron net-create network --queue_id=<queue_id>
- Creates a default system - queue.$ neutron queue-create --default True --min 10 --max 2000 default + Creates a default system queue.
Lists QoS - queues.$ neutron queue-list + + $ neutron queue-create --default True --min 10 --max 2000 default
- Deletes a QoS - queue. - $ neutron queue-delete <queue_id or name>' + $ neutron queue-list +
+ Deletes a QoS queue. + + $ neutron queue-delete <queue_id or name>'
- + @@ -1692,74 +1398,52 @@
Recommended values for - max_lp_per_bridged_lsRecommended values for max_lp_per_bridged_ls
- In addition to these network types, the NSX - plug-in also supports a special - l3_ext network type, - which maps external networks to specific NSX - gateway services as discussed in the next - section. + In addition to these network types, the NSX plug-in also supports a special + l3_ext network type, which maps external networks to + specific NSX gateway services as discussed in the next section.
VMware NSX L3 extension - NSX exposes its L3 capabilities through gateway - services which are usually configured out of band - from OpenStack. To use NSX with L3 capabilities, - first create a L3 gateway service in the NSX - Manager. Next, in - /etc/neutron/plugins/vmware/nsx.ini - set default_l3_gw_service_uuid - to this value. By default, routers are mapped to - this gateway service. + NSX exposes its L3 capabilities through gateway services which are usually + configured out of band from OpenStack. To use NSX with L3 capabilities, first + create a L3 gateway service in the NSX Manager. Next, in + /etc/neutron/plugins/vmware/nsx.ini set + default_l3_gw_service_uuid to this value. By default, + routers are mapped to this gateway service.
VMware NSX L3 extension operations - Create external network and map it to a - specific NSX gateway service: + Create external network and map it to a specific NSX gateway + service: $ neutron net-create public --router:external=True --provider:network_type l3_ext \ --provider:physical_network <L3-Gateway-Service-UUID> - Terminate traffic on a specific VLAN from a - NSX gateway service: + Terminate traffic on a specific VLAN from a NSX gateway service: $ neutron net-create public --router:external=True --provider:network_type l3_ext \ --provider:physical_network <L3-Gateway-Service-UUID> --provider:segmentation_id <VLAN_ID>
- Operational status synchronization in the - VMware NSX plug-in - Starting with the Havana release, the VMware NSX - plug-in provides an asynchronous mechanism for - retrieving the operational status for neutron - resources from the NSX back-end; this applies to - network, - port, and - router resources. - The back-end is polled periodically, and the - status for every resource is retrieved; then the - status in the Networking database is updated only - for the resources for which a status change - occurred. As operational status is now retrieved - asynchronously, performance for - GET operations is + Operational status synchronization in the VMware NSX plug-in + Starting with the Havana release, the VMware NSX plug-in provides an + asynchronous mechanism for retrieving the operational status for neutron + resources from the NSX back-end; this applies to network, + port, and router resources. + The back-end is polled periodically, and the status for every resource is + retrieved; then the status in the Networking database is updated only for the + resources for which a status change occurred. As operational status is now + retrieved asynchronously, performance for GET operations is consistently improved. - Data to retrieve from the back-end are divided - in chunks in order to avoid expensive API - requests; this is achieved leveraging NSX APIs - response paging capabilities. The minimum chunk - size can be specified using a configuration - option; the actual chunk size is then determined - dynamically according to: total number of - resources to retrieve, interval between two - synchronization task runs, minimum delay between - two subsequent requests to the NSX - back-end. - The operational status synchronization can be - tuned or disabled using the configuration options - reported in this table; it is however worth noting - that the default values work fine in most - cases. + Data to retrieve from the back-end are divided in chunks in order to avoid + expensive API requests; this is achieved leveraging NSX APIs response paging + capabilities. The minimum chunk size can be specified using a configuration + option; the actual chunk size is then determined dynamically according to: total + number of resources to retrieve, interval between two synchronization task runs, + minimum delay between two subsequent requests to the NSX back-end. + The operational status synchronization can be tuned or disabled using the + configuration options reported in this table; it is however worth noting that + the default values work fine in most cases. - + @@ -1780,118 +1464,88 @@ - - - + + - + state_sync_interval. + - + - +
Configuration options for tuning - operational status synchronization in the NSX - plug-inConfiguration options for tuning operational status synchronization in + the NSX plug-in
nsx_sync 120 seconds Integer; no constraint.Interval in seconds between two run of - the synchronization task. If the - synchronization task takes more than - state_sync_interval - seconds to execute, a new instance of - the task is started as soon as the - other is completed. Setting the value - for this option to 0 will disable the + Interval in seconds between two run of the synchronization task. If + the synchronization task takes more than + state_sync_interval seconds to execute, a new + instance of the task is started as soon as the other is completed. + Setting the value for this option to 0 will disable the synchronization task.
max_random_sync_delay nsx_sync 0 secondsInteger. Must not exceed - min_sync_req_delayWhen different from zero, a random - delay between 0 and - max_random_sync_delay - will be added before processing the - next chunk.Integer. Must not exceed min_sync_req_delayWhen different from zero, a random delay between 0 and + max_random_sync_delay will be added before + processing the next chunk.
min_sync_req_delay nsx_sync 10 seconds Integer. Must not exceed - state_sync_interval.The value of this option can be tuned - according to the observed load on the - NSX controllers. Lower values will - result in faster synchronization, but - might increase the load on the - controller cluster.The value of this option can be tuned according to the observed load + on the NSX controllers. Lower values will result in faster + synchronization, but might increase the load on the controller + cluster.
min_chunk_size nsx_sync 500 resources Integer; no constraint.Minimum number of resources to - retrieve from the back-end for each - synchronization chunk. The expected - number of synchronization chunks is - given by the ratio between - state_sync_interval - and - min_sync_req_delay. - This size of a chunk might increase if - the total number of resources is such - that more than - min_chunk_size - resources must be fetched in one chunk - with the current number of - chunks.Minimum number of resources to retrieve from the back-end for each + synchronization chunk. The expected number of synchronization chunks + is given by the ratio between state_sync_interval + and min_sync_req_delay. This size of a chunk + might increase if the total number of resources is such that more + than min_chunk_size resources must be fetched in + one chunk with the current number of chunks.
always_read_status nsx_sync False Boolean; no constraint.When this option is enabled, the - operational status will always be - retrieved from the NSX back-end ad - every GET request. - In this case it is advisable to - disable the synchronization task.When this option is enabled, the operational status will always be + retrieved from the NSX back-end ad every GET + request. In this case it is advisable to disable the synchronization + task.
- When running multiple OpenStack Networking - server instances, the status synchronization task - should not run on every node; doing so sends - unnecessary traffic to the NSX back-end and - performs unnecessary DB operations. Set the - - configuration option to a non-zero value - exclusively on a node designated for back-end - status synchronization. - The fields=status - parameter in Networking API requests always - triggers an explicit query to the NSX back end, - even when you enable asynchronous state - synchronization. For example, GET + When running multiple OpenStack Networking server instances, the status + synchronization task should not run on every node; doing so sends unnecessary + traffic to the NSX back-end and performs unnecessary DB operations. Set the + configuration option to a non-zero + value exclusively on a node designated for back-end status + synchronization. + The fields=status parameter in Networking API requests + always triggers an explicit query to the NSX back end, even when you enable + asynchronous state synchronization. For example, GET /v2.0/networks/<net-id>?fields=status&fields=name.
Big Switch plug-in extensions - This section explains the Big Switch Neutron - plug-in-specific extension. + This section explains the Big Switch Neutron plug-in-specific extension.
Big Switch router rules - Big Switch allows router rules to be added to - each tenant router. These rules can be used to - enforce routing policies such as denying traffic - between subnets or traffic to external networks. - By enforcing these at the router level, network - segmentation policies can be enforced across many - VMs that have differing security groups. + Big Switch allows router rules to be added to each tenant router. These rules + can be used to enforce routing policies such as denying traffic between subnets + or traffic to external networks. By enforcing these at the router level, network + segmentation policies can be enforced across many VMs that have differing + security groups.
Router rule attributes - Each tenant router has a set of router rules - associated with it. Each router rule has the - attributes in this table. Router rules and - their attributes can be set using the - neutron router-update - command, through the Horizon interface or the - Neutron API. + Each tenant router has a set of router rules associated with it. Each + router rule has the attributes in this table. Router rules and their + attributes can be set using the neutron router-update + command, through the Horizon interface or the Neutron API. - + @@ -1908,76 +1562,59 @@ - - + + - - + + - + - - + +
Big Switch Router rule - attributesBig Switch Router rule attributes
source YesA valid CIDR or one of the - keywords 'any' or 'external'The network that a packet's source - IP must match for the rule to be - appliedA valid CIDR or one of the keywords 'any' or 'external'The network that a packet's source IP must match for the rule to + be applied
destination YesA valid CIDR or one of the - keywords 'any' or 'external'The network that a packet's - destination IP must match for the - rule to be appliedA valid CIDR or one of the keywords 'any' or 'external'The network that a packet's destination IP must match for the + rule to be applied
action Yes 'permit' or 'deny'Determines whether or not the - matched packets will allowed to - cross the routerDetermines whether or not the matched packets will allowed to + cross the router
nexthop NoA plus-separated (+) list of - next-hop IP addresses. For example, - 1.1.1.1+1.1.1.2.Overrides the default virtual - router used to handle traffic for - packets that match the ruleA plus-separated (+) list of next-hop IP addresses. For example, + 1.1.1.1+1.1.1.2.Overrides the default virtual router used to handle traffic for + packets that match the rule
-
+
Order of rule processing - The order of router rules has no effect. - Overlapping rules are evaluated using longest - prefix matching on the source and destination - fields. The source field is matched first so - it always takes higher precedence over the - destination field. In other words, longest - prefix matching is used on the destination - field only if there are multiple matching - rules with the same source. + The order of router rules has no effect. Overlapping rules are evaluated + using longest prefix matching on the source and destination fields. The + source field is matched first so it always takes higher precedence over the + destination field. In other words, longest prefix matching is used on the + destination field only if there are multiple matching rules with the same + source.
-
+
Big Switch router rules operations - Router rules are configured with a router - update operation in OpenStack Networking. The - update overrides any previous rules so all - rules must be provided at the same - time. - Update a router with rules to permit traffic - by default but block traffic from external - networks to the 10.10.10.0/24 subnet: + Router rules are configured with a router update operation in OpenStack + Networking. The update overrides any previous rules so all rules must be + provided at the same time. + Update a router with rules to permit traffic by default but block traffic + from external networks to the 10.10.10.0/24 subnet: $ neutron router-update Router-UUID --router_rules type=dict list=true\ source=any,destination=any,action=permit \ source=external,destination=10.10.10.0/24,action=deny - Specify alternate next-hop addresses for a - specific subnet: + Specify alternate next-hop addresses for a specific subnet: $ neutron router-update Router-UUID --router_rules type=dict list=true\ source=any,destination=any,action=permit \ source=10.10.10.0/24,destination=any,action=permit,nexthops=10.10.10.254+10.10.10.253 - Block traffic between two subnets while - allowing everything else: + Block traffic between two subnets while allowing everything else: $ neutron router-update Router-UUID --router_rules type=dict list=true\ source=any,destination=any,action=permit \ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny @@ -1987,16 +1624,13 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
L3 metering - The L3 metering API extension enables administrators to - configure IP ranges and assign a specified label to them - to be able to measure traffic that goes through a virtual + The L3 metering API extension enables administrators to configure IP ranges and assign + a specified label to them to be able to measure traffic that goes through a virtual router. - The L3 metering extension is decoupled from the - technology that implements the 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. + The L3 metering extension is decoupled from the technology that implements the + 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 @@ -2024,15 +1658,13 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny - + - + @@ -2067,34 +1699,31 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny - + - + - +
name String NoneHuman-readable name for the metering - label. Might not be unique.Human-readable name for the metering label. Might not be unique.
description String NoneThe optional description for the metering - label.The optional description for the metering label.
tenant_id direction String (Either ingress or egress) ingressThe direction in which metering rule is - applied, either ingress or egress.The direction in which metering rule is applied, either ingress or + egress.
metering_label_id uuid-str N/A - The metering label ID to associate - with this metering rule. + The metering label ID to associate with this metering rule.
excluded Boolean FalseSpecify 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).Specify 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_prefix String (CIDR) N/AIndicates remote IP prefix to be - associated with this metering rule.Indicates remote IP prefix to be associated with this metering + rule.
@@ -2102,11 +1731,9 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
Basic L3 metering operations - Only administrators can manage the L3 metering - labels and rules. - This table shows example neutron - commands that enable you to complete basic L3 metering - operations: + Only administrators can manage the L3 metering labels and rules. + This table shows example neutron commands that enable you to + complete basic L3 metering operations: @@ -2136,8 +1763,7 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
Basic L3 operations
- Shows information for a specified - label. + Shows information for a specified label. $ neutron meter-label-show label-uuid @@ -2165,8 +1791,7 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
- Lists metering all label - rules. + Lists metering all label rules. $ neutron meter-label-rule-list @@ -2174,8 +1799,7 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny
- Shows information for a specified - label rule. + Shows information for a specified label rule. $ neutron meter-label-rule-show rule-uuid diff --git a/doc/admin-guide-cloud/networking/section_networking_introduction.xml b/doc/admin-guide-cloud/networking/section_networking_introduction.xml index b2575433e8..09781dfe53 100644 --- a/doc/admin-guide-cloud/networking/section_networking_introduction.xml +++ b/doc/admin-guide-cloud/networking/section_networking_introduction.xml @@ -232,6 +232,113 @@
+
+ Firewall-as-a-Service (FWaaS) overview + The Firewall-as-a-Service (FWaaS) plug-in + adds perimeter firewall management to Networking. FWaaS uses iptables to + apply firewall policy to all Networking routers within a project. FWaaS + supports one firewall policy and logical firewall instance per + project. + Whereas security groups operate at the instance-level, FWaaS + operates at the perimeter by filtering traffic at the neutron + router. + + FWaaS is currently in technical preview; untested operation + is not recommended. + + The example diagram below illustrates the flow of ingress and + egress traffic for the VM2 instance: +
+ FWaaS architecture + + + + + +
+ + Enable FWaaS + Enable the FWaaS plugin in the neutron.conf file: + + service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin +[fwaas] +driver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver +enabled = True + FWaaS management options are available in OpenStack dashboard. Enable the option in the + file typically located on the controller node: + /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py + + 'enable_firewall' = True + + Configure Firewall-as-a-Service + First create the firewall rules and create a policy that contains them, then + create a firewall that applies the policy: + + Create a firewall rule: + $ neutron firewall-rule-create --protocol <tcp|udp|icmp|any> --destination-port <port-range> --action <allow|deny> + The CLI requires a protocol value; if the rule is + protocol agnostic, the 'any' value can be used. + + + Create a firewall policy: + $ neutron firewall-policy-create --firewall-rules "<firewall-rule IDs or names separated by space>" myfirewallpolicy + The order of the rules specified above is important.You + can create a firewall policy without and rules and add rules + later either with the update operation (when adding multiple + rules) or with the insert-rule operations (when adding a single + rule). Please check the CLI Reference + for more details on these operations. + + FWaaS always adds a default + rule at the lowest precedence of each policy. Consequently, + a firewall policy with no rules blocks all traffic by + default. + + + + Create a firewall: + $ neutron firewall-create <firewall-policy-uuid> + The firewall remains in + PENDING_CREATE state until a Networking + router is created, and an interface is attached. + + + + Allowed-address-pairs + + + allow you to specify + mac_address/ip_address(cidr) pairs that pass through a port + regardless of subnet. This enables the use of protocols such as + VRRP, which floats an IP address between two instances to enable + fast data plane failover. + + The allowed-address-pairs extension is currently only + supported by these plug-ins: ML2, Open vSwitch, and VMware + NSX. + + + Basic allowed-address-pairs operations + + + + Create a port with a specific allowed-address-pairs: + $ neutron port-create net1 --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr> + + + Update a port adding allowed-address-pairs: + $ neutron port-update <port-uuid> --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr> + + + + OpenStack Networking prevents setting an allowed-address-pair + that matches the mac_address and ip_address of a port. This is + because that would have no effect since traffic matching the + mac_address and ip_address is already allowed to pass through the + port. + +
Plug-in architecture The original Compute network implementation assumed a @@ -1465,34 +1572,5 @@ interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
-
- Configure FWaaS agent - The Firewall-as-a-Service (FWaaS) agent is - co-located with the Neutron L3 agent and does not - require any additional packages apart from those - required for the Neutron L3 agent. You can enable the - FWaaS functionality by setting the configuration, as - follows. - - To configure FWaaS service and agent - - Set this parameter in the - neutron.conf file on - the host that runs neutron-server: - service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin - - - To use the reference implementation, you - must also update the FWaaS driver configuration in - the fwaas_driver.ini file on - every node where the Neutron L3 agent is - deployed: - [fwaas] -driver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver -enabled = True - - -
diff --git a/doc/common/figures/fwaas.png b/doc/common/figures/fwaas.png new file mode 100644 index 0000000000..a0b6d5456f Binary files /dev/null and b/doc/common/figures/fwaas.png differ diff --git a/doc/common/figures/fwaas.svg b/doc/common/figures/fwaas.svg new file mode 100644 index 0000000000..8789f94ca1 --- /dev/null +++ b/doc/common/figures/fwaas.svg @@ -0,0 +1,33668 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + Physical Router + + + PhysicalSwitch + + + + + + + + FWaaS + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + VM2 + Tenant Network 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Neutron Router + Networking Node 1 + Compute Node 2 + Open vSwitch 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Security Group + + + + + + + Tenant Network 1 + + + + + + + + + + + + Compute Node 1 + Open vSwitch 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + VM1 + + + + + + + + + + + + + + + Security Group + + + + + + + + + + + + + + + + + + +