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.
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#