An Introduction to Aruba SD-WAN: Business Intent Overlays 

Today let’s talk about one of the building block features of the Aruba EdgeConnect Enterprise solution. It is called Business Intent Overlays (BIOs). As the traffic is moved across BIOs using set policies, most of the traffic treatment configurations are applied to BIOs. In this small article let’s understand what BIOs is and in subsequent posts, I’ll try to explain other features that are related to overlays.

Fig 1.1- Aruba SD-WAN: Business Intent Overlays 

Overview
All the applications have different business priorities. Aruba EdgeConnect Enterprise (formally known as Silver Peak SD-WAN) follows the top-down approach to deploying traffic forwarding policies from the business point of view. EdgeConnect Enterprise solution utilizes the Business Intent Overlays concept to determine the best path to follow. It is determined in real-time based on the current underlay conditions when matched traffic is to be forwarded.

Before we go deep into Business Intent Overlays there are two terms that I would like to clarify as these are basics to understand the concept. These two terms are Underlay & Overlay. Underlay tunnels are physical transport networks i.e. MPLS, Internet, LTE, or other transports. These physical links connect sites together.

Overlay Tunnels are logical paths and utilize the underlay links to forward traffic. If we try to understand these two we can take an analogy of Google Maps where we can find the shortest path between source and destination (this is an overlay network). This shortest path utilizes one of the available streets, highways, etc. (this is an underlay network). The Overlay is a logical shortest path over the underlay network.

Business Intent Overlay is the set of policies that defines multiple things –

• Identify traffic based on ALC/Interface and consider the same as an overlay
• Network Topology for identified traffic (Hub/Spoke, Mesh, Regional, etc.)
• Type of links that are to be used for traffic forwarding (Underlay Tunnels)
• Role of the links (Primary, Secondary, or Backup)

There can be multiple such overlays to group the application and follow the same traffic pattern. If we represent the same graphically BIOs can be represented as –

Figure 1: Business Intent Overlay

At the bottom, we have an underlay network consisting of routers and media to connect sites. Using the same underlay network, BIOs allow an administrator to write traffic policies for Real-Time Apps & Critical Apps.

How does it look in real?

Let’s see the BIOS settings in Orchestrator in a lab environment. Configuration settings in BIOs can go too deep, but I am going slow to keep things simple here. Please observe the highlighted boxed configuration in the output (only for OVH region).

Figure 2: Business Intent Overlay Snapshot

 There are 4 BIOs configured in the above figure, RealTime, CriticalApps, BulkApps, and Default Overlay. There can be up to 7 such BIOs configured in a network. You can say these are the different sets of fabrics/overlays treating applications identified by settings. How is traffic matched to an overlay? This is done using the traffic access policy. There are three methods to map the traffic to an overlay:

• Overlay ACL – standard ACLs automatically match traffic and assign to an overlay. Any change in the ACL is pushed to all the appliances across the network
• Match LAN ports – whatever coming from the matched Label, put into the overlay. You can use the physical and logical interfaces label to match and treat the traffic accordingly
• Match Appliance ACL – match based on the ACL configured on the SD-WAN appliance using the templates

Overlay ACLs are preconfigured with standard protocols as per the category of the network and only need modification if you want to treat your network applications differently.

You can figure out from the output above I am matching Traffic using Overlay ACLs. In addition to this match, there is two other options available to match –

Figure 3: Traffic Access Policies & Fabric Traffic Settings

Once the traffic is categorized you can define settings for 1) traffic within the fabric (Internal sites) and 2) for traffic going to the Internet for each BIOs. Above screen is showing the traffic treatment for internal network (Site to site traffic) –

1.       Network Topology – you can decide what topology to be formed for the selected BIOS. In the above case for the RealTime application, the topology is Hub & Spoke.

2.     What are the interfaces and their roles – in our case, we have three links MPLS, Internet, and LTE. MPLS and Internet are the primary link and will be used for traffic forwarding. Once both links are down, traffic will be forwarded to LTE link. There are three categories of links primary, secondary, and backup. Primary failover to secondary and secondary failover to backup (only if both primary and secondary are down).

3.       You can define the Service Level Objectives that control the conditions that define when to stop sending traffic to a connection. As you can see, these are loss, latency, and jitter thresholds defined in our case. Now you say “Use Backup when SLO is not meeting.

 

Figure 4: Backup Selection Criteria

4.       From the Overlay Configuration page you can also define the link bonding policies to various options – High Availability, High Quality, High Throughput etc.

5.       QoS Security & Optimization Settings – you can turn on or off the WAN optimization feature to be used for this overlay and other QoS Configuration settings.

It would be unfair to conclude if we don’t talk about the treatment that can be provided to the Internet Bound traffic (public subnets). Breakout Traffic to the Internet and Cloud Services setting can be accessed from the “Overlay Configuration” page with just by a single click on the “Breakout Traffic…” section.

Figure 5: BIOS Setting for Breakout Traffic

Here you can fine-tune the settings for public network traffic. Such as where do you want to send the traffic. You can set the “Preferred Policy Order” for that purpose.

Figure 6: Breakout Preferred Policy Order

In our example, we are saying the first breakout traffic to the Internet using the local link. If the local internet link is down then using the overlay (SD-WAN fabric) send it to the central site. Aruba EdgeConnect Enterprise solution does support integration to other leading SSE providers like Zscaler, Netskope, McAfee, PaloAlto, Cisco, etc.

You have the option to define policies for those cloud providers and drag it to the “Preferred Policy Order” section. This selection order matters in our case, traffic first uses the local circuit and then to the DC route. The change of sequence above will modify the behavior accordingly.

At last, we can say that a Business Intent Overlay is a profile that is configured to determine how the overlay is calculated based upon the "intent" of types of traffic like voice, replication, or web traffic. It’s like the shortest and the most optimum path across the network for traffic forwarded. All these settings collectively define a Top-Down configuration approach in line with Business Requirements or Intent!