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

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/ip_reservation_in_guest_networks.rst
----------------------------------------------------------------------
diff --git a/source/networking/ip_reservation_in_guest_networks.rst 
b/source/networking/ip_reservation_in_guest_networks.rst
new file mode 100644
index 0000000..c8b8f38
--- /dev/null
+++ b/source/networking/ip_reservation_in_guest_networks.rst
@@ -0,0 +1,125 @@
+.. 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 Reservation in Isolated Guest Networks
+-----------------------------------------
+
+In isolated guest networks, a part of the guest IP address space can be
+reserved for non-CloudStack VMs or physical servers. To do so, you
+configure a range of Reserved IP addresses by specifying the CIDR when a
+guest network is in Implemented state. If your customers wish to have
+non-CloudStack controlled VMs or physical servers on the same network,
+they can share a part of the IP address space that is primarily provided
+to the guest network.
+
+In an Advanced zone, an IP address range or a CIDR is assigned to a
+network when the network is defined. The CloudStack virtual router acts
+as the DHCP server and uses CIDR for assigning IP addresses to the guest
+VMs. If you decide to reserve CIDR for non-CloudStack purposes, you can
+specify a part of the IP address range or the CIDR that should only be
+allocated by the DHCP service of the virtual router to the guest VMs
+created in CloudStack. The remaining IPs in that network are called
+Reserved IP Range. When IP reservation is configured, the administrator
+can add additional VMs or physical servers that are not part of
+CloudStack to the same network and assign them the Reserved IP
+addresses. CloudStack guest VMs cannot acquire IPs from the Reserved IP
+Range.
+
+
+IP Reservation Considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Consider the following before you reserve an IP range for non-CloudStack
+machines:
+
+-  IP Reservation is supported only in Isolated networks.
+
+-  IP Reservation can be applied only when the network is in Implemented
+   state.
+
+-  No IP Reservation is done by default.
+
+-  Guest VM CIDR you specify must be a subset of the network CIDR.
+
+-  Specify a valid Guest VM CIDR. IP Reservation is applied only if no
+   active IPs exist outside the Guest VM CIDR.
+
+   You cannot apply IP Reservation if any VM is alloted with an IP
+   address that is outside the Guest VM CIDR.
+
+-  To reset an existing IP Reservation, apply IP reservation by
+   specifying the value of network CIDR in the CIDR field.
+
+   For example, the following table describes three scenarios of guest
+   network creation:
+
+   ===== ============= ============== ======================================== 
========================================================
+   Case  CIDR          Network CIDR   Reserved IP Range for Non-CloudStack VMs 
Description
+   ===== ============= ============== ======================================== 
========================================================
+   1     10.1.1.0/24   None           None                                     
No IP Reservation.
+   2     10.1.1.0/26   10.1.1.0/24    10.1.1.64 to 10.1.1.254                  
IP Reservation configured by the UpdateNetwork API with
+                                                                               
guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR 
+                                                                               
field in the UI.
+   3     10.1.1.0/24   None           None                                     
Removing IP Reservation by the UpdateNetwork API with
+                                                                               
guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR 
+                                                                               
field in the UI.
+   ===== ============= ============== ======================================== 
========================================================
+
+
+Limitations
+~~~~~~~~~~~
+
+-  The IP Reservation is not supported if active IPs that are found
+   outside the Guest VM CIDR.
+
+-  Upgrading network offering which causes a change in CIDR (such as
+   upgrading an offering with no external devices to one with external
+   devices) IP Reservation becomes void if any. Reconfigure IP
+   Reservation in the new re-implemeted network.
+
+
+Best Practices
+~~~~~~~~~~~~~~
+
+Apply IP Reservation to the guest network as soon as the network state
+changes to Implemented. If you apply reservation soon after the first
+guest VM is deployed, lesser conflicts occurs while applying
+reservation.
+
+
+Reserving an IP Range
+~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. Click the name of the network you want to modify.
+
+#. In the Details tab, click Edit. |ip-edit-icon.png|
+
+   The CIDR field changes to editable one.
+
+#. In CIDR, specify the Guest VM CIDR.
+
+#. Click Apply.
+
+   Wait for the update to complete. The Network CIDR and the Reserved IP
+   Range are displayed on the Details page.
+
+
+.. |ip-edit-icon.png| image:: /_static/images/edit-icon.png
+   :alt: button to edit.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/isolation_in_advanced_zone_with_vlan.rst
----------------------------------------------------------------------
diff --git a/source/networking/isolation_in_advanced_zone_with_vlan.rst 
b/source/networking/isolation_in_advanced_zone_with_vlan.rst
new file mode 100644
index 0000000..61a4e57
--- /dev/null
+++ b/source/networking/isolation_in_advanced_zone_with_vlan.rst
@@ -0,0 +1,202 @@
+.. 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.
+   
+
+Isolation in Advanced Zone Using Private VLAN
+---------------------------------------------
+
+Isolation of guest traffic in shared networks can be achieved by using
+Private VLANs (PVLAN). PVLANs provide Layer 2 isolation between ports
+within the same VLAN. In a PVLAN-enabled shared network, a user VM
+cannot reach other user VM though they can reach the DHCP server and
+gateway, this would in turn allow users to control traffic within a
+network and help them deploy multiple applications without communication
+between application as well as prevent communication with other users'
+VMs.
+
+-  Isolate VMs in a shared networks by using Private VLANs.
+
+-  Supported on KVM, XenServer, and VMware hypervisors
+
+-  PVLAN-enabled shared network can be a part of multiple networks of a
+   guest VM.
+
+
+About Private VLAN
+~~~~~~~~~~~~~~~~~~
+
+In an Ethernet switch, a VLAN is a broadcast domain where hosts can
+establish direct communication with each another at Layer 2. Private
+VLAN is designed as an extension of VLAN standard to add further
+segmentation of the logical broadcast domain. A regular VLAN is a single
+broadcast domain, whereas a private VLAN partitions a larger VLAN
+broadcast domain into smaller sub-domains. A sub-domain is represented
+by a pair of VLANs: a Primary VLAN and a Secondary VLAN. The original
+VLAN that is being divided into smaller groups is called Primary, which
+implies that all VLAN pairs in a private VLAN share the same Primary
+VLAN. All the secondary VLANs exist only inside the Primary. Each
+Secondary VLAN has a specific VLAN ID associated to it, which
+differentiates one sub-domain from another.
+
+Three types of ports exist in a private VLAN domain, which essentially
+determine the behaviour of the participating hosts. Each ports will have
+its own unique set of rules, which regulate a connected host's ability
+to communicate with other connected host within the same private VLAN
+domain. Configure each host that is part of a PVLAN pair can be by using
+one of these three port designation:
+
+-  **Promiscuous**: A promiscuous port can communicate with all the
+   interfaces, including the community and isolated host ports that
+   belong to the secondary VLANs. In Promiscuous mode, hosts are
+   connected to promiscuous ports and are able to communicate directly
+   with resources on both primary and secondary VLAN. Routers, DHCP
+   servers, and other trusted devices are typically attached to
+   promiscuous ports.
+
+-  **Isolated VLANs**: The ports within an isolated VLAN cannot
+   communicate with each other at the layer-2 level. The hosts that are
+   connected to Isolated ports can directly communicate only with the
+   Promiscuous resources. If your customer device needs to have access
+   only to a gateway router, attach it to an isolated port.
+
+-  **Community VLANs**: The ports within a community VLAN can
+   communicate with each other and with the promiscuous ports, but they
+   cannot communicate with the ports in other communities at the layer-2
+   level. In a Community mode, direct communication is permitted only
+   with the hosts in the same community and those that are connected to
+   the Primary PVLAN in promiscuous mode. If your customer has two
+   devices that need to be isolated from other customers' devices, but
+   to be able to communicate among themselves, deploy them in community
+   ports.
+
+For further reading:
+
+-  `Understanding Private
+   VLANs 
<http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swpvlan.html#wp1038379>`_
+
+-  `Cisco Systems' Private VLANs: Scalable Security in a Multi-Client
+   Environment <http://tools.ietf.org/html/rfc5517>`_
+
+-  `Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept
+   Overview (1010691) <http://kb.vmware.com>`_
+
+
+Prerequisites
+~~~~~~~~~~~~~
+
+-  Use a PVLAN supported switch.
+
+   See `Private VLAN Catalyst Switch Support
+   Matrix 
<http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a0080094830.shtml>`_
 for
+   more information.
+
+-  All the layer 2 switches, which are PVLAN-aware, are connected to
+   each other, and one of them is connected to a router. All the ports
+   connected to the host would be configured in trunk mode. Open
+   Management VLAN, Primary VLAN (public) and Secondary Isolated VLAN
+   ports. Configure the switch port connected to the router in PVLAN
+   promiscuous trunk mode, which would translate an isolated VLAN to
+   primary VLAN for the PVLAN-unaware router.
+
+   Note that only Cisco Catalyst 4500 has the PVLAN promiscuous trunk
+   mode to connect both normal VLAN and PVLAN to a PVLAN-unaware switch.
+   For the other Catalyst PVLAN support switch, connect the switch to
+   upper switch by using cables, one each for a PVLAN pair.
+
+-  Configure private VLAN on your physical switches out-of-band.
+
+-  Before you use PVLAN on XenServer and KVM, enable Open vSwitch (OVS).
+
+   .. note:: 
+      OVS on XenServer and KVM does not support PVLAN natively. Therefore,
+      CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by
+      modifying the flow table.
+
+
+Creating a PVLAN-Enabled 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.
+
+   -  **Secondary Isolated VLAN ID**: The unique ID of the Secondary
+      Isolated VLAN.
+
+      For the description on Secondary Isolated VLAN, see
+      `About Private VLAN" <#about-private-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.
+
+   -  **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.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/multiple_guest_networks.rst
----------------------------------------------------------------------
diff --git a/source/networking/multiple_guest_networks.rst 
b/source/networking/multiple_guest_networks.rst
new file mode 100644
index 0000000..dd90f66
--- /dev/null
+++ b/source/networking/multiple_guest_networks.rst
@@ -0,0 +1,207 @@
+.. 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.
+
+
+Using Multiple Guest Networks
+-----------------------------
+
+In zones that use advanced networking, additional networks for guest
+traffic may be added at any time after the initial installation. You can
+also customize the domain name associated with the network by specifying
+a DNS suffix for each network.
+
+A VM's networks are defined at VM creation time. A VM cannot add or
+remove networks after it has been created, although the user can go into
+the guest and remove the IP address from the NIC on a particular
+network.
+
+Each VM has just one default network. The virtual router's DHCP reply
+will set the guest's default gateway as that for the default network.
+Multiple non-default networks may be added to a guest in addition to the
+single, required default network. The administrator can control which
+networks are available as the default network.
+
+Additional networks can either be available to all accounts or be
+assigned to a specific account. Networks that are available to all
+accounts are zone-wide. Any user with access to the zone can create a VM
+with access to that network. These zone-wide networks provide little or
+no isolation between guests.Networks that are assigned to a specific
+account provide strong isolation.
+
+
+Adding an Additional Guest Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Network.
+
+#. Click Add guest network. 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 name of the zone this network applies to. Each zone
+      is a broadcast domain, and therefore each zone has a different IP
+      range for the guest network. The administrator must configure the
+      IP range for each zone.
+
+   -  **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 Create.
+
+
+Reconfiguring Networks in VMs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack provides you the ability to move VMs between networks and
+reconfigure a VM's network. You can remove a VM from a network and add
+to a new network. You can also change the default network of a virtual
+machine. With this functionality, hybrid or traditional server loads can
+be accommodated with ease.
+
+This feature is supported on XenServer, VMware, and KVM hypervisors.
+
+
+Prerequisites
+^^^^^^^^^^^^^
+
+Ensure that vm-tools are running on guest VMs for adding or removing
+networks to work on VMware hypervisor.
+
+
+Adding a Network
+^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, click Instances.
+
+#. Choose the VM that you want to work with.
+
+#. Click the NICs tab.
+
+#. Click Add network to VM.
+
+   The Add network to VM dialog is displayed.
+
+#. In the drop-down list, select the network that you would like to add
+   this VM to.
+
+   A new NIC is added for this network. You can view the following
+   details in the NICs page:
+
+   -  ID
+
+   -  Network Name
+
+   -  Type
+
+   -  IP Address
+
+   -  Gateway
+
+   -  Netmask
+
+   -  Is default
+
+   -  CIDR (for IPv6)
+
+
+Removing a Network
+^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, click Instances.
+
+#. Choose the VM that you want to work with.
+
+#. Click the NICs tab.
+
+#. Locate the NIC you want to remove.
+
+#. Click Remove NIC button. |remove-nic.png|
+
+#. Click Yes to confirm.
+
+
+Selecting the Default Network
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, click Instances.
+
+#. Choose the VM that you want to work with.
+
+#. Click the NICs tab.
+
+#. Locate the NIC you want to work with.
+
+#. Click the Set default NIC button. |set-default-nic.png|.
+
+#. Click Yes to confirm.
+
+Changing the Network Offering on a Guest Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A user or administrator can change the network offering that is
+associated with an existing guest network.
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. If you are changing from a network offering that uses the CloudStack
+   virtual router to one that uses external devices as network service
+   providers, you must first stop all the VMs on the network.
+
+#. In the left navigation, choose Network.
+
+#. Click the name of the network you want to modify.
+
+#. In the Details tab, click Edit. |edit-icon.png|
+
+#. In Network Offering, choose the new network offering, then click
+   Apply.
+
+   A prompt is displayed asking whether you want to keep the existing
+   CIDR. This is to let you know that if you change the network
+   offering, the CIDR will be affected.
+
+   If you upgrade between virtual router as a provider and an external
+   network device as provider, acknowledge the change of CIDR to
+   continue, so choose Yes.
+
+#. Wait for the update to complete. Don't try to restart VMs until the
+   network change is complete.
+
+#. If you stopped any VMs, restart them.
+
+
+.. |remove-nic.png| image:: /_static/images/remove-nic.png
+   :alt: button to remove a NIC.
+.. |set-default-nic.png| image:: /_static/images/set-default-nic.png
+   :alt: button to set a NIC as default one.
+.. |edit-icon.png| image:: /_static/images/edit-icon.png
+   :alt: button to edit.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/multiple_ip_ranges.rst
----------------------------------------------------------------------
diff --git a/source/networking/multiple_ip_ranges.rst 
b/source/networking/multiple_ip_ranges.rst
new file mode 100644
index 0000000..2833c60
--- /dev/null
+++ b/source/networking/multiple_ip_ranges.rst
@@ -0,0 +1,43 @@
+.. 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 Multiple IP Ranges
+------------------------
+
+.. note:: The feature can only be implemented on IPv4 addresses.
+
+CloudStack provides you with the flexibility to add guest IP ranges from
+different subnets in Basic zones and security groups-enabled Advanced
+zones. For security groups-enabled Advanced zones, it implies multiple
+subnets can be added to the same VLAN. With the addition of this
+feature, you will be able to add IP address ranges from the same subnet
+or from a different one when IP address are exhausted. This would in
+turn allows you to employ higher number of subnets and thus reduce the
+address management overhead. To support this feature, the capability of
+``createVlanIpRange`` API is extended to add IP ranges also from a
+different subnet.
+
+Ensure that you manually configure the gateway of the new subnet before
+adding the IP range. Note that CloudStack supports only one gateway for
+a subnet; overlapping subnets are not currently supported.
+
+Use the ``deleteVlanRange`` API to delete IP ranges. This operation
+fails if an IP from the remove range is in use. If the remove range
+contains the IP address on which the DHCP server is running, CloudStack
+acquires a new IP from the same subnet. If no IP is available in the
+subnet, the remove operation fails.
+
+This feature is supported on KVM, xenServer, and VMware hypervisors.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/multiple_ips_on_single_nic.rst
----------------------------------------------------------------------
diff --git a/source/networking/multiple_ips_on_single_nic.rst 
b/source/networking/multiple_ips_on_single_nic.rst
new file mode 100644
index 0000000..b67109a
--- /dev/null
+++ b/source/networking/multiple_ips_on_single_nic.rst
@@ -0,0 +1,98 @@
+.. 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.
+
+
+Configuring Multiple IP Addresses on a Single NIC
+-------------------------------------------------
+
+CloudStack provides you the ability to associate multiple private IP
+addresses per guest VM NIC. In addition to the primary IP, you can
+assign additional IPs to the guest VM NIC. This feature is supported on
+all the network configurations: Basic, Advanced, and VPC. Security
+Groups, Static NAT and Port forwarding services are supported on these
+additional IPs.
+
+As always, you can specify an IP from the guest subnet; if not
+specified, an IP is automatically picked up from the guest VM subnet.
+You can view the IPs associated with for each guest VM NICs on the UI.
+You can apply NAT on these additional guest IPs by using network
+configuration option in the CloudStack UI. You must specify the NIC to
+which the IP should be associated.
+
+This feature is supported on XenServer, KVM, and VMware hypervisors.
+Note that Basic zone security groups are not supported on VMware.
+
+
+Use Cases
+~~~~~~~~~
+
+Some of the use cases are described below:
+
+-  Network devices, such as firewalls and load balancers, generally work
+   best when they have access to multiple IP addresses on the network
+   interface.
+
+-  Moving private IP addresses between interfaces or instances.
+   Applications that are bound to specific IP addresses can be moved
+   between instances.
+
+-  Hosting multiple SSL Websites on a single instance. You can install
+   multiple SSL certificates on a single instance, each associated with
+   a distinct IP address.
+
+
+Guidelines
+~~~~~~~~~~
+
+To prevent IP conflict, configure different subnets when multiple
+networks are connected to the same VM.
+
+
+Assigning Additional IPs to a VM
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI.
+
+#. In the left navigation bar, click Instances.
+
+#. Click the name of the instance you want to work with.
+
+#. In the Details tab, click NICs.
+
+#. Click View Secondary IPs.
+
+#. Click Acquire New Secondary IP, and click Yes in the confirmation
+   dialog.
+
+   You need to configure the IP on the guest VM NIC manually. CloudStack
+   will not automatically configure the acquired IP address on the VM.
+   Ensure that the IP address configuration persist on VM reboot.
+
+   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
+   StaticNAT rules.
+
+
+Port Forwarding and StaticNAT Services Changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Because multiple IPs can be associated per NIC, you are allowed to
+select a desired IP for the Port Forwarding and StaticNAT services. The
+default is the primary IP. To enable this functionality, an extra
+optional parameter 'vmguestip' is added to the Port forwarding and
+StaticNAT APIs (enableStaticNat, createIpForwardingRule) to indicate on
+what IP address NAT need to be configured. If vmguestip is passed, NAT
+is configured on the specified private IP of the VM. if not passed, NAT
+is configured on the primary IP of the VM.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/multiple_subnets_in_shared_network.rst
----------------------------------------------------------------------
diff --git a/source/networking/multiple_subnets_in_shared_network.rst 
b/source/networking/multiple_subnets_in_shared_network.rst
new file mode 100644
index 0000000..53b30bb
--- /dev/null
+++ b/source/networking/multiple_subnets_in_shared_network.rst
@@ -0,0 +1,99 @@
+.. 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.
+   
+
+Multiple Subnets in Shared Network
+----------------------------------
+
+CloudStack provides you with the flexibility to add guest IP ranges from
+different subnets in Basic zones and security groups-enabled Advanced
+zones. For security groups-enabled Advanced zones, it implies multiple
+subnets can be added to the same VLAN. With the addition of this
+feature, you will be able to add IP address ranges from the same subnet
+or from a different one when IP address are exhausted. This would in
+turn allows you to employ higher number of subnets and thus reduce the
+address management overhead. You can delete the IP ranges you have
+added.
+
+
+Prerequisites and Guidelines
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  This feature can only be implemented:
+
+   -  on IPv4 addresses
+
+   -  if virtual router is the DHCP provider
+
+   -  on KVM, xenServer, and VMware hypervisors
+
+-  Manually configure the gateway of the new subnet before adding the IP
+   range.
+
+-  CloudStack supports only one gateway for a subnet; overlapping
+   subnets are not currently supported
+
+
+Adding Multiple Subnets to a Shared Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, choose Infrastructure.
+
+#. On Zones, click View More, then click the zone to which you want to
+   work with..
+
+#. Click Physical Network.
+
+#. In the Guest node of the diagram, click Configure.
+
+#. Click Networks.
+
+#. Select the networks you want to work with.
+
+#. Click View IP Ranges.
+
+#. Click Add IP Range.
+
+   The Add IP Range dialog is displayed, as follows:
+
+   |add-ip-range.png|
+
+#. Specify the following:
+
+   All the fields are mandatory.
+
+   -  **Gateway**: The gateway for the tier you create. Ensure that the
+      gateway is within the Super CIDR range that you specified while
+      creating the VPC, and is not overlapped with the CIDR of any
+      existing tier within the VPC.
+
+   -  **Netmask**: The netmask for the tier you create.
+
+      For example, if the VPC CIDR is 10.0.0.0/16 and the network tier
+      CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the
+      netmask of the tier is 255.255.255.0.
+
+   -  **Start IP/ End IP**: A range of IP addresses that are accessible
+      from the Internet and will be allocated to guest VMs. Enter the
+      first and last IP addresses that define a range that CloudStack
+      can assign to guest VMs .
+
+#. Click OK.
+
+
+.. |add-ip-range.png| image:: /_static/images/add-ip-range.png
+   :alt: adding an IP range to a network.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/networking_in_pod.rst
----------------------------------------------------------------------
diff --git a/source/networking/networking_in_pod.rst 
b/source/networking/networking_in_pod.rst
new file mode 100644
index 0000000..b7305be
--- /dev/null
+++ b/source/networking/networking_in_pod.rst
@@ -0,0 +1,45 @@
+.. 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.
+
+
+Networking in a Pod
+-------------------
+
+The figure below illustrates network setup within a single pod. The
+hosts are connected to a pod-level switch. At a minimum, the hosts
+should have one physical uplink to each switch. Bonded NICs are
+supported as well. The pod-level switch is a pair of redundant gigabit
+switches with 10 G uplinks.
+
+|networksinglepod.png| 
+
+Servers are connected as follows:
+
+-  Storage devices are connected to only the network that carries
+   management traffic.
+
+-  Hosts are connected to networks for both management traffic and
+   public traffic.
+
+-  Hosts are also connected to one or more networks carrying guest
+   traffic.
+
+We recommend the use of multiple physical Ethernet cards to implement
+each network interface as well as redundant switch fabric in order to
+maximize throughput and improve reliability.
+
+
+.. |networksinglepod.png| image:: /_static/images/network-singlepod.png
+   :alt: diagram showing logical view of network in a pod.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/networking_in_zone.rst
----------------------------------------------------------------------
diff --git a/source/networking/networking_in_zone.rst 
b/source/networking/networking_in_zone.rst
new file mode 100644
index 0000000..ae6231d
--- /dev/null
+++ b/source/networking/networking_in_zone.rst
@@ -0,0 +1,34 @@
+.. 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.
+
+
+Networking in a Zone
+--------------------
+
+The following figure illustrates the network setup within a single zone.
+
+|networksetupzone.png|
+
+A firewall for management traffic operates in the NAT mode. The network
+typically is assigned IP addresses in the 192.168.0.0/16 Class B private
+address space. Each pod is assigned IP addresses in the 192.168.\*.0/24
+Class C private address space.
+
+Each zone has its own set of public IP addresses. Public IP addresses
+from different zones do not overlap.
+
+
+.. |networksetupzone.png| image:: /_static/images/network-setup-zone.png
+   :alt: Depicts 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/palo_alto_config.rst
----------------------------------------------------------------------
diff --git a/source/networking/palo_alto_config.rst 
b/source/networking/palo_alto_config.rst
new file mode 100644
index 0000000..456b3c2
--- /dev/null
+++ b/source/networking/palo_alto_config.rst
@@ -0,0 +1,475 @@
+.. 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.
+
+
+Setup a Palo Alto Networks Firewall
+-----------------------------------
+
+
+Functionality Provided
+~~~~~~~~~~~~~~~~~~~~~~
+
+This implementation enables the orchestration of a Palo Alto Networks Firewall 
+from within CloudStack UI and API.  
+
+**The following features are supported**:
+
+-  List/Add/Delete Palo Alto Networks service provider
+
+-  List/Add/Delete Palo Alto Networks network service offering
+
+-  List/Add/Delete Palo Alto Networks network using the above service offering
+
+-  Add an instance to a Palo Alto Networks network
+
+-  Source NAT management on network create and delete
+
+-  List/Add/Delete Ingress Firewall rule
+
+-  List/Add/Delete Egress Firewall rule (both 'Allow' and 'Deny' default rules 
+   supported)
+
+-  List/Add/Delete Port Forwarding rule
+
+-  List/Add/Delete Static NAT rule
+
+-  Apply a Threat Profile to all firewall rules (more details in the 
+   Additional Features section)
+
+-  Apply a Log Forwarding profile to all firewall rules (more details in the 
+   Additional Features section)
+
+
+
+Initial Palo Alto Networks Firewall Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Anatomy of the Palo Alto Networks Firewall
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+-  In **'Network > Interfaces'** there is a list of physical interfaces as 
+   well as aggregated physical interfaces which are used for managing traffic 
+   in and out of the Palo Alto Networks Firewall device.
+
+-  In **'Network > Zones'** there is a list of the different configuration 
+   zones.  This implementation will use two zones; a public (defaults to 
+   'untrust') and private (defaults to 'trust') zone.
+
+-  In **'Network > Virtual Routers'** there is a list of VRs which handle 
+   traffic routing for the Palo Alto Firewall.  We only use a single Virtual 
+   Router on the firewall and it is used to handle all the routing to the next 
+   network hop.
+
+-  In **'Objects > Security Profile Groups'** there is a list of profiles 
+   which can be applied to firewall rules.  These profiles are used to better 
+   understand the types of traffic that is flowing through your network.  
+   Configured when you add the firewall provider to CloudStack.
+
+-  In **'Objects > Log Forwarding'** there is a list of profiles which can be 
+   applied to firewall rules.  These profiles are used to better track the 
+   logs generated by the firewall.  Configured when you add the firewall 
+   provider to CloudStack.
+
+-  In **'Policies > Security'** there is a list of firewall rules that are 
+   currently configured.  You will not need to modify this section because it 
+   will be completely automated by CloudStack, but you can review the firewall 
+   rules which have been created here.
+
+-  In **'Policies > NAT'** there is a list of the different NAT rules.  You 
+   will not need to modify this section because it will be completely 
+   automated by CloudStack, but you can review the different NAT rules that 
+   have been created here.  Source NAT, Static NAT and Destination NAT (Port 
+   Forwarding) rules will show up in this list.
+
+
+
+Configure the Public / Private Zones on the firewall
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+No manual configuration is required to setup these zones because CloudStack 
+will configure them automatically when you add the Palo Alto Networks firewall 
+device to CloudStack as a service provider.  This implementation depends on 
+two zones, one for the public side and one for the private side of the 
+firewall.  
+
+-  The public zone (defaults to 'untrust') will contain all of the public 
+   interfaces and public IPs.
+
+-  The private zone (defaults to 'trust') will contain all of the private 
+   interfaces and guest network gateways.
+
+The NAT and firewall rules will be configured between these zones.
+
+
+
+Configure the Public / Private Interfaces on the firewall
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This implementation supports standard physical interfaces as well as grouped 
+physical interfaces called aggregated interfaces.  Both standard interfaces 
+and aggregated interfaces are treated the same, so they can be used 
+interchangeably. For this document, we will assume that we are using 
+'ethernet1/1' as the public interface and 'ethernet1/2' as the private 
+interface.  If aggregated interfaces where used, you would use something 
+like 'ae1' and 'ae2' as the interfaces.
+
+This implementation requires that the 'Interface Type' be set to 'Layer3' for 
+both the public and private interfaces.  If you want to be able to use the 
+'Untagged' VLAN tag for public traffic in CloudStack, you will need to enable 
+support for it in the public 'ethernet1/1' interface (details below).  
+
+**Steps to configure the Public Interface**:
+
+#. Log into Palo Alto Networks Firewall
+
+#. Navigate to 'Network > Interfaces'
+
+#. Click on 'ethernet1/1' (for aggregated ethernet, it will probably be called 
+   'ae1')
+
+#. Select 'Layer3' from the 'Interface Type' list
+
+#. Click 'Advanced'
+
+#. Check the 'Untagged Subinterface' check-box
+
+#. Click 'OK'
+
+**Steps to configure the Private Interface**:
+
+#. Click on 'ethernet1/2' (for aggregated ethernet, it will probably be called 
+   'ae2')
+
+#. Select 'Layer3' from the 'Interface Type' list
+
+#. Click 'OK'
+
+
+
+Configure a Virtual Router on the firewall
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The Virtual Router on the Palo Alto Networks Firewall is not to be confused 
+with the Virtual Routers that CloudStack provisions.  For this implementation, 
+the Virtual Router on the Palo Alto Networks Firewall will ONLY handle the 
+upstream routing from the Firewall to the next hop.
+
+**Steps to configure the Virtual Router**:
+
+#. Log into Palo Alto Networks Firewall
+
+#. Navigate to 'Network > Virtual Routers'
+
+#. Select the 'default' Virtual Router or Add a new Virtual Router if there 
+   are none in the list
+
+   - If you added a new Virtual Router, you will need to give it a 'Name'
+
+#. Navigate to 'Static Routes > IPv4'
+
+#. 'Add' a new static route
+
+   -  **Name**: next_hop (you can name it anything you want)
+   
+   -  **Destination**: 0.0.0.0/0 (send all traffic to this route)
+   
+   -  **Interface**: ethernet1/1 (or whatever you set your public interface 
+      as)
+   
+   -  **Next Hop**: (specify the gateway IP for the next hop in your network)
+   
+   -  Click 'OK'
+
+#. Click 'OK'
+
+
+
+Configure the default Public Subinterface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The current implementation of the Palo Alto Networks firewall integration uses 
+CIDRs in the form of 'w.x.y.z/32' for the public IP addresses that CloudStack 
+provisions.  Because no broadcast or gateway IPs are in this single IP range, 
+there is no way for the firewall to route the traffic for these IPs.  To route 
+the traffic for these IPs, we create a single subinterface on the public 
+interface with an IP and a CIDR which encapsulates the CloudStack public IP 
+range.  This IP will need to be inside the subnet defined by the CloudStack 
+public range netmask, but outside the CloudStack public IP range.  The CIDR 
+should reflect the same subnet defined by the CloudStack public range netmask. 
 
+The name of the subinterface is determined by the VLAN configured for the 
+public range in CloudStack.
+
+To clarify this concept, we will use the following example.
+
+**Example CloudStack Public Range Configuration**:
+
+-  **Gateway**: 172.30.0.1
+
+-  **Netmask**: 255.255.255.0
+
+-  **IP Range**: 172.30.0.100 - 172.30.0.199
+
+-  **VLAN**: Untagged
+
+**Configure the Public Subinterface**:
+
+#. Log into Palo Alto Networks Firewall
+
+#. Navigate to 'Network > Interfaces'
+
+#. Select the 'ethernet1/1' line (not clicking on the name)
+
+#. Click 'Add Subinterface' at the bottom of the window
+
+#. Enter 'Interface Name': 'ethernet1/1' . '9999' 
+
+   -  9999 is used if the CloudStack public range VLAN is 'Untagged'
+   
+   -  If the CloudStack public range VLAN is tagged (eg: 333), then the name 
+      will reflect that tag
+
+#. The 'Tag' is the VLAN tag that the traffic is sent to the next hop with, so 
+   set it accordingly.  If you are passing 'Untagged' traffic from CloudStack 
+   to your next hop, leave it blank.  If you want to pass tagged traffic from 
+   CloudStack, specify the tag.
+
+#. Select 'default' from the 'Config > Virtual Router' drop-down (assuming 
+   that is what your virtual router is called)
+
+#. Click the 'IPv4' tab
+
+#. Select 'Static' from the 'Type' radio options
+
+#. Click 'Add' in the 'IP' section
+
+#. Enter '172.30.0.254/24' in the new line
+
+   -  The IP can be any IP outside the CloudStack public IP range, but inside 
+      the CloudStack public range netmask (it can NOT be the gateway IP)
+   
+   -  The subnet defined by the CIDR should match the CloudStack public range 
+      netmask
+   
+#. Click 'OK'
+
+
+Commit configuration on the Palo Alto Networks Firewall
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In order for all the changes we just made to take effect, we need to commit 
+the changes.
+
+#. Click the 'Commit' link in the top right corner of the window
+
+#. Click 'OK' in the commit window overlay
+
+#. Click 'Close' to the resulting commit status window after the commit 
+   finishes
+
+
+
+Setup the Palo Alto Networks Firewall in CloudStack
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Add the Palo Alto Networks Firewall as a Service Provider
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+#. Navigate to 'Infrastructure > Zones > ZONE_NAME > Physical Network > 
+   NETWORK_NAME (guest) > Configure; Network Service Providers'
+
+#. Click on 'Palo Alto' in the list
+
+#. Click 'View Devices'
+
+#. Click 'Add Palo Alto Device'
+
+#. Enter your configuration in the overlay.  This example will reflect the 
+   details previously used in this guide.
+
+   -  **IP Address**: (the IP of the Palo Alto Networks Firewall)
+   
+   -  **Username**: (the admin username for the firewall)
+   
+   -  **Password**: (the admin password for the firewall)
+   
+   -  **Type**: Palo Alto Firewall
+   
+   -  **Public Interface**: ethernet1/1 (use what you setup earlier as the 
+      public interface if it is different from my examples)
+   
+   -  **Private Interface**: ethernet1/2 (use what you setup earlier as the 
+      private interface if it is different from my examples)
+   
+   -  **Number of Retries**: 2 (the default is fine)
+   
+   -  **Timeout**: 300 (the default is fine) 
+   
+   -  **Public Network**: untrust (this is the public zone on the firewall and 
+      did not need to be configured)
+   
+   -  **Private Network**: trust (this is the private zone on the firewall and 
+      did not need to be configured)
+   
+   -  **Virtual Router**: default (this is the name of the Virtual Router we 
+      setup on the firewall)
+   
+   -  **Palo Alto Threat Profile**: (not required.  name of the 'Security 
+      Profile Groups' to apply.  more details in the 'Additional Features' 
+      section)
+   
+   -  **Palo Alto Log Profile**: (not required.  name of the 'Log Forwarding' 
+      profile to apply.  more details in the 'Additional Features' section)
+   
+   -  **Capacity**: (not required) 
+   
+   -  **Dedicated**: (not required)
+
+#. Click 'OK'
+
+#. Click on 'Palo Alto' in the breadcrumbs to go back one screen.
+
+#. Click on 'Enable Provider' |EnableDisableFeature.png|
+
+
+Add a Network Service Offering to use the new Provider
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are 6 'Supported Services' that need to be configured in the network 
+service offering for this functionality.  They are DHCP, DNS, Firewall, Source 
+NAT, Static NAT and Port Forwarding.  For the other settings, there are 
+probably additional configurations which will work, but I will just document a 
+common case.
+
+#. Navigate to 'Service Offerings'
+
+#. In the drop-down at the top, select 'Network Offerings'
+
+#. Click 'Add Network Offering'
+
+   -  **Name**: (name it whatever you want)
+
+   -  **Description**: (again, can be whatever you want)
+
+   -  **Guest Type**: Isolated
+
+   -  **Supported Services**:
+
+      -  **DHCP**: Provided by 'VirtualRouter'
+
+      -  **DNS**: Provided by 'VirtualRouter'
+
+      -  **Firewall**: Provided by 'PaloAlto'
+
+      -  **Source NAT**: Provided by 'PaloAlto'
+
+      -  **Static NAT**: Provided by 'PaloAlto'
+
+      -  **Port Forwarding**: Provided by 'PaloAlto'
+
+   -  **System Offering for Router**: System Offering For Software Router
+
+   -  **Supported Source NAT Type**: Per account (this is the only supported 
+      option)
+
+   -  **Default egress policy**: (both 'Allow' and 'Deny' are supported)
+
+#. Click 'OK'
+
+#. Click on the newly created service offering
+
+#. Click 'Enable network offering' |EnableDisableFeature.png|
+
+When adding networks in CloudStack, select this network offering to use the 
+Palo Alto Networks firewall.
+
+
+Additional Features
+~~~~~~~~~~~~~~~~~~~
+
+In addition to the standard functionality exposed by CloudStack, we have added 
+a couple additional features to this implementation.  We did not add any new 
+screens to CloudStack, but we have added a couple fields to the 'Add Palo Alto 
+Service Provider' screen which will add functionality globally for the device.
+
+
+Palo Alto Networks Threat Profile
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This feature allows you to specify a 'Security Profile Group' to be applied to 
+all of the firewall rules which are created on the Palo Alto Networks firewall 
+device.
+
+To create a 'Security Profile Group' on the Palo Alto Networks firewall, do 
+the following: 
+
+#. Log into the Palo Alto Networks firewall
+
+#. Navigate to 'Objects > Security Profile Groups'
+
+#. Click 'Add' at the bottom of the page to add a new group
+
+#. Give the group a Name and specify the profiles you would like to include in 
+   the group
+
+#. Click 'OK'
+
+#. Click the 'Commit' link in the top right of the screen and follow the on 
+   screen instructions
+
+Once you have created a profile, you can reference it by Name in the 'Palo 
+Alto Threat Profile' field in the 'Add the Palo Alto Networks Firewall as a 
+Service Provider' step.
+
+
+Palo Alto Networks Log Forwarding Profile
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This feature allows you to specify a 'Log Forwarding' profile to better manage 
+where the firewall logs are sent to.  This is helpful for keeping track of 
+issues that can arise on the firewall.
+
+To create a 'Log Forwarding' profile on the Palo Alto Networks Firewall, do 
+the following: 
+
+#. Log into the Palo Alto Networks firewall
+
+#. Navigate to 'Objects > Log Forwarding'
+
+#. Click 'Add' at the bottom of the page to add a new profile
+
+#. Give the profile a Name and specify the details you want for the traffic 
+   and threat settings
+
+#. Click 'OK'
+
+#. Click the 'Commit' link in the top right of the screen and follow the on 
+   screen instructions
+
+Once you have created a profile, you can reference it by Name in the 'Palo 
+Alto Log Profile' field in the 'Add the Palo Alto Networks Firewall as a 
+Service Provider' step.
+
+
+
+Limitations
+~~~~~~~~~~~
+
+-  The implementation currently only supports a single public IP range in 
+   CloudStack
+   
+-  Usage tracking is not yet implemented
+
+.. |EnableDisableFeature.png| image:: 
/_static/images/enable-disable-autoscale.png
+   :alt: button to enable or disable feature.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/persistent_networks.rst
----------------------------------------------------------------------
diff --git a/source/networking/persistent_networks.rst 
b/source/networking/persistent_networks.rst
new file mode 100644
index 0000000..9aa15d5
--- /dev/null
+++ b/source/networking/persistent_networks.rst
@@ -0,0 +1,94 @@
+.. 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.
+   
+
+Persistent Networks
+-------------------
+
+The network that you can provision without having to deploy any VMs on
+it is called a persistent network. A persistent network can be part of a
+VPC or a non-VPC environment.
+
+When you create other types of network, a network is only a database
+entry until the first VM is created on that network. When the first VM
+is created, a VLAN ID is assigned and the network is provisioned. Also,
+when the last VM is destroyed, the VLAN ID is released and the network
+is no longer available. With the addition of persistent network, you
+will have the ability to create a network in CloudStack in which
+physical devices can be deployed without having to run any VMs.
+Additionally, you can deploy physical devices on that network.
+
+One of the advantages of having a persistent network is that you can
+create a VPC with a tier consisting of only physical devices. For
+example, you might create a VPC for a three-tier application, deploy VMs
+for Web and Application tier, and use physical machines for the Database
+tier. Another use case is that if you are providing services by using
+physical hardware, you can define the network as persistent and
+therefore even if all its VMs are destroyed the services will not be
+discontinued.
+
+
+Persistent Network Considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Persistent network is designed for isolated networks.
+
+-  All default network offerings are non-persistent.
+
+-  A network offering cannot be editable because changing it affects the
+   behavior of the existing networks that were created using this
+   network offering.
+
+-  When you create a guest network, the network offering that you select
+   defines the network persistence. This in turn depends on whether
+   persistent network is enabled in the selected network offering.
+
+-  An existing network can be made persistent by changing its network
+   offering to an offering that has the Persistent option enabled. While
+   setting this property, even if the network has no running VMs, the
+   network is provisioned.
+
+-  An existing network can be made non-persistent by changing its
+   network offering to an offering that has the Persistent option
+   disabled. If the network has no running VMs, during the next network
+   garbage collection run the network is shut down.
+
+-  When the last VM on a network is destroyed, the network garbage
+   collector checks if the network offering associated with the network
+   is persistent, and shuts down the network only if it is
+   non-persistent.
+
+
+Creating a Persistent Guest Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To create a persistent network, perform the following:
+
+#. Create a network offering with the Persistent option enabled.
+
+   See `"Creating a New Network Offering" 
+   <networking.html#creating-a-new-network-offering>`_.
+
+#. Select Network from the left navigation pane.
+
+#. Select the guest network that you want to offer this network service
+   to.
+
+#. Click the Edit button.
+
+#. From the Network Offering drop-down, select the persistent network
+   offering you have just created.
+
+#. Click OK.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/portable_ips.rst
----------------------------------------------------------------------
diff --git a/source/networking/portable_ips.rst 
b/source/networking/portable_ips.rst
new file mode 100644
index 0000000..7daed13
--- /dev/null
+++ b/source/networking/portable_ips.rst
@@ -0,0 +1,131 @@
+.. 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.
+   
+
+Portable IPs
+------------
+
+About Portable IP
+~~~~~~~~~~~~~~~~~
+
+Portable IPs in CloudStack are region-level pool of IPs, which are
+elastic in nature, that can be transferred across geographically
+separated zones. As an administrator, you can provision a pool of
+portable public IPs at region level and are available for user
+consumption. The users can acquire portable IPs if admin has provisioned
+portable IPs at the region level they are part of. These IPs can be use
+for any service within an advanced zone. You can also use portable IPs
+for EIP services in basic zones.
+
+The salient features of Portable IP are as follows:
+
+-  IP is statically allocated
+
+-  IP need not be associated with a network
+
+-  IP association is transferable across networks
+
+-  IP is transferable across both Basic and Advanced zones
+
+-  IP is transferable across VPC, non-VPC isolated and shared networks
+
+-  Portable IP transfer is available only for static NAT.
+
+
+Guidelines
+^^^^^^^^^^
+
+Before transferring to another network, ensure that no network rules
+(Firewall, Static NAT, Port Forwarding, and so on) exist on that
+portable IP.
+
+
+Configuring Portable IPs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as an administrator or end user.
+
+#. In the left navigation, click Regions.
+
+#. Choose the Regions that you want to work with.
+
+#. Click View Portable IP.
+
+#. Click Portable IP Range.
+
+   The Add Portable IP Range window is displayed.
+
+#. Specify the following:
+
+   -  **Start IP/ End IP**: A range of IP addresses that are accessible
+      from the Internet and will be allocated to guest VMs. Enter the
+      first and last IP addresses that define a range that CloudStack
+      can assign to guest VMs.
+
+   -  **Gateway**: The gateway in use for the Portable IP addresses you
+      are configuring.
+
+   -  **Netmask**: The netmask associated with the Portable IP range.
+
+   -  **VLAN**: The VLAN that will be used for public traffic.
+
+#. Click OK.
+
+
+Acquiring a Portable IP
+~~~~~~~~~~~~~~~~~~~~~~~
+
+#. 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.
+
+#. Click Yes in the confirmation dialog.
+
+   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.
+
+
+Transferring Portable IP
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+An IP can be transferred from one network to another only if Static NAT
+is enabled. However, when a portable IP is associated with a network,
+you can use it for any service in the network.
+
+To transfer a portable IP across the networks, execute the following
+API:
+
+.. code:: bash
+
+    
http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=a242c476-ef37-441e-9c7b-b303e2a9cb4f&networkid=6e7cd8d1-d1ba-4c35-bdaf-333354cbd49810
+
+Replace the UUID with appropriate UUID. For example, if you want to
+transfer a portable IP to network X and VM Y in a network, execute the
+following:
+
+.. code:: bash
+
+    
http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=Y&networkid=X

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/public_ips_and_vlans_for_accounts.rst
----------------------------------------------------------------------
diff --git a/source/networking/public_ips_and_vlans_for_accounts.rst 
b/source/networking/public_ips_and_vlans_for_accounts.rst
new file mode 100644
index 0000000..42a4640
--- /dev/null
+++ b/source/networking/public_ips_and_vlans_for_accounts.rst
@@ -0,0 +1,154 @@
+.. 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.
+
+
+Reserving Public IP Addresses and VLANs for Accounts
+----------------------------------------------------
+
+CloudStack provides you the ability to reserve a set of public IP
+addresses and VLANs exclusively for an account. During zone creation,
+you can continue defining a set of VLANs and multiple public IP ranges.
+This feature extends the functionality to enable you to dedicate a fixed
+set of VLANs and guest IP addresses for a tenant.
+
+Note that if an account has consumed all the VLANs and IPs dedicated to
+it, the account can acquire two more resources from the system.
+CloudStack provides the root admin with two configuration parameter to
+modify this default behavior: use.system.public.ips and
+use.system.guest.vlans. These global parameters enable the root admin to
+disallow an account from acquiring public IPs and guest VLANs from the
+system, if the account has dedicated resources and these dedicated
+resources have all been consumed. Both these configurations are
+configurable at the account level.
+
+This feature provides you the following capabilities:
+
+-  Reserve a VLAN range and public IP address range from an Advanced
+   zone and assign it to an account
+
+-  Disassociate a VLAN and public IP address range from an account
+
+-  View the number of public IP addresses allocated to an account
+
+-  Check whether the required range is available and is conforms to
+   account limits.
+
+   The maximum IPs per account limit cannot be superseded.
+
+
+Dedicating IP Address Ranges to an Account
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. Log in to the CloudStack UI as administrator.
+
+#. In the left navigation bar, click Infrastructure.
+
+#. In Zones, click View All.
+
+#. Choose the zone you want to work with.
+
+#. Click the Physical Network tab.
+
+#. In the Public node of the diagram, click Configure.
+
+#. Click the IP Ranges tab.
+
+   You can either assign an existing IP range to an account, or create a
+   new IP range and assign to an account.
+
+#. To assign an existing IP range to an account, perform the following:
+
+   #. Locate the IP range you want to work with.
+
+   #. Click Add Account |addAccount-icon.png| button.
+
+      The Add Account dialog is displayed.
+
+   #. Specify the following:
+
+      -  **Account**: The account to which you want to assign the IP
+         address range.
+
+      -  **Domain**: The domain associated with the account.
+
+      To create a new IP range and assign an account, perform the
+      following:
+
+      #. Specify the following:
+
+         -  **Gateway**
+
+         -  **Netmask**
+
+         -  **VLAN**
+
+         -  **Start IP**
+
+         -  **End IP**
+
+         -  **Account**: Perform the following:
+
+            #. Click Account.
+
+               The Add Account page is displayed.
+
+            #. Specify the following:
+
+               -  **Account**: The account to which you want to
+                  assign an IP address range.
+
+               -  **Domain**: The domain associated with the
+                  account.
+
+            #. Click OK.
+
+      #. Click Add.
+
+
+Dedicating VLAN Ranges to an Account
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+#. After the CloudStack Management Server is installed, log in to the
+   CloudStack UI as administrator.
+
+#. In the left navigation bar, click Infrastructure.
+
+#. In Zones, click View All.
+
+#. Choose the zone you want to work with.
+
+#. Click the Physical Network tab.
+
+#. In the Guest node of the diagram, click Configure.
+
+#. Select the Dedicated VLAN Ranges tab.
+
+#. Click Dedicate VLAN Range.
+
+   The Dedicate VLAN Range dialog is displayed.
+
+#. Specify the following:
+
+   -  **VLAN Range**: The VLAN range that you want to assign to an
+      account.
+
+   -  **Account**: The account to which you want to assign the
+      selected VLAN range.
+
+   -  **Domain**: The domain associated with the account.
+
+
+.. |addAccount-icon.png| image:: /_static/images/addAccount-icon.png
+   :alt: button to assign an IP range to an account.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/releasing_an_ip_address.rst
----------------------------------------------------------------------
diff --git a/source/networking/releasing_an_ip_address.rst 
b/source/networking/releasing_an_ip_address.rst
new file mode 100644
index 0000000..a662d0d
--- /dev/null
+++ b/source/networking/releasing_an_ip_address.rst
@@ -0,0 +1,38 @@
+.. 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.
+
+
+Releasing an IP Address
+-----------------------
+
+When the last rule for an IP address is removed, you can release that IP
+address. The IP address still belongs to the VPC; however, it can be
+picked up for any guest network again.
+
+#. 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 release.
+
+#. Click the Release IP button. |ReleaseIPButton.png|
+
+
+.. |ReleaseIPButton.png| image:: /_static/images/release-ip-icon.png
+   :alt: button to release an IP

Reply via email to