This article explains how to apply DSCP marking to CloudBridge appliance when Quality of Service (QoS) is enabled.

Background

Many networking environments use different QoS engine/traffic shaper outside of CloudBridge and hence disable the QoS feature of CloudBridge. Some of the users however would want to use CloudBridge and also perform DSCP markings on the traffic. To achieve this, you should enable both DSCP marking as well as QoS on CloudBridge. This requirement is predominantly requested for WCCP clustering.
Note: Although bandwidth shaping is effectively disabled, the ICA and VoIP will still be lined up in front of the queue and get preferential latency benefit which comes with QoS.

Test Bed Details

• CloudBridge Build – 7.3.0-194
• CloudBridge hardware used – CloudBridge 600 and CloudBridge 4000
• Delay router
• Topology - Linux Host (C1-172.89.1.10), CloudBridge 600, DRT, CloudBridge 4000 (Marking DSCP bits), Linux Host (S1-172.89.40.63)

Configuration Details

• The defaults link limits, 1Gbps for non-SDX platforms and 10Gbps for SDX platforms were retained.
• Two Traffic Shaping policies DSCP1[Priority: Medium (Priority 32), DiffServ/TOS: AF11 - Gold (DSCP 10)] and DSCP2[Priority: High (Priority 128), DiffServ/TOS: AF31 - Gold (DSCP 26)] have been created.

Instructions

Complete the following procedure to apply DSCP marking to CloudBridge appliance when QoS is enabled:

1. Go to Configuration > Optimization Rules > Traffic Shaping Polices.

   

   

   

2. Bind the TSP policies DSCP1 and DSCP2 to Service Classes SC1 and SC2 respectively.

   

   

3. Start traffic for both the Service Classes and increase the number of connections dynamically.
   You can observe that bandwidth is shared equally among the two Service Classes (irrespective of the priority) with the default link speeds and the QoS is not triggered, but the packets are marked with DSCP settings.

The following is a TCP dump captured from a Linux client machine:

[root@qosclient01 ~]# tcpdump -vvv -nn -i eth1 -e host 172.89.40.63 -c 50
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
20:45:23.622150 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x28, ttl  62, id 14578, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.43663 > 172.89.1.10.5001: P 935034457:935035837(1380) ack 3342685248 win 1380
20:45:23.622564 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x28, ttl  62, id 13573, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.43673 > 172.89.1.10.5001: P 942389908:942391288(1380) ack 3339709656 win 1380
20:45:23.622629 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x28, ttl  62, id 15575, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.43710 > 172.89.1.10.5001: P 941697196:941698576(1380) ack 3329269511 win 1380
20:45:23.622690 00:30:48:8f:ff:5f > 00:10:f3:1d:48:ac, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl  64, id 1880, offset 0, flags [DF], proto: TCP (6), length: 40) 172.89.1.10.5001 > 172.89.40.63.43663: ., cksum 0x899f (correct), 1:1(0) ack 1380 win 3882
20:45:23.623092 00:30:48:8f:ff:5f > 00:10:f3:1d:48:ac, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl  64, id 57730, offset 0, flags [DF], proto: TCP (6), length: 40) 172.89.1.10.5001 > 172.89.40.63.43673: ., cksum 0xb20e (correct), 1:1(0) ack 1380 win 4507
20:45:23.622163 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x68, ttl  62, id 12818, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.80 > 172.89.1.10.45707: P 2260193390:2260194770(1380) ack 213427112 win 5520
20:45:23.622170 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x28, ttl  62, id 13977, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.43679 > 172.89.1.10.5001: P 938810016:938811396(1380) ack 3341924192 win 1380
20:45:23.622174 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x68, ttl  62, id 12821, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.80 > 172.89.1.10.45707: P 1380:2760(1380) ack 1 win 5520
20:45:23.622200 00:30:48:8f:ff:5f > 00:10:f3:1d:48:ac, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl  64, id 31925, offset 0, flags [DF], proto: TCP (6), length: 40) 172.89.1.10.45707 > 172.89.40.63.80: ., cksum 0x08ae (correct), 1:1(0) ack 2760 win 24576
20:45:23.622255 00:30:48:8f:ff:5f > 00:10:f3:1d:48:ac, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl  64, id 26194, offset 0, flags [DF], proto: TCP (6), length: 40) 172.89.1.10.5001 > 172.89.40.63.43679: ., cksum 0x8a25 (correct), 1:1(0) ack 1380 win 3839
20:45:23.622285 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x68, ttl  62, id 12823, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.80 > 172.89.1.10.45707: P 2760:4140(1380) ack 1 win 5520
20:45:23.622289 00:10:f3:1d:48:ac > 00:30:48:8f:ff:5f, ethertype IPv4 (0x0800), length 1434: (tos 0x68, ttl  62, id 12825, offset 0, flags [none], proto: TCP (6), length: 1420) 172.89.40.63.80 > 172.89.1.10.45707: P 4140:5520(1380) ack 1 win 5520
20:45:23.622304 00:30:48:8f:ff:5f > 00:10:f3:1d:48:ac, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl  64, id 31926, offset 0, flags [DF], proto: TCP (6), length: 40) 172.89.1.10.45707 > 172.89.40.63.80: ., cksum 0xfde5 (correct), 1:1(0) ack 5520 win 24576

CTX138485 - How to Capture Network Packet Trace on a Linux or Windows CloudBridge Appliance