Cisco SD-WAN Traffic Engineering, route traffic on a different path than routing table, without changing routing table, exactly like PBR (Policy Based Routing) in traditional Cisco routers.

Cisco SD-WAN Traffic Engineering Overview

Traffic engineering is another data plane policy implemented in a centralized policy in vSmart controller. However, it is implemented centrally, but final policy is pushed from the vSmart controller to WAN edge routers. Otherwise, it is not possible to implement a data plane policy in vSmart controller since data traffic never goes through vSmart controller.

Traffic Engineering in SD-WAN Policy Hierarchical
Traffic Engineering in SD-WAN Policy Hierarchical

currently there is a direct connection between site2 and site3. As an example of traffic engineering, let’s change the path of traffic between these two sites in a way that it goes through hub site without manipulating any routes in routing table. in other words, we will change path of the traffic between site2 and site3 with changing next-hop address but in data plane and routing table will not be changed.

Cisco SD-WAN Traffic Engineering Example
Cisco SD-WAN Traffic Engineering Example

Ciscoo SD-WAN Traffic Engineering Configuration

Before starting configuration, let’s check how is the connection between site2 and site3 as an example.

cEdge2#traceroute 172.16.3.1 source 172.16.2.1
% Invalid source address- IP address not on any of our up interfaces
cEdge2#traceroute vrf 10 172.16.3.1 source 172.16.2.1
Type escape sequence to abort.
Tracing the route to 172.16.3.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.3.1 7 msec *  3 msec

as you can see, at the moment we have a direct connections between site2 and site3. We will change the path in a way that it goes through hub site.

In the previous section, we implemented data plane access list and application firewall in centralized policy. Since it is not possible to apply more than one data plane policy to vSmart controller, I will edit this policy also to include our new traffic engineering policy.

I change the Name and Description from ACL_from_Services to ACL_ENG_from_Services to show that it includes both policies.

If you remember, in addition to application firewall, there are some other data plane policies that can be implemented in the vSamrt controller. with clicking on sequence type, you see that QoS and Traffic Engineering are some of these policies.  We choose Traffic Engineering to implement our new data plane policy.

The most important point in implementing traffic engineering is to change TLOC for our target traffic. We change TLOC to hub site for any traffic between WAN sites.

CONFIGURATION -> POLICIES -> Centralized Policy -> Custom Options -> Traffic Policy -> Traffic Data -> ACL_from_Services -> Edit

 Name: ACL_ENG_from_Services
 Description: ACL_ENG_from_Services

 Sequence Type -> Traffic Engineering
  sequence 1: 
   Match:
    Source Data Prefix: 172.16.0.0/24
    Destination Data Prefix: 172.16.0.0/24
   Actios:
    Accept
    TLOC: HUB_LOCATION (created in previous sections)
    VPN: 10
   Default Actioon: Accept

Then we have to activate our new policy.

If we check the configuration difference, it is clear that our previous vSmart data plane policy is edited and new traffic engineering rules are added.

Just to review, remember that this policy is already applied to all spokes in direction from service VPN to WAN infrastructure.

CONFIGURATION -> POLICIES -> Centralized Policy -> vSmart_Policy -> Edit -> Policy Application -> Traffic Data
 ACL_ENG_from_Services
  Site List: SPOKES
  VPN List: VPN 10
  Direction: service

We can also review the configuration by clicking preview button.

viptela-policy:policy
 data-policy _VPN10_ACL_ENG_from_Services
  vpn-list VPN10
    ...
    sequence 31
     match
      source-ip 172.16.2.0/24
      destination-ip 172.16.3.0/24
     !
     action accept
      set
       vpn 10
       tloc-list HUB_LOCATION
      !
     !
    !
  default-action accept
 !
 lists
  ...
  tloc-list HUB_LOCATION
   tloc 1.1.1.101 color public-internet encap ipsec 
   tloc 1.1.1.101 color mpls encap ipsec 
  !
 !
!
apply-policy
 ...
 site-list SPOKES
  data-policy _VPN10_ACL_ENG_from_Services from-service
 !
 ...

Now we can check again the connectivity from site2 to site3 to see if traffic engineering works and traffic goes through hub site.

cEdge2#traceroute vrf 10 172.16.3.1 source 172.16.2.1
Type escape sequence to abort.
Tracing the route to 172.16.3.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.1.101 1 msec 14 msec 2 msec
  2 172.16.3.1 2 msec *  3 msec
cEdge2#
cEdge2#traceroute vrf 10 172.16.3.1 source 172.16.2.1
Type escape sequence to abort.
Tracing the route to 172.16.3.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.2.101 1 msec 1 msec 2 msec
  2 172.16.3.1 3 msec 2 msec *
cEdge2#

We can trace multiple times. As you can see traffic is load shared between internet and mpls path since there are multiple path to reach hub location.

Back to: Implementing Cisco SD-WAN Solutions > Cisco SD-WAN Data plane Policies

Leave a Reply

Your email address will not be published. Required fields are marked *


Post comment