Cisco SDWAN - Application-Aware Routing

  • Tue, Feb 6, 2024
  • 5-minute read

Hi buddies! 😉
Today we’re going to talk about Cisco SDWAN Application-Aware Routing! I’ll cover this topic from both theory and practical points of view. Are you ready? Let’s goooo 😊

Application-Aware Routing

This is one of the coolest think about Cisco SDWAN technology, Edges will take routing and forwarding decisions based on path performances.
Application-aware routing monitors network and path properties within the data plane tunnels connecting Cisco IOS XE Catalyst SD-WAN devices. It leverages this data to calculate the most efficient routes for data traffic. These properties encompass factors such as packet loss, latency, jitter, as well as the load, cost, and bandwidth of a link.

Disclaimer

DYOR (Do Your Own Research). Test the procedure before apply changes into your production environment.

Topology

In today’s lesson we’ll use the following topology:
01

In this topology we have:

  • 2 Hubs: VITORCHIANO and PALMANOVA
  • 2 Spokes: FUCINO and SPOKE_SAT
DEVICE ROLE SYSTEM-IP SITE-ID
vManage vManage 10.150.0.20 1
vBond vBond 10.150.0.21 1
vSmart vSmart 10.150.0.22 1
FUC_HUB_1 SPOKE 10.150.0.111 1
FUC_HUB_2 SPOKE 10.150.0.112 1
VIT_HUB_1 HUB 10.150.0.121 2
VIT_HUB_2 HUB 10.150.0.122 2
SPOKE_SAT_1 SPOKE 10.150.0.131 3
SPOKE_SAT_2 SPOKE 10.150.0.132 3
PAL_HUB_1 HUB 10.150.0.141 4
PAL_HUB_2 HUB 10.150.0.142 4

Please note that we’ll work only with the following sites: SPOKE_SAT and VITORCHIANO.

In the SPOKE_SAT we have the following TLOC colors:

  • BLUE –> the preferred one –> represent the KU_SAT connection
  • BRONZE –> represent the KA_SAT connection

In the VITORCHIANO site, one of the hub of our infrastructure, we have the following TLOC colors (build over Loopbacks):

  • MPLS –> the preferred one –> represent the MPLS connection –> loopback advertised over MPLS link
  • LTE –> represent the LTE connection –> loopback advertised over MPLS link
  • BLUE –> represent the KU_SAT connection –> loopback advertised over KU link
  • BRONZE –> represent the KA_SAT connection –> loopback advertised over NPLS link

Why tunnels over a loopback? I suggest you to read this Cisco whitepaper that explain the use cases.
For my project, the reason is the following:
“If the WAN Edge router is deployed inline, and traffic needs to be routed from one interface in VPN 0 to another interface in VPN 0, this is another use case to use tunnel configurations on a loopback interface. The reason the tunnel interface has to be removed from the physical interface is because once a tunnel is applied there, it becomes a hardened interface and will only allow certain traffic in/out and can break connectivity depending on what traffic is being routed”

One more thing, about TLOCs, color restrict has been enabled.

Control Connections

Let’s see the status of control connections from sites to controllers:

SPOKE_SAT cEdges have tunnels to Controllers over both TLOCs:
02

  • 2 tunnels to vBond, one per each TLOC
  • 2 tunnels to vSmart, one per each TLOC
  • 1 tunnel to vManage, in this case the TLOC color is BLUE that represent the KU connection, the preferred for this site. Remember that KU > KA.

VITORCHIANO cEdges have tunnels to Controllers over all the TLOCs (4):
03

  • 4 tunnels to vBond, one per each TLOC
  • 4 tunnels to vSmart, one per each TLOC
  • 1 tunnel to vManage, in this case the TLOC color is MPLS that represent the MPLS connection, the preferred for this site.

BFD Sessions

Let’s see the status of BFD sessions between SPOKE_SAT and VITORCHIANO:

SPOKE_SAT cEdges have 4 tunnels to VITORCHIANO:
04

Please note that the other BFD sessions are related to the other Hub called PALMANOVA, which will not be used in this blog post.

VITORCHIANO cEdges have 4 tunnels to SPOKE_SAT:
05

Remember that we enabled the color restrict, so it’s ok to have “only” these tunnels and not a full mesh topology.

Service VPN

In our topology we configured only one Service VPN, defined with ID 20.

SPOKE_SAT VPN 20 subnet: 10.3.3.0/24, the client has the following IP address 10.3.3.10 VITORCHIANO VPN 20 subnet: 10.2.3.0/24, the client has the following IP address 10.2.3.10

Here are the OMP routes received by SPOKE_SAT cEdges: 06

Here are the OMP routes received by VITORCHIANO cEdges: 07

As you can see, the devices are advertising the VPN 20 subnets.
Now, verify that the host in SPOKE_SAT can reach the VITORCHIANO host:
08

Great, there is reachability between the hosts!

Packet-Loss generator

EVE-ng allow you to introduce a device that can introduce: jitter, delay and packet-loss in one or more links.
To install it, please do the following:

  1. Go to: https://www.eve-ng.net/repo/pool/main/e/eve-ng-addons-netem/
  2. Download this file: eve-ng-addons-netem_2.0.3-61_amd64.deb
  3. Copy the file into EVE-ng VM, I put the file here: /opt/unetlab/addons/qemu/
  4. SSH to EVE-ng VM and move to the destination folder, then install it with: sudo dpkg –install eve-ng-addons-netem_2.0.3-61_amd64.deb

Go to EVE-ng GUI and add a new node, you will be able to add the “Linux” node: 09

Perfect. I put 2 traffic generator in my topology: one after KU connection and one after KA connection.
I applied a delay of 300ms to the KA traffic generator in order to recognize the path different when we’ll activate the Application-Aware Routing policy.

TEST

Perfect! Have fun with this feature and make sure to take always the most performant path! 😉

Thanks for your time I hope that you’re enjoying my blog!
If you have some questions, please drop me a message through social networks!😊
👈 You can find the relative icons here on the left of the page

Riccardo

Cisco300-415Cisco SDWAN