From 81e4cdc9d9f3647f779d6a726f04c2888d57463d Mon Sep 17 00:00:00 2001 From: kallimachos Date: Fri, 22 Aug 2014 15:16:44 +1000 Subject: [PATCH] Updates to advanced networking chapter Change-Id: I1b5b7cfd422f68f25cb963dd89cc4fec592ac24e --- doc/networking-guide/ch_advanced.xml | 1774 +---------------- .../section_networking_adv_agent.xml | 450 +++++ .../section_networking_adv_features.xml | 1758 ++++++++++++++++ ...on_networking_adv_operational_features.xml | 162 ++ 4 files changed, 2375 insertions(+), 1769 deletions(-) create mode 100644 doc/networking-guide/section_networking_adv_agent.xml create mode 100644 doc/networking-guide/section_networking_adv_features.xml create mode 100644 doc/networking-guide/section_networking_adv_operational_features.xml diff --git a/doc/networking-guide/ch_advanced.xml b/doc/networking-guide/ch_advanced.xml index 62c46d8da0..5d6647e70e 100644 --- a/doc/networking-guide/ch_advanced.xml +++ b/doc/networking-guide/ch_advanced.xml @@ -6,1775 +6,11 @@ xml:id="ch_advanced"> Advanced configuration options - Bacon ipsum dolor sit amet biltong meatloaf andouille, turducken - bresaola pork belly beef ribs ham hock capicola tail prosciutto - landjaeger meatball pork loin. Swine turkey jowl, porchetta doner - boudin meatloaf. Shoulder capicola prosciutto, shank landjaeger short - ribs sirloin turducken pork belly boudin frankfurter chuck. Salami - shankle bresaola cow filet mignon ham hock shank. + This section describes advanced configuration options for various system components. For example, configuration options where the default works but that the user wants to customize options. After installing from packages, $NEUTRON_CONF_DIR is /etc/neutron. - - provider networks: - - - - - - -
- Provider networks - Networks can be categorized as either tenant networks or provider networks. Tenant - networks are created by normal users. Details about how these networks are - physically realized remain hidden from those users. Provider networks are created - with administrative credentials, specifying the details of how the network is - physically realized. Provider networks usually match an existing network in the - data center. - Provider networks enable cloud administrators to create virtual networks that map - directly to the physical networks in the data center. This is commonly used to give - tenants direct access to a public network, which can be used to reach the Internet. It - 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 virtual networks and underlying physical mechanisms such as VLANs and - tunnels. When this extension is supported, 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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Provider extension terminology
TermDescription
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 - names.
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.
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.
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 - 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.
- 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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Provider network attributes
Attribute nameTypeDefault ValueDescription
provider:network_typeStringN/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.
provider:physical_networkStringIf 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_idIntegerN/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.
- 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. -
-
- Provider extension API operations - To use the provider extension with the default policy settings, you must have the - administrative role. - This list shows example neutron commands that enable you to complete basic - provider extension API operations: - - - Shows all attributes of a network, including provider attributes: - $ neutron net-show NAME_OR_NET_ID - - - Creates a local provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type local - - - When you create flat networks, PHYS_NET_NAME - must be known to the plug-in. See the OpenStack Configuration - Reference for details. Creates a flat provider - network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type flat --provider:physical_network PHYS_NET_NAME - - - When you create VLAN networks, PHYS_NET_NAME - must be known to the plug-in. See the OpenStack Configuration - Reference for details on configuring network_vlan_ranges to - identify all physical networks. When you create VLAN networks, - VID can fall either within or outside any - configured ranges of VLAN IDs from which tenant networks are allocated. - Creates a VLAN provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type vlan --provider:physical_network PHYS_NET_NAME --provider:segmentation_id VID - - - When you create GRE networks, TUNNEL_ID can be - either inside or outside any tunnel ID ranges from which tenant networks are - allocated. - After you create provider networks, you can allocate subnets, which you - can use in the same way as other virtual networks, subject to authorization - policy based on the specified TENANT_ID. Creates - a GRE provider network: - $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type gre --provider:segmentation_id TUNNEL_ID - - -
-
-
- L3 routing and NAT - 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Router
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the router.
nameStringNoneHuman-readable name for the router. Might not be unique.
admin_state_upBoolTrueThe administrative state of router. If false (down), the router does not - forward packets.
statusStringN/A - Indicates whether router is currently operational. -
tenant_iduuid-strN/AOwner of the router. Only admin users can specify a tenant_id other than - its own.
external_gateway_infodict contain 'network_id' key-value pairNullExternal network that this router connects to for gateway services (for - example, NAT)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Floating IP
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the floating IP.
floating_ip_addressstring (IP address)allocated by NetworkingThe external network IP address available to be mapped to an internal IP - address.
floating_network_iduuid-strN/A - The network indicating the set of subnets from which the floating - IP should be allocated -
router_iduuid-strN/ARead-only value indicating the router that connects the external network - to the associated internal port, if a port is associated.
port_iduuid-strNullIndicates the internal Networking port associated with the external - floating IP.
fixed_ip_addressstring (IP address)NullIndicates the IP address on the internal port that the - floating IP maps to (since Networking ports might have more than one IP - address).
tenant_iduuid-strN/AOwner of the Floating IP. Only admin users can specify a tenant_id other - than its own.
-
- -
- Basic L3 operations - External networks are visible to all users. However, the default policy settings - 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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic L3 operations
OperationCommand
- Creates external networks. - - # neutron net-create public --router:external=True -$ neutron subnet-create public 172.16.1.0/24 -
- Lists external networks. - - $ neutron net-list -- --router:external=True -
- 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 -$ neutron net-create net2 -$ neutron subnet-create net2 10.0.1.0/24 -$ neutron router-create router1 -$ neutron router-interface-add router1 SUBNET1_UUID -$ neutron router-interface-add router1 SUBNET2_UUID -
- 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 -
- Lists routers. - - $ neutron router-list -
- Shows information for a specified router. - - $ neutron router-show ROUTER_ID -
- Shows all internal interfaces for a router. - - $ neutron router-port-list ROUTER_ID -$ neutron router-port-list ROUTER_NAME -
- 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). -
- Creates a floating IP address and associates it with a - port. - - $ neutron floatingip-create EXT_NET_ID -$ neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID -
- 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 FLOATING_IP_ID -
- Deletes the floating IP address. - - $ neutron floatingip-delete FLOATING_IP_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 -
-
-
- -
- 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. - - - - 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 - 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 - unlike Networking, which is port based. - - - -
- Security group API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security group attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group.
nameStringNoneHuman-readable name for the security group. Might not be unique. Cannot - be named default as that is automatically created for a tenant.
descriptionStringNoneHuman-readable description of a security group.
tenant_iduuid-strN/AOwner of the security group. Only admin users can specify a tenant_id - other than their own.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security group rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group rule.
security_group_iduuid-str or Integerallocated by NetworkingThe security group to associate rule with.
directionStringN/AThe direction the traffic is allow (ingress/egress) from a VM.
protocolStringNoneIP Protocol (icmp, tcp, udp, and so on).
port_range_minIntegerNonePort at start of range
port_range_maxIntegerNonePort at end of range
ethertypeStringNoneethertype in L2 packet (IPv4, IPv6, and so on)
remote_ip_prefixstring (IP cidr)NoneCIDR for address range
remote_group_iduuid-str or Integerallocated by Networking or ComputeSource security group to apply to rule.
tenant_iduuid-strN/AOwner of the security group rule. Only admin users can specify a - tenant_id other than its own.
-
-
- Basic security group operations - This table shows example neutron commands that enable you to complete basic - security group operations: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic security group operations
OperationCommand
- 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 -
- 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 group rules. - - $ neutron security-group-rule-list -
- 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 -
-
-
- -
- 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. - - This list shows example neutron commands that enable you to complete 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 WEBSERVER1_IP --protocol-port 80 mypool -$ neutron lb-member-create --address WEBSERVER2_IP --protocol-port 80 mypool - - - Creates a health monitor that 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 - - - 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 - - -
- -
- Firewall-as-a-Service - The Firewall-as-a-Service (FWaaS) API is an experimental API that enables early - adopters and vendors to test their networking implementations. -
- Firewall-as-a-Service API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewall rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall rule.
tenant_iduuid-strN/AOwner of the firewall rule. Only admin users can specify a tenant_id - other than its own.
nameStringNoneHuman readable name for the firewall rule (255 characters limit).
descriptionStringNoneHuman-readable description for the firewall rule (1024 characters - limit).
firewall_policy_iduuid-str or Noneallocated by NetworkingThis is a read-only attribute that gets populated with the UUID of the - firewall policy when this firewall rule is associated with a firewall - policy. A firewall rule can be associated with only one firewall policy - at a time. However, the association can be changed to a different - firewall policy.
sharedBooleanFalseWhen set to True makes this firewall rule visible to tenants other than - its owner and it can be used in firewall policies not owned by its - tenant.
protocolStringNoneIP protocol (icmp, tcp, udp, None).
ip_versionInteger or String4IP version (4, 6).
source_ip_addressString (IP address or CIDR)NoneSource IP address or CIDR.
destination_ip_addressString (IP address or CIDR)NoneDestination IP address or CIDR.
source_portInteger or String (either as a single port number or in the format of a - ':' separated range)NoneSource port number or a range.
destination_portInteger or String (either as a single port number or in the format of a - ':' separated range)NoneDestination port number or a range.
positionIntegerNoneThis is a read-only attribute that gets assigned to this rule when the - rule is associated with a firewall policy. It indicates the position of - this rule in that firewall policy.
actionStringdenyAction to be performed on the traffic matching the rule (allow, - deny).
enabledBooleanTrueWhen set to False, disables this rule in the firewall - policy. Facilitates selectively turning off rules without having to - disassociate the rule from the firewall policy.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewall policies
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall policy.
tenant_iduuid-strN/AOwner of the firewall policy. Only admin users can specify a tenant_id - other their own.
nameStringNoneHuman readable name for the firewall policy (255 characters limit).
descriptionStringNoneHuman readable description for the firewall policy (1024 characters - limit).
sharedBooleanFalseWhen set to True, the command makes this firewall policy visible to - tenants other than its owner and can be used to associate with firewalls not owned by - its tenant.
firewall_rulesList of uuid-str or NoneNoneThis is an ordered list of firewall rule UUIDs. The firewall applies the - rules in the order in which they appear in this list.
auditedBooleanFalseWhen set to True by the policy owner, the command indicates that - the firewall policy has been audited. This attribute is meant - to aid in the firewall policy audit work flows. Each time the - firewall policy or the associated firewall rules are changed, - this attribute is set to False and must be explicitly set - to True through an update operation.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Firewalls
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall.
tenant_iduuid-strN/AOwner of the firewall. Only admin users can specify a tenant_id other - than its own.
nameStringNoneHuman readable name for the firewall (255 characters limit).
descriptionStringNoneHuman readable description for the firewall (1024 characters - limit).
admin_state_upBooleanTrueThe administrative state of the firewall. If False (down), the firewall - does not forward any packets.
statusStringN/A - Indicates whether the firewall is currently operational. Possible - values include: - - - ACTIVE - - - DOWN - - - PENDING_CREATE - - - PENDING_UPDATE - - - PENDING_DELETE - - - ERROR - - -
firewall_policy_iduuid-str or NoneNoneThe firewall policy UUID that this firewall is associated with. This - firewall implements the rules contained in the firewall policy - represented by this UUID.
-
-
- -
- Plug-in specific extensions - - 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. -
- 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 - 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. -
- VMware NSX QoS API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VMware NSX QoS attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the QoS queue.
defaultBooleanFalse by defaultIf True, ports are created with this queue size unless the - network port is created or associated with a queue at port - creation time.
nameStringNoneName for QoS queue.
minInteger0Minimum Bandwidth Rate (kbps).
maxIntegerN/AMaximum Bandwidth Rate (kbps).
qos_markingStringuntrusted by defaultWhether QoS marking should be trusted or untrusted.
dscpInteger0DSCP Marking value.
tenant_iduuid-strN/AThe owner of the QoS queue.
-
-
- Basic VMware NSX QoS operations - This table shows example neutron commands that enable you to complete - basic queue operations: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic VMware NSX QoS operations
OperationCommand
- Creates QoS queue (admin-only). - - $ neutron queue-create --min 10 --max 1000 myqueue -
- Associates a queue with a network. - - $ neutron net-create network --queue_id=QUEUE_ID -
- Creates a default system queue. - - $ neutron queue-create --default True --min 10 --max 2000 default -
- Lists QoS queues. - - $ neutron queue-list -
- Deletes a QoS queue. - - $ neutron queue-delete QUEUE_ID_OR_NAME' -
-
-
-
- VMware NSX provider networks extension - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Recommended values for max_lp_per_bridged_ls
NSX versionRecommended Value
2.x64
3.0.x5,000
3.1.x5,000
3.2.x10,000
- 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 an 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: - $ 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: - $ 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 - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Configuration options for tuning operational status synchronization in - the NSX plug-in
Option nameGroupDefault valueType and constraintsNotes
state_sync_intervalnsx_sync120 secondsInteger; 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 - synchronization task.
max_random_sync_delaynsx_sync0 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.
min_sync_req_delaynsx_sync10 secondsInteger. 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.
min_chunk_sizensx_sync500 resourcesInteger; 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.
always_read_statusnsx_syncFalseBoolean; 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 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. -
- 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. -
- 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 Networking API. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Big Switch Router rule attributes
Attribute nameRequiredInput TypeDescription
sourceYesA 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
destinationYesA 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
actionYes'permit' or 'deny'Determines whether or not the matched packets will allowed to - cross the router
nexthopNoA 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. -
-
- 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: - $ 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: - $ 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: - $ 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 -
-
-
-
-
- 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 - 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. -
- L3 metering API abstractions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Label
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering label.
nameStringNoneHuman-readable name for the metering label. Might not be unique.
descriptionStringNoneThe optional description for the metering label.
tenant_iduuid-strN/AOwner of the metering label.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering rule.
directionString (Either ingress or egress)ingressThe direction in which metering rule is applied, either ingress or - egress.
metering_label_iduuid-strN/A - The metering label ID to associate with this metering rule. -
excludedBooleanFalseSpecify whether the remote_ip_prefix will be excluded or not from - traffic counters of the metering label (for example, to not count the - traffic of a specific IP address of a range).
remote_ip_prefixString (CIDR)N/AIndicates remote IP prefix to be associated with this metering - rule.
-
- -
- Basic L3 metering operations - Only administrators can manage the L3 metering labels and rules. - This table shows example neutron commands that enable you to - complete basic L3 metering operations: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic L3 operations
OperationCommand
- Creates a metering label. - - $ neutron meter-label-create LABEL1 --description "DESCRIPTION_LABEL1" -
- Lists metering labels. - - $ neutron meter-label-list -
- Shows information for a specified label. - - $ neutron meter-label-show LABEL_UUID -$ neutron meter-label-show LABEL1 -
- Deletes a metering label. - - $ neutron meter-label-delete LABEL_UUID -$ neutron meter-label-delete LABEL1 -
- Creates a metering rule. - - $ neutron meter-label-rule-create LABEL_UUID CIDR --direction DIRECTION --excluded - For example: - $ neutron meter-label-rule-create label1 10.0.0.0/24 --direction ingress -$ neutron meter-label-rule-create label1 20.0.0.0/24 --excluded -
- Lists metering all label rules. - - $ neutron meter-label-rule-list -
- Shows information for a specified label rule. - - $ neutron meter-label-rule-show RULE_UUID -
Deletes a metering label rule. - $ neutron meter-label-rule-delete RULE_UUID -
-
-
- - + + +
Firewall-as-a-Service FIXME @@ -1787,4 +23,4 @@ source=10.10.10.0/24,destination=10.20.20.20/24,action=deny Service chaining FIXME
- + \ No newline at end of file diff --git a/doc/networking-guide/section_networking_adv_agent.xml b/doc/networking-guide/section_networking_adv_agent.xml new file mode 100644 index 0000000000..3968bb5758 --- /dev/null +++ b/doc/networking-guide/section_networking_adv_agent.xml @@ -0,0 +1,450 @@ + +
+ Advanced agent options + This section describes advanced configuration options for server plug-ins and agents. +
+ OpenStack Networking server with plug-in + This web server runs the OpenStack Networking API Web Server. It loads + a plug-in and passes the API calls to the plug-in for processing. The + neutron-server service receives one or more configuration files + as input. For example: + neutron-server --config-file NEUTRON_CONFIG_FILE --config-file PLUGIN_CONFIG_FILE + The neutron configuration file contains the common neutron configuration options. + The plug-in configuration file contains the plug-in specific options. + The plug-in that runs on the service is loaded through the + core_plugin configuration option. In some cases, a plug-in + might have an agent that performs the actual networking. + Most plug-ins require an SQL database. After you install and start the database + server, set a password for the root account and delete the anonymous accounts: + $ > mysql -u root +mysql> update mysql.user set password = password('iamroot') where user = 'root'; +mysql> delete from mysql.user where user = ''; + Create a database and user account specifically for plug-in: + mysql> create database DATABASE_NAME +mysql> create user 'USER_NAME'@'localhost' identified by 'USER_NAME'; +mysql> create user 'USER_NAME'@'%' identified by 'USER_NAME'; +mysql> grant all on DATABASE_NAME.* to 'USER_NAME'@'%'; + After this step completes, you can update the settings in the relevant plug-in + configuration files. Find the plug-in specific configuration files at + $NEUTRON_CONF_DIR/plugins. + Some plug-ins have an L2 agent that performs the actual networking. That is, the agent + attaches the virtual machine NIC to the OpenStack Networking network. Each node should + run an L2 agent. Note that the agent receives the following input parameters: + neutron-plugin-agent --config-file NEUTRON_CONFIG_FILE --config-file PLUGIN_CONFIG_FILE + You must complete these tasks before you can work with the plug-in: + + + Ensure that the core plug-in is updated. + + + Ensure that the database connection is correctly set. + + + The following table shows sample values for the configuration options. Some Linux + packages might provide installation utilities that configure these values. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Settings
OptionValue
Open vSwitch +
core_plugin ($NEUTRON_CONF_DIR/neutron.conf)openvswitch
connection (in the plugin configuration file, section + [database])mysql://USERNAME:PASSWORD@localhost/ovs_neutron?charset=utf8
Plug-in Configuration File$NEUTRON_CONF_DIR/plugins/openvswitch/ovs_neutron_plugin.ini
Agentneutron-openvswitch-agent
Linux Bridge +
core_plugin ($NEUTRON_CONF_DIR/neutron.conf)linuxbridge
connection (in the plug-in configuration file, section + [database])mysql://USERNAME:PASSWORD@localhost/neutron_linux_bridge?charset=utf8
Plug-in Configuration File$NEUTRON_CONF_DIR/plugins/linuxbridge/linuxbridge_conf.ini
Agentneutron-linuxbridge-agent
+
+
+ DHCP agent + You can run a DHCP server that allocates IP addresses to virtual machines that run on + the network. When a subnet is created, by default, the subnet has DHCP enabled. + The node that runs the DHCP agent should run: + neutron-dhcp-agent --config-file NEUTRON_CONFIG_FILE --config-file DHCP_CONFIG_FILE + Currently the DHCP agent uses dnsmasq to perform that static + address assignment. + You must configure a driver that matches the plug-in that runs on the service. + + + + + + + + + + + + + + + + + + + + + + + + +
Settings
OptionValue
Open vSwitch +
interface_driver ($NEUTRON_CONF_DIR/dhcp_agent.ini)neutron.agent.linux.interface.OVSInterfaceDriver
Linux Bridge +
interface_driver ($NEUTRON_CONF_DIR/dhcp_agent.ini)neutron.agent.linux.interface.BridgeInterfaceDriver
+
+ Namespace + By default, the DHCP agent uses Linux network namespaces to support overlapping IP + addresses. For information about network namespaces support, see the Limitations section. + If the Linux installation does not support network namespaces, you must disable + network namespaces in the DHCP agent configuration file. The default value of + is True. + use_namespaces = False +
+
+
+ L3 agent + You can run an L3 agent that enables layer 3 forwarding and floating IP support. + The node that runs the L3 agent should run: + neutron-l3-agent --config-file NEUTRON_CONFIG_FILE --config-file L3_CONFIG_FILE + You must configure a driver that matches the plug-in that runs on the service. This + driver creates the routing interface. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Settings
OptionValue
Open vSwitch +
interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)br-ex
Linux Bridge +
interface_driver ($NEUTRON_CONF_DIR/l3_agent.ini)neutron.agent.linux.interface.BridgeInterfaceDriver
external_network_bridge ($NEUTRON_CONF_DIR/l3_agent.ini)This field must be empty (or the bridge name for the external network).
+ The L3 agent communicates with the OpenStack Networking server through the OpenStack + Networking API, so the following configuration is required: + + + OpenStack Identity authentication: + auth_url="$KEYSTONE_SERVICE_PROTOCOL://$KEYSTONE_AUTH_HOST:$KEYSTONE_AUTH_PORT/v2.0" + For example: + http://10.56.51.210:5000/v2.0 + + + Administrative user details: + admin_tenant_name $SERVICE_TENANT_NAME +admin_user $Q_ADMIN_USERNAME +admin_password $SERVICE_PASSWORD + + +
+ Namespace + By default, the L3 agent uses Linux network namespaces to support overlapping IP + addresses. + For information about network namespaces support, see the Limitation section. + If the Linux installation does not support network namespaces, you must disable + network namespaces in the L3 agent configuration file. The default value of + is True. + use_namespaces = False + When you set to False, only one + router ID is supported per node. + Use the configuration option to configure the + router: + # If use_namespaces is set to False then the agent can only configure one router. +# This is done by setting the specific router_id. +router_id = 1064ad16-36b7-4c2f-86f0-daa2bcbd6b2a + To configure it, you must run the OpenStack Networking service, create a router, + and set the router ID value to the value in the L3 agent + configuration file. + $ neutron router-create myrouter1 +Created a new router: ++-----------------------+--------------------------------------+ +| Field | Value | ++-----------------------+--------------------------------------+ +| admin_state_up | True | +| external_gateway_info | | +| id | 338d42d7-b22e-42c5-9df6-f3674768fe75 | +| name | myrouter1 | +| status | ACTIVE | +| tenant_id | 0c236f65baa04e6f9b4236b996555d56 | ++-----------------------+--------------------------------------+ +
+
+ Multiple external networks + Use one of these methods to support multiple external networks: + + + Assign multiple subnets to an external network. + + + Use multiple floating IP pools. + + + The following sections describe these options. +
+ Assign multiple subnets to an external network + This approach leverages the addition of on-link routes, which enables a router + to host floating IPs from any subnet on an external network regardless of which + subnet the primary router IP address comes from. This method does not require + the creation of multiple external networks. + To add a subnet to the external network, use the following command + template: + $ neutron subnet-create EXT_NETWORK_NAME CIDR + For example: + $ neutron subnet-create my-ext_network 10.0.0.0/29 +
+
+ Multiple floating IP pools + The L3 API in OpenStack Networking supports multiple floating IP pools. In + OpenStack Networking, a floating IP pool is represented as an external network + and a floating IP is allocated from a subnet associated with the external + network. Because you can associate each L3 agent with, at most, one external + network, you must invoke multiple L3 agents to define multiple floating IP + pools. Use the option in the L3 + agent configuration file to define the external network that the L3 agent + handles. You can run multiple L3 agent instances on one host. + In addition, when you run multiple L3 agents, set the + option to + True for only one L3 agent in an OpenStack Networking + deployment and set this option to False for all other L3 + agents. Because the default value of this parameter is True, + you must configure it carefully. + Before starting L3 agents, you must create routers and external networks, + update the configuration files with UUID of external networks, and start L3 + agents. + For the first agent, invoke it with the following + l3_agent.ini, where the + option is set to + True. + handle_internal_only_routers = True +gateway_external_network_id = 2118b11c-011e-4fa5-a6f1-2ca34d372c35 +external_network_bridge = br-ex + $ python /opt/stack/neutron/bin/neutron-l3-agent + --config-file /etc/neutron/neutron.conf + --config-file=/etc/neutron/l3_agent.ini + For the second (or later) agent, invoke it with the following + l3_agent.ini where the + option is set to + False. + handle_internal_only_routers = False +gateway_external_network_id = e828e54c-850a-4e74-80a8-8b79c6a285d8 +external_network_bridge = br-ex-2 +
+
+
+
+ L3 metering agent + You can run an L3 metering agent that enables layer 3 traffic metering. In general, + you should launch the metering agent on all nodes that run the L3 agent: + neutron-metering-agent --config-file NEUTRON_CONFIG_FILE --config-file L3_METERING_CONFIG_FILE + You must configure a driver that matches the plug-in that runs on the service. The + driver adds metering to the routing interface. + + + + + + + + + + + + + + + + + + + + + + + + +
Settings
OptionValue
Open vSwitch +
interface_driver ($NEUTRON_CONF_DIR/metering_agent.ini)neutron.agent.linux.interface.OVSInterfaceDriver
Linux Bridge +
interface_driver ($NEUTRON_CONF_DIR/metering_agent.ini)neutron.agent.linux.interface.BridgeInterfaceDriver
+
+ Namespace + The metering agent and the L3 agent must have the same network namespaces + configuration. + + If the Linux installation does not support network namespaces, you must + disable network namespaces in the L3 metering configuration file. The default + value of the option is True. + + use_namespaces = False +
+
+ L3 metering driver + You must configure any driver that implements the metering abstraction. Currently + the only available implementation uses iptables for metering. + driver = neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeteringDriver +
+
+ L3 metering service driver + To enable L3 metering, you must set the following option in the + neutron.conf file on the host that runs neutron-server: + service_plugins = metering +
+
+
+ Limitations + + + No equivalent for nova-network + option. Nova-network has a model where the L3, NAT, and DHCP + processing happen on the compute node itself, rather than a dedicated networking + node. OpenStack Networking now support running multiple l3-agent and dhcp-agents + with load being split across those agents, but the tight coupling of that + scheduling with the location of the VM is not supported in Icehouse. The Juno + release is expected to include an exact replacement for the + option in nova-network. + + + Linux network namespace required on nodes running neutron-l3-agent + or neutron-dhcp-agent if overlapping IPs are in + use. To support overlapping IP addresses, the OpenStack + Networking DHCP and L3 agents use Linux network namespaces by default. The hosts + running these processes must support network namespaces. To support network + namespaces, the following are required: + + + Linux kernel 2.6.24 or later (with CONFIG_NET_NS=y + in kernel configuration) + + + iproute2 utilities ('ip' command) version 3.1.0 (aka 20111117) or + later + + + To check whether your host supports namespaces, run these commands as + root: + # ip netns add test-ns +# ip netns exec test-ns ifconfig + If these commands succeed, your platform is likely sufficient to use the + dhcp-agent or l3-agent with namespaces. In our experience, Ubuntu 12.04 or later + support namespaces as does Fedora 17 and later, but some earlier RHEL platforms + do not by default. It might be possible to upgrade the iproute2 package on a platform that does not + support namespaces by default. + If you must disable namespaces, make sure that the + neutron.conf file that is used by neutron-server has the following + setting: + allow_overlapping_ips=False + Also, ensure that the dhcp_agent.ini and + l3_agent.ini files have the following setting: + use_namespaces=False + + If the host does not support namespaces, the neutron-l3-agent and neutron-dhcp-agent should run on different hosts because + there is no isolation between the IP addresses created by the L3 agent and + by the DHCP agent. By manipulating the routing, the user can ensure that + these networks have access to one another. + + If you run both L3 and DHCP services on the same node, you should enable + namespaces to avoid conflicts with routes: + use_namespaces=True + + + No IPv6 support for L3 agent. The neutron-l3-agent, used by + many plug-ins to implement L3 forwarding, supports only IPv4 forwarding. + Currently, there are no errors provided if you configure IPv6 addresses via the + API. + + + ZeroMQ support is experimental. Some agents, including + neutron-dhcp-agent, neutron-openvswitch-agent, and neutron-linuxbridge-agent use RPC to + communicate. ZeroMQ is an available option in the configuration file, but has + not been tested and should be considered experimental. In particular, issues + might occur with ZeroMQ and the dhcp agent. + + + MetaPlugin is experimental. This release includes a + MetaPlugin that is intended to support multiple plug-ins at the same time for + different API requests, based on the content of those API requests. The core + team has not thoroughly reviewed or tested this functionality. Consider this + functionality to be experimental until further validation is performed. + + +
+
\ No newline at end of file diff --git a/doc/networking-guide/section_networking_adv_features.xml b/doc/networking-guide/section_networking_adv_features.xml new file mode 100644 index 0000000000..7254cec141 --- /dev/null +++ b/doc/networking-guide/section_networking_adv_features.xml @@ -0,0 +1,1758 @@ + +
+ 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 + community. +
+ Provider networks + Networks can be categorized as either tenant networks or provider networks. Tenant + networks are created by normal users. Details about how these networks are + physically realized remain hidden from those users. Provider networks are created + with administrative credentials, specifying the details of how the network is + physically realized. Provider networks usually match an existing network in the + data center. + Provider networks enable cloud administrators to create virtual networks that map + directly to the physical networks in the data center. This is commonly used to give + tenants direct access to a public network, which can be used to reach the Internet. It + 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 virtual networks and underlying physical mechanisms such as VLANs and + tunnels. When this extension is supported, 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Provider extension terminology
TermDescription
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 + names.
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.
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.
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 + 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.
+ 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Provider network attributes
Attribute nameTypeDefault ValueDescription
provider:network_typeStringN/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.
provider:physical_networkStringIf 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_idIntegerN/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.
+ 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. +
+
+ Provider extension API operations + To use the provider extension with the default policy settings, you must have the + administrative role. + This list shows example neutron commands that enable you to complete basic + provider extension API operations: + + + Shows all attributes of a network, including provider attributes: + $ neutron net-show NAME_OR_NET_ID + + + Creates a local provider network: + $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type local + + + When you create flat networks, PHYS_NET_NAME + must be known to the plug-in. See the OpenStack Configuration + Reference for details. Creates a flat provider + network: + $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type flat --provider:physical_network PHYS_NET_NAME + + + When you create VLAN networks, PHYS_NET_NAME + must be known to the plug-in. See the OpenStack Configuration + Reference for details on configuring network_vlan_ranges to + identify all physical networks. When you create VLAN networks, + VID can fall either within or outside any + configured ranges of VLAN IDs from which tenant networks are allocated. + Creates a VLAN provider network: + $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type vlan --provider:physical_network PHYS_NET_NAME --provider:segmentation_id VID + + + When you create GRE networks, TUNNEL_ID can be + either inside or outside any tunnel ID ranges from which tenant networks are + allocated. + After you create provider networks, you can allocate subnets, which you + can use in the same way as other virtual networks, subject to authorization + policy based on the specified TENANT_ID. Creates + a GRE provider network: + $ neutron net-create NAME --tenant_id TENANT_ID --provider:network_type gre --provider:segmentation_id TUNNEL_ID + + +
+
+
+ L3 routing and NAT + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Router
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the router.
nameStringNoneHuman-readable name for the router. Might not be unique.
admin_state_upBoolTrueThe administrative state of router. If false (down), the router does not + forward packets.
statusStringN/A + Indicates whether router is currently operational. +
tenant_iduuid-strN/AOwner of the router. Only admin users can specify a tenant_id other than + its own.
external_gateway_infodict contain 'network_id' key-value pairNullExternal network that this router connects to for gateway services (for + example, NAT)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Floating IP
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the floating IP.
floating_ip_addressstring (IP address)allocated by NetworkingThe external network IP address available to be mapped to an internal IP + address.
floating_network_iduuid-strN/A + The network indicating the set of subnets from which the floating + IP should be allocated +
router_iduuid-strN/ARead-only value indicating the router that connects the external network + to the associated internal port, if a port is associated.
port_iduuid-strNullIndicates the internal Networking port associated with the external + floating IP.
fixed_ip_addressstring (IP address)NullIndicates the IP address on the internal port that the + floating IP maps to (since Networking ports might have more than one IP + address).
tenant_iduuid-strN/AOwner of the Floating IP. Only admin users can specify a tenant_id other + than its own.
+
+ +
+ Basic L3 operations + External networks are visible to all users. However, the default policy settings + 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic L3 operations
OperationCommand
+ Creates external networks. + + # neutron net-create public --router:external=True +$ neutron subnet-create public 172.16.1.0/24 +
+ Lists external networks. + + $ neutron net-list -- --router:external=True +
+ 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 +$ neutron net-create net2 +$ neutron subnet-create net2 10.0.1.0/24 +$ neutron router-create router1 +$ neutron router-interface-add router1 SUBNET1_UUID +$ neutron router-interface-add router1 SUBNET2_UUID +
+ 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 +
+ Lists routers. + + $ neutron router-list +
+ Shows information for a specified router. + + $ neutron router-show ROUTER_ID +
+ Shows all internal interfaces for a router. + + $ neutron router-port-list ROUTER_ID +$ neutron router-port-list ROUTER_NAME +
+ 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). +
+ Creates a floating IP address and associates it with a + port. + + $ neutron floatingip-create EXT_NET_ID +$ neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID +
+ 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 FLOATING_IP_ID +
+ Deletes the floating IP address. + + $ neutron floatingip-delete FLOATING_IP_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 +
+
+
+ +
+ 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. + + + + 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 + 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 + unlike Networking, which is port based. + + + +
+ Security group API abstractions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Security group attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group.
nameStringNoneHuman-readable name for the security group. Might not be unique. Cannot + be named default as that is automatically created for a tenant.
descriptionStringNoneHuman-readable description of a security group.
tenant_iduuid-strN/AOwner of the security group. Only admin users can specify a tenant_id + other than their own.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Security group rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the security group rule.
security_group_iduuid-str or Integerallocated by NetworkingThe security group to associate rule with.
directionStringN/AThe direction the traffic is allow (ingress/egress) from a VM.
protocolStringNoneIP Protocol (icmp, tcp, udp, and so on).
port_range_minIntegerNonePort at start of range
port_range_maxIntegerNonePort at end of range
ethertypeStringNoneethertype in L2 packet (IPv4, IPv6, and so on)
remote_ip_prefixstring (IP cidr)NoneCIDR for address range
remote_group_iduuid-str or Integerallocated by Networking or ComputeSource security group to apply to rule.
tenant_iduuid-strN/AOwner of the security group rule. Only admin users can specify a + tenant_id other than its own.
+
+
+ Basic security group operations + This table shows example neutron commands that enable you to complete basic + security group operations: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic security group operations
OperationCommand
+ 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 +
+ 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 group rules. + + $ neutron security-group-rule-list +
+ 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 +
+
+
+ +
+ 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. + + This list shows example neutron commands that enable you to complete 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 WEBSERVER1_IP --protocol-port 80 mypool +$ neutron lb-member-create --address WEBSERVER2_IP --protocol-port 80 mypool + + + Creates a health monitor that 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 + + + 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 + + +
+ +
+ Firewall-as-a-Service + The Firewall-as-a-Service (FWaaS) API is an experimental API that enables early + adopters and vendors to test their networking implementations. +
+ Firewall-as-a-Service API abstractions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Firewall rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall rule.
tenant_iduuid-strN/AOwner of the firewall rule. Only admin users can specify a tenant_id + other than its own.
nameStringNoneHuman readable name for the firewall rule (255 characters limit).
descriptionStringNoneHuman-readable description for the firewall rule (1024 characters + limit).
firewall_policy_iduuid-str or Noneallocated by NetworkingThis is a read-only attribute that gets populated with the UUID of the + firewall policy when this firewall rule is associated with a firewall + policy. A firewall rule can be associated with only one firewall policy + at a time. However, the association can be changed to a different + firewall policy.
sharedBooleanFalseWhen set to True makes this firewall rule visible to tenants other than + its owner and it can be used in firewall policies not owned by its + tenant.
protocolStringNoneIP protocol (icmp, tcp, udp, None).
ip_versionInteger or String4IP version (4, 6).
source_ip_addressString (IP address or CIDR)NoneSource IP address or CIDR.
destination_ip_addressString (IP address or CIDR)NoneDestination IP address or CIDR.
source_portInteger or String (either as a single port number or in the format of a + ':' separated range)NoneSource port number or a range.
destination_portInteger or String (either as a single port number or in the format of a + ':' separated range)NoneDestination port number or a range.
positionIntegerNoneThis is a read-only attribute that gets assigned to this rule when the + rule is associated with a firewall policy. It indicates the position of + this rule in that firewall policy.
actionStringdenyAction to be performed on the traffic matching the rule (allow, + deny).
enabledBooleanTrueWhen set to False, disables this rule in the firewall + policy. Facilitates selectively turning off rules without having to + disassociate the rule from the firewall policy.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Firewall policies
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall policy.
tenant_iduuid-strN/AOwner of the firewall policy. Only admin users can specify a tenant_id + other their own.
nameStringNoneHuman readable name for the firewall policy (255 characters limit).
descriptionStringNoneHuman readable description for the firewall policy (1024 characters + limit).
sharedBooleanFalseWhen set to True, the command makes this firewall policy visible to + tenants other than its owner and can be used to associate with firewalls not owned by + its tenant.
firewall_rulesList of uuid-str or NoneNoneThis is an ordered list of firewall rule UUIDs. The firewall applies the + rules in the order in which they appear in this list.
auditedBooleanFalseWhen set to True by the policy owner, the command indicates that + the firewall policy has been audited. This attribute is meant + to aid in the firewall policy audit work flows. Each time the + firewall policy or the associated firewall rules are changed, + this attribute is set to False and must be explicitly set + to True through an update operation.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Firewalls
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the firewall.
tenant_iduuid-strN/AOwner of the firewall. Only admin users can specify a tenant_id other + than its own.
nameStringNoneHuman readable name for the firewall (255 characters limit).
descriptionStringNoneHuman readable description for the firewall (1024 characters + limit).
admin_state_upBooleanTrueThe administrative state of the firewall. If False (down), the firewall + does not forward any packets.
statusStringN/A + Indicates whether the firewall is currently operational. Possible + values include: + + + ACTIVE + + + DOWN + + + PENDING_CREATE + + + PENDING_UPDATE + + + PENDING_DELETE + + + ERROR + + +
firewall_policy_iduuid-str or NoneNoneThe firewall policy UUID that this firewall is associated with. This + firewall implements the rules contained in the firewall policy + represented by this UUID.
+
+
+ +
+ Plug-in specific extensions + + 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. +
+ 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 + 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. +
+ VMware NSX QoS API abstractions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VMware NSX QoS attributes
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the QoS queue.
defaultBooleanFalse by defaultIf True, ports are created with this queue size unless the + network port is created or associated with a queue at port + creation time.
nameStringNoneName for QoS queue.
minInteger0Minimum Bandwidth Rate (kbps).
maxIntegerN/AMaximum Bandwidth Rate (kbps).
qos_markingStringuntrusted by defaultWhether QoS marking should be trusted or untrusted.
dscpInteger0DSCP Marking value.
tenant_iduuid-strN/AThe owner of the QoS queue.
+
+
+ Basic VMware NSX QoS operations + This table shows example neutron commands that enable you to complete + basic queue operations: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic VMware NSX QoS operations
OperationCommand
+ Creates QoS queue (admin-only). + + $ neutron queue-create --min 10 --max 1000 myqueue +
+ Associates a queue with a network. + + $ neutron net-create network --queue_id=QUEUE_ID +
+ Creates a default system queue. + + $ neutron queue-create --default True --min 10 --max 2000 default +
+ Lists QoS queues. + + $ neutron queue-list +
+ Deletes a QoS queue. + + $ neutron queue-delete QUEUE_ID_OR_NAME' +
+
+
+
+ VMware NSX provider networks extension + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Recommended values for max_lp_per_bridged_ls
NSX versionRecommended Value
2.x64
3.0.x5,000
3.1.x5,000
3.2.x10,000
+ 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 an 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: + $ 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: + $ 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Configuration options for tuning operational status synchronization in + the NSX plug-in
Option nameGroupDefault valueType and constraintsNotes
state_sync_intervalnsx_sync120 secondsInteger; 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 + synchronization task.
max_random_sync_delaynsx_sync0 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.
min_sync_req_delaynsx_sync10 secondsInteger. 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.
min_chunk_sizensx_sync500 resourcesInteger; 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.
always_read_statusnsx_syncFalseBoolean; 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 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. +
+ 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. +
+ 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 Networking API. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Big Switch Router rule attributes
Attribute nameRequiredInput TypeDescription
sourceYesA 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
destinationYesA 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
actionYes'permit' or 'deny'Determines whether or not the matched packets will allowed to + cross the router
nexthopNoA 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. +
+
+ 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: + $ 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: + $ 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: + $ 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 +
+
+
+
+
+ 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 + 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. +
+ L3 metering API abstractions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Label
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering label.
nameStringNoneHuman-readable name for the metering label. Might not be unique.
descriptionStringNoneThe optional description for the metering label.
tenant_iduuid-strN/AOwner of the metering label.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Rules
Attribute nameTypeDefault ValueDescription
iduuid-strgeneratedUUID for the metering rule.
directionString (Either ingress or egress)ingressThe direction in which metering rule is applied, either ingress or + egress.
metering_label_iduuid-strN/A + The metering label ID to associate with this metering rule. +
excludedBooleanFalseSpecify whether the remote_ip_prefix will be excluded or not from + traffic counters of the metering label (for example, to not count the + traffic of a specific IP address of a range).
remote_ip_prefixString (CIDR)N/AIndicates remote IP prefix to be associated with this metering + rule.
+
+ +
+ Basic L3 metering operations + Only administrators can manage the L3 metering labels and rules. + This table shows example neutron commands that enable you to + complete basic L3 metering operations: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic L3 operations
OperationCommand
+ Creates a metering label. + + $ neutron meter-label-create LABEL1 --description "DESCRIPTION_LABEL1" +
+ Lists metering labels. + + $ neutron meter-label-list +
+ Shows information for a specified label. + + $ neutron meter-label-show LABEL_UUID +$ neutron meter-label-show LABEL1 +
+ Deletes a metering label. + + $ neutron meter-label-delete LABEL_UUID +$ neutron meter-label-delete LABEL1 +
+ Creates a metering rule. + + $ neutron meter-label-rule-create LABEL_UUID CIDR --direction DIRECTION --excluded + For example: + $ neutron meter-label-rule-create label1 10.0.0.0/24 --direction ingress +$ neutron meter-label-rule-create label1 20.0.0.0/24 --excluded +
+ Lists metering all label rules. + + $ neutron meter-label-rule-list +
+ Shows information for a specified label rule. + + $ neutron meter-label-rule-show RULE_UUID +
Deletes a metering label rule. + $ neutron meter-label-rule-delete RULE_UUID +
+
+
+
\ No newline at end of file diff --git a/doc/networking-guide/section_networking_adv_operational_features.xml b/doc/networking-guide/section_networking_adv_operational_features.xml new file mode 100644 index 0000000000..ac6deced7c --- /dev/null +++ b/doc/networking-guide/section_networking_adv_operational_features.xml @@ -0,0 +1,162 @@ + +
+ Advanced operational features +
+ Logging settings + Networking components use Python logging module to do + logging. Logging configuration can be provided in + neutron.conf or as command-line + options. Command options override ones in + neutron.conf. + To configure logging for Networking components, use one + of these methods: + + + Provide logging settings in a logging + configuration file. + See Python + logging how-to to learn more about logging. + + + Provide logging setting in + neutron.conf + [DEFAULT] +# Default log level is WARNING +# Show debugging output in logs (sets DEBUG log level output) +# debug = False + +# Show more verbose log output (sets INFO log level output) if debug is False +# verbose = False + +# log_format = %(asctime)s %(levelname)8s [%(name)s] %(message)s +# log_date_format = %Y-%m-%d %H:%M:%S + +# use_syslog = False +# syslog_log_facility = LOG_USER + +# if use_syslog is False, we can set log_file and log_dir. +# if use_syslog is False and we do not set log_file, +# the log will be printed to stdout. +# log_file = +# log_dir = + + +
+
+ Notifications + Notifications can be sent when Networking resources such + as network, subnet and port are created, updated or + deleted. +
+ Notification options + To support DHCP agent, rpc_notifier driver must be + set. To set up the notification, edit notification + options in neutron.conf: + # ============ Notification System Options ===================== + +# Notifications can be sent when network/subnet/port are create, updated or deleted. +# There are three methods of sending notifications: logging (via the +# log_file directive), rpc (via a message queue) and +# noop (no notifications sent, the default) + +# Notification_driver can be defined multiple times +# Do nothing driver +# notification_driver = neutron.openstack.common.notifier.no_op_notifier +# Logging driver +# notification_driver = neutron.openstack.common.notifier.log_notifier +# RPC driver +notification_driver = neutron.openstack.common.notifier.rpc_notifier + +# default_notification_level is used to form actual topic names or to set logging level +# default_notification_level = INFO + +# default_publisher_id is a part of the notification payload +# host = myhost.com +# default_publisher_id = $host + +# Defined in rpc_notifier for rpc way, can be comma-separated values. +# The actual topic names will be %s.%(default_notification_level)s +notification_topics = notifications +
+
+ Setting cases +
+ Logging and RPC + These options configure the Networking + server to send notifications through logging and + RPC. The logging options are described in + OpenStack Configuration Reference + . RPC notifications go to 'notifications.info' + queue bound to a topic exchange defined by + 'control_exchange' in + neutron.conf. + # ============ Notification System Options ===================== + +# Notifications can be sent when network/subnet/port are create, updated or deleted. +# There are three methods of sending notifications: logging (via the +# log_file directive), rpc (via a message queue) and +# noop (no notifications sent, the default) + +# Notification_driver can be defined multiple times +# Do nothing driver +# notification_driver = neutron.openstack.common.notifier.no_op_notifier +# Logging driver +notification_driver = neutron.openstack.common.notifier.log_notifier +# RPC driver +notification_driver = neutron.openstack.common.notifier.rpc_notifier + +# default_notification_level is used to form actual topic names or to set logging level +default_notification_level = INFO + +# default_publisher_id is a part of the notification payload +# host = myhost.com +# default_publisher_id = $host + +# Defined in rpc_notifier for rpc way, can be comma-separated values. +# The actual topic names will be %s.%(default_notification_level)s +notification_topics = notifications +
+
+ Multiple RPC topics + These options configure the Networking + server to send notifications to multiple RPC + topics. RPC notifications go to + 'notifications_one.info' and + 'notifications_two.info' queues bound to a topic + exchange defined by 'control_exchange' in + neutron.conf. + # ============ Notification System Options ===================== + +# Notifications can be sent when network/subnet/port are create, updated or deleted. +# There are three methods of sending notifications: logging (via the +# log_file directive), rpc (via a message queue) and +# noop (no notifications sent, the default) + +# Notification_driver can be defined multiple times +# Do nothing driver +# notification_driver = neutron.openstack.common.notifier.no_op_notifier +# Logging driver +# notification_driver = neutron.openstack.common.notifier.log_notifier +# RPC driver +notification_driver = neutron.openstack.common.notifier.rabbit_notifier + +# default_notification_level is used to form actual topic names or to set logging level +default_notification_level = INFO + +# default_publisher_id is a part of the notification payload +# host = myhost.com +# default_publisher_id = $host + +# Defined in rpc_notifier for rpc way, can be comma-separated values. +# The actual topic names will be %s.%(default_notification_level)s +notification_topics = notifications_one,notifications_two +
+
+
+
\ No newline at end of file