You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by se...@apache.org on 2014/05/17 09:34:34 UTC
[5/7] split the networking2 file into multiple includes and renamed
it to 'networking_and_traffic': This closes #11
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/acquiring_an_ip_address.rst
----------------------------------------------------------------------
diff --git a/source/networking/acquiring_an_ip_address.rst b/source/networking/acquiring_an_ip_address.rst
new file mode 100644
index 0000000..b6556db
--- /dev/null
+++ b/source/networking/acquiring_an_ip_address.rst
@@ -0,0 +1,42 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+Acquiring a New IP Address
+--------------------------
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. Click the name of the network where you want to work with.
+
+#. Click View IP Addresses.
+
+#. Click Acquire New IP.
+
+ The Acquire New IP window is displayed.
+
+#. Specify whether you want cross-zone IP or not.
+
+ If you want Portable IP click Yes in the confirmation dialog. If you
+ want a normal Public IP click No.
+
+ For more information on Portable IP, see `"Portable
+ IPs" <#portable-ips>`_.
+
+ Within a few moments, the new IP address should appear with the state
+ Allocated. You can now use the IP address in port forwarding or
+ static NAT rules.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/advanced_zone_config.rst
----------------------------------------------------------------------
diff --git a/source/networking/advanced_zone_config.rst b/source/networking/advanced_zone_config.rst
new file mode 100644
index 0000000..63027b3
--- /dev/null
+++ b/source/networking/advanced_zone_config.rst
@@ -0,0 +1,152 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+
+Advanced Zone Physical Network Configuration
+--------------------------------------------
+
+Within a zone that uses advanced networking, you need to tell the
+Management Server how the physical network is set up to carry different
+kinds of traffic in isolation.
+
+
+Configure Guest Traffic in an Advanced Zone
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These steps assume you have already logged in to the CloudStack UI. To
+configure the base guest network:
+
+#. In the left navigation, choose Infrastructure. On Zones, click View
+ More, then click the zone to which you want to add a network.
+
+#. Click the Network tab.
+
+#. Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ |addguestnetwork.png|
+
+#. Provide the following information:
+
+ - **Name**: The name of the network. This will be user-visible
+
+ - **Display Text**: The description of the network. This will be
+ user-visible
+
+ - **Zone**: The zone in which you are configuring the guest network.
+
+ - **Network offering**: If the administrator has configured multiple
+ network offerings, select the one you want to use for this network
+
+ - **Guest Gateway**: The gateway that the guests should use
+
+ - **Guest Netmask**: The netmask in use on the subnet the guests
+ will use
+
+#. Click OK.
+
+
+Configure Public Traffic in an Advanced Zone
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In a zone that uses advanced networking, you need to configure at least
+one range of IP addresses for Internet traffic.
+
+
+Configuring a Shared Guest Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as administrator.
+
+#. In the left navigation, choose Infrastructure.
+
+#. On Zones, click View More.
+
+#. Click the zone to which you want to add a guest network.
+
+#. Click the Physical Network tab.
+
+#. Click the physical network you want to work with.
+
+#. On the Guest node of the diagram, click Configure.
+
+#. Click the Network tab.
+
+#. Click Add guest network.
+
+ The Add guest network window is displayed.
+
+#. Specify the following:
+
+ - **Name**: The name of the network. This will be visible to the user.
+
+ - **Description**: The short description of the network that can be
+ displayed to users.
+
+ - **VLAN ID**: The unique ID of the VLAN.
+
+ - **Isolated VLAN ID**: The unique ID of the Secondary Isolated
+ VLAN.
+
+ - **Scope**: The available scopes are Domain, Account, Project, and
+ All.
+
+ - **Domain**: Selecting Domain limits the scope of this guest
+ network to the domain you specify. The network will not be
+ available for other domains. If you select Subdomain Access,
+ the guest network is available to all the sub domains within
+ the selected domain.
+
+ - **Account**: The account for which the guest network is being
+ created for. You must specify the domain the account belongs
+ to.
+
+ - **Project**: The project for which the guest network is being
+ created for. You must specify the domain the project belongs
+ to.
+
+ - **All**: The guest network is available for all the domains,
+ account, projects within the selected zone.
+
+ - **Network Offering**: If the administrator has configured multiple
+ network offerings, select the one you want to use for this
+ network.
+
+ - **Gateway**: The gateway that the guests should use.
+
+ - **Netmask**: The netmask in use on the subnet the guests will use.
+
+ - **IP Range**: A range of IP addresses that are accessible from the
+ Internet and are assigned to the guest VMs.
+
+ If one NIC is used, these IPs should be in the same CIDR in the
+ case of IPv6.
+
+ - **IPv6 CIDR**: The network prefix that defines the guest network
+ subnet. This is the CIDR that describes the IPv6 addresses in use
+ in the guest networks in this zone. To allot IP addresses from
+ within a particular address block, enter a CIDR.
+
+ - **Network Domain**: A custom DNS suffix at the level of a network.
+ If you want to assign a special domain name to the guest VM
+ network, specify a DNS suffix.
+
+#. Click OK to confirm.
+
+
+.. |addguestnetwork.png| image:: /_static/images/add-guest-network.png
+ :alt: Add Guest network setup in a single zone.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/basic_zone_config.rst
----------------------------------------------------------------------
diff --git a/source/networking/basic_zone_config.rst b/source/networking/basic_zone_config.rst
new file mode 100644
index 0000000..a1ba26c
--- /dev/null
+++ b/source/networking/basic_zone_config.rst
@@ -0,0 +1,24 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+
+Basic Zone Physical Network Configuration
+-----------------------------------------
+
+In a basic network, configuring the physical network is fairly
+straightforward. You only need to configure one guest network to carry
+traffic that is generated by guest VMs. When you first add a zone to
+CloudStack, you set up the guest network through the Add Zone screens.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/dns_and_dhcp.rst
----------------------------------------------------------------------
diff --git a/source/networking/dns_and_dhcp.rst b/source/networking/dns_and_dhcp.rst
new file mode 100644
index 0000000..c84cffa
--- /dev/null
+++ b/source/networking/dns_and_dhcp.rst
@@ -0,0 +1,22 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+DNS and DHCP
+------------
+
+The Virtual Router provides DNS and DHCP services to the guests. It
+proxies DNS requests to the DNS server configured on the Availability
+Zone.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/elastic_ips.rst
----------------------------------------------------------------------
diff --git a/source/networking/elastic_ips.rst b/source/networking/elastic_ips.rst
new file mode 100644
index 0000000..fe83a3b
--- /dev/null
+++ b/source/networking/elastic_ips.rst
@@ -0,0 +1,104 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+About Elastic IPs
+-----------------
+
+Elastic IP (EIP) addresses are the IP addresses that are associated with
+an account, and act as static IP addresses. The account owner has the
+complete control over the Elastic IP addresses that belong to the
+account. As an account owner, you can allocate an Elastic IP to a VM of
+your choice from the EIP pool of your account. Later if required you can
+reassign the IP address to a different VM. This feature is extremely
+helpful during VM failure. Instead of replacing the VM which is down,
+the IP address can be reassigned to a new VM in your account.
+
+Similar to the public IP address, Elastic IP addresses are mapped to
+their associated private IP addresses by using StaticNAT. The EIP
+service is equipped with StaticNAT (1:1) service in an EIP-enabled basic
+zone. The default network offering,
+DefaultSharedNetscalerEIPandELBNetworkOffering, provides your network
+with EIP and ELB network services if a NetScaler device is deployed in
+your zone. Consider the following illustration for more details.
+
+|eip-ns-basiczone.png|
+
+In the illustration, a NetScaler appliance is the default entry or exit
+point for the CloudStack instances, and firewall is the default entry or
+exit point for the rest of the data center. Netscaler provides LB
+services and staticNAT service to the guest networks. The guest traffic
+in the pods and the Management Server are on different subnets / VLANs.
+The policy-based routing in the data center core switch sends the public
+traffic through the NetScaler, whereas the rest of the data center goes
+through the firewall.
+
+The EIP work flow is as follows:
+
+- When a user VM is deployed, a public IP is automatically acquired
+ from the pool of public IPs configured in the zone. This IP is owned
+ by the VM's account.
+
+- Each VM will have its own private IP. When the user VM starts, Static
+ NAT is provisioned on the NetScaler device by using the Inbound
+ Network Address Translation (INAT) and Reverse NAT (RNAT) rules
+ between the public IP and the private IP.
+
+ .. note::
+ Inbound NAT (INAT) is a type of NAT supported by NetScaler, in which
+ the destination IP address is replaced in the packets from the public
+ network, such as the Internet, with the private IP address of a VM in
+ the private network. Reverse NAT (RNAT) is a type of NAT supported by
+ NetScaler, in which the source IP address is replaced in the packets
+ generated by a VM in the private network with the public IP address.
+
+- This default public IP will be released in two cases:
+
+ - When the VM is stopped. When the VM starts, it again receives a
+ new public IP, not necessarily the same one allocated initially,
+ from the pool of Public IPs.
+
+ - The user acquires a public IP (Elastic IP). This public IP is
+ associated with the account, but will not be mapped to any private
+ IP. However, the user can enable Static NAT to associate this IP
+ to the private IP of a VM in the account. The Static NAT rule for
+ the public IP can be disabled at any time. When Static NAT is
+ disabled, a new public IP is allocated from the pool, which is not
+ necessarily be the same one allocated initially.
+
+For the deployments where public IPs are limited resources, you have the
+flexibility to choose not to allocate a public IP by default. You can
+use the Associate Public IP option to turn on or off the automatic
+public IP assignment in the EIP-enabled Basic zones. If you turn off the
+automatic public IP assignment while creating a network offering, only a
+private IP is assigned to a VM when the VM is deployed with that network
+offering. Later, the user can acquire an IP for the VM and enable static
+NAT.
+
+For more information on the Associate Public IP option, see
+`"Creating a New Network Offering" <networking.html#creating-a-new-network-offering>`_.
+
+.. note::
+ The Associate Public IP feature is designed only for use with user VMs.
+ The System VMs continue to get both public IP and private by default,
+ irrespective of the network offering configuration.
+
+New deployments which use the default shared network offering with EIP
+and ELB services to create a shared network in the Basic zone will
+continue allocating public IPs to each user VM.
+
+
+.. |eip-ns-basiczone.png| image:: /_static/images/eip-ns-basiczone.png
+ :alt: Elastic IP in a NetScaler-enabled Basic Zone.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/external_firewalls_and_load_balancers.rst
----------------------------------------------------------------------
diff --git a/source/networking/external_firewalls_and_load_balancers.rst b/source/networking/external_firewalls_and_load_balancers.rst
new file mode 100644
index 0000000..1652b77
--- /dev/null
+++ b/source/networking/external_firewalls_and_load_balancers.rst
@@ -0,0 +1,661 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+External Firewalls and Load Balancers
+-------------------------------------
+
+CloudStack is capable of replacing its Virtual Router with an external
+Juniper SRX device and an optional external NetScaler or F5 load
+balancer for gateway and load balancing services. In this case, the VMs
+use the SRX as their gateway.
+
+
+About Using a NetScaler Load Balancer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Citrix NetScaler is supported as an external network element for load
+balancing in zones that use isolated networking in advanced zones. Set
+up an external load balancer when you want to provide load balancing
+through means other than CloudStack's provided virtual router.
+
+.. note::
+ In a Basic zone, load balancing service is supported only if
+ Elastic IP or Elastic LB services are enabled.
+
+When NetScaler load balancer is used to provide EIP or ELB services in a
+Basic zone, ensure that all guest VM traffic must enter and exit through
+the NetScaler device. When inbound traffic goes through the NetScaler
+device, traffic is routed by using the NAT protocol depending on the
+EIP/ELB configured on the public IP to the private IP. The traffic that
+is originated from the guest VMs usually goes through the layer 3
+router. To ensure that outbound traffic goes through NetScaler device
+providing EIP/ELB, layer 3 router must have a policy-based routing. A
+policy-based route must be set up so that all traffic originated from
+the guest VM's are directed to NetScaler device. This is required to
+ensure that the outbound traffic from the guest VM's is routed to a
+public IP by using NAT.For more information on Elastic IP, see
+`"About Elastic IP" <#about-elastic-ip>`_.
+
+The NetScaler can be set up in direct (outside the firewall) mode. It
+must be added before any load balancing rules are deployed on guest VMs
+in the zone.
+
+The functional behavior of the NetScaler with CloudStack is the same as
+described in the CloudStack documentation for using an F5 external load
+balancer. The only exception is that the F5 supports routing domains,
+and NetScaler does not. NetScaler can not yet be used as a firewall.
+
+To install and enable an external load balancer for CloudStack
+management, see External Guest Load Balancer Integration in the
+Installation Guide.
+
+The Citrix NetScaler comes in three varieties. The following
+summarizes how these variants are treated in CloudStack.
+
+**MPX**
+
+- Physical appliance. Capable of deep packet inspection. Can act as
+ application firewall and load balancer
+
+- In advanced zones, load balancer functionality fully supported without
+ limitation. In basic zones, static NAT, elastic IP (EIP), and elastic
+ load balancing (ELB) are also provided.
+
+**VPX**
+
+- Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V
+ hypervisors. Same functionality as MPX
+
+- Supported on ESXi and XenServer. Same functional support as for MPX.
+ CloudStack will treat VPX and MPX as the same device type.
+
+**SDX**
+
+- Physical appliance. Can create multiple fully isolated VPX instances on
+ a single appliance to support multi-tenant usage
+
+- CloudStack will dynamically provision, configure, and manage the life
+ cycle of VPX instances on the SDX. Provisioned instances are added into
+ CloudStack automatically - no manual configuration by the administrator
+ is required. Once a VPX instance is added into CloudStack, it is treated
+ the same as a VPX on an ESXi host.
+
+
+Configuring SNMP Community String on a RHEL Server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The SNMP Community string is similar to a user id or password that
+provides access to a network device, such as router. This string is sent
+along with all SNMP requests. If the community string is correct, the
+device responds with the requested information. If the community string
+is incorrect, the device discards the request and does not respond.
+
+The NetScaler device uses SNMP to communicate with the VMs. You must
+install SNMP and configure SNMP Community string for a secure
+communication between the NetScaler device and the RHEL machine.
+
+#. Ensure that you installed SNMP on RedHat. If not, run the following
+ command:
+
+ .. code:: bash
+
+ yum install net-snmp-utils
+
+#. Edit the /etc/snmp/snmpd.conf file to allow the SNMP polling from the
+ NetScaler device.
+
+ #. Map the community name into a security name (local and mynetwork,
+ depending on where the request is coming from):
+
+ .. note::
+ Use a strong password instead of public when you edit the
+ following table.
+
+ .. code:: bash
+
+ # sec.name source community
+ com2sec local localhost public
+ com2sec mynetwork 0.0.0.0 public
+
+ .. note:: Setting to 0.0.0.0 allows all IPs to poll the NetScaler server.
+
+ #. Map the security names into group names:
+
+ .. code:: bash
+
+ # group.name sec.model sec.name
+ group MyRWGroup v1 local
+ group MyRWGroup v2c local
+ group MyROGroup v1 mynetwork
+ group MyROGroup v2c mynetwork
+
+ #. Create a view to allow the groups to have the permission to:
+
+ .. code:: bash
+
+ incl/excl subtree mask view all included .1
+
+ #. Grant access with different write permissions to the two groups to
+ the view you created.
+
+ .. code:: bash
+
+ # context sec.model sec.level prefix read write notif
+ access MyROGroup "" any noauth exact all none none
+ access MyRWGroup "" any noauth exact all all all
+
+#. Unblock SNMP in iptables.
+
+ .. code:: bash
+
+ iptables -A INPUT -p udp --dport 161 -j ACCEPT
+
+#. Start the SNMP service:
+
+ .. code:: bash
+
+ service snmpd start
+
+#. Ensure that the SNMP service is started automatically during the
+ system startup:
+
+ .. code:: bash
+
+ chkconfig snmpd on
+
+
+Initial Setup of External Firewalls and Load Balancers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When the first VM is created for a new account, CloudStack programs the
+external firewall and load balancer to work with the VM. The following
+objects are created on the firewall:
+
+- A new logical interface to connect to the account's private VLAN. The
+ interface IP is always the first IP of the account's private subnet
+ (e.g. 10.1.1.1).
+
+- A source NAT rule that forwards all outgoing traffic from the
+ account's private VLAN to the public Internet, using the account's
+ public IP address as the source address
+
+- A firewall filter counter that measures the number of bytes of
+ outgoing traffic for the account
+
+The following objects are created on the load balancer:
+
+- A new VLAN that matches the account's provisioned Zone VLAN
+
+- A self IP for the VLAN. This is always the second IP of the account's
+ private subnet (e.g. 10.1.1.2).
+
+
+Ongoing Configuration of External Firewalls and Load Balancers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Additional user actions (e.g. setting a port forward) will cause further
+programming of the firewall and load balancer. A user may request
+additional public IP addresses and forward traffic received at these IPs
+to specific VMs. This is accomplished by enabling static NAT for a
+public IP address, assigning the IP to a VM, and specifying a set of
+protocols and port ranges to open. When a static NAT rule is created,
+CloudStack programs the zone's external firewall with the following
+objects:
+
+- A static NAT rule that maps the public IP address to the private IP
+ address of a VM.
+
+- A security policy that allows traffic within the set of protocols and
+ port ranges that are specified.
+
+- A firewall filter counter that measures the number of bytes of
+ incoming traffic to the public IP.
+
+The number of incoming and outgoing bytes through source NAT, static
+NAT, and load balancing rules is measured and saved on each external
+element. This data is collected on a regular basis and stored in the
+CloudStack database.
+
+
+Load Balancer Rules
+~~~~~~~~~~~~~~~~~~~
+
+A CloudStack user or administrator may create load balancing rules that
+balance traffic received at a public IP to one or more VMs. A user
+creates a rule, specifies an algorithm, and assigns the rule to a set of
+VMs.
+
+.. note::
+ If you create load balancing rules while using a network service
+ offering that includes an external load balancer device such as
+ NetScaler, and later change the network service offering to one that
+ uses the CloudStack virtual router, you must create a firewall rule on
+ the virtual router for each of your existing load balancing rules so
+ that they continue to function.
+
+
+.. _adding-lb-rule:
+
+Adding a Load Balancer Rule
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. Click the name of the network where you want to load balance the
+ traffic.
+
+#. Click View IP Addresses.
+
+#. Click the IP address for which you want to create the rule, then
+ click the Configuration tab.
+
+#. In the Load Balancing node of the diagram, click View All.
+
+ In a Basic zone, you can also create a load balancing rule without
+ acquiring or selecting an IP address. CloudStack internally assign an
+ IP when you create the load balancing rule, which is listed in the IP
+ Addresses page when the rule is created.
+
+ To do that, select the name of the network, then click Add Load
+ Balancer tab. Continue with #7.
+
+#. Fill in the following:
+
+ - **Name**: A name for the load balancer rule.
+
+ - **Public Port**: The port receiving incoming traffic to be
+ balanced.
+
+ - **Private Port**: The port that the VMs will use to receive the
+ traffic.
+
+ - **Algorithm**: Choose the load balancing algorithm you want
+ CloudStack to use. CloudStack supports a variety of well-known
+ algorithms. If you are not familiar with these choices, you will
+ find plenty of information about them on the Internet.
+
+ - **Stickiness**: (Optional) Click Configure and choose the
+ algorithm for the stickiness policy. See Sticky Session Policies
+ for Load Balancer Rules.
+
+ - **AutoScale**: Click Configure and complete the AutoScale
+ configuration as explained in :ref:`conf-autoscale`.
+
+ - **Health Check**: (Optional; NetScaler load balancers only) Click
+ Configure and fill in the characteristics of the health check
+ policy. See :ref:`health-check`.
+
+ - **Ping path (Optional)**: Sequence of destinations to which to
+ send health check queries. Default: / (all).
+
+ - **Response time (Optional)**: How long to wait for a response
+ from the health check (2 - 60 seconds). Default: 5 seconds.
+
+ - **Interval time (Optional)**: Amount of time between health
+ checks (1 second - 5 minutes). Default value is set in the
+ global configuration parameter lbrule\_health
+ check\_time\_interval.
+
+ - **Healthy threshold (Optional)**: Number of consecutive health
+ check successes that are required before declaring an instance
+ healthy. Default: 2.
+
+ - **Unhealthy threshold (Optional)**: Number of consecutive
+ health check failures that are required before declaring an
+ instance unhealthy. Default: 10.
+
+#. Click Add VMs, then select two or more VMs that will divide the load
+ of incoming traffic, and click Apply.
+
+ The new load balancer rule appears in the list. You can repeat these
+ steps to add more load balancer rules for this IP address.
+
+
+Sticky Session Policies for Load Balancer Rules
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sticky sessions are used in Web-based applications to ensure continued
+availability of information across the multiple requests in a user's
+session. For example, if a shopper is filling a cart, you need to
+remember what has been purchased so far. The concept of "stickiness" is
+also referred to as persistence or maintaining state.
+
+Any load balancer rule defined in CloudStack can have a stickiness
+policy. The policy consists of a name, stickiness method, and
+parameters. The parameters are name-value pairs or flags, which are
+defined by the load balancer vendor. The stickiness method could be load
+balancer-generated cookie, application-generated cookie, or
+source-based. In the source-based method, the source IP address is used
+to identify the user and locate the user's stored data. In the other
+methods, cookies are used. The cookie generated by the load balancer or
+application is included in request and response URLs to create
+persistence. The cookie name can be specified by the administrator or
+automatically generated. A variety of options are provided to control
+the exact behavior of cookies, such as how they are generated and
+whether they are cached.
+
+For the most up to date list of available stickiness methods, see the
+CloudStack UI or call listNetworks and check the
+SupportedStickinessMethods capability.
+
+
+.. _health-check:
+
+Health Checks for Load Balancer Rules
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+(NetScaler load balancer only; requires NetScaler version 10.0)
+
+Health checks are used in load-balanced applications to ensure that
+requests are forwarded only to running, available services. When
+creating a load balancer rule, you can specify a health check policy.
+This is in addition to specifying the stickiness policy, algorithm, and
+other load balancer rule options. You can configure one health check
+policy per load balancer rule.
+
+Any load balancer rule defined on a NetScaler load balancer in
+CloudStack can have a health check policy. The policy consists of a ping
+path, thresholds to define "healthy" and "unhealthy" states, health
+check frequency, and timeout wait interval.
+
+When a health check policy is in effect, the load balancer will stop
+forwarding requests to any resources that are found to be unhealthy. If
+the resource later becomes available again, the periodic health check
+will discover it, and the resource will once again be added to the pool
+of resources that can receive requests from the load balancer. At any
+given time, the most recent result of the health check is displayed in
+the UI. For any VM that is attached to a load balancer rule with a
+health check configured, the state will be shown as UP or DOWN in the UI
+depending on the result of the most recent health check.
+
+You can delete or modify existing health check policies.
+
+To configure how often the health check is performed by default, use the
+global configuration setting healthcheck.update.interval (default value
+is 600 seconds). You can override this value for an individual health
+check policy.
+
+For details on how to set a health check policy using the UI, see
+:ref:`adding-lb-rule`.
+
+
+.. _conf-autoscale:
+
+Configuring AutoScale
+~~~~~~~~~~~~~~~~~~~~~
+
+AutoScaling allows you to scale your back-end services or application
+VMs up or down seamlessly and automatically according to the conditions
+you define. With AutoScaling enabled, you can ensure that the number of
+VMs you are using seamlessly scale up when demand increases, and
+automatically decreases when demand subsides. Thus it helps you save
+compute costs by terminating underused VMs automatically and launching
+new VMs when you need them, without the need for manual intervention.
+
+NetScaler AutoScaling is designed to seamlessly launch or terminate VMs
+based on user-defined conditions. Conditions for triggering a scaleup or
+scaledown action can vary from a simple use case like monitoring the CPU
+usage of a server to a complex use case of monitoring a combination of
+server's responsiveness and its CPU usage. For example, you can
+configure AutoScaling to launch an additional VM whenever CPU usage
+exceeds 80 percent for 15 minutes, or to remove a VM whenever CPU usage
+is less than 20 percent for 30 minutes.
+
+CloudStack uses the NetScaler load balancer to monitor all aspects of a
+system's health and work in unison with CloudStack to initiate scale-up
+or scale-down actions.
+
+.. note::
+ AutoScale is supported on NetScaler Release 10 Build 74.4006.e and beyond.
+
+
+Prerequisites
+^^^^^^^^^^^^^
+
+Before you configure an AutoScale rule, consider the following:
+
+- Ensure that the necessary template is prepared before configuring
+ AutoScale. When a VM is deployed by using a template and when it
+ comes up, the application should be up and running.
+
+ .. note::
+ If the application is not running, the NetScaler device considers the
+ VM as ineffective and continues provisioning the VMs unconditionally
+ until the resource limit is exhausted.
+
+- Deploy the templates you prepared. Ensure that the applications come
+ up on the first boot and is ready to take the traffic. Observe the
+ time requires to deploy the template. Consider this time when you
+ specify the quiet time while configuring AutoScale.
+
+- The AutoScale feature supports the SNMP counters that can be used to
+ define conditions for taking scale up or scale down actions. To
+ monitor the SNMP-based counter, ensure that the SNMP agent is
+ installed in the template used for creating the AutoScale VMs, and
+ the SNMP operations work with the configured SNMP community and port
+ by using standard SNMP managers. For example, see
+ `"Configuring SNMP Community String on a RHELServer"
+ <#configuring-snmp-community-string-on-a-rhel-server>`_
+ to configure SNMP on a RHEL machine.
+
+- Ensure that the endpointe.url parameter present in the Global
+ Settings is set to the Management Server API URL. For example,
+ ``http://10.102.102.22:8080/client/api``. In a multi-node Management
+ Server deployment, use the virtual IP address configured in the load
+ balancer for the management server's cluster. Additionally, ensure
+ that the NetScaler device has access to this IP address to provide
+ AutoScale support.
+
+ If you update the endpointe.url, disable the AutoScale functionality
+ of the load balancer rules in the system, then enable them back to
+ reflect the changes. For more information see :ref:`update-autoscale`.
+
+- If the API Key and Secret Key are regenerated for an AutoScale user,
+ ensure that the AutoScale functionality of the load balancers that
+ the user participates in are disabled and then enabled to reflect the
+ configuration changes in the NetScaler.
+
+- In an advanced Zone, ensure that at least one VM should be present
+ before configuring a load balancer rule with AutoScale. Having one VM
+ in the network ensures that the network is in implemented state for
+ configuring AutoScale.
+
+
+Configuration
+^^^^^^^^^^^^^
+
+Specify the following:
+
+|autoscaleateconfig.png|
+
+- **Template**: A template consists of a base OS image and application.
+ A template is used to provision the new instance of an application on
+ a scaleup action. When a VM is deployed from a template, the VM can
+ start taking the traffic from the load balancer without any admin
+ intervention. For example, if the VM is deployed for a Web service,
+ it should have the Web server running, the database connected, and so
+ on.
+
+- **Compute offering**: A predefined set of virtual hardware
+ attributes, including CPU speed, number of CPUs, and RAM size, that
+ the user can select when creating a new virtual machine instance.
+ Choose one of the compute offerings to be used while provisioning a
+ VM instance as part of scaleup action.
+
+- **Min Instance**: The minimum number of active VM instances that is
+ assigned to a load balancing rule. The active VM instances are the
+ application instances that are up and serving the traffic, and are
+ being load balanced. This parameter ensures that a load balancing
+ rule has at least the configured number of active VM instances are
+ available to serve the traffic.
+
+ .. note::
+ If an application, such as SAP, running on a VM instance is down for
+ some reason, the VM is then not counted as part of Min Instance
+ parameter, and the AutoScale feature initiates a scaleup action if
+ the number of active VM instances is below the configured value.
+ Similarly, when an application instance comes up from its earlier
+ down state, this application instance is counted as part of the
+ active instance count and the AutoScale process initiates a scaledown
+ action when the active instance count breaches the Max instance
+ value.
+
+- **Max Instance**: Maximum number of active VM instances that **should
+ be assigned to**\ a load balancing rule. This parameter defines the
+ upper limit of active VM instances that can be assigned to a load
+ balancing rule.
+
+ Specifying a large value for the maximum instance parameter might
+ result in provisioning large number of VM instances, which in turn
+ leads to a single load balancing rule exhausting the VM instances
+ limit specified at the account or domain level.
+
+ .. note::
+ If an application, such as SAP, running on a VM instance is down for
+ some reason, the VM is not counted as part of Max Instance parameter.
+ So there may be scenarios where the number of VMs provisioned for a
+ scaleup action might be more than the configured Max Instance value.
+ Once the application instances in the VMs are up from an earlier down
+ state, the AutoScale feature starts aligning to the configured Max
+ Instance value.
+
+Specify the following scale-up and scale-down policies:
+
+- **Duration**: The duration, in seconds, for which the conditions you
+ specify must be true to trigger a scaleup action. The conditions
+ defined should hold true for the entire duration you specify for an
+ AutoScale action to be invoked.
+
+- **Counter**: The performance counters expose the state of the
+ monitored instances. By default, CloudStack offers four performance
+ counters: Three SNMP counters and one NetScaler counter. The SNMP
+ counters are Linux User CPU, Linux System CPU, and Linux CPU Idle.
+ The NetScaler counter is ResponseTime. The root administrator can add
+ additional counters into CloudStack by using the CloudStack API.
+
+- **Operator**: The following five relational operators are supported
+ in AutoScale feature: Greater than, Less than, Less than or equal to,
+ Greater than or equal to, and Equal to.
+
+- **Threshold**: Threshold value to be used for the counter. Once the
+ counter defined above breaches the threshold value, the AutoScale
+ feature initiates a scaleup or scaledown action.
+
+- **Add**: Click Add to add the condition.
+
+Additionally, if you want to configure the advanced settings, click Show
+advanced settings, and specify the following:
+
+- **Polling interval**: Frequency in which the conditions, combination
+ of counter, operator and threshold, are to be evaluated before taking
+ a scale up or down action. The default polling interval is 30
+ seconds.
+
+- **Quiet Time**: This is the cool down period after an AutoScale
+ action is initiated. The time includes the time taken to complete
+ provisioning a VM instance from its template and the time taken by an
+ application to be ready to serve traffic. This quiet time allows the
+ fleet to come up to a stable state before any action can take place.
+ The default is 300 seconds.
+
+- **Destroy VM Grace Period**: The duration in seconds, after a
+ scaledown action is initiated, to wait before the VM is destroyed as
+ part of scaledown action. This is to ensure graceful close of any
+ pending sessions or transactions being served by the VM marked for
+ destroy. The default is 120 seconds.
+
+- **Security Groups**: Security groups provide a way to isolate traffic
+ to the VM instances. A security group is a group of VMs that filter
+ their incoming and outgoing traffic according to a set of rules,
+ called ingress and egress rules. These rules filter network traffic
+ according to the IP address that is attempting to communicate with
+ the VM.
+
+- **Disk Offerings**: A predefined set of disk size for primary data
+ storage.
+
+- **SNMP Community**: The SNMP community string to be used by the
+ NetScaler device to query the configured counter value from the
+ provisioned VM instances. Default is public.
+
+- **SNMP Port**: The port number on which the SNMP agent that run on
+ the provisioned VMs is listening. Default port is 161.
+
+- **User**: This is the user that the NetScaler device use to invoke
+ scaleup and scaledown API calls to the cloud. If no option is
+ specified, the user who configures AutoScaling is applied. Specify
+ another user name to override.
+
+- **Apply**: Click Apply to create the AutoScale configuration.
+
+
+Disabling and Enabling an AutoScale Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you want to perform any maintenance operation on the AutoScale VM
+instances, disable the AutoScale configuration. When the AutoScale
+configuration is disabled, no scaleup or scaledown action is performed.
+You can use this downtime for the maintenance activities. To disable the
+AutoScale configuration, click the Disable AutoScale |EnableDisable.png| button.
+
+The button toggles between enable and disable, depending on whether
+AutoScale is currently enabled or not. After the maintenance operations
+are done, you can enable the AutoScale configuration back. To enable,
+open the AutoScale configuration page again, then click the Enable
+AutoScale |EnableDisable.png| button.
+
+
+.. _update-autoscale:
+
+Updating an AutoScale Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You can update the various parameters and add or delete the conditions
+in a scaleup or scaledown rule. Before you update an AutoScale
+configuration, ensure that you disable the AutoScale load balancer rule
+by clicking the Disable AutoScale button.
+
+After you modify the required AutoScale parameters, click Apply. To
+apply the new AutoScale policies, open the AutoScale configuration page
+again, then click the Enable AutoScale button.
+
+
+Runtime Considerations
+^^^^^^^^^^^^^^^^^^^^^^
+
+- An administrator should not assign a VM to a load balancing rule
+ which is configured for AutoScale.
+
+- Before a VM provisioning is completed if NetScaler is shutdown or
+ restarted, the provisioned VM cannot be a part of the load balancing
+ rule though the intent was to assign it to a load balancing rule. To
+ workaround, rename the AutoScale provisioned VMs based on the rule
+ name or ID so at any point of time the VMs can be reconciled to its
+ load balancing rule.
+
+- Making API calls outside the context of AutoScale, such as destroyVM,
+ on an autoscaled VM leaves the load balancing configuration in an
+ inconsistent state. Though VM is destroyed from the load balancer
+ rule, NetScaler continues to show the VM as a service assigned to a
+ rule.
+
+
+.. |autoscaleateconfig.png| image:: /_static/images/autoscale-config.png
+ :alt: Configuring AutoScale.
+.. |EnableDisable.png| image:: /_static/images/enable-disable-autoscale.png
+ :alt: button to enable or disable AutoScale.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/global_server_load_balancing.rst
----------------------------------------------------------------------
diff --git a/source/networking/global_server_load_balancing.rst b/source/networking/global_server_load_balancing.rst
new file mode 100644
index 0000000..3d88f4d
--- /dev/null
+++ b/source/networking/global_server_load_balancing.rst
@@ -0,0 +1,453 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+Global Server Load Balancing Support
+------------------------------------
+
+CloudStack supports Global Server Load Balancing (GSLB) functionalities
+to provide business continuity, and enable seamless resource movement
+within a CloudStack environment. CloudStack achieve this by extending
+its functionality of integrating with NetScaler Application Delivery
+Controller (ADC), which also provides various GSLB capabilities, such as
+disaster recovery and load balancing. The DNS redirection technique is
+used to achieve GSLB in CloudStack.
+
+In order to support this functionality, region level services and
+service provider are introduced. A new service 'GSLB' is introduced as a
+region level service. The GSLB service provider is introduced that will
+provider the GSLB service. Currently, NetScaler is the supported GSLB
+provider in CloudStack. GSLB functionality works in an Active-Active
+data center environment.
+
+
+About Global Server Load Balancing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Global Server Load Balancing (GSLB) is an extension of load balancing
+functionality, which is highly efficient in avoiding downtime. Based on
+the nature of deployment, GSLB represents a set of technologies that is
+used for various purposes, such as load sharing, disaster recovery,
+performance, and legal obligations. With GSLB, workloads can be
+distributed across multiple data centers situated at geographically
+separated locations. GSLB can also provide an alternate location for
+accessing a resource in the event of a failure, or to provide a means of
+shifting traffic easily to simplify maintenance, or both.
+
+
+Components of GSLB
+^^^^^^^^^^^^^^^^^^
+
+A typical GSLB environment is comprised of the following components:
+
+- **GSLB Site**: In CloudStack terminology, GSLB sites are represented
+ by zones that are mapped to data centers, each of which has various
+ network appliances. Each GSLB site is managed by a NetScaler
+ appliance that is local to that site. Each of these appliances treats
+ its own site as the local site and all other sites, managed by other
+ appliances, as remote sites. It is the central entity in a GSLB
+ deployment, and is represented by a name and an IP address.
+
+- **GSLB Services**: A GSLB service is typically represented by a load
+ balancing or content switching virtual server. In a GSLB environment,
+ you can have a local as well as remote GSLB services. A local GSLB
+ service represents a local load balancing or content switching
+ virtual server. A remote GSLB service is the one configured at one of
+ the other sites in the GSLB setup. At each site in the GSLB setup,
+ you can create one local GSLB service and any number of remote GSLB
+ services.
+
+- **GSLB Virtual Servers**: A GSLB virtual server refers to one or more
+ GSLB services and balances traffic between traffic across the VMs in
+ multiple zones by using the CloudStack functionality. It evaluates
+ the configured GSLB methods or algorithms to select a GSLB service to
+ which to send the client requests. One or more virtual servers from
+ different zones are bound to the GSLB virtual server. GSLB virtual
+ server does not have a public IP associated with it, instead it will
+ have a FQDN DNS name.
+
+- **Load Balancing or Content Switching Virtual Servers**: According to
+ Citrix NetScaler terminology, a load balancing or content switching
+ virtual server represents one or many servers on the local network.
+ Clients send their requests to the load balancing or content
+ switching virtual server's virtual IP (VIP) address, and the virtual
+ server balances the load across the local servers. After a GSLB
+ virtual server selects a GSLB service representing either a local or
+ a remote load balancing or content switching virtual server, the
+ client sends the request to that virtual server's VIP address.
+
+- **DNS VIPs**: DNS virtual IP represents a load balancing DNS virtual
+ server on the GSLB service provider. The DNS requests for domains for
+ which the GSLB service provider is authoritative can be sent to a DNS
+ VIP.
+
+- **Authoritative DNS**: ADNS (Authoritative Domain Name Server) is a
+ service that provides actual answer to DNS queries, such as web site
+ IP address. In a GSLB environment, an ADNS service responds only to
+ DNS requests for domains for which the GSLB service provider is
+ authoritative. When an ADNS service is configured, the service
+ provider owns that IP address and advertises it. When you create an
+ ADNS service, the NetScaler responds to DNS queries on the configured
+ ADNS service IP and port.
+
+
+How Does GSLB Works in CloudStack?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Global server load balancing is used to manage the traffic flow to a web
+site hosted on two separate zones that ideally are in different
+geographic locations. The following is an illustration of how GLSB
+functionality is provided in CloudStack: An organization, xyztelco, has
+set up a public cloud that spans two zones, Zone-1 and Zone-2, across
+geographically separated data centers that are managed by CloudStack.
+Tenant-A of the cloud launches a highly available solution by using
+xyztelco cloud. For that purpose, they launch two instances each in both
+the zones: VM1 and VM2 in Zone-1 and VM5 and VM6 in Zone-2. Tenant-A
+acquires a public IP, IP-1 in Zone-1, and configures a load balancer
+rule to load balance the traffic between VM1 and VM2 instances.
+CloudStack orchestrates setting up a virtual server on the LB service
+provider in Zone-1. Virtual server 1 that is set up on the LB service
+provider in Zone-1 represents a publicly accessible virtual server that
+client reaches at IP-1. The client traffic to virtual server 1 at IP-1
+will be load balanced across VM1 and VM2 instances.
+
+Tenant-A acquires another public IP, IP-2 in Zone-2 and sets up a load
+balancer rule to load balance the traffic between VM5 and VM6 instances.
+Similarly in Zone-2, CloudStack orchestrates setting up a virtual server
+on the LB service provider. Virtual server 2 that is setup on the LB
+service provider in Zone-2 represents a publicly accessible virtual
+server that client reaches at IP-2. The client traffic that reaches
+virtual server 2 at IP-2 is load balanced across VM5 and VM6 instances.
+At this point Tenant-A has the service enabled in both the zones, but
+has no means to set up a disaster recovery plan if one of the zone
+fails. Additionally, there is no way for Tenant-A to load balance the
+traffic intelligently to one of the zones based on load, proximity and
+so on. The cloud administrator of xyztelco provisions a GSLB service
+provider to both the zones. A GSLB provider is typically an ADC that has
+the ability to act as an ADNS (Authoritative Domain Name Server) and has
+the mechanism to monitor health of virtual servers both at local and
+remote sites. The cloud admin enables GSLB as a service to the tenants
+that use zones 1 and 2.
+
+|gslb.png|
+
+Tenant-A wishes to leverage the GSLB service provided by the xyztelco
+cloud. Tenant-A configures a GSLB rule to load balance traffic across
+virtual server 1 at Zone-1 and virtual server 2 at Zone-2. The domain
+name is provided as A.xyztelco.com. CloudStack orchestrates setting up
+GSLB virtual server 1 on the GSLB service provider at Zone-1. CloudStack
+binds virtual server 1 of Zone-1 and virtual server 2 of Zone-2 to GLSB
+virtual server 1. GSLB virtual server 1 is configured to start
+monitoring the health of virtual server 1 and 2 in Zone-1. CloudStack
+will also orchestrate setting up GSLB virtual server 2 on GSLB service
+provider at Zone-2. CloudStack will bind virtual server 1 of Zone-1 and
+virtual server 2 of Zone-2 to GLSB virtual server 2. GSLB virtual server
+2 is configured to start monitoring the health of virtual server 1 and
+2. CloudStack will bind the domain A.xyztelco.com to both the GSLB
+virtual server 1 and 2. At this point, Tenant-A service will be globally
+reachable at A.xyztelco.com. The private DNS server for the domain
+xyztelcom.com is configured by the admin out-of-band to resolve the
+domain A.xyztelco.com to the GSLB providers at both the zones, which are
+configured as ADNS for the domain A.xyztelco.com. A client when sends a
+DNS request to resolve A.xyztelcom.com, will eventually get DNS
+delegation to the address of GSLB providers at zone 1 and 2. A client
+DNS request will be received by the GSLB provider. The GSLB provider,
+depending on the domain for which it needs to resolve, will pick up the
+GSLB virtual server associated with the domain. Depending on the health
+of the virtual servers being load balanced, DNS request for the domain
+will be resolved to the public IP associated with the selected virtual
+server.
+
+
+Configuring GSLB
+~~~~~~~~~~~~~~~~
+
+To configure a GSLB deployment, you must first configure a standard load
+balancing setup for each zone. This enables you to balance load across
+the different servers in each zone in the region. Then on the NetScaler
+side, configure both NetScaler appliances that you plan to add to each
+zone as authoritative DNS (ADNS) servers. Next, create a GSLB site for
+each zone, configure GSLB virtual servers for each site, create GLSB
+services, and bind the GSLB services to the GSLB virtual servers.
+Finally, bind the domain to the GSLB virtual servers. The GSLB
+configurations on the two appliances at the two different zones are
+identical, although each sites load-balancing configuration is specific
+to that site.
+
+Perform the following as a cloud administrator. As per the example given
+above, the administrator of xyztelco is the one who sets up GSLB:
+
+#. In the cloud.dns.name global parameter, specify the DNS name of your
+ tenant's cloud that make use of the GSLB service.
+
+#. On the NetScaler side, configure GSLB as given in `Configuring Global
+ Server Load Balancing
+ (GSLB) <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-con.html>`_:
+
+ #. Configuring a standard load balancing setup.
+
+ #. Configure Authoritative DNS, as explained in `Configuring an
+ Authoritative DNS
+ Service <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-adns-svc-tsk.html>`_.
+
+ #. Configure a GSLB site with site name formed from the domain name
+ details.
+
+ Configure a GSLB site with the site name formed from the domain
+ name.
+
+ As per the example given above, the site names are A.xyztelco.com
+ and B.xyztelco.com.
+
+ For more information, see `Configuring a Basic GSLB
+ Site <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-basic-site-tsk.html>`_.
+
+ #. Configure a GSLB virtual server.
+
+ For more information, see `Configuring a GSLB Virtual
+ Server <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-vsvr-tsk.html>`_.
+
+ #. Configure a GSLB service for each virtual server.
+
+ For more information, see `Configuring a GSLB
+ Service <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-config-svc-tsk.html>`_.
+
+ #. Bind the GSLB services to the GSLB virtual server.
+
+ For more information, see `Binding GSLB Services to a GSLB Virtual
+ Server <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-bind-svc-vsvr-tsk.html>`_.
+
+ #. Bind domain name to GSLB virtual server. Domain name is obtained
+ from the domain details.
+
+ For more information, see `Binding a Domain to a GSLB Virtual
+ Server <http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-gslb-bind-dom-vsvr-tsk.html>`_.
+
+#. In each zone that are participating in GSLB, add GSLB-enabled
+ NetScaler device.
+
+ For more information, see :ref:`enabling-gslb-in-ns`.
+
+As a domain administrator/ user perform the following:
+
+#. Add a GSLB rule on both the sites.
+
+ See ":ref:`adding-gslb-rule`".
+
+#. Assign load balancer rules.
+
+ See ":ref:`assigning-lb-rule-gslb`".
+
+
+Prerequisites and Guidelines
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- The GSLB functionality is supported both Basic and Advanced zones.
+
+- GSLB is added as a new network service.
+
+- GSLB service provider can be added to a physical network in a zone.
+
+- The admin is allowed to enable or disable GSLB functionality at
+ region level.
+
+- The admin is allowed to configure a zone as GSLB capable or enabled.
+
+ A zone shall be considered as GSLB capable only if a GSLB service
+ provider is provisioned in the zone.
+
+- When users have VMs deployed in multiple availability zones which are
+ GSLB enabled, they can use the GSLB functionality to load balance
+ traffic across the VMs in multiple zones.
+
+- The users can use GSLB to load balance across the VMs across zones in
+ a region only if the admin has enabled GSLB in that region.
+
+- The users can load balance traffic across the availability zones in
+ the same region or different regions.
+
+- The admin can configure DNS name for the entire cloud.
+
+- The users can specify an unique name across the cloud for a globally
+ load balanced service. The provided name is used as the domain name
+ under the DNS name associated with the cloud.
+
+ The user-provided name along with the admin-provided DNS name is used
+ to produce a globally resolvable FQDN for the globally load balanced
+ service of the user. For example, if the admin has configured
+ xyztelco.com as the DNS name for the cloud, and user specifies 'foo'
+ for the GSLB virtual service, then the FQDN name of the GSLB virtual
+ service is foo.xyztelco.com.
+
+- While setting up GSLB, users can select a load balancing method, such
+ as round robin, for using across the zones that are part of GSLB.
+
+- The user shall be able to set weight to zone-level virtual server.
+ Weight shall be considered by the load balancing method for
+ distributing the traffic.
+
+- The GSLB functionality shall support session persistence, where
+ series of client requests for particular domain name is sent to a
+ virtual server on the same zone.
+
+ Statistics is collected from each GSLB virtual server.
+
+
+.. _enabling-gslb-in-ns:
+
+Enabling GSLB in NetScaler
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In each zone, add GSLB-enabled NetScaler device for load balancing.
+
+#. Log in as administrator to the CloudStack UI.
+
+#. In the left navigation bar, click Infrastructure.
+
+#. In Zones, click View More.
+
+#. Choose the zone you want to work with.
+
+#. Click the Physical Network tab, then click the name of the physical
+ network.
+
+#. In the Network Service Providers node of the diagram, click
+ Configure.
+
+ You might have to scroll down to see this.
+
+#. Click NetScaler.
+
+#. Click Add NetScaler device and provide the following:
+
+ For NetScaler:
+
+ - **IP Address**: The IP address of the SDX.
+
+ - **Username/Password**: The authentication credentials to access
+ the device. CloudStack uses these credentials to access the
+ device.
+
+ - **Type**: The type of device that is being added. It could be F5
+ Big Ip Load Balancer, NetScaler VPX, NetScaler MPX, or NetScaler
+ SDX. For a comparison of the NetScaler types, see the CloudStack
+ Administration Guide.
+
+ - **Public interface**: Interface of device that is configured to be
+ part of the public network.
+
+ - **Private interface**: Interface of device that is configured to
+ be part of the private network.
+
+ - **GSLB service**: Select this option.
+
+ - **GSLB service Public IP**: The public IP address of the NAT
+ translator for a GSLB service that is on a private network.
+
+ - **GSLB service Private IP**: The private IP of the GSLB service.
+
+ - **Number of Retries**. Number of times to attempt a command on the
+ device before considering the operation failed. Default is 2.
+
+ - **Capacity**: The number of networks the device can handle.
+
+ - **Dedicated**: When marked as dedicated, this device will be
+ dedicated to a single account. When Dedicated is checked, the
+ value in the Capacity field has no significance implicitly, its
+ value is 1.
+
+#. Click OK.
+
+
+.. _adding-gslb-rule:
+
+Adding a GSLB Rule
+^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as a domain administrator or user.
+
+#. In the left navigation pane, click Region.
+
+#. Select the region for which you want to create a GSLB rule.
+
+#. In the Details tab, click View GSLB.
+
+#. Click Add GSLB.
+
+ The Add GSLB page is displayed as follows:
+
+ |gslb-add.png|
+
+#. Specify the following:
+
+ - **Name**: Name for the GSLB rule.
+
+ - **Description**: (Optional) A short description of the GSLB rule
+ that can be displayed to users.
+
+ - **GSLB Domain Name**: A preferred domain name for the service.
+
+ - **Algorithm**: (Optional) The algorithm to use to load balance the
+ traffic across the zones. The options are Round Robin, Least
+ Connection, and Proximity.
+
+ - **Service Type**: The transport protocol to use for GSLB. The
+ options are TCP and UDP.
+
+ - **Domain**: (Optional) The domain for which you want to create the
+ GSLB rule.
+
+ - **Account**: (Optional) The account on which you want to apply the
+ GSLB rule.
+
+#. Click OK to confirm.
+
+
+.. _assigning-lb-rule-gslb:
+
+Assigning Load Balancing Rules to GSLB
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as a domain administrator or user.
+
+#. In the left navigation pane, click Region.
+
+#. Select the region for which you want to create a GSLB rule.
+
+#. In the Details tab, click View GSLB.
+
+#. Select the desired GSLB.
+
+#. Click view assigned load balancing.
+
+#. Click assign more load balancing.
+
+#. Select the load balancing rule you have created for the zone.
+
+#. Click OK to confirm.
+
+
+Known Limitation
+~~~~~~~~~~~~~~~~
+
+Currently, CloudStack does not support orchestration of services across
+the zones. The notion of services and service providers in region are to
+be introduced.
+
+
+.. |gslb.png| image:: /_static/images/gslb.png
+ :alt: GSLB architecture
+.. |gslb-add.png| image:: /_static/images/add-gslb.png
+ :alt: adding a gslb rule.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/guest_ip_ranges.rst
----------------------------------------------------------------------
diff --git a/source/networking/guest_ip_ranges.rst b/source/networking/guest_ip_ranges.rst
new file mode 100644
index 0000000..d0edf78
--- /dev/null
+++ b/source/networking/guest_ip_ranges.rst
@@ -0,0 +1,29 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+Guest IP Ranges
+---------------
+
+The IP ranges for guest network traffic are set on a per-account basis
+by the user. This allows the users to configure their network in a
+fashion that will enable VPN linking between their guest network and
+their clients.
+
+In shared networks in Basic zone and Security Group-enabled Advanced
+networks, you will have the flexibility to add multiple guest IP ranges
+from different subnets. You can add or remove one IP range at a time.
+For more information, see `"About Multiple IP
+Ranges" <#about-multiple-ip-ranges>`_.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/guest_traffic.rst
----------------------------------------------------------------------
diff --git a/source/networking/guest_traffic.rst b/source/networking/guest_traffic.rst
new file mode 100644
index 0000000..51374d1
--- /dev/null
+++ b/source/networking/guest_traffic.rst
@@ -0,0 +1,50 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+Guest Traffic
+-------------
+
+A network can carry guest traffic only between VMs within one zone.
+Virtual machines in different zones cannot communicate with each other
+using their IP addresses; they must communicate with each other by
+routing through a public IP address.
+
+See a typical guest traffic setup given below:
+
+|guest-traffic-setup.png|
+
+Typically, the Management Server automatically creates a virtual router
+for each network. A virtual router is a special virtual machine that
+runs on the hosts. Each virtual router in an isolated network has three
+network interfaces. If multiple public VLAN is used, the router will
+have multiple public interfaces. Its eth0 interface serves as the
+gateway for the guest traffic and has the IP address of 10.1.1.1. Its
+eth1 interface is used by the system to configure the virtual router.
+Its eth2 interface is assigned a public IP address for public traffic.
+If multiple public VLAN is used, the router will have multiple public
+interfaces.
+
+The virtual router provides DHCP and will automatically assign an IP
+address for each guest VM within the IP range assigned for the network.
+The user can manually reconfigure guest VMs to assume different IP
+addresses.
+
+Source NAT is automatically configured in the virtual router to forward
+outbound traffic for all guest VMs
+
+
+.. |guest-traffic-setup.png| image:: /_static/images/guest-traffic-setup.png
+ :alt: Depicts a guest traffic setup
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/inter_vlan_routing.rst
----------------------------------------------------------------------
diff --git a/source/networking/inter_vlan_routing.rst b/source/networking/inter_vlan_routing.rst
new file mode 100644
index 0000000..fd651a8
--- /dev/null
+++ b/source/networking/inter_vlan_routing.rst
@@ -0,0 +1,96 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+About Inter-VLAN Routing (nTier Apps)
+-------------------------------------
+
+Inter-VLAN Routing (nTier Apps) is the capability to route network
+traffic between VLANs. This feature enables you to build Virtual Private
+Clouds (VPC), an isolated segment of your cloud, that can hold
+multi-tier applications. These tiers are deployed on different VLANs
+that can communicate with each other. You provision VLANs to the tiers
+your create, and VMs can be deployed on different tiers. The VLANs are
+connected to a virtual router, which facilitates communication between
+the VMs. In effect, you can segment VMs by means of VLANs into different
+networks that can host multi-tier applications, such as Web,
+Application, or Database. Such segmentation by means of VLANs logically
+separate application VMs for higher security and lower broadcasts, while
+remaining physically connected to the same device.
+
+This feature is supported on XenServer, KVM, and VMware hypervisors.
+
+The major advantages are:
+
+- The administrator can deploy a set of VLANs and allow users to deploy
+ VMs on these VLANs. A guest VLAN is randomly alloted to an account
+ from a pre-specified set of guest VLANs. All the VMs of a certain
+ tier of an account reside on the guest VLAN allotted to that account.
+
+ .. note::
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+- The administrator can allow users create their own VPC and deploy the
+ application. In this scenario, the VMs that belong to the account are
+ deployed on the VLANs allotted to that account.
+
+- Both administrators and users can create multiple VPCs. The guest
+ network NIC is plugged to the VPC virtual router when the first VM is
+ deployed in a tier.
+
+- The administrator can create the following gateways to send to or
+ receive traffic from the VMs:
+
+ - **VPN Gateway**: For more information, see `"Creating a VPN gateway for the
+ VPC" <#creating-a-vpn-gateway-for-the-vpc>`_.
+
+ - **Public Gateway**: The public gateway for a VPC is added to the
+ virtual router when the virtual router is created for VPC. The
+ public gateway is not exposed to the end users. You are not
+ allowed to list it, nor allowed to create any static routes.
+
+ - **Private Gateway**: For more information, see ":ref:`adding-priv-gw-vpc`".
+
+- Both administrators and users can create various possible
+ destinations-gateway combinations. However, only one gateway of each
+ type can be used in a deployment.
+
+ For example:
+
+ - **VLANs and Public Gateway**: For example, an application is
+ deployed in the cloud, and the Web application VMs communicate
+ with the Internet.
+
+ - **VLANs, VPN Gateway, and Public Gateway**: For example, an
+ application is deployed in the cloud; the Web application VMs
+ communicate with the Internet; and the database VMs communicate
+ with the on-premise devices.
+
+- The administrator can define Network Access Control List (ACL) on the
+ virtual router to filter the traffic among the VLANs or between the
+ Internet and a VLAN. You can define ACL based on CIDR, port range,
+ protocol, type code (if ICMP protocol is selected) and Ingress/Egress
+ type.
+
+The following figure shows the possible deployment scenarios of a
+Inter-VLAN setup:
+
+|mutltier.png|
+
+To set up a multi-tier Inter-VLAN deployment, see ":ref:`configuring-vpc`".
+
+
+.. |mutltier.png| image:: /_static/images/multi-tier-app.png
+ :alt: a multi-tier setup.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/ip_forwarding_and_firewalling.rst
----------------------------------------------------------------------
diff --git a/source/networking/ip_forwarding_and_firewalling.rst b/source/networking/ip_forwarding_and_firewalling.rst
new file mode 100644
index 0000000..0999eb7
--- /dev/null
+++ b/source/networking/ip_forwarding_and_firewalling.rst
@@ -0,0 +1,280 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+IP Forwarding and Firewalling
+-----------------------------
+
+By default, all incoming traffic to the public IP address is rejected.
+All outgoing traffic from the guests is also blocked by default.
+
+To allow outgoing traffic, follow the procedure in :ref:`egress-fw-rules`.
+
+To allow incoming traffic, users may set up firewall rules and/or port
+forwarding rules. For example, you can use a firewall rule to open a
+range of ports on the public IP address, such as 33 through 44. Then use
+port forwarding rules to direct traffic from individual ports within
+that range to specific ports on user VMs. For example, one port
+forwarding rule could route incoming traffic on the public IP's port 33
+to port 100 on one user VM's private IP.
+
+
+Firewall Rules
+~~~~~~~~~~~~~~
+
+By default, all incoming traffic to the public IP address is rejected by
+the firewall. To allow external traffic, you can open firewall ports by
+specifying firewall rules. You can optionally specify one or more CIDRs
+to filter the source IPs. This is useful when you want to allow only
+incoming requests from certain IP addresses.
+
+You cannot use firewall rules to open ports for an elastic IP address.
+When elastic IP is used, outside access is instead controlled through
+the use of security groups. See `"Adding a Security
+Group" <#adding-a-security-group>`_.
+
+In an advanced zone, you can also create egress firewall rules by using
+the virtual router. For more information, see ":ref:`egress-fw-rules`".
+
+Firewall rules can be created using the Firewall tab in the Management
+Server UI. This tab is not displayed by default when CloudStack is
+installed. To display the Firewall tab, the CloudStack administrator
+must set the global configuration parameter firewall.rule.ui.enabled to
+"true."
+
+To create a firewall rule:
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. Click the name of the network where you want to work with.
+
+#. Click View IP Addresses.
+
+#. Click the IP address you want to work with.
+
+#. Click the Configuration tab and fill in the following values.
+
+ - **Source CIDR**: (Optional) To accept only traffic from IP
+ addresses within a particular address block, enter a CIDR or a
+ comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave
+ empty to allow all CIDRs.
+
+ - **Protocol**: The communication protocol in use on the opened
+ port(s).
+
+ - **Start Port and End Port**: The port(s) you want to open on the
+ firewall. If you are opening a single port, use the same number in
+ both fields
+
+ - **ICMP Type and ICMP Code**: Used only if Protocol is set to ICMP.
+ Provide the type and code required by the ICMP protocol to fill
+ out the ICMP header. Refer to ICMP documentation for more details
+ if you are not sure what to enter
+
+#. Click Add.
+
+
+.. _egress-fw-rules:
+
+Egress Firewall Rules in an Advanced Zone
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The egress traffic originates from a private network to a public
+network, such as the Internet. By default, the egress traffic is blocked
+in default network offerings, so no outgoing traffic is allowed from a
+guest network to the Internet. However, you can control the egress
+traffic in an Advanced zone by creating egress firewall rules. When an
+egress firewall rule is applied, the traffic specific to the rule is
+allowed and the remaining traffic is blocked. When all the firewall
+rules are removed the default policy, Block, is applied.
+
+
+Prerequisites and Guidelines
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Consider the following scenarios to apply egress firewall rules:
+
+- Egress firewall rules are supported on Juniper SRX and virtual
+ router.
+
+- The egress firewall rules are not supported on shared networks.
+
+- Allow the egress traffic from specified source CIDR. The Source CIDR
+ is part of guest network CIDR.
+
+- Allow the egress traffic with protocol TCP,UDP,ICMP, or ALL.
+
+- Allow the egress traffic with protocol and destination port range.
+ The port range is specified for TCP, UDP or for ICMP type and code.
+
+- The default policy is Allow for the new network offerings, whereas on
+ upgrade existing network offerings with firewall service providers
+ will have the default egress policy Deny.
+
+
+Configuring an Egress Firewall Rule
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. In Select view, choose Guest networks, then click the Guest network
+ you want.
+
+#. To add an egress rule, click the Egress rules tab and fill out the
+ following fields to specify what type of traffic is allowed to be
+ sent out of VM instances in this guest network:
+
+ |egress-firewall-rule.png|
+
+ - **CIDR**: (Add by CIDR only) To send traffic only to the IP
+ addresses within a particular address block, enter a CIDR or a
+ comma-separated list of CIDRs. The CIDR is the base IP address of
+ the destination. For example, 192.168.0.0/22. To allow all CIDRs,
+ set to 0.0.0.0/0.
+
+ - **Protocol**: The networking protocol that VMs uses to send
+ outgoing traffic. The TCP and UDP protocols are typically used for
+ data exchange and end-user communications. The ICMP protocol is
+ typically used to send error messages or network monitoring data.
+
+ - **Start Port, End Port**: (TCP, UDP only) A range of listening
+ ports that are the destination for the outgoing traffic. If you
+ are opening a single port, use the same number in both fields.
+
+ - **ICMP Type, ICMP Code**: (ICMP only) The type of message and
+ error code that are sent.
+
+#. Click Add.
+
+
+Configuring the Default Egress Policy
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The default egress policy for Isolated guest network is configured by
+using Network offering. Use the create network offering option to
+determine whether the default policy should be block or allow all the
+traffic to the public network from a guest network. Use this network
+offering to create the network. If no policy is specified, by default
+all the traffic is allowed from the guest network that you create by
+using this network offering.
+
+You have two options: Allow and Deny.
+
+Allow
+'''''
+
+If you select Allow for a network offering, by default egress traffic is
+allowed. However, when an egress rule is configured for a guest network,
+rules are applied to block the specified traffic and rest are allowed.
+If no egress rules are configured for the network, egress traffic is
+accepted.
+
+Deny
+''''
+
+If you select Deny for a network offering, by default egress traffic for
+the guest network is blocked. However, when an egress rules is
+configured for a guest network, rules are applied to allow the specified
+traffic. While implementing a guest network, CloudStack adds the
+firewall egress rule specific to the default egress policy for the guest
+network.
+
+This feature is supported only on virtual router and Juniper SRX.
+
+#. Create a network offering with your desirable default egress policy:
+
+ #. Log in with admin privileges to the CloudStack UI.
+
+ #. In the left navigation bar, click Service Offerings.
+
+ #. In Select Offering, choose Network Offering.
+
+ #. Click Add Network Offering.
+
+ #. In the dialog, make necessary choices, including firewall
+ provider.
+
+ #. In the Default egress policy field, specify the behaviour.
+
+ #. Click OK.
+
+#. Create an isolated network by using this network offering.
+
+ Based on your selection, the network will have the egress public
+ traffic blocked or allowed.
+
+
+Port Forwarding
+~~~~~~~~~~~~~~~
+
+A port forward service is a set of port forwarding rules that define a
+policy. A port forward service is then applied to one or more guest VMs.
+The guest VM then has its inbound network access managed according to
+the policy defined by the port forwarding service. You can optionally
+specify one or more CIDRs to filter the source IPs. This is useful when
+you want to allow only incoming requests from certain IP addresses to be
+forwarded.
+
+A guest VM can be in any number of port forward services. Port forward
+services can be defined but have no members. If a guest VM is part of
+more than one network, port forwarding rules will function only if they
+are defined on the default network
+
+You cannot use port forwarding to open ports for an elastic IP address.
+When elastic IP is used, outside access is instead controlled through
+the use of security groups. See Security Groups.
+
+To set up port forwarding:
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. If you have not already done so, add a public IP address range to a
+ zone in CloudStack. See Adding a Zone and Pod in the Installation
+ Guide.
+
+#. Add one or more VM instances to CloudStack.
+
+#. In the left navigation bar, click Network.
+
+#. Click the name of the guest network where the VMs are running.
+
+#. Choose an existing IP address or acquire a new IP address. See
+ `"Acquiring a New IP Address" <#acquiring-a-new-ip-address>`_.
+ Click the name of the IP address in the list.
+
+#. Click the Configuration tab.
+
+#. In the Port Forwarding node of the diagram, click View All.
+
+#. Fill in the following:
+
+ - **Public Port**: The port to which public traffic will be
+ addressed on the IP address you acquired in the previous step.
+
+ - **Private Port**: The port on which the instance is listening for
+ forwarded public traffic.
+
+ - **Protocol**: The communication protocol in use between the two
+ ports
+
+#. Click Add.
+
+
+.. |egress-firewall-rule.png| image:: /_static/images/egress-firewall-rule.png
+ :alt: adding an egress firewall rule.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/source/networking/ip_load_balancing.rst
----------------------------------------------------------------------
diff --git a/source/networking/ip_load_balancing.rst b/source/networking/ip_load_balancing.rst
new file mode 100644
index 0000000..6d2edd9
--- /dev/null
+++ b/source/networking/ip_load_balancing.rst
@@ -0,0 +1,31 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information#
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+
+IP Load Balancing
+-----------------
+
+The user may choose to associate the same public IP for multiple guests.
+CloudStack implements a TCP-level load balancer with the following
+policies.
+
+- Round-robin
+
+- Least connection
+
+- Source IP
+
+This is similar to port forwarding but the destination may be multiple
+IP addresses.