Palo Alto QoS & Traffic Shaping on PAN-OS: — Classes, Profiles, Policies & the Egress-Only Rule

① Why shape traffic at all — the full-link problem

Picture Sneha, an L2 engineer at Infosys, on a Monday morning. The Pune branch has a single 50 Mbps internet link (203.0.113.10 on the outside, the LAN sitting on 10.20.0.0/16). At 9 a.m. the nightly cloud backup is still running, and a sales team's voice call to a client keeps breaking up. The link isn't broken — it's full, and every flow is fighting for the same pipe with no referee.

This is the problem QoS exists to solve. QoS does not add bandwidth — it can't conjure more Mbps. What it does is decide who waits when the link is congested. You carve the link into lanes (PAN-OS calls them classes), give the voice call a guaranteed, high-priority lane, and cap the backup so it can only use what's left over.

On PAN-OS, QoS is built from three pieces that you'll meet in order: a QoS profile (defines the lanes — up to 8 classes, each with guaranteed and maximum egress bandwidth and a priority), a QoS policy (classifies each session into a class, by App-ID, service, source or DSCP), and the QoS interface (where you attach the profile and where shaping actually happens). Miss any one of the three and nothing shapes.

Here is the rule to tattoo on your brain: QoS is always enforced on the egress interface — the interface a packet leaves from. PAN-OS states it plainly: "QoS is always enabled and enforced on the egress interface for a traffic flow." Shaping is about controlling a queue as packets go out the door; you can't un-send bits that have already arrived. So enabling QoS on your internet-facing interface shapes your upload; to influence the download, you shape on the internal interface where that return traffic egresses toward the LAN.

The four ideas QoS hinges on

Tap each card — these four are what every PAN-OS QoS question, and every real ticket, comes back to.

② The QoS profile — eight classes, guaranteed vs max, and the real-time lane

The QoS profile is where you define the lanes. You build it at Network > Network Profiles > QoS Profile and click Add. At the top you set the profile's overall Egress Max and Egress Guaranteed. Then you add up to eight classes (Class 1 through Class 8), and for each class you set its own Egress Guaranteed, Egress Max, and — the important one — its Priority.

The four priorities are real-time, high, medium and low. Real-time is special: it's the reserved ambulance lane, meant for latency-sensitive traffic like voice and video (SIP/RTP). Under congestion, the firewall serves the real-time class's queue first, keeping jitter and latency low. The other priorities share the remaining bandwidth in weighted order. A classic design is Class 1 = real-time for voice, Class 2 = high for business SaaS, and Class 8 = low for backups.

Guaranteed vs max is the part students fumble, so be precise. Egress Guaranteed is a floor — it's the bandwidth a class is assured when the link is congested, but it is not pre-reserved while idle (other classes can borrow it until the owner needs it). Egress Max is a ceiling — the most a class may ever use. Set a class's Egress Max to 0 and you mean "no limit" for that class. The art is sizing guarantees so they add up to less than the link.

admin@PA-VM> show qos interface ethernet1/1

Interface: ethernet1/1
  Number of Subinterface(s): 0
  Maximum egress bandwidth: 50000 kbps
  Default profile (clear text): WAN-Shaping-50M
  Class    Priority    Egress Max(kbps)   Egress Guaranteed(kbps)
  class1   real-time   0 (unlimited)      10000
  class2   high        0 (unlimited)      20000
  class4   medium      0 (unlimited)      0          <-- default/unclassified
  class8   low         15000              0

③ The QoS policy — classify by App-ID, service, source or DSCP

A profile only defines empty lanes. The QoS policy is what puts each session into a lane. You build it at Policies > QoS and Add a rule. On the matching tabs you can classify by Source (zone/address/user), Destination, Application (App-ID), Service/URL Category, and DSCP/ToS. Then, under the rule's settings, you pick the QoS Class (1–8) that matching traffic should receive. That's the whole job: match traffic → assign a class.

App-ID is the powerful matcher — you can say "sip and rtp go to Class 1" or "web-browsing goes to Class 2" by name, regardless of port. But here's the catch that surprises everyone: App-ID isn't instant. When a session starts, the firewall needs the first several packets to identify the app. Until then the session is unknown and rides the default class. For long flows (a backup, a video call) this is invisible; for tiny, short-lived sessions it matters.

QoS can also mark DSCP, not just read it. In the QoS policy you can set an outbound DSCP value — for example, stamp voice with EF (46) — so that every router and switch after the firewall keeps honouring that priority end-to-end. Crucially, because the firewall classifies on the decrypted session, DSCP marking works on SSL-decrypted traffic too: even encrypted apps you've decrypted can be identified by App-ID and then marked on the way out.

That leads to the clear-text vs tunneled split. On clear-text (and decrypted) traffic the firewall sees the real App-ID and classifies precisely. But for traffic inside an IPsec or GRE tunnel, the inner application is encrypted — App-ID is blind to it. There you classify by the outer DSCP/ToS value instead, and you attach a separate profile for tunneled traffic. When you enable QoS on the interface, PAN-OS lets you set one default profile for Clear Text traffic and another for Tunneled traffic — they're handled independently.

④ Verify, the gotchas, and the PCNSE angle

Configuring QoS without verifying it is how you get a 2 a.m. callback. After your Commit, prove it three ways. First, the live graph: Network > QoS, then Statistics on the interface — you'll see real-time per-class bandwidth, so you can watch Class 1 fill with voice and Class 8 get squeezed during the backup window. Second, the CLI. Third, generate real congestion and re-check, because QoS does nothing on an idle link.

admin@PA-VM> show qos interface ethernet1/1 throughput 0
admin@PA-VM> show qos interface ethernet1/1

Class      Priority   Egress(kbps)   Guaranteed(kbps)   Current(kbps)   Drops
class1     real-time  0              10000              8420            0
class2     high       0              20000              19500           2
class4     medium     0              0                  3100            0
class8     low        15000          0                  14980           1875
  (class8 = backup, capped at 15 Mbps, dropping excess; class1 voice clean)

Three production gotchas to carry into every QoS job. (1) Egress only — you can't shape the download on the WAN interface; shape it on the LAN side. (2) First packets are unclassified — App-ID needs a few packets, so brand-new short sessions briefly ride Class 4; design for it. (3) Guaranteed math — if the sum of class guarantees exceeds the link's egress max, nothing is guaranteed. A bonus one: tiny QoS classes on a busy box used to cost throughput, which is why PAN-OS 11.1 introduced Lockless QoS on the PA-3400 and PA-5400 series so QoS no longer caps performance there.

For the PCNSE / PCNSA exam, QoS sits under traffic management and shows up as scenario questions, not trivia. Expect to be tested on: the order (profile → policy → enable on interface), that QoS is egress-enforced, the 8 classes and the four priorities (with real-time for voice), the default Class 4 for unmatched traffic, and the difference between guaranteed vs max egress bandwidth. A favourite trap is the egress-direction question — "why doesn't QoS on the untrust interface shape my downloads?" Know that cold and you'll pick up the marks.