Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

QoS/TE configuration and testing


Table of Contents
minLevel2


This summary report contains traffic policing and shaping configuration proposals in case of Junos CCC L2VPN provisioning. The principal requirements for each circuit refer to the policing and shaping. Moreover, hard policing should be avoided in order to prevent frequent packet losses due to out-of-profile traffic, whereas output shaping should be deployed in order to shape traffic and to introduce traffic latency as a trade-off to traffic drop.

Nevertheless, policing is highly encouraged as a result of a notion that user can easily saturate individual circuit and inadvertently affect other circuits traversing the same links and devices. Shaping process should be done as a first step towards prevention of circuit congestion and it should behave as a form of soft policing where latency addition through buffering acts like a prevention of packet drop.

This summary is organized as follows: Section 1 contains policer configuration and its application on the interface and LSP level. Section 2 contains shaping configuration in relation to Hierarchical QoS (HQoS). 

Policer configuration proposal and implementation approach

The use of traffic policer can be specified in several ways, each producing identical results concerning the limitation of bandwidth over the L2VPN circuit. Basic policer configuration is provided in the following inset containing bandwidth limit and burst size limit parameters.

[edit firewall]

policer policer-name {

if-exceeding {

bandwidth-limit bandwidth-value;

burst-size-limit burst-value;

}

then {

discard;

}

}

 

family any {

filter filter-name {

term term-name {

then {

policer police-name;

accept;

}

}

}

}

 

Policer should be applied as a part of the filter inside which policer is referenced. Family any is specified in order to generalize the traffic family since the traffic could be IPv4, IPv6, MPLS or CCC depending on the policer application.

Such configured filter containing the policer may be applied on the interface (specifically, on the unit level) or on the LSP level. Both configuration scenarios are depicted in the following insets, respectively.

[edit interface interface-name]

flexible-vlan-tagging;

mtu 9000;

encapsulation flexible-ethernet-services;

unit unit-number {

encapsulation vlan-ccc;

vlan-id vlan-number;

input-vlan-map pop;

output-vlan-map push;

filter {

input filter-name;

}

}

 


[edit protocols mpls label-switched-path LSP-name]

 

to loopback-address;

bandwidth bandwidth-value ######### should be the same one as in policer

least-fill;

policing filter filter-name

 

 

As it was mentioned, both configurations provide the same results, so from the traffic policing standpoint, either configuration may be applied. Bearing in mind that CCC L2VPN circuits are being used and that they allocate a single dedicated LSP for individual circuit, it may more structured to use LSP policing instead of policing on the ingress interface. Main reason for this proposal is the fact that single interface is used for multiple unit configuration which provide ingress into CCC dedicated LSPs. Since circuit establishment depends on specification of transmit and receive LSPs, policer filter must be applied on both sides of the circuit. This is also a mandatory with interface unit policing filters.

Lab testing was performed to verify the configuration and to see how policer parameters affect the traffic passing over the circuit. Lab topology is given in the Fig. 1.

Fig. 1 Policer test topology.

Iperf was used to measure bandwidth between lab compute nodes. Policer was configured with bandwidth-limit of 50Mbps and burst-size limit of 3.125kB. Burst size limit was chosen based on 5ms rule suggesting that 5ms bursts are allowed in relation to the bandwidth limit of 50Mbps giving 3.125kB burst size. Iperf TCP test showed the following results:

taas@lab1-compute0:~$ iperf -c 172.30.0.2 -P 6

------------------------------------------------------------

Client connecting to 172.30.0.2, TCP port 5001

TCP window size: 85.0 KByte (default)

------------------------------------------------------------

[ 8] local 172.30.0.1 port 39076 connected with 172.30.0.2 port 5001

[ 3] local 172.30.0.1 port 39071 connected with 172.30.0.2 port 5001

[ 4] local 172.30.0.1 port 39072 connected with 172.30.0.2 port 5001

[ 5] local 172.30.0.1 port 39073 connected with 172.30.0.2 port 5001

[ 6] local 172.30.0.1 port 39074 connected with 172.30.0.2 port 5001

[ 7] local 172.30.0.1 port 39075 connected with 172.30.0.2 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-11.8 sec 768 KBytes 532 Kbits/sec

[ 8] 0.0-13.0 sec 640 KBytes 405 Kbits/sec

[ 5] 0.0-13.0 sec 768 KBytes 483 Kbits/sec

[ 7] 0.0-13.4 sec 768 KBytes 471 Kbits/sec

[ 4] 0.0-13.4 sec 896 KBytes 549 Kbits/sec

[ 6] 0.0-13.8 sec 1.00 MBytes 608 Kbits/sec

[SUM] 0.0-13.8 sec 4.75 MBytes 2.89 Mbits/sec

 

Measured bandwidth of 2.89Mbits/sec is significantly below bandwidth limit configured in the policer. The measured low bandwidth is the result of Iperf traffic and its bursty nature. In the following table, the results are depicted based on the burst-size limit parameter whereas bandwidth-limit was constant at 50Mbps:

 

Burst-size limit

Burst period

Measured bandwidth

Test 1

3.125kB

5ms

2.89 Mbits/sec

Test 2

100kB

16ms

21.1 Mbits/sec

Test 3

200kB

32ms

35.6 Mbits/sec

Test 4

500kB

80ms

45.6 Mbits/sec

 

Given the bursty nature of Iperf TCP traffic, the increase of burst size limit enables that measured bandwidth converges towards bandwidth limit value which was chosen for these tests to be 50 Mbps.

In order to overcome the Iperf TCP traffic bursty nature, further tests were carried out using Iperf UDP traffic with constant 50Mbps stream. The results are shown in the following inset:

taas@lab1-compute0:~$ iperf -c 172.30.0.2 -u -b 50m

------------------------------------------------------------

Client connecting to 172.30.0.2, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 208 KByte (default)

------------------------------------------------------------

[ 3] local 172.30.0.1 port 51597 connected with 172.30.0.2 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 59.7 MBytes 50.0 Mbits/sec

[ 3] Sent 42554 datagrams

[ 3] Server Report:

[ 3] 0.0-10.0 sec 58.0 MBytes 48.6 Mbits/sec 0.002 ms 1214/42553 (2.9%)

[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

Measured bandwidth is 48.6 Mbps and there are some lost packets in the process. For UDP tests, increasing burst size does not result in increasing the measured bandwidth as it was the case with TCP traffic. Finally, the conclusion can be made that the configured policer is operational and depending on the policer parameters it can easily be adapted to the various traffic types. 

Traffic shaping configuration proposal

As a result of each user having its own circuit and there is a requirement for traffic shaping instead of doing hard policing, hierarchical QoS deployment is scalable and flexible approach for this use case as it allows configuration of shaping rate for each circuit egressing on the particular physical interface. Specifically, each interface unit may be configured with specific parameters regarding traffic classification, priority and guaranteed rate. For the purpose of this use case, shaping rate or peak information rate (PIR) is the crucial parameter determining shaping features.

Hierarchical QoS (HQoS) allows flexible per-unit deployment and configuration of shaping rates as well as committed information rate (CIR) and transmission rate per queue. For the purpose of this deployment and testing, shaping has to be deployed on an interface and on a unit level. Thus, putting interface in PIR-only 1mode according to which bandwidth is distributed proportionally to configured shaping-rate parameter.

HQOS configuration is depicted in the following inset:

[edit interfaces]

Interface-name {

hierarchical-scheduler;

flexible-vlan-tagging;

mtu 9000;

encapsulation flexible-ethernet-services;

unit unit-number {

encapsulation vlan-ccc;

vlan-id 10;

input-vlan-map pop;

output-vlan-map push;

}

unit unit-number {

encapsulation vlan-ccc;

vlan-id vlan-number;

input-vlan-map pop;

output-vlan-map push;

}

}

 

[edit class-of-service]

traffic-control-profiles {

name {

shaping-rate value;

}

}

 

interface

interface-name {

unit unit-number {

output-traffic-control-profile name

}

}

}

 

Proposed configuration for the use case would be to configure physical interface PIR parameter and the shaping rates for each traffic-control-profile which would contain shaping-rate for the specific circuit. Proposed configuration is depicted in the following inset:

[edit interfaces]

ge-0/2/0 {

hierarchical-scheduler;

flexible-vlan-tagging;

mtu 9000;

encapsulation flexible-ethernet-services;

unit 10 {

encapsulation vlan-ccc;

vlan-id 10;

input-vlan-map pop;

output-vlan-map push;

}

unit 20 {

encapsulation vlan-ccc;

vlan-id 20;

input-vlan-map pop;

output-vlan-map push;

}

}

 

 

[edit class-of-service]

traffic-control-profiles {

PIR-1000M-IF{

shaping-rate 100m;

}

}

 

traffic-control-profiles {

PIR-100M-unit10{

shaping-rate 50m;

}

}

traffic-control-profiles {

PIR-200M-unit20{

shaping-rate 50m;

}

}

 

interface

ge-0/2/0 {

output-traffic-control-profile PIR-1000M-IF

unit 10 {

output-traffic-control-profile PIR-100M-unit10

}

Unit 20 {

output-traffic-control-profile PIR-200M-unit20

}

}

}

 

From the previous configuration, PIR is configured on the physical interface level, e.g. 1000Mbps, whereas unit 10 and 20 have separate shaping rates 100Mbps and 200Mbps, respectively. Consequently, two scenarios are distinguished. First, when there is undersubscribed bandwidth on the physical interface, i.e. when the sum of shaping rates of all units is less than PIR configured on the physical level. Second, when there is an oversubscription of PIR resulting from the sum of all shaping rates on units being higher than PIR on physical interface.

Undersubscribed PIR results in bandwidth excess and proportional sharing based on unit PIRs, whereas oversubscribed PIR scenario results in correcting unit PIRs again proportionally based on unit PIRs in a manner that they are decreased since overall bandwidth cannot be higher that the physical interface PIR.

Testing topology (Fig. 2) is similar like the one depicted in Fig. 1, but with following differences:

  • Juniper MX80 chassis currently deployed in GTS labs do not support HQoS configuration on user interface, i.e. on gigabit ports. Therefore, separate lab scenario was built consisting of Juniper MX104 and Juniper MX10 chassis with MIC-3D-20SFP-E line cards with HQOS support;

  • No VLAN tagging was used on user ports toward lab-test hosts;

  • MPLS LSPs are established over gigabit ports instead over ten gig ports as was the case in GTS lab.

Fig. 2 Hierarchical QoS test topology.

Previous differences between GTS and HQoS lab are not significant resulting in the validity of the results received from these tests. The main reason for building another lab topology was the lack of HQoS support on MX80s deployed in the GTS lab.

The results are shown in the inset below. As with policer testing and bandwidth measuring, Iperf tool was used and TCP traffic was investigated. Measured bandwidth converges towards shaping rate, but as a result of bursty TCP traffic generated by the Iperf, the tests failed to show configured shaping rate value, instead measured bandwidth is somewhat lower.

Accepted connection from 172.16.100.1, port 10944

[ 5] local 172.16.100.2 port 5201 connected to 172.16.100.1 port 10945

[ ID] Interval Transfer Bandwidth

[ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec

[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec

[ 5] 2.00-3.00 sec 3.43 MBytes 28.7 Mbits/sec

[ 5] 3.00-4.00 sec 5.20 MBytes 43.6 Mbits/sec

[ 5] 4.00-5.00 sec 5.20 MBytes 43.6 Mbits/sec

[ 5] 5.00-6.00 sec 5.20 MBytes 43.6 Mbits/sec

[ 5] 6.00-7.00 sec 5.20 MBytes 43.6 Mbits/sec

[ 5] 7.00-8.00 sec 5.26 MBytes 44.1 Mbits/sec

[ 5] 8.00-9.00 sec 5.15 MBytes 43.2 Mbits/sec

[ 5] 9.00-10.00 sec 5.20 MBytes 43.6 Mbits/sec

[ 5] 10.00-10.23 sec 1.18 MBytes 43.1 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

 

Similar results are observed if configured shaping rate for interface unit is changed to 100Mbps, which is shown in the following output:

Connecting to host 172.16.100.2, port 5201

[ 4] local 172.16.100.1 port 24320 connected to 172.16.100.2 port 5201

[ ID] Interval Transfer Bandwidth

[ 4] 0.00-1.00 sec 256 KBytes 2.10 Mbits/sec

[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec

[ 4] 2.00-3.00 sec 8.75 MBytes 73.4 Mbits/sec

[ 4] 3.00-4.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 4.00-5.00 sec 10.5 MBytes 88.1 Mbits/sec

[ 4] 5.00-6.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 6.00-7.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 7.00-8.00 sec 10.5 MBytes 88.1 Mbits/sec

[ 4] 8.00-9.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 9.00-10.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 10.00-11.00 sec 10.4 MBytes 87.0 Mbits/sec

[ 4] 11.00-11.74 sec 7.75 MBytes 87.4 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth

[ 4] 0.00-11.74 sec 100 MBytes 71.4 Mbits/sec sender

[ 4] 0.00-11.74 sec 100 MBytes 71.4 Mbits/sec receiver

 

 

It is worth to highlight the comparison between the policing and shaping results. In case of policing, it was necessary for Iperf traffic to significantly increase burst size in order to accept TCP traffic and to measure policed-rate bandwidth. On the other hand, for HQoS tests as a result of shaping and automatic allocation of available buffer space, measured bandwidth was already close to PIR values. Therefore, depending on the level of hard policing necessary (meaning how much bursting is allowed), shaping and policing may have similar effects on the traffic. 

Conclusion

In order to perform more accurate measurement of bandwidth, different tools are needed to verify to what extent the deployed QoS policers and shapers affect end-to-end bandwidth. Such tools would need to provide more granular traffic generation control, i.e. exact bandwidth, burst size, etc. However, for the purpose of QoS configuration validation testing, the conducted tests have shown that proposed policer and HQoS configuration is operational and appropriately addresses requirements for use cases in question.

1 PIR-only mode – Interface is in this mode if none of the child interfaces are configured with guaranteed-rate parameter, i.e. when they do not have CIR parameter configured.