Our last altq example is one which surfaced around the time of one of the many spam or virus storms we've seen during the last few years. It's fairly common knowledge that the machines causing these bursts of email are practically all Windows machines. PF has a fairly reliable operating system fingerprinting mechanism which detects the operating system at the other end of a network connection. One OpenBSD user got sufficiently tired of all this meaningless traffic, and posted some selected bits of his pf.conf on his blog:
altq on $ext_if cbq queue { q_default q_web q_mail }
queue q_default cbq(default)
queue q_web (...)
## all mail limited to 1Mb/sec
queue q_mail bandwidth 1Mb { q_mail_windows }
## windows mail limited to 56Kb/sec
queue q_mail_windows bandwidth 56Kb
pass in quick proto tcp from any os "Windows" to $ext_if port 25 \
keep state queue q_mail_windows
pass in quick proto tcp from any to $ext_if port 25 label "smtp" \
keep state queue q_mail" I can't believe I didn't see this earlier. Oh, how sweet. ... Already a huge difference in my load. Bwa ha ha. "
Randal L. Schwartz, 29. January 2004, http://use.perl.org/~merlyn/journal/17094
Here all email traffic is assigned one megabit worth of bandwidth, while email traffic originating at Windows hosts get to share a subqueue of 56 Kbit total. No wonder the total load went down and the blog post ends with what must be an evil chuckle.
I must confess this is something I've wanted very much to do myself, but I've never dared. A few too many of our customers have for their own reasons chosen to run their mail service on Windows, and we do like to receive most of their mail. In a little while, we'll have a look at a different PF approach which may have achieved much of the same effect.
A somewhat more thorough treatment of ALTQ (including a basic HFSC traffic shaper configuration) can be found in The Book of PF.