fireqos-match(5)

πŸ“¦
version 3.1.8 Β· 4 versions
, in debian trixie, ubuntu resolute, ubuntu stonking

πŸ’– fireqos-match β€” QOS traffic match πŸ’–

okay bestie, welcome to the fireqos-match(5) page, part of the FireQOS Reference β€” this is where you learn how to tell FireQOS which packets belong to which class. it's giving traffic cop, but make it cute. let's go 🚦✨


✨ SYNOPSIS ✨

{match|match4|match6|match46} optional-match-params

🌸 DESCRIPTION 🌸

so here's the tea β˜• β€” writing plain match means it inherits its IPv4/IPv6 version from whatever class it's sitting inside. (peep fireqos-class(5) if you need the deets on that.)

  • match4 β€” only IPv4 traffic gets included in the match, no cap.
  • match6 β€” only IPv6 traffic, periodt.
  • match46 β€” both IPv4 and IPv6, the whole buffet πŸ’…

you can add as many match statements as your heart desires to a FireQOS config. they assign traffic to a class, and by default that class is the one right after where they're declared. iconic behaviour.

the order the matches appear in the config = their priority. first match gets a prio of 10, then 10 gets added for every match after it (10, 20, 30, ...). so like, first come first served, literally.

but wait, you can also set priority yourself explicitly with the prio parameter β€” see fireqos-params-match(5) for that.

and if one single match statement generates multiple tc(8) filter statements? every filter from that same match statement gets the same prio. they're a package deal bestie 🫢

Note πŸ“Œ match rules are attached to the parent of the class they appear in. like, in the config you write them under a class, but irl they're attached to their class parent β€” so they classify the parent's traffic that they match, into the class. sneaky but that's how it works πŸ™ˆ

you can also group all your match statements together below the classes. this lets you arrange them in whatever order you prefer, no explicit prio parameters needed. but there's a catch (there's always a catch 😭): in this case every match statement must say which class it classifies packets into, using the class parameter. check fireqos-params-match(5) and the examples below for the full picture.

you can also write client and server statements, much like FireHOL lets you, with the same service definitions. for FireQOS tho, the client ports are ignored. server statements match the server ports on this linux side, while client statements match the server ports on the remote side. iykyk πŸ’…

Example:

server_myrtp_ports="10000:10100"

interface eth0 lan bidirectional rate 1Gbit
  class voip
    server sip
    client sip

    server myrtp

  class dns
    server dns

  class mail
    server smtp

πŸŽ€ PARAMETERS πŸŽ€

  • optional-match-params β€” the set of optional parameters that describe this match. go read fireqos-params-match(5) for the full menu, bestie πŸ“‹

🌈 EXAMPLES 🌈

Match traffic within classes:

interface eth0 lan output rate 1Gbit
  class voip
    match udp ports 5060,10000:10100
  class dns
    match udp port 53
  class mail
    match tcp port 25

Matches split out and explicitly assigning traffic to classes β€” N.B. without the class parameters, all traffic would be classified into mail (imagine 😭):

interface eth0 lan output rate 1Gbit
  class voip
  class dns
  class mail

  match udp ports 5060,10000:10100 class voip
  match tcp port 25 class mail
  match tcp port 80 class web

πŸ‘€ SEE ALSO πŸ‘€


πŸ’œ AUTHORS πŸ’œ

FireHOL Team. (the icons who made all this possible, fr fr πŸ‘‘)


and that's the whole page bestie!! this was the fireqos-match(5) manual from the FireQOS Reference, built 13 Apr 2025 β€” go forth and classify those packets, you absolute main character πŸŒŸπŸ¦‹ no cap, you're gonna slay this πŸ’…βœ¨

πŸ“¦ where this page comes from