23. cisco SD-WAN Bandwidth Policing - RAYKA (are you a network engineer?)

Cisco SD-WAN Bandwidth Policing makes it possible to limit bandwidth of specific data traffic. It is a data plane policy which can be implemented both in localized and centralized policy.

20. Cisco SD-WAN access list and application firewall

Bandwidth Policing Overview

Although bandwidth policing is a data plane policy, but it can be implemented both through localized and also centralized policy.

We can push the policy directly to WAN edge routers through a localized policy, or it can be implemented via a centralized policy.

If a data plane policy such as bandwidth policing is implemented through a centralized policy, the final policy must be pushed from vSmart controller to WAN edge routers, otherwise it cannot affect data traffic since data traffic never goes through the vSmart controller.

Bandwidth Policing Topology Overview

This is the Topology in which we will implement bandwidth policing. Site1 to Site4 are connected to each other through existing SD-WAN infrastructure. all WAN edge routers are connected to the LAN side through Gigabitethernet3 and with IP Subnet 172.16.11.0/24 to 172.16.14.0/24.

As an example I have connected two computers behind Site1 and Site4 with IP Addresses 172.16.11.10 and 172.16.14.10. our target is to limit upload bandwidth from Site1 to Site4 to a specific value.

We will implement this scenario with both localized and centralized policy.

With localized policy, we apply the policy directly to gigabitethernet3 of the WAN edge router in Site1 in the direction from LAN to WAN. In the topology, it is shown with green color.

With centralized policy, policy will be applied to vSamrt controller but finally it will be pushed from vSamrt controller to Gigabitethernet3 of site1 WAN edge router so it can control data traffic bandwidth from site1 to site4.

QoS Parameters Oveview

Another important point to note is that delay, jitter, and loss are not the only QoS parameters which can control the quality of applications. But bandwidth is probably the most important parameter. Because if the bandwidth is sufficient for an application, we will have no delays, jitter or losses in our data traffic.

In QoS we have two options for bandwidth control. Bandwidth limiting that can be implemented using bandwidth policing or bandwidth shaping tools. Another option is to guarantee bandwidth of a given application, which can be implemented using queuing tools.

Cisco SD-WAN Bandwidth policing using Localized Policy

Before we start configuring bandwidth policing, let’s check how much bandwidth we have from Site1 to Site4 if there is no restriction. We check it with sending ftp traffic from site1 to site4.

As you can see, there is a high bandwidth connection between these two sites.

Configuring Policing using Localized Policy

As the first method, we implement bandwidth policing with localized policy.

In the first step we configure final allowed and restricted bandwidth, which we will limit from Site1 to Site4. Let’s configure it to 200kbps.

CONFIGURATION -> POLICIES -> Localized Policy -> Custom Options -> List -> Policer -> New Policer List
 Policer List Name: 200kbps
 Burst (bps): 200000
 Exceed: Drop
 Rate (bps): 200000

Policy itself will be implemented through access control list policy in localized policy.

CONFIGURATION -> POLICIES -> Localized Policy -> Custom Options -> Access Control List -> Add Access Control List Policy -> Add IPV4 ACL Policy
 Name: SITE1_to_SITE4_ACL
 Description: SITE1_to_SITE4_ACL
 Sequence 1:
  Match:
   Source IP Prefix: 172.16.11.0/24
   Destination IP Prefix: 172.16.14.0/24
  Action:
   Policer: 200kbps
   Counter Name: site1_to_site4_count
  Default Action: Accept

Now we need to apply our access control policy to cEdge1 router.

There is already a localized data plane policy that is applied to the cEdge1 router named cEdge1_Policy. We will edit this policy to add our new access control policy.

CONFIGURATION -> POLICIES -> Localized Policy -> cEdge1_Policy -> Edit -> Access Control List -> Add Access Control List Policy -> Import Existing -> SITE1_to_SITE4_ACL

Now we can preview our final commands that will be copied to cEdge1 router.

policy
 access-list SITE1_to_SITE4_ACL
    sequence 1
     match
      source-ip 172.16.11.0/24
      destination-ip 172.16.14.0/24
     !
     action accept
      policer 200kbps
      count site1_to_site4_count
     !
    !
  default-action accept
 !
  policer 200kbps
   burst 200000
   exceed drop
   rate 200000
  !

But still it is not finished. Now we have to apply our access control list policy to Gigabitethernet3 interface in cEdge1 router and with the direction from LAN to WAN.

And the configuration changes when applying the access control list on gigabitethernet3 are as shown here.

 # apply ACL to cEdge1 VPN 10 Interface
CONFIGURATION -> TEMPLATES  -> Feature -> CSR1000v_Interface_Data_Center
 Section: ACL/QoS
 Ingress ACL - IPv4: On
 IPv4 Ingress Access List: SITE1_to_SITE4_ACL

 # cEdge1
sdwaninterface
 interface GigabitEthernet3
  access-list SITE1_to_SITE4_ACL in

Again we check our bandwidth from site1 to site4 with sending ftp traffic. we expect that bandwidth will be limited to 200kbps as we have configured.

At the same time we can check our bandwidth policy and if it effects traffic through CLI commands.

With command “show sdwan policy access-list-associations”, we can check which policy is applied to which interfaces.

cEdge1#show sdwan policy access-list-associations
                                      INTERFACE
NAME                INTERFACE NAME    DIRECTION
-------------------------------------------------
SITE1_to_SITE4_ACL  GigabitEthernet3  in

With command “show sdwan policy access-list-counters”, we check if traffics are matched with our policy.

cEdge1#show sdwan policy access-list-counters
NAME                COUNTER NAME          PACKETS  BYTES
---------------------------------------------------------------
SITE1_to_SITE4_ACL  default_action_count  1270906  1639796081
                    site1_to_site4_count  1129     1458863

With command “show sdwan policy access-list-policers”, we can check the policy itself and how much traffic is matched with the policy.

cEdge1#show sdwan policy access-list-policers
                    POLICER    OOS      OOS
NAME                NAME       PACKETS  BYTES
------------------------------------------------
SITE1_to_SITE4_ACL  1.200kbps  556      728474

Cisco SD-WAN Bandwidth policing using Centralized Policy

As he second method, we will implement the same scenario but this time through centralized policy.

First we have to remove our current localized policy so we can make sure that traffic is matched with our new centralized policy.

# remove policy from interface 
CONFIGURATION -> TEMPLATES  -> Feature -> CSR1000v_Interface_Data_Center
 Section: ACL/QoS
 Ingress ACL - IPv4: default

 # cEdge1
sdwaninterface
 interface GigabitEthernet3
  no access-list SITE1_to_SITE4_ACL in

Now we can create our new centralized policy to limit bandwidth from site1 to site4.

If you remember, we have many options in the Centralized Policy and in the section “Traffic Policy”, some of which we implemented in the previous sections such as Access List, Traffic Engineering, and Application aware Routing. In this section we choose QoS as our policy type to configure bandwidth policing.

CONFIGURATION -> POLICIES -> Centralized Policy -> Custom Option -> Traffic Policy -> Traffic Data -> Add Policy -> Create New
 Name: SITE1_to_SITE4_Policing
 Description: SITE1_to_SITE4_Policing
 Sequence Type: QoS
  Sequence 1:
   Match:
    Source IP Prefix: 172.16.11.0/24
    Destination IP Prefix: 172.16.14.0/24
   Action:
    policer: 200kbps
    Counter Name: site1_to_site4_count
   Default Action: Accept

Now our new bandwidth policing policy, must be applied to vSamrt controller. Already there is policy with the name of vSmart_Policy applied to vSmart controller. Our new policy will be added to existing vSmart_Policy.

First we have to add it into vSmart controller.

CONFIGURATION -> POLICIES -> Centralized Policy -> vSmart_Policy -> Traffic Rules -> Traffic Data -> Add Policy -> Import Existing -> SITE1_to_SITE4_Policing

Then we need to tell vSamrt controller which sites the policy needs to be copied to and in which direction.

Policy Application -> Traffic Data -> Section: SITE1_to_SITE4_Policing -> New Site List and VPN List -> From Service
 Select Site List: HUB
 Select VPN List: VPN10

Before activating new policy, we preview the commands

viptela-policy:policy
 data-policy _VPN10_SITE1_to_SITE4_Policing
  vpn-list VPN10
    sequence 1
     match
      source-ip 172.16.11.0/24
      destination-ip 172.16.14.0/24
     !
     action accept
      set
       policer 200kbps
      !
      count site1_to_site4_count_-1451988374
     !
    !
  default-action accept
 !
  policer 200kbps
   burst 200000
   exceed drop
   rate 200000
  !
 lists
  site-list HUB
   site-id 101 
  !
  vpn-list VPN10
   vpn 10 
  !
apply-policy
 site-list HUB
  data-policy _VPN10_SITE1_to_SITE4_Policing from-service

Now we can save and activate policy.

Let’s check again effective bandwidth from site1 to site4 with sending ftp traffic from site1 to site4.

At the same time, we check it with CLI command to make sure that the policy is pushed to cEdge1 router and traffics are matched with our policy

With command “show sdwan policy from-vsmart data-policy”, we check if policy is pushed from vSamrt controller to cEdge1 router.

cEdge1#show sdwan policy from-vsmart data-policy
from-vsmart data-policy _VPN10_SITE1_to_SITE4_Policing
 direction from-service
 vpn-list VPN10
  sequence 1
   match
    source-ip      172.16.11.0/24
    destination-ip 172.16.14.0/24
   action accept
    count site1_to_site4_count_469802181
    set
     policer 200kbps
  default-action accept

With command “show sdwan policy data-policy-filter”, we make sure if traffics are matched with our policy.

cEdge1#show sdwan policy data-policy-filter
data-policy-filter _VPN10_SITE1_to_SITE4_Policing
 data-policy-vpnlist VPN10
  data-policy-counter default_action_count
   packets 2
   bytes   317
  data-policy-counter site1_to_site4_count_469802181
   packets 2317
   bytes   3016309
  data-policy-policer 1.200kbps
   oos-packets 764
   oos-bytes   1002122

cEdge1#