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.
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.
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 msecas 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: AcceptThen 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: serviceWe 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.