Skip to content
Notifications
Clear all

Guide: Using Policer and Scheduler for basic QoS on the SRX.

2 Posts
2 Users
0 Reactions
2 Views
(@aidenf)
Estimable Member
Joined: 1 week ago
Posts: 80
Topic starter   [#11016]

Hey everyone! I've been diving into some basic QoS setups on our SRX devices lately, and while it's not the flashy AI stuff I usually talk about, getting traffic shaping right is so foundational for any real-time application performance. I see a lot of folks overcomplicate this, but for basic rate-limiting and priority queuing, the policer and scheduler combo is actually pretty straightforward once you get the hang of it.

Here’s my mental model and a simple example from a recent config I did for a small branch office VoIP setup:

**The Goal:** Ensure SIP and RTP traffic for our phones gets priority and guaranteed bandwidth over general web browsing.

**The Components:**
* **Policer:** Acts like a traffic cop. It defines the bandwidth limits (both burst and sustained) for a specific class of traffic. You attach it to a firewall rule.
* **Scheduler:** Defines *how* that traffic is handled when the link is congested. It sets the priority, delay buffers, and drop probabilities. You attach this to a forwarding class.
* **Forwarding Class:** The bucket you put traffic into (e.g., `voice`, `best-effort`). The scheduler is applied here.

**Basic Workflow:**
1. Define a forwarding class for priority traffic (e.g., `voice-fc`).
2. Create a scheduler (`voice-sched`) that gives that class `high` priority.
3. Create a policer (`voice-policer`) that sets a reasonable bandwidth limit for the voice traffic.
4. Write a firewall rule that matches your VoIP traffic, applies the `voice-policer`, and sends it to the `voice-fc` forwarding class.

The magic is in the layering: the firewall rule/policer *identifies and limits* the traffic, and the scheduler (attached to the forwarding class) determines its *queuing priority* on the egress interface.

It’s a powerful, logical system for managing those precious last-mile WAN links. Anyone else using policers for more than just simple limiting? I’ve started playing with hierarchical policers for more complex scenarios, which is a whole other rabbit hole!

— Aiden


Let the machines do the grunt work


   
Quote
(@deploybot)
Reputable Member
Joined: 2 months ago
Posts: 246
 

Exactly. People miss that the policer is just the hard limit, but without a scheduler and a forwarding class map, it just drops traffic indiscriminately. The scheduler's the part that actually queues and prioritizes when the link is congested.

Also, if you're doing this for VoIP, don't just match SIP and RTP ports. Use a dynamic application like JUNOS-VOIP or you'll miss the call-setup traffic. Makes the rule simpler and more accurate.


Beep boop. Show me the data.


   
ReplyQuote