Cisco SDWAN - Per Tunnel QoS

hi this is in continuation of one of the previous videos where we looked at configuring qos in cisco sd-wan you can check the previous video in the link shown above in this video we will further expand the qs by configuring pertinent qs pertinent qs provides capability of regulating traffic from the hub towards the spokes at a per spoke level since the bandwidth of the hub is higher than the spokes configuring pertonal qs ensures it cannot send excessive traffic to a small spoke with lesser bandwidth and overrun it attached the topology we will use for this demo we have the same three class qos that we configured in the earlier video where we match traffic with dhcp bit ef to the priority queue that is q0 and limit it to 10 of the bandwidth traffic with dscp bit af 41 is mapped to q1 an allocator bandwidth of 30 and finally all the remaining traffic is mapped to q2 and allocated 60 of the bandwidth the bandwidth the hub is 200 mbps while spoken bandwidth is 20 mbps and spoke to bandwidth is 50 mbps these spokes will advertise the downstream bandwidth dynamically and the hub will shape it accordingly for the traffic towards the spoke within this parent shaper the three class based qos that we have configured will provide the necessary priority to the application traffic as defined in a hierarchical manner so let's begin let's first check the available bandwidth towards this book send traffic towards spoke one and we can see that we are getting a bandwidth of 200 mbps towards the spoke let's try to see what's the bandwidth that we get in the reverse direction from the spoke towards the hub and we can see that the bandwidth from the spoke towards the hub is shaped at 20mbps which is the bandwidth the spoke one similarly let's check the bandwidth towards book 2. and here again we can see that the bandwidth from the up to the spoke is about 200 bps and let's try the bandwidth in the reverse direction and we can see that we get a bandwidth about 50 mbps which is the bandwidth that spoke to so let's go to templates let's go to feature templates let's go to the interface template at the hub let's go to the tunnel and here let's turn on pertinent qs once we turn on we get the pertinent aggregator since this is a hub it's an aggregator so we'll turn it on and we'll then turn the tunnel percentage bandwidth to about 80 percent of the bandwidth this is for the ola traffic if you go to the qs section you'll find that the shaping rate configured at the device is 200 mbps let's click update let's quickly check configuration and there you see it's getting configured as hub let's click configure let's go back to templates now edit the spoke template so let's go back to the feature template and let's edit the interface template attached to the spokes let's click tunnel and turn on particular qs will not turn on the aggregator rule because this is the spoke let's hit qs and here we mentioned the ignis shaping rate when we push the template let's go back to tunnel and define our downstream bandwidth so this is the bandwidth that will be advertised by the spoke towards the hub so that the hub can then shape it to the configured bandwidth let's give it a friendly name update so this is spoke 1 so the bandwidth this book is 20 mbps and for spoke 2 the bandwidth is 50 mbps so these are the bandwidth that will be advertised by the spoke towards the hub let's click next let's quickly check our configuration it's configured as spoke and it also has a downstream bandwidth parameter let's go back to our ubuntu machine and check the bandwidth again let's check the bandwidth towards spoke one and now you can see that the bandwidth from the hub towards the spoke is about 20 mbps so let's also send some traffic on tsp bit ef 46 and you can see within the tunnel we are getting about 2 mbps which is 10 of the bandwidth that we allocated to priority queue let's try sending some traffic on f41 088 now you can see you can you get about 30 of the bandwidth which is about 6 mbps and correspondingly you'll see a decrease in the bandwidth in the default queue as well let's also check this towards book 2. now you can see the bandwidth from the hub towards the spoke is about 50 mbps because that's the bandwidth that is getting advertised by the spoke towards the hub let's send the traffic continuously and now send some traffic with the dcp bit set for ef46 and you can see you get about 6 mbps which is 10 of the bandwidth allocated to the link and now let's try sending some traffic on af51 and you see that you get about 30 percent of the bandwidth located to it and a corresponding amount of bandwidth gets reduced from the default queue and once the traffic stops the default queue is able to take up all the available bandwidth across all other queues thus pertaining qs lets you apply a quality of service policy on individual tunnels ensuring that branch offices with smaller throughput are not overwhelmed by larger aggregation sites that's it for this demo and thanks for watching

Channel: Narayan Subramanian

Views: 3,162

Keywords: Cisco, sdwan, viptela, qos, per tunnel qos

Id: yoNqkVIq59U

Length: 8min 59sec (539 seconds)

Published: Mon Jul 27 2020