CloudBridge Virtual WAN 8.0 Deployment Planning Guide. This document provides guidance on designing your Citrix CloudBridge Virtual WAN deployment.

Transcription

1 CloudBridge Virtual WAN 8.0 Deployment Planning Guide This document provides guidance on designing your Citrix CloudBridge Virtual WAN deployment.

2 Copyright and Trademark Notice CITRIX SYSTEMS, INC., ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT MAY BE REPRODUCED OR TRANSMITTED IN ANY FORM OR BY ANY MEANS OR USED TO MAKE DERIVATIVE WORK (SUCH AS TRANSLATION, TRANSFORMATION, OR ADAPTATION) WITHOUT THE EXPRESS WRITTEN PERMISSION OF CITRIX SYSTEMS, INC. Citrix, Citrix Systems, CloudBridge, Citrix Repeater, Branch Repeater, WANScaler, NetScaler, XenServer, Orbital Data, Orbital 5500, Orbital 6500, Orbital 6800, TotalTransport, AutoOptimizer Engine, and Adaptive Rate Control are trademarks of Citrix Systems. Citrix Systems assumes no responsibility for errors in this document, and retains the right to make changes at any time, without notice. Portions licensed under the Apache License, Version licenses/license-2.0. Portions licensed under the Gnu Public License, including xmlrpc++, glibc, rpmlibs, beecrypt. Portions licensed under the Gnu Public License with product-specific clauses, including the Linux kernel ( libstdc++, and libgcc. Portions are free software with vendor-specific licensing, including zlib ( netsnmp ( license.html), openssl ( krb5-libs ( /web.mit.edu/kerberos/krb5-1.3/krb /doc/krb5-install.html), tcp_wrappers (ftp://ftp.porcupine.org/pub/security/tcp_wrappers_license), bzip2-libs ( sources.redhat.com/bzip2/), popt ( Elfutils-libelf is licensed under the OSL 1.0 license, JPGraph licensed under the terms given in LZS licensed from Hifn corporation, Iperf licensed under the terms given in This product includes PHP, freely available from P a g e 2

3 Contents 1 About This Guide... 5 Purpose... 5 Audience... 5 Related Documents CloudBridge Virtual WAN Solution Overview Virtual WAN Solution Architecture... 7 Basic Concepts in the Virtual WAN Architecture... 8 CloudBridge Virtual WAN Nodes... 8 Virtual WAN Services...10 Virtual WAN Service Provisioning...12 Topology Deployment Options Arm Topology...13 In-line Topology...14 Gateway Mode Deploying High Availability for Virtual WAN Master Control Node (MCN)...16 MCN High Availability in 1-Arm Topology...17 MCN High Availability in a Parallel In-line Topology...18 Client Nodes...18 Geographically Distributed HA Virtual WAN Deployment Options Small/Medium Enterprises...20 Branch-to-Branch traffic...20 Large Enterprises...21 Inter-Zone Traffic Deploying Virtual WAN with WAN Optimization Additional Deployment Considerations Firewall Rules and NAT...27 Deploying Branches without Firewalls...28 Deploying Intranet Services...28 Completing Configuration by Adding Routes...29 P a g e 3

4 Local Access Routes...29 Intranet Routes...29 Summary of Additional Deployment Considerations Provisioning Guidelines Provisioning Groups...31 Fair Shares...32 P a g e 4

5 About This Guide Purpose This guide provides an overview of deployment options for the CloudBridge Virtual WAN solution, and an explanation of fundamental concepts of Virtual WAN architecture. Audience This guide is intended for Network Administrators defining a deployment approach for CloudBridge Virtual WAN. Readers are assumed to be familiar with the physical setup and operation of networking equipment. Related Documents The following additional CloudBridge Virtual WAN documentation is available on the Citrix Support Portal ( Citrix CloudBridge Virtual WAN 8.0 Installation and Configuration Guide You can also find related Citrix CloudBridge WAN Optimization hardware documentation at this location: P a g e 5

6 CloudBridge Virtual WAN Solution Overview The primary features of CloudBridge Virtual WAN are as follows: Provides bandwidth aggregation from all available WAN paths into one Virtual Path to the WAN. Provides seamless failover in the event of failure in one of the WAN paths. Application awareness protects critical applications in the event of WAN failure. If failure occurs, critical apps are prioritized over non-critical applications. Provides packet duplication for applications with extreme sensitivity to packet loss (for example, VoIP applications). P a g e 6

7 Virtual WAN Solution Architecture This section explains the basic concepts of CloudBridge Virtual WAN architecture, and how the solution is organized to maximize results in a typical incumbent Enterprise network environment. CloudBridge Virtual WAN maximizes WAN performance for all applications by making optimal use of all available WAN resources. The Virtual WAN enables you to combine traditional WAN private circuits (for example, MPLS), with a variety of other cost effective links (for example, Internet and LTE cellular). The following diagram provides an example of a basic Virtual WAN topology for maximizing results in a typical Enterprise network environment. Figure 1. Example Enterprise topology The typical Enterprise topology comprises the following application elements and connectivity characteristics: An IP network consisting of switches, routers, and firewalls implements the WAN and access to the Internet. Branches are connected to the Private WAN, and can differ as to whether they connect to the Internet. On-premises applications are hosted in an Enterprise datacenter. Users scattered across branch sites access those applications through a private MPLS WAN. Applications in secondary service provider data centers are accessed through MPLS or VPNs over the Internet. P a g e 7

8 Cloud-based applications are hosted by third parties and reachable through the Internet. Internet access is available in some WAN sites. Basic Concepts in the Virtual WAN Architecture To deliver the main features outlined in the typical Enterprise scenario above, CloudBridge Virtual WAN implements an overlay IP network on top of the existing IP networking infrastructure. The Virtual WAN dominates this overlay network. For a WAN site to receive the full benefits of the Virtual WAN, it must be connected to a secondary WAN link, in addition to the primary MPLS link. The following sections describe the fundamental architectural elements of the Virtual WAN. CloudBridge Virtual WAN Nodes The CloudBridge Virtual WAN architecture comprises one Master Control Node (MCN) located in the Enterprise data center, and several client nodes installed at each branch site within the scope of the Virtual WAN. The following diagram depicts how the Virtual WAN nodes are inserted into our typical incumbent Enterprise network. In this scenario, the topology has been modified to add Internet links at all locations. Figure 2. Inserting CloudBridge Virtual WAN nodes into the Enterprise network P a g e 8

9 To achieve the full benefits of the Virtual WAN, it is crucial that you deploy the Virtual WAN nodes in a scheme that enables CloudBridge Virtual WAN to control all of the traffic over the WAN. Ideally, Virtual WAN clients should be deployed in all of the sites across the WAN, and at endpoints where Enterprise application flows initiate and terminate. Virtual IP Addresses (VIP) Virtual Paths CloudBridge Virtual WAN establishes an overlay IP network, defined privately among the MCN and the client nodes. From the perspective of the surrounding network elements, CloudBridge Virtual WAN is a collection of L2 devices, and traffic is most typically ingested in L2 mode. CloudBridge Virtual WAN forwards each IP packet to specific interfaces in the destination node, therefore steering these packets through specific paths in the WAN. To carry out the forwarding operation, each physical interface in the MCN and in all client nodes must be assigned at least one routable IP Address, deemed a Virtual IP Address (VIP). VIPs are not advertised to the surrounding network elements for routing. As they are known only to the MCN and Virtual WAN clients, the VIPs constitute the endpoints of all circuits in the overlay network implemented by CloudBridge Virtual WAN. Logical Links between two VIPs are defined as WAN paths. Traffic sent over a WAN path is encapsulated using the Virtual Path Control Protocol (UDP port 4980). All of the WAN paths between two specific CloudBridge Virtual WAN sites create the Virtual Path connecting those sites. The following figure illustrates the relationship between the WAN paths and the Virtual Paths. P a g e 9

10 Figure 3. Relationship between the WAN paths and Virtual Paths. In the example illustrated above, there are two WAN Paths connecting each branch to the main data center; one over MPLS, and one over the Internet. The combination of both WAN paths constitute the Virtual Path between the data center and each branch site. Virtual Paths are statically defined between the MCN and the client nodes when you initially configure the Virtual WAN. In this way, all benefits of the CloudBridge Virtual WAN solution are automatically delivered in the resulting hub-and-spoke Virtual WAN. For branch-to-branch traffic, Dynamic Virtual Paths can be configured to provide bandwidth aggregation, seamless failover, and application awareness features, without requiring an extra hop over the MCN. Virtual WAN Services In some cases, the ideal situation of having CloudBridge Virtual WAN nodes in all sites and application endpoints is not always possible. This is due to the fact that some applications could be hosted in third-party environments on the Internet itself. However, in all cases, all active application flows consume WAN resources, and contend for bandwidth against one another in the Enterprise WAN. CloudBridge Virtual WAN is designed to manage available bandwidth across the WAN, assigning resources to each application according to its criticality. This is accomplished by means of the CloudBridge Virtual WAN Services. The Virtual WAN Services manage the provisioning, control, and tracking of all flows over the WAN. P a g e 10

11 There are four Virtual WAN Services, defined as follows: Virtual Path Service This is traffic within the Virtual WAN. Such traffic originates and terminates in locations that have a CloudBridge Virtual WAN node (MCN or client), and is conveyed over static or dynamic Virtual Paths. Intranet service This is traffic that travels across a Virtual WAN node in only one end of the flow. This traffic is never encapsulated, and does not experience any of the solution benefits. Cloudbridge Virtual WAN manages bandwidth only by rate-limiting this traffic relative to other services as specified in the provisioning configuration, during times of contention. Note that under certain conditions and if configured traffic between a pair of Virtual WAN Appliances that ordinarily travels over a Virtual Path, may instead be treated as Intranet traffic in order to maintain network reliability. Internet service This is traffic traveling out to the public Internet. Traffic of this mode is not encapsulated. During times of contention, CloudBridge Virtual WAN actively manages bandwidth by rate-limiting Internet traffic relative to the Virtual Path and Intranet traffic as provisioned by the administrator. Passthrough service This is traffic not matching any of the categories above, or deemed not to be of interest. Note that Virtual WAN does not account for this traffic in terms of the bandwidth it uses. All of the features and benefits of the CloudBridge Virtual WAN solution described above can be realized only in the context of Virtual Path Service traffic; hence, the importance of installing CloudBridge Virtual WAN clients in as many application endpoints as possible. Traffic conveyed by the Virtual Path Service can thereby be maximized. While the core features do not apply to the Intranet and Internet services, setting up those services correctly is highly important. CloudBridge Virtual WAN can then fully manage the WAN traffic, as these services coexist with the Virtual Path Service on the WAN, and contend for the same resources. P a g e 11

12 In normal L2 deployment mode, CloudBridge Virtual WAN operates as follows: For traffic intake, Virtual WAN behaves as a Layer 2 device. When sending packets out, Virtual WAN forwards (on a packet-by packet basis) IP traffic matching the Virtual Path Services over the best available WAN link. Virtual WAN shapes traffic matching Intranet or Internet services to match provisioned bandwidth. Traffic not matching any defined services is bridged as Passthrough. Virtual WAN Service Provisioning CloudBridge Virtual WAN Provisioning allows for allocating WAN resources to all defined services (Virtual Paths, Intranet, Internet), with very high granularity for all WAN links in the network. Provisioning constitutes the last step in the setup process, where traffic engineering design for the Enterprise WAN is applied to the overlay Virtual Network. In all WAN sites, provisioning configuration ensures that in a fully-loaded WAN scenario, bandwidth is shared among all services in each WAN Link according to design specifications. To provide for highly granular, fair bandwidth provisioning, CloudBridge Virtual WAN enables you to specify bandwidth Shares. A Share is a configurable numeric value that allocates for each active service a fraction of the bandwidth considered as fair for such service. During high WAN utilization periods, CloudBridge Virtual WAN makes best efforts to hold the specified fair bandwidth portion for each service. In addition, you can define a minimum bandwidth for each service. CloudBridge Virtual WAN then guarantees that each service receives the specified minimum bandwidth. Fair and minimum bandwidth are used to control traffic during congestion. They do not come into effect when traffic is light. NOTE: For additional information regarding Virtual WAN provisioning, see the section entitled, Provisioning Guidelines at the end of this guide. P a g e 12

13 Topology Deployment Options This section describes topology options for inserting the data center (MCN) and branch (client) CloudBridge Virtual WAN nodes into your Enterprise network. The following two topology options are available for both node types: 1-arm In-line To maximize the benefit of a CloudBridge Virtual WAN solution, the following general considerations apply to all topology scenarios: All traffic over the WAN in any direction should travel through the Virtual WAN MCN and clients. For both the Enterprise data center and branch sites, you should deploy the CloudBridge Virtual WAN nodes as the last network elements to process WAN traffic before the edge router. Virtual WAN nodes should also have full visibility of the links connecting each site to the WAN. The following sections describe in detail the available topology options. All diagrams are logical. The same concepts should be mapped to concrete topologies at your Enterprise site. 1-Arm Topology This topology requires modifications to routing tables. For this topology, you must define policy-based routing (PBR) rules in the corresponding routers for steering traffic to the Virtual WAN nodes. You should also configure PBR rules for the Enterprise data center and branches, as follows: LAN to WAN direction: The Virtual WAN should be the last hop before forwarding traffic over the WAN, or to the Internet. WAN to LAN Direction: The Virtual WAN should be the first hop after receiving WAN traffic from a remote site or from the Internet. P a g e 13

14 Figure 4. Example 1-Arm topology In-line Topology In an in-line topology, the Virtual WAN operates at Layer 2 between the WAN side and the LAN side. This topology is minimally intrusive to the incumbent network routing scheme. No modifications at the L3 level are required. The insertion requires L2 changes, which may result in rearrangement of switch connections of routers, or the configuration of additional VLANs. In in-line mode, the Virtual WAN receives traffic on the LAN side as an L2 device, and performs IP forwarding for traffic matching predefined services, as follows: Virtual Path is utilized for traffic going to other CloudBridge Virtual WAN sites. Intranet service is utilized for destinations within the private network outside the scope of the Virtual WAN. Internet service is utilized for traffic going out to the Internet. For traffic that does not match any of the above, Virtual WAN acts as a bridge in the context of the Passthrough service. In a multi-router scenario, Proxy ARP must be enabled. The following diagram depicts the in-line topology in WAN sites. P a g e 14

15 Figure 5. Example In-line topology Gateway Mode You can deploy Virtual WAN appliances in Gateway mode (L3), if this scenario befits your Enterprise network. In this case, you must fully insert the Virtual WAN nodes into the network routing scheme. This might require that you also configure static routes within the Virtual WAN solution. P a g e 15

16 Deploying High Availability for Virtual WAN This section discusses High Availability (HA) and redundancy for the two types of nodes in the CloudBridge Virtual WAN solution architecture. These two node types are as follows: Master Control Node (MCN) Client nodes The following sections provide an overview of High Availability deployment for each of these node types. Master Control Node (MCN) The Master Control Node (MCN) is the center of the Virtual WAN. The MCN provides configuration to the remote appliances (client nodes), and builds and maintain the status of all services in the Virtual WAN. Only one active MCN can exist in the entire network. Due to its criticality in the Virtual WAN operation, High Availability for the MCN node is of utmost importance. To that end, CloudBridge Virtual WAN features 1+1 redundancy for MCN nodes. To implement Virtual WAN High Availability, you must configure a pair of MCNs to form an Active/Standby cluster. Both MCNs in an HA pair are configured and connected in the same way as dictated by your deployment design. Configuration is mirrored across both MCNs. Each MCN has a unique set of Virtual IP Addresses. VIPs in both MCNs must be selected for health-check traffic. Upon failure of the Active MCN, the Standby MCN takes control. After this transition, there is a period of convergence in which the Virtual WAN will be reestablished, and the backup MCN will rebuild the state of the Virtual WAN. P a g e 16

17 It is important to note that in the event of a failure of the active MCN, the underlying network infrastructure will not be affected. Therefore, the private WAN will continue to allow all sites in the network to access internal application. In addition, Internet links will allow for Internet/cloud access in all sites. However, during the transition period, the core Virtual WAN features are inactive until the Standby MCN becomes fully active. The most critical situation is that the lack of bandwidth aggregation may cause temporary congestion on the MPLS links until MCN is reestablished. The following sections describe how to implement MCN High Availability can be implemented for Virtual WAN topologies. MCN High Availability in 1-Arm Topology High Availability in a 1-arm topology requires policy-based routing (PBR) at the core router. PBR must be coupled with IP SLA, which is then used to determine which of the two MCNs is currently active. The following logical diagram illustrates the High Availability arrangement for a 1-arm topology. Figure 6. MCN High Availability implemented in a 1-arm topology P a g e 17

18 MCN High Availability in a Parallel In-line Topology The recommended High Availability configuration for an in-line topology is also simple and minimally intrusive to the routing tables in the network. Some changes to the L2 configuration are required for insertion of the two MCNs (two new VLANs). The recommended High Availability configuration provides for the following: The active MCN bridges traffic between LAN and WAN sides. The standby MCN remains inactive and does not bridge any traffic until the Active MCN fails. Fail-to-block interface configuration is required in both MCNs. No specific router configuration is required for L2 mode. The following diagram depicts an MCN High Availability configuration in a parallel inline topology. Figure 7. MCN High Availability in a parallel in-line topology Client Nodes You can implement client redundancy by using a Fail-to-Wire or Fail-to-Block configuration in the client physical interfaces. The exact configuration depends upon how the client node is inserted in the network of the remote site. P a g e 18

19 Geographically Distributed HA Geographically distributed High Availability enables one Virtual WAN client in the network to take over the MCN function, in the event that the primary MCN fails. You can designate only one client node as the backup MCN. The designated client continues to function as a client node, until the primary MCN fails. This option may be useful for leveraging secondary data centers, or large branches in the Enterprise network that host on-premise application servers in normal operation. The following diagram illustrates a geographically distributed MCN High Availability configuration. Figure 8. Geographically distributed MCN High Availability configuration Virtual WAN Deployment Options This section covers the deployment of CloudBridge Virtual WAN in different Customer scenarios. The main factor to be considered is the size of the incumbent WAN on which CloudBridge Virtual WAN will be deployed. Each Virtual WAN node in the network can support up to 256 Virtual Paths, which gives rise to two basic scenarios, as follows: Small/Medium Enterprises, with less than 256 WAN sites Large Enterprises, with a total number of sites exceeding 256 The reminder of this section covers recommendations for deploying High-availability, branch-to-branch communication, Internet and Intranet access in the scenarios mentioned above. P a g e 19

20 Small/Medium Enterprises In this scenario, a single pair of MCNs is required for 1+1 redundancy. You can implement this using any of the topologies discussed in the previous sections. L2 in-line is the recommended topology. It is minimally invasive, as it only requires two extra VLANs, and leaves incumbent routing tables unaffected. The alternative 1-Arm topology requires a new PBR and IP SLA routing configuration to detect MCN failure. The following diagram illustrates both the recommended and the alternative topology options. Figure 9. In-line and 1-arm topologies for a small to medium Enterprise Branch-to-Branch traffic In the small/medium Enterprise scenario, branch-to-branch traffic can be handled in either of the following ways: Permanent Virtual Paths for high traffic volume Dynamic Virtual Paths P a g e 20

21 Large Enterprises In a large Enterprise scenario, the total number of WAN sites exceeds 256. Therefore, several MCN pairs are required. To accommodate all sites, WAN Zones must be defined. Each WAN Zone is a group of WAN sites that can be easily collectively referenced collectively by CloudBridge Virtual WAN. Best practice is to define WAN zones adhering to an existing IP Addressing scheme, identifying groups of 256 sites with IP subnets that can be referenced by a single summary IP subnet. After you have defined the WAN zones and assigned them to an MCN pair, PBR is required at the Enterprise data center for steering traffic to/from each zone to the assigned MCN pair. The following diagram illustrates the logical deployment of CloudBridge Virtual WAN in N WAN Zones using a 1-arm topology. Figure 10. Virtual WAN deployment in multiple WAN Zones in a 1-arm topology Each zone here is referenced by a single summary IP subnet. The resulting PBR routing table at the core router will have one entry per zone, which is as follows: for all packets with a source OR destination IP Address matching the summary IP subnet of Zone 1, forward traffic to the active MCN Z1. P a g e 21

22 Inter-Zone Traffic Example In a zoned deployment, an MCN pair controlling a given zone is unaware of the existence of the other zones. As long as traffic flows are contained in the same zone, traffic will be transported using the Virtual Path Service. And therefore, all of the benefits of the CloudBridge Virtual WAN solution will be in effect, whether over Permanent or Dynamic Virtual Paths. For inter-zone traffic, special considerations are necessary to ensure optimal performance. The most common inter-zone traffic scenario is branch-to-branch interactive communication (Enterprise VoIP systems, Lync, Skype, and so forth). To avoid an unnecessary hop over the MCN, traffic of that sort should not be sent over a Virtual Path. Rather, it should be sent over Intranet services. Intranet service is not mandatory, but is highly recommended. If Intranet service is not defined, IP traffic sent to IP Addresses outside the zone will be considered as Passthrough and will still reach its destination as expected. However, since the Virtual WAN does not account for Passthrough traffic in the provisioning scheme, it is highly recommended that you configure an Intranet service in all sites where inter-zone traffic is non-negligible. In that way, inter-zone traffic can be properly provisioned and taken into consideration. NOTE: If incidents of high-volume branch-to-branch traffic are detected, a minor zone rearrangement may be necessary. This is so traffic can be handled by the same MCN, and therefore transported over Virtual Path Services. In this example, we consider an Enterprise with 800 branches, with an average of 100+ users per branch. After reviewing the WAN and analyzing its IP Addressing scheme, it was found that there are four IP subnets that summarize groups of 200 WAN sites each. The following diagram illustrates this scenario. P a g e 22

23 Figure 11. Example of an inter-zone traffic scenario Thus, one WAN zone is defined for each of the four summary IP subnets. To implement the Virtual WAN, the following configuration is applied: Data center (MCN) site: One MCN node is deployed at the Enterprise data center to service each zone. PBR is configured at the core router to steer traffic to and from each zone to the corresponding assigned MCN node. Branch (client) sites: All client nodes in a given zone are configured to activate Intranet and Internet services. The configuration for each MCN and branch site includes the following: Intranet service is defined, and one route is added for each of the three remaining zones, using the summary IP subnet for each zone. This is in order to take into account any inter-zone traffic, and enable provisioning for it. Internet service each site is configured by specifying the Internet Link(s) for that site. P a g e 23

24 Deploying Virtual WAN with WAN Optimization You can implement joint deployment of CloudBridge WAN Optimization and Virtual WAN technologies by inserting the Virtual WAN, as shown in the following diagram: Figure 12. Joint deployment of CloudBridge WAN Optimization and Virtual WAN CloudBridge WAN Optimization Appliances are not aware of the Virtual WAN, and so traffic is processed by CloudBridge WAN Optimization as if the WAN consisted of one or more physical links managed by the core or edge routers. The scenario depicted in the diagram above can be implemented using various topologies, a discussion of which is beyond the scope of this document. However, in all cases, the CloudBridge Virtual WAN nodes should observe the following rules: The Virtual WAN should be the last logical hop for packets sent over the private WAN (or to the Internet) before reaching edge routers and firewalls. The Virtual WAN should be the first logical hop for packets received by edge routers or firewalls coming from the Private WAN (or the Internet). P a g e 24

25 As long as these rules are observed, the joint deployment of Virtual WAN and WAN Optimization can be implemented for a variety of topologies or combinations of thereof. Both the Virtual WAN Appliances and the WAN Optimization Appliances can be deployed using either an in-line, or 1-arm topology. The choice as to which to use depends upon which best suits the specific characteristics of your Enterprise network. In any event, you must configure neighboring routers and switches to ensure that the Virtual WAN Appliances and WAN Optimization Appliances are chained correctly. The following diagram illustrates a pure in-line deployment of both Virtual WAN and WAN Optimization. The connection in this case is restricted to Layer 2; only the LAN switches would require configuring and patching. Figure 13. Pure in-line deployment of Virtual WAN and WAN Optimization The following diagram shows an example 1-arm deployment. Figure 14. Example 1-arm deployment P a g e 25

26 In this example, the core router must be configured to implement the appliance chaining configuration as shown, for traffic going out to the WAN (red), and coming in from the WAN (green). The following rules are required: Traffic must be forwarded to the Virtual WAN node in both directions, and PBR rules must be configured at the router. Traffic must be forwarded to the WAN Optimization node in both directions, and PBR or WCCP must be configured at the router. P a g e 26

27 Additional Deployment Considerations This section outlines details regarding routing, security, and firewall traversal that must be considered when configuring CloudBridge Virtual WAN. To facilitate the discussion, we will use the example environment illustrated in the following figure. Figure 15. Example environment In this environment, there is a third party data center hosting some Enterprise applications, and branches that are connected to the Internet without a firewall (small sites). Firewall Rules and NAT In this scenario, for all Virtual WAN sites (both MCN and clients), you must configure each firewall to permit the Virtual Path Service to establish WAN paths through it to leverage Internet connectivity. To enable Internet WAN paths, firewalls in both ends of a Virtual Path must have UDP port 4980 enabled in both the inbound and outbound directions. CloudBridge Virtual WAN uses UDP port 4980 by default, as both the source and destination port. In addition, depending on the incumbent network architecture, NAT rules might be necessary to properly map the public Internet IP Addresses specified for both endpoints of the Internet WAN paths in the Virtual WAN configuration. P a g e 27

28 Deploying Branches without Firewalls When configuring virtual interfaces on the CloudBridge Virtual WAN Appliances, an option is presented to declare each interface as Trusted or Untrusted. Virtual WAN allows traffic of all types over trusted interfaces. Therefore, trusted interfaces can be used for all of the services Virtual WAN provides: Virtual Path, Intranet, Internet, and Passthrough. On the other hand, untrusted interfaces can be used only for the Virtual Path Service, as the only allowable traffic through them consists of UDP 4980 (used by the Virtual Path service) and ICMP (for diagnostics). Combining the restrictions above with the fact that untrusted interfaces are securityhardened, the Virtual WAN can be deployed without a firewall in branches that do not require the Internet service for Web browsing, or for accessing cloud applications. Small locations in certain industries may fit the Virtual WAN use case without a firewall. Figure 16 on page 30 illustrates a scenario that includes a branch site without a firewall. Deploying Intranet Services As explained in previous sections, Intranet service must be activated in each location by adding a route for each WAN location outside the scope of CloudBridge Virtual WAN. The example in Error! Reference source not found. takes into consideration ccess to an application hosted in a third-party data center. By adding Intranet routes within all locations using such applications, the Intranet Service can be properly provisioned. This then ensures that traffic generated by the applications receives the fair amount of resources assigned by the Network Administrator, and will not overly congest the WAN. As Intranet services are always associated with specific routes, several of them can be defined and associated with different applications. The definition of multiple Intranet services is useful for more effective provisioning of WAN bandwidth for specific applications. P a g e 28

29 Completing Configuration by Adding Routes CloudBridge Virtual WAN automatically builds an internal routing table that includes all of the VIPs configured in the system, as well as all available Internet links. However, the Virtual WAN does not automatically learn about adjacent subnets from routers. With the information you provide when you configure the Virtual WAN, the system is capable of building a routing table that covers the forwarding of traffic among VIPs, and out to the Internet. After initial configuration, the Internet service is the only service that is fully routable and properly configured for provisioning. To complete the configuration of the Virtual Path and the Intranet services, you must add more routes. Further details about this are provided in the remainder of this section. Local Access Routes To complete the configuration of the Virtual Path Service and enable end-to-end connectivity throughout the Virtual WAN, you must configure manual routes in all locations to reach local data subnets. After you have done this, CloudBridge Virtual WAN then propagates the new route definitions to all nodes in the Virtual WAN. Intranet Routes Intranet routes are used for allowing Intranet services to be managed and provisioned, covering all traffic traveling to sites outside of the Virtual WAN. An Intranet route has no Gateway IP Address, but instead is associated with the Intranet service being activated. There can be multiple Intranet services, each associated with a WAN site or an application. For each Intranet service, subnetwork and masks must be configured. For example, in the previous diagram, Intranet service and associated routes should point to the thirdparty data center, as well as the sites hosting the target applications that are not on the Virtual WAN. For effectively controlling Intranet traffic across the Virtual WAN, you must define the Intranet service and route associated with each Virtual WAN node, and assign them to a private WAN Link. P a g e 29

30 Summary of Additional Deployment Considerations The following diagram shows all of the routes that must be added to our example environment, for proper routing and provisioning within the Virtual Path and Intranet services. Figure 16. Example environment with routes added P a g e 30

31 Provisioning Guidelines Provisioning allows for the bidirectional (Ingress/Egress) distribution of bandwidth for a WAN Link among the various services associated with that WAN Link. There are two steps to provisioning that provide for this bandwidth distribution in a simple and effective way. These are as follows: Provisioning groups - (Optional.) Create and edit groups of bandwidth. Services - View and edit bandwidth settings for services within a bandwidth group. The following sections discuss these concepts in more detail. Provisioning Groups A Provisioning Group is a container for an arbitrary collection of services on any given WAN Link. They allow the user to allocate bandwidth at a high-level before drilling down to the individual services within the group for fine-tuning. They also provide a boundary for the automatic redistribution of bandwidth within the child services of the Provisioning Group. You can use Shares to distribute the permitted bandwidth over groups, and services within groups. NOTE: Provisioning Groups are available to simplify the provisioning process, but are not required if they are not needed. The total number of Shares is unrestricted, enabling you to configure any amount of granularity or precision when allocating bandwidth among the different groups and services. P a g e 31

32 Fair Shares In the Provisioning configuration, Shares are used to distribute the WAN-to- LAN/LAN-to-WAN bandwidth, which is the Permitted Rate minus the total Minimum Reserved Bandwidth of all services on the WAN Link. All services are initially assigned to a default group that is allocated all of the eligible bandwidth. You can create additional groups and allocate bandwidth to its members by specifying some number of Fair Shares for the group. All services receive their specified Minimum Reserved Bandwidth allocation before Fair Share distribution. This can result in groups with equal Fair Shares having disparate Fair Rates. Fair Rates can also be affected by Service Maximums, if defined. P a g e 32