AsterNOS-VPP Quality of Service(QoS) User Case

ByAlex

Network administrators face a daily dilemma: how to prevent bandwidth-hungry applications from crushing business-critical services. How do you enforce fair bandwidth allocation across multiple tenants? Can you guarantee minimum performance while allowing elastic bursts when capacity is available?

This user case demonstrates how AsterNOS-VPP’s QoS engine addresses these challenges through three real-world scenarios, transforming a congested network into a predictable, high-performance environment.

The Test Environment

Lab Setup

For this case study, we deployed an Asteraix ET2508 gateway running AsterNOS-VPP to simulate common enterprise traffic management scenarios.

Network Components

Device TypeOperating SystemRole in TopologyFunction
ET2508 GatewayAsterNOS-VPPQoS GatewayQoS device under test
Physical PCWindowsInternal ClientClient PC for generating traffic and testing speed.
Physical PCLinux or WindowsTraffic ServerServer in the WAN zone (External PC) running iperf3

Network Topology

AsterNOS-VPP-QoS-user-case-topology

Target Configuration Plan:

Device / Logical InterfaceIP Address / SubnetDefault GatewayNotes / Connection Point
AsterNOS VM (WAN)192.168.200.166/24192.168.200.1Connects via Ethernet1 to Upstream Switch
AsterNOS VM (LAN)172.16.10.1/24–Gateway for Internal Client (Ethernet2 in VLAN 10)
Internal Client PC172.16.10.10/24172.16.10.1Connects to AsterNOS Ethernet2
Traffic Server (External)192.168.200.251/24192.168.200.1Connects to Upstream Switch

Configuration steps

Base Configuration

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

We confirmed the internal client could reach the traffic server (192.168.200.251) before proceeding with QoS testing.

Case 1: Taming Bandwidth Hogs

The Situation
A typical office scenario: video streaming and P2P downloads are consuming all available bandwidth. Critical business applications—email, VoIP, cloud services—are starved for connectivity. Employees are frustrated, productivity suffers.

The Goal
Limit UDP traffic (commonly used by video/P2P) to 10 Mbps in both directions while allowing TCP traffic (used by office applications) to run at full speed.

Configuration Approach

We implemented flow-based policing that intelligently distinguishes between protocol types rather than applying blanket restrictions.

Step 1: Define Traffic Behavior
Created a policing policy using Single Rate Three Color Marker:

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

Parameters: CIR 1250 kbps (10 Mbps), CBS 100000 bytes (burst buffer)

Step 2: Create Classification Rules
Defined ACLs to identify UDP traffic in both directions:

# Upload control (ingress)
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

# Download control (egress)
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

Verified with: sonic(config)# do show acl rule

Step 3: Apply to Interface
Bound policies to the LAN interface:

sonic(config)# interface ethernet 2
sonic(config-if-2)# acl flow-control-ingress
sonic(config-if-2)# acl flow-control-out
sonic(config-if-2)# exit

Test Results

UDP Traffic (Video/P2P Applications):

# Test command
iperf3 -c 192.168.200.251 -u -b 50M -t 10 -i 1
iperf3 -c 192.168.200.251 -u -b 50M -R -t 10 -i 1

Result: Bandwidth strictly capped at 10 Mbps with packet loss—working exactly as designed.

TCP Traffic (Business Applications):

# Test command
iperf3 -c 192.168.200.251 -t 10 -i 1
iperf3 -c 192.168.200.251 -R -t 10 -i 1

Result: Achieved 950 Mbps throughput—completely unaffected by UDP restrictions.

Business Impact

✅ Email, web browsing, and cloud applications run at full speed
✅ Video streaming controlled without complete blocking
✅ User complaints about application performance: eliminated

Case 2: Multi-Tenant Fair Share

The Situation
You’re providing internet connectivity to multiple tenants in a building. Each tenant pays for a 50 Mbps dedicated line. Without enforcement, heavy users consume more than their fair share, causing service complaints from other tenants.
The Goal
Enforce a strict 50 Mbps limit on Ethernet2 in both directions, regardless of traffic type—simulating a dedicated line per tenant.

Configuration Approach

Rather than flow-based control, we implemented port-based rate limiting that applies universally.

Step 1: Remove Previous Policy

sonic(config)# interface ethernet 2
sonic(config-if-2)# no acl flow-control-ingress
sonic(config-if-2)# exit

Step 2: Define Port-Level Behavior

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

Parameters: CIR 6250 kbps (50 Mbps), CBS 100000 bytes

Step 3: Apply Bidirectionally

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

Test Results

Upload Test (Ingress Limit):

iperf3 -c 192.168.200.251 -u -b 100M -t 10 -i 1

Result: Bandwidth capped at 50 Mbps

Download Test (Egress Limit):

iperf3 -c 192.168.200.251 -u -b 100M -R -t 10 -i 1

Result: Bandwidth also capped at 50 Mbps

Business Impact

✅ Each tenant receives exactly the bandwidth they paid for
✅ Fair resource allocation prevents neighbor disputes
✅ Predictable service quality for SLA compliance
✅ Simplified billing tied to committed rates

Case 3: Elastic Bandwidth SLA

The Situation
Your customers need guaranteed minimum bandwidth for business operations but want the ability to burst beyond that during off-peak hours when network capacity is available. Fixed-rate plans are either too expensive (if overprovisioned) or too restrictive (if underprovisioned).
The Goal
Guarantee 10 Mbps baseline (CIR), allow bursts up to 20 Mbps (PIR), and drop traffic exceeding 20 Mbps. This creates a flexible “guaranteed + burstable” service model.

Configuration Approach

We implemented Two-Rate Three-Color Marker (TR-TCM) which provides three traffic zones:

  • Green (Conforming): Within CIR—always forwarded
  • Yellow (Exceeding): Between CIR and PIR—forwarded if capacity available
  • Red (Violating): Above PIR—dropped

Step 1: Remove Previous Policy

sonic(config)# interface ethernet 2
sonic(config-if-2)# no traffic-behavior bind
sonic(config-if-2)# exit

Step 2: Define TR-TCM Behavior

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

Parameters:

  • CIR 1250 kbps (10 Mbps guaranteed)
  • CBS 100000 bytes
  • PIR 2500 kbps (20 Mbps peak)
  • PBS 200000 bytes (must exceed CBS)

Step 3: Apply to Interface

sonic(config)# interface ethernet 2
sonic(config-if-2)# traffic-behavior bind sla-elastic-20m
sonic(config-if-2)# exit

Test Results

“Yellow Zone” Test (Elastic Burst):

iperf3 -c 192.168.200.251 -u -b 15M -t 10 -i 1

Result: Achieved 15 Mbps (exceeding CIR but within PIR)—burst allowed.

“Red Zone” Test (Peak Enforcement):

iperf3 -c 192.168.200.251 -u -b 50M -t 10 -i 1

Result: Capped at 20 Mbps (PIR limit enforced)—excess traffic dropped.

Business Impact

✅ Customers pay lower base rates for guaranteed 10 Mbps
✅ Automatic burst capability during available capacity
✅ No overage billing surprises—hard cap at 20 Mbps
✅ Cost-effective scaling for variable workloads
✅ Competitive differentiation in service offerings

Performance Summary

Verification Command

Check all configured traffic behaviors:

sonic# show traffic-behavior rule

Output:

Behavior Name          Mode      CIR(kbps)  CBS(bytes)  PIR(kbps)  PBS(bytes)
-----------------------------------------------------------------------------------
flow-policer-10m       SR-TCM    1250       100000      -          -
port-policer-50m       SR-TCM    6250       100000      -          -
sla-elastic-20m        TR-TCM    1250       100000      2500       200000

Test Results Matrix

ScenarioTraffic TypeExpected ThroughputActual ResultStatus
Case 1UDP (Limited)10 Mbps10 Mbps✅ Pass
Case 1TCP (Unlimited)950 Mbps950 Mbps✅ Pass
Case 2Any Protocol50 Mbps50 Mbps✅ Pass
Case 3Burst (15M)15 Mbps15 Mbps✅ Pass
Case 3Peak (50M)20 Mbps20 Mbps✅ Pass

Key Takeaways

What This Case Study Demonstrated:

  1. Granular Control Without Collateral Damage
    Flow-based policing controlled problematic applications (video/P2P) while leaving business-critical TCP traffic at line rate—achieving 950 Mbps for office applications.
  2. Fair Multi-Tenant Enforcement
    Port-based limiting provided strict per-tenant bandwidth caps, delivering predictable SLA compliance and eliminating resource contention.
  3. Flexible SLA Models
    TR-TCM enabled cost-effective “guaranteed + burstable” services, allowing customers to burst to 2x their base rate during available capacity.
  4. Production-Grade Performance
    All scenarios achieved line-rate forwarding on standard x86 hardware, demonstrating AsterNOS-VPP’s capability to handle enterprise-scale traffic management.

Real-World Applications:

  • Enterprises: Application prioritization, WAN optimization, cloud traffic management
  • ISPs: Tiered service offerings, bandwidth abuse prevention, congestion management
  • MSPs: Multi-tenant isolation, SLA enforcement, customer-specific policies
  • Cloud Providers: Elastic bandwidth models, cost-effective oversubscription

The Bottom Line
QoS isn’t just about limiting bandwidth—it’s about intelligent allocation. AsterNOS-VPP’s flexible policing engine transforms network capacity into a strategic business asset, enabling differentiated services, predictable performance, and efficient resource utilization.

Support & Resources

Need hardware for your deployment? Check out AsterNOS-VPP compatible hardware:

Or download the free version for x86 platforms and test in your lab environment!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *