Skip to content
Ask AI

QoS-VPP Case

This guide provides a step-by-step tutorial for configuring the Quality of Service (QoS) capabilities of the Asterfusion ET2500 Open Intelligent Gateway running AsterNOS-VPP.

By following this guide, you will learn how to implement progressively advanced traffic control strategies, moving from granular flow control to interface-level management, and finally to complex service level agreements (SLA). The scenarios covered are:

  • Phase 1: Bi-directional Flow-Based Policing (Smart Flow Control): Configuring the gateway to intelligently limit high-bandwidth UDP traffic (e.g., video/P2P) while allowing TCP traffic (e.g., office work) to pass at full speed.
  • Phase 2: Bi-directional Port-Based Rate Limiting (Hard Limiting): Applying a strict bandwidth limit on a specific physical interface, regardless of traffic type, suitable for tenant management.
  • Phase 3: Elastic Bandwidth Management (tr-TCM): Implementing a “Guaranteed + Burstable” bandwidth service using Two-Rate Three-Color Marker (tr-TCM) technology.

***## Preparation: Building the Basic Network

Before applying QoS policies, we must ensure basic connectivity and NAT are working.

-** Lab Components:| Device Type / Operating System | Role in Topology | Key Function in This Guide | | ---------------------------------- | -------------------- | ------------------------------------------------------ | | ET2500 / AsterNOS | QoS Gateway | Device Under Test (DUT) for QoS configuration. | | Physical PC / Windows | Internal Client | Client PC for generating traffic and testing speed. | | Physical PC / Linux or Windows | Traffic Server **| Server in the WAN zone (External PC) running iperf3. |

-** Target Configuration Plan:| Device / Logical Interface | IP Address / Subnet | Default Gateway | Notes / Connection Point | | ------------------------------ | ----------------------- | ------------------- | -------------------------------------------------- | | AsterNOS VM (WAN)| 192.168.200.166/24 | 192.168.200.1 | Connects via Ethernet1 to Upstream Switch | | AsterNOS VM (LAN)| 172.16.10.1/24 | - | Gateway for Internal Client (Ethernet2 in VLAN 10) | | Internal Client PC | 172.16.10.10/24 | 172.16.10.1 | Connects to AsterNOS Ethernet2 | | Traffic Server (External)**| 192.168.200.251/24 | 192.168.200.1 | Connects to Upstream Switch |

Configuration steps** Step 1: Configure Interfaces, Routing and NAT **```bash

Section titled “Configuration steps** Step 1: Configure Interfaces, Routing and NAT **```bash”

sonic# configure terminal sonic(config)# interface ethernet 1 sonic(config-if-1)# ip address 192.168.200.166/24 sonic(config-if-1)# nat-zone 1 sonic(config-if-1)# exit

sonic(config)# vlan 10 sonic(config-vlan-10)# exit sonic(config)# interface vlan 10 sonic(config-vlanif-10)# ip address 172.16.10.1/24 sonic(config-vlanif-10)# exit sonic(config)# interface ethernet 2 sonic(config-if-2)# switchport access vlan 10 sonic(config-if-2)# exit

sonic(config)# ip route 0.0.0.0/0 192.168.200.1

sonic(config)# nat enable sonic(config)# nat pool global_pool 192.168.200.166 sonic(config)# nat binding global_bind global_pool ```** Verification:** Ensure the Internal Client can ping the Traffic Server (192.168.200.251).***

Phase 1: Bi-directional Flow-Based Policing (Smart Flow Control)

Section titled “Phase 1: Bi-directional Flow-Based Policing (Smart Flow Control)”

Goal: Limit UDP traffic (e.g., Video/P2P) to 10 Mbps in both Upload and Download directions, while allowing TCP traffic (e.g., Office work) to utilize the full available bandwidth without restriction.

  • Step 1: Define Traffic Behavior Create a behavior that defines the rate limit (CAR) for UDP traffic.
    • CIR: 1250 KBps.
    • CBS: 100000 Bytes (Burst buffer).
Terminal window
sonic(config)# traffic behavior FLOW_POLICER_10M
sonic(config-traffic-behavior-FLOW_POLICER_10M)# car sr-tcm cir 1250 cbs 100000
sonic(config-traffic-behavior-FLOW_POLICER_10M)# exit
  • Step 2: Define Flow Classification (ACLs) Create two ACLs (Ingress and Egress) to identify UDP traffic. TCP and other traffic will match the default permit rule (or you can explicitly add a permit rule). 1. Configure Ingress ACL (Upload Control)
Terminal window
sonic(config)# access-list L3 FLOW_CONTROL ingress
sonic(config-l3-acl-FLOW_CONTROL)# rule 10 ip-protocol 17 traffic-behavior FLOW_POLICER_10M
sonic(config-l3-acl-FLOW_CONTROL)# exit
  • 2. Configure Egress ACL (Download Control)
Terminal window
sonic(config)# access-list L3 FLOW_CONTROL_OUT egress
sonic(config-l3-acl-FLOW_CONTROL_OUT)# rule 10 ip-protocol 17 traffic-behavior FLOW_POLICER_10M
sonic(config-l3-acl-FLOW_CONTROL_OUT)# exit
  • 3. Verify ACL rule
Terminal window
sonic(config)# do show acl rule

  • Step 3: Apply Policies to Interface Bind both ACLs to the LAN interface (Ethernet2) to enforce bi-directional control.
Terminal window
sonic(config)# interface ethernet 2
sonic(config-if-2)# acl FLOW_CONTROL
sonic(config-if-2)# acl FLOW_CONTROL_OUT
sonic(config-if-2)# exit
  1. UDP Test (Should be Limited): Execute: iperf3 -c 192.168.200.251 -u -b 50M -t 10 -i 1 (Add -R for download test) Expected Result: The bandwidth is strictly limited to ~10 Mbps with high packet loss in both directions.

  1. TCP Test (Should be Unlimited): Execute: iperf3 -c 192.168.200.251 -t 10 -i 1 (Add -R for download test) Expected Result: The bandwidth reaches ~950 Mbps (or line rate), proving that normal office traffic is unaffected.

## Phase 2: Port-Based Bi-directional Rate Limiting Goal:* Limit the** total bandwidth of Ethernet2 to50Mbps in both directions **(Upload/Ingress and Download/Egress). This effectively simulates a 50Mbps dedicated line for a tenant.

-** Step 1: Clean Up Previous Configuration **```bash sonic(config)# interface ethernet 2 sonic(config-if-2)# no acl FLOW_CONTROL sonic(config-if-2)# exit

-** Step 2: Define Port Limit Behavior **-** CIR:**6250 KBps.
```bash
sonic(config)# traffic behavior PORT_POLICER_50M
sonic(config-traffic-behavior-PORT_POLICER_50M)# car sr-tcm cir 6250 cbs 100000
sonic(config-traffic-behavior-PORT_POLICER_50M)# exit

-** Step 3: Bind to Interface (Both Directions)** Bind the behavior to both Ingress (default) and Egress directions to enforce a symmetric speed limit.

Terminal window
sonic(config)# interface ethernet 2
sonic(config-if-2)# traffic-behavior bind PORT_POLICER_50M
sonic(config-if-2)# traffic-behavior bind egress PORT_POLICER_50M
sonic(config-if-2)# exit
  1. ** Upload Test (Ingress Limit):** Execute: iperf3 -c 192.168.200.251 -u -b 100M -t 10 -i 1** Expected Result:** Bandwidth capped at**~50Mbps **.

  1. ** Download Test (Egress Limit):** Execute: iperf3 -c 192.168.200.251 -u -b 100M -R -t 10 -i 1** Expected Result:** Bandwidth is also capped at**~50Mbps **.

***

Phase 3: Elastic Bandwidth Management (tr-TCM)

Section titled “Phase 3: Elastic Bandwidth Management (tr-TCM)”

Goal: Implement a flexible SLA policy where the user is guaranteed 10Mbps (CIR) but allowed to burst up to 20Mbps (PIR). Traffic exceeding 20Mbps is dropped.

  • Step 1: Clean Up Previous Configuration
Terminal window
sonic(config)# interface ethernet 2
sonic(config-if-2)# no traffic-behavior bind
sonic(config-if-2)# exit
  • Step 2: Define Two-Rate Three-Color Marker (tr-TCM)
    • CIR (Guaranteed): 1250 KBps.
    • PIR (Peak): 2500 KBps.
    • PBS: 200000 Bytes (Peak buffer, must be > CBS).
Terminal window
sonic(config)# traffic behavior SLA_ELASTIC_20M
sonic(config-traffic-behavior-SLA_ELASTIC_20M)# car tr-tcm cir 1250 cbs 100000 pir 2500 pbs 200000
sonic(config-traffic-behavior-SLA_ELASTIC_20M)# exit
  • Step 3: Bind to Interface
Terminal window
sonic(config)# interface ethernet 2
sonic(config-if-2)# traffic-behavior bind SLA_ELASTIC_20M
sonic(config-if-2)# exit
  1. Test “Yellow” Zone (Elastic Burst): Execute: iperf3 -c 192.168.200.251 -u -b 15M -t 10 -i 1 Expected Result: Bandwidth reaches 15Mbps (exceeding CIR but within PIR), showing allowed burst.

  1. Test “Red” Zone (Peak Cap): Execute: iperf3 -c 192.168.200.251 -u -b 50M -t 10 -i 1 Expected Result: Bandwidth is strictly capped at ~20Mbps (PIR limit).

***## Summary of QoS Policies

After configuring the scenarios above, you can verify all created traffic behaviors in the system database. This confirms that the rate-limiting parameters (CIR, PIR, CBS, PBS) are correctly defined.

-** Command:**```bash sonic# show traffic-behavior rule

-** Output Verification:** Ensure that the modes (`SR_TCM` vs `TR_TCM`) and rate values match your design requirements.
![](/media/archbee/xCLWAlyWFhPk-Ifw1Kgfs-20251223-063611.png)***
## Conclusion
This guide has verified the comprehensive QoS capabilities of AsterNOS-VPP, enabling granular traffic management from basic port limits to complex flow-based and elastic bandwidth strategies.