EdgeConnect SD-WAN Overlay Design
Overlays in the EdgeConnect SD-WAN solution are built using IPsec tunnels. On top of the IPsec tunnels, traffic is placed into a Business Intent Overlay (BIO) that directs the traffic using specific guidelines and settings. The BIO includes many different components (interfaces, policies, SLAs, etc.). Design considerations are outlined below.
More information about BIOs and link bonding can be found in the EdgeConnect SD-WAN BIO and Link Bonding Policy technical white paper.
The above video summarizes the information in this chapter of the VSG.
Table of contents
Traffic Classification
Classifications are assigned in each BIO. The SD-WAN appliance can be assigned to recognize specific applications or use an overlay access list based on DSCP markings, L3/L4 ACLs, and the built-in DPI Engine referred to as First Packet IQ.
In the design phase, consider how to coordinate the set-up of BIOs for different types of traffic. Application identification is recommended, with DSCP or ACLs used as fallback.
Review the default overlay ACLs and modify as needed. Also use application groups, which bundle common applications together, when appropriate.
Topology
Topology dictates where IPsec tunnels are built and determines the scalability of the SD-WAN solution. Use of hub-and-spoke topologies is recommended for BIOs that do not require optimized spoke-to-spoke routing. Generally, the only BIO configured as mesh is real-time to allow latency sensitive applications to route directly between spokes.
Regional Routing
Regions can be defined within the SD-WAN topology to accommodate larger scale networks. This enables using a hub-and-spoke or full-mesh topology within a region with a full mesh of IPsec tunnels between the regions. This is an advanced design generally used only for larger scale networks. For regional routing design assistance, contact the Aruba account team.
Interface Selection
Primary and backup interfaces are defined in the BIO. Interfaces in the primary interfaces list are frequently probed for health and are all used to transport traffic, based on the bonding policy.
Backup interfaces are used only when all primary circuits are down or do not meet the configured SLAs. Backup interfaces pass only enough traffic to keep the IPsec tunnel running and do not have health probes.
Best practice is to place all commodity Internet and MPLS interfaces on the primary interface list and use the backup list for metered interfaces such as mobile circuits.
Service Level Objectives
BIOs can be defined with Service Level Objectives (SLOs) to remove them from the available interfaces if they fall out of a policy range. High Availability and High Quality link bonding policies exclude links based on overlay brownout. For this reason, setting SLOs is not needed for most environments. If a BIO-level SLO is required, it should be set at a high value to let the link bonding policy manage the overlay.
Suggested values for BIO-level SLOs are:
Real-Time BIOs:
- Latency - 250ms
- Loss - 10%
- Jitter - 50ms
TCP-Based BIOs
- Latency - 500ms
- Loss - 10%
- Jitter - 50ms
Link Bonding Policy
Link Bonding policies define how traffic is distributed across eligible links and how forward error correction (FEC) is applied to the traffic. Four default link bonding policies enable the creation of custom policies.
The default real-time BIO uses the High Availability link bonding policy and the remainder of the BIOs use the High Quality bonding policy. Characteristics of each bonding policy are provided below.
High Availability
High availability chooses the best performing path, uses the path until it is near full, then waterfalls traffic onto the next best performing path. All traffic receives 1:1 FEC when a copy of the packet is placed on another transport. High availability link bonding policy type should be used only for real-time traffic, since it renders the effective bandwidth to 50%.
High Quality
High quality policy chooses the best performing path, uses the path until it is near full, then waterfalls traffic onto the next best performing path. Adaptive FEC is used to provide parity packets only if there is degradation of the circuit. High quailty link bonding policy should be used as the default selection for all non-real-time traffic types.
High Throughput
High throughput policy load-balances packets across all transports performing below the SLO defined in the BIO. Adaptive FEC is used to provide parity packets only if there is degradation of the circuit. This link bonding policy is used only in unique circumstances.
High Efficiency
High efficiency policy load-balances packets across all transports performing below the SLO defined in the BIO. No FEC is used in this bonding policy. This link bonding policy is used only in unique circumstances.
QOS, Security, and Optimization
QOS
Different applications have different quality of service (QOS) and end-user experience requirements. For example, voice and video traffic requires zero packet loss and extremely low delay while file transfers require large amounts of bandwidth, but some amount of delay is acceptable.
Silver Peak enables network designers to define logical or virtual WAN overlays that reflect application QOS requirements relevant to the business.
EdgeConnect maps applications to the appropriate overlay, which enables the SD-WAN to optimize routing decisions automatically. EdgeConnect continuously monitors bonded tunnels and physical WAN links, factoring real-time data about delay, jitter, and packet loss to make intelligent routing decisions. The Silver Peak SD-WAN learns and adapts to optimize and dynamically change paths if necessary, based on actual performance with no application disruption. When link conditions change, the SD-WAN can revert to the original path.
EdgeConnect performs both egress and ingress traffic shaping. IT staff can program minimum and maximum bandwidth limits on the egress traffic to shape the engine by traffic class to ensure that no single application consumes all the WAN bandwidth.
Ingress shaping can be programmed to ensure that low-priority traffic does not override higher priority traffic. For example, video streaming or social media applications can be prevented from compromising the performance of higher priority business applications.
Within the EdgeConnect SD-WAN solution, two main components manage QOS:
- The shaper provides a simplified way to configure QoS (Quality of Service) globally on the appliances. It shapes traffic by allocating bandwidth as a percentage of the system bandwidth. The shaper’s parameters are organized into ten traffic classes. Four traffic classes are preconfigured and named real-time, interactive, default, and best effort.
- The BIO is used to trust or remark traffic. It determines how the packets are mapped to their assigned traffic class.
When designing the branch, it is critical to consider the overall QOS policy and determine the QOS markings to use and how to map the traffic classes.
Optimization
The EdgeConnect enterprise solution delivers robust WAN optimization, as described in the EdgeConnect SD-WAN Solution Overview section. Optimization should be applied individually for each BIO and applied only to BIOs that require or would benefit from using boost. Use optimization for BIOs when caching is needed or high latency (100ms+) is expected.
Breakout Traffic to Internet and Cloud Services
As enterprises migrate more applications to the cloud, changing traffic patterns drive the need to transform wide area network (WAN) and security architectures.
When applications were solely hosted in enterprise data centers, traffic from branch locations was backhauled to the data center over private circuits. In today’s modern, cloud-first enterprise, applications are hosted everywhere – at the data center, in public and private clouds – and delivered by myriad Software-as-a-Service (SaaS) providers.
Users can access applications from anywhere, from any device, and across diverse WAN transports including broadband Internet. The increasing variety of access complicates IT development of effective security models. The dissolving enterprise security perimeter leads to an expanded and varied attack surface, significantly increasing the critical need for advanced data and threat protection services to mitigate exposure to threats.
Aruba responded to these challenges with the Secure Access Service Edge (SASE) architecture that combines the strength of SD-WAN with cloud-delivered security services.
The Aruba EdgeConnect Platform delivers industry-leading integration and automation with cloud-delivered security services.
| Security Partner | Service | Integration |
|---|---|---|
| Checkpoint | Harmony Connect | API Integration |
| Forcepoint | Cloud Security | Service Orchestration |
| iBoss | Cloud Security | Service Orchestration |
| McAfee | Unified Cloud Edge | Service Orchestration |
| Netskope | NewEdge SWG | Service Orchestration |
| Palo Alto | Prisma Access | Service Orchestration |
| Symantec | Web Security Service | Service Orchestration |
| Zscaler | Zscaler Internet Access | API Integration |
Aruba Orchestrator automates the establishment of data plane IPsec tunnels between EdgeConnect appliances and their nearest security service cloud instances. This is performed with full API integration where connection establishment is single-ended and the Orchestrator arranges the connection to partner services, or with Service Orchestration where the Orchestrator ingests a list of partner-service access points then builds the connections.
Internet egress is configured on a per-BIO basis. General recommendations for designing Internet egress are outlined below. Recommendations may vary based on specific security requirements.
- Trusted traffic should be sent directly to the Internet, with minimal security inspection to meet corporate policy, using the built-in zone-based firewall if needed. Backhauling egress traffic over the data center should be used only if local Internet is not available.
- Untrusted, high-risk, or sensitive traffic should be sent to a cloud security solution for additional inspection. Backhauling this egress traffic over the data center should be performed only if local Internet is not available.
- Guest traffic should be sent directly to the Internet, with minimal security inspection. Due to the high cost of backhauling traffic, backhauling should not be performed if a local Internet outage occurs. Exceptions may be needed for important guest traffic in specific environments.
- Traditional cellular connections should be used only for backup Internet egress, and only for specific high-impact BIOs. If modern 5G cellular backups with high bandwidth and no data caps are used, consider using them as part of the primary Internet egress selection.
App Express
SaaS applications have multiple access hubs across the world and within the same region, coupled with various Internet providers. The user experience can vary significantly between different paths. To ensure the best experience for end users, all available paths should be monitored and tested. App Express enables admins to designate up to 50 applications for testing on all available paths, assigning each path an apex score.
This score is rated on a scale of 0 to 100, where 100 is the best possible score. The score is calculated by assessing network latency. Network latency values come from synthetic traffic generated by the EdgeConnect gateway and end-user traffic. Only outbound traffic from the EdgeConnect gateway to the SaaS application is considered for path selection, excluding any LAN side latency. Latency values are measured on a minute-by-minute basis for users accessing an application and every five minutes for traffic generated by the EdgeConnect gateway.
App Express probes applications using local breakouts, hubs, and SSE providers. Cloud-based hubs and SSE providers may have additional paths to an application. In this case, App Express probes all available paths, up to 32 paths per application.
When enabling App Express consider:
- Path selection proceeds WAN ACLs. For example: if an admin wants to always use one path for an application, App express ignores this ruleset.
- Loopbacks must be configured.
- Passthrough is not supported.
- DNS proxy is automatically enabled per SaaS application, even if it’s not globally enabled.
- Apps can only be a part of one group.
- For backhaul, Administrative distance is ignored (looking only at the last 10 peer priorities).
- Loopbacks must be configured.
Zone Based Firewall
Zone based firewalling (ZBFW) can be applied between LAN interface pairs or between a LAN segment and the Internet. The ZBFW feature can support L3/L4 inspection based on port/protocol using First Packet IQ.
Intrusion Detection System (IDS) also is supported. It monitors traffic for potential threats and malicious activity and generates threat event notifications based on configured rules. Packets are inspected against signatures downloaded to Orchestrator from Cloud Portal. Orchestrator sends appliances the signature file along with rules added to the allow list. Traffic is designated for inspection using matching rules enabled in the firewall zones.
Cloud Integration
This guide is intended to provide a foundation for SD-WAN design; detailed design guidance for cloud integration is outside the scope of the content.
It is important to consider the following elements of cloud integration in the foundational design.
EdgeConnect can be deployed in virtual private clouds within Public Cloud IaaS providers.
Many large enterprises have workloads in and across multiple public IaaS providers. EdgeConnect can be deployed in “Multi-Cloud-Hub” providers such as Equinix, Megaport, and Alkira. The multi-cloud-hub provider mediates between the different cloud IaaS providers, and can connect using dedicated interconnection services for each provider.
