cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From raj...@apache.org
Subject [08/40] git commit: split the networking2 file into multiple includes and renamed it to 'networking_and_traffic': This closes #11
Date Wed, 10 Sep 2014 06:39:17 GMT
split the networking2 file into multiple includes and renamed it to 'networking_and_traffic': This closes #11


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/commit/72a3a7c1
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/tree/72a3a7c1
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/diff/72a3a7c1

Branch: refs/heads/4.4
Commit: 72a3a7c109c7ef198dc1fe99d91a4dd2ff6791a7
Parents: 5a4a44d
Author: Will Stevens <wstevens@cloudops.com>
Authored: Fri May 16 17:35:52 2014 -0400
Committer: Sebastien Goasguen <runseb@gmail.com>
Committed: Sat May 17 09:35:01 2014 +0200

----------------------------------------------------------------------
 source/index.rst                                |    2 +-
 source/networking/acquiring_an_ip_address.rst   |   42 +
 source/networking/advanced_zone_config.rst      |  152 +
 source/networking/basic_zone_config.rst         |   24 +
 source/networking/dns_and_dhcp.rst              |   22 +
 source/networking/elastic_ips.rst               |  104 +
 .../external_firewalls_and_load_balancers.rst   |  661 ++
 .../networking/global_server_load_balancing.rst |  453 ++
 source/networking/guest_ip_ranges.rst           |   29 +
 source/networking/guest_traffic.rst             |   50 +
 source/networking/inter_vlan_routing.rst        |   96 +
 .../ip_forwarding_and_firewalling.rst           |  280 +
 source/networking/ip_load_balancing.rst         |   31 +
 .../ip_reservation_in_guest_networks.rst        |  125 +
 .../isolation_in_advanced_zone_with_vlan.rst    |  202 +
 source/networking/multiple_guest_networks.rst   |  207 +
 source/networking/multiple_ip_ranges.rst        |   43 +
 .../networking/multiple_ips_on_single_nic.rst   |   98 +
 .../multiple_subnets_in_shared_network.rst      |   99 +
 source/networking/networking_in_pod.rst         |   45 +
 source/networking/networking_in_zone.rst        |   34 +
 source/networking/palo_alto_config.rst          |  475 ++
 source/networking/persistent_networks.rst       |   94 +
 source/networking/portable_ips.rst              |  131 +
 .../public_ips_and_vlans_for_accounts.rst       |  154 +
 source/networking/releasing_an_ip_address.rst   |   38 +
 source/networking/remote_access_vpn.rst         |  696 ++
 source/networking/security_groups.rst           |  214 +
 source/networking/static_nat.rst                |   56 +
 .../networking/virtual_private_cloud_config.rst | 1438 ++++
 source/networking2.rst                          | 7033 ------------------
 source/networking_and_traffic.rst               |   82 +
 source/palo_alto_config.rst                     |  282 -
 source/systemvm.rst                             |    8 +-
 34 files changed, 6180 insertions(+), 7320 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/index.rst
----------------------------------------------------------------------
diff --git a/source/index.rst b/source/index.rst
index ddfa3bb..cc25dd4 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -114,7 +114,7 @@ Managing Networks and Traffic
 .. toctree::
    :maxdepth: 2
 
-   networking2
+   networking_and_traffic
 
 Managing the Cloud
 ------------------

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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/72a3a7c1/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.


Mime
View raw message