Configure DIA AnyPath so that a DIA link can fail over
to VPN tunnel links.
| Where Can I Use This? | What Do I Need? |
When your
SD-WAN direct internet access (DIA) links from an ISP experience a
blackout or brownout, you need those links to fail over to another link to ensure
business continuity. DIA links can
fail over to an MPLS link, but
you may not have an MPLS link. DIA links must be able to fail over to another link
that has a direct path or indirect path (through a
hub)
to the internet; the DIA traffic can take
any path available to get to the
internet and isn’t restricted to DIA. DIA AnyPath supports a DIA link failing over
to a private VPN tunnel going to a hub firewall to then reach the
internet.
There are several use cases for
wanting an internet link to fail over to a VPN tunnel (DIA AnyPath):
- You want to transition away from an expensive MPLS link to one
or more public internet connections, usually from different vendors.
- You have multiple hubs in a VPN cluster to allow a waterfall-type
of failover from the primary hub to a succession of backup hubs.
- In a split tunneling scenario, you want only a particular bandwidth-intensive
application to go directly to the internet through the branch’s
DIA link instead of going back to the data center hub through the
VPN tunnel, thus saving WAN bandwidth costs. In the event of a DIA
brownout or blackout, this application traffic fails over to the
data center hub to reach the internet; and if necessary can subsequently
fail over to a second hub to reach the internet.
- In a different split tunneling scenario, you want most of your internet traffic to go out the
DIA link rather than backhaul the traffic to the data center for internet
breakout. However, you want specific applications (that may need additional
scanning or logging by another security device) to go back to the data center.
You create an SD-WAN policy rule to direct those applications to
a primary path to the hub, rather than the normal DIA link as determined by the
default route in the firewall’s route table. In the event of a brownout or
blackout, those applications fail over to take the branch’s DIA interface.
DIA AnyPath introduces the concept of a principal virtual interface, which can include
both DIA links and nested hub virtual interfaces and branch virtual
interfaces (VPN tunnels) that each include their own links. The principal
virtual interface can have a maximum of nine DIA (Ethernet) interfaces, hub virtual
interfaces, and branch virtual interfaces. You assign a Link Tag to a hub when you
add the hub device to Panorama. Assuming you use the SD-WAN plugin,
Auto VPN assigns that Link Tag to the hub virtual interface, which allows you to
specify the tag in a Traffic Distribution profile to control the failover order
among virtual interfaces.
A principal
virtual interface is referred to as a DIA-VIF in CLI commands.
A principal virtual interface can have
interface members that belong to different Security zones. However,
the best practice is to have all member interfaces in the principal
virtual interface belong to the same Security zone. Another best
practice is to have at least one member interface in the principal virtual
interface be of the link type Ethernet, Cable mode, ADSL, Fiber,
LTE, or WiFi.
The following topology example shows
Branch1 with two ISP connections and an MPLS link. Branch1 also
has a Hub1 virtual interface with three VPN tunnels connecting to
Hub1, and a Hub2 virtual interface of three VPN tunnels connecting
to Hub2. Branch1 also has a branch2 virtual interface with three
VPN tunnels connecting to Branch2 and a branch3 virtual interface
with three VPN tunnels connecting to Branch3. The goal of DIA AnyPath
is to configure the order in which DIA can fail over to VPN tunnels
to reach the internet directly or indirectly and thus maintain business
continuity.
When you configure a principal virtual interface, it automatically becomes the default route so
that internet traffic is routed properly to any of the members of the principal
virtual interface (both DIA links and VPN tunnels). The path selection is based on
SD-WAN Path Quality profiles and Traffic Distribution profiles,
which you would set to use the Top Down Priority distribution method to control the
failover order. In the example topology, a Traffic Distribution profile can list the
tag for the principal virtual interface first, then the tag for the Hub1 virtual
interface, and then the tag for the Hub2 virtual interface.
Zooming in to a deeper level of failover priority, a hub virtual interface has multiple tunnel
members, so you need a way to prioritize the failover order of the members, such as
prioritizing that a broadband VPN tunnel be used before an LTE VPN tunnel. You
specify the priority using the VPN Failover Metric in the SD-WAN Interface Profile that you apply to the Ethernet interface.
The lower the metric value, the higher the priority for the tunnel to be selected
upon failover. In the topology example, in the Hub1 virtual interface, a lower VPN
Failover Metric for t11 than for t12 causes internet traffic to fail over to t11
before t12. If multiple tunnels in a virtual interface have the same metric, SD-WAN sends new session traffic to the tunnels in round-robin
fashion.