PF Queue for inbound problem

ProServ

Active Member

Reaction score: 2
Messages: 133

Hi,

I'm trying to get a decent rule set using ALTQ for inbound traffic primarily to stop abusers from massive downloads which congest the network and kill VoIP traffic.

But I keep getting:
Code:
pfctl: the sum of the child bandwidth higher than parent "root_fxp1"
/etc/pf.conf:65: syntax error
However, line 65 is:
Code:
queue boss_in bandwith 5Mb cbq(borrow)
The inbound ALTQ is:
Code:
altq on $int_if cbq bandwidth 21Mb queue { std_in, abuser_in, voip_in, low_pri_in, boss_in }

queue std_in bandwidth 6Mb cbq(default)
queue low_pri_in bandwidth 2Mb priority 4
queue abuser_in bandwidth 3Mb priority 5
queue voip_in bandwidth 4Mb priority 6
queue boss_in bandwith 5Mb cbq(borrow)
When I add the above it is LESS than the total of 21 Mbps.

The only way to get pf loaded is to
Code:
#queue boss_in bandwith 5Mb cbq(borrow)
but that is not the right way IMHO.

Any help here is appreciated.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,057
Messages: 31,638

You can't shape incoming traffic, only outgoing. Which is logical if you think about it. When the traffic hits your firewall it's already on the line.
 
OP
OP
P

ProServ

Active Member

Reaction score: 2
Messages: 133

SirDice said:
You can't shape incoming traffic, only outgoing. Which is logical if you think about it. When the traffic hits your firewall it's already on the line.
Hi @SirDice,

I beg to differ with you. See what the PF FAQ from OpenBSD says:

Code:
# enable queueing on the internal interface to control traffic coming in
# from the Internet. use the cbq scheduler to control bandwidth. max
# bandwidth is 2Mbps.

altq on dc0 cbq bandwidth 2Mb queue { std_in, ssh_im_in, dns_in, bob_in }

# define the parameters for the child queues.
# std_in      - the standard queue. any filter rule below that does not
#               explicitly specify a queue will have its traffic added
#               to this queue.
# ssh_im_in   - interactive SSH and various instant message traffic.
# dns_in      - DNS replies.
# bob_in      - bandwidth reserved for Bob's workstation. allow him to
#               borrow.

queue std_in    bandwidth 1.6Mb cbq(default)
queue ssh_im_in bandwidth 200Kb priority 4
queue dns_in    bandwidth 120Kb priority 5
queue bob_in    bandwidth 80Kb cbq(borrow)
So this must work. Again the problem I have is that using the above methodology, the last line in my configuration when run produces the error.
 
Last edited by a moderator:

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,057
Messages: 31,638

ProServ said:
Code:
# enable queueing on the internal interface to control traffic coming in
# from the Internet. use the cbq scheduler to control bandwidth. max
# bandwidth is 2Mbps.
Yes, except this throttles the traffic that goes out the internal interface, not what comes in on the WAN interface.

If your uplink is saturated throttling what comes out the firewall/router doesn't help you much. Your VoIP traffic will still suffer because your uplink is filled up.
 

throAU

Aspiring Daemon

Reaction score: 147
Messages: 910

Yup, what he said. Traffic is only put in a queue while it is waiting to be SENT. You'll want to set up outbound queuing on your INTERNAL interface. This won't affect local traffic because only traffic outside of your local network should be traversing the router (I'm assuming for the moment you aren't using your edge router to do inter-vlan routing here).

If your inbound interface starts to drop packets due to rate limit on send, TCP (on the remote server) will/should start to back off on the other end to reduce throughput. If it's UDP there's not a lot you can do.
 
OP
OP
P

ProServ

Active Member

Reaction score: 2
Messages: 133

I am very confused then as to why the FAQ clearly states:

Code:
enable queueing on the internal interface to control traffic [B][U]coming in[/U][/B] from the Internet.
 

throAU

Aspiring Daemon

Reaction score: 147
Messages: 910

ProServ said:
My issues are downloads from people here on the internal LAN.
Yes, this is what I am talking about. However, you can not set up inbound queuing on an interface because you can't process/buffer traffic (i.e., put it in a queue) that you have not received yet. To classify traffic you need to have received it. Once you've received it, it is too late to shape. So you can only shape it when you are deciding whether to send.

The only way you can get traffic into a queue is to do the queuing when you are processing it for SEND. I.e., either outbound queue on your WAN interface for outbound traffic, or fudge inbound queuing with an outbound queue on your LAN interface.

ProServ said:
I am very confused then as to why the FAQ clearly states:

Code:
enable queueing on the [B]internal interface[/B] to control traffic [B][U]coming in[/U][/B] from the Internet.
This is exactly what the FAQ is telling you to do. Control outbound traffic by outbound queuing on your external (WAN) interface, and control inbound traffic by setting up an outbound queue on your internal interface.

When your router (pf firewall) decides to start dropping traffic that has arrived via the outside interface before forwarding to the LAN, TCP on the remote end will back off and reduce its send rate.

This isn't a pf restriction by the way - it's a restriction on how TCP/IP works. I've just set up the same thing on a bunch of my Cisco routers, because IOS can't do inbound queues either.

And anything that claims to do inbound QoS will be fudging it via a method similar to the above, whatever knobs you tweak in the GUI; you simply can't select what to drop until you've already received it.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 8,057
Messages: 31,638

The way to deal with this is by using a company policy that restricts downloading. I mean what are they downloading anyway? If it's anything illegal (warez for example) you don't want to have the company involved.

Now, a policy won't actually stop people from downloading but you can use a lart to knock some sense into them (or simply fire them).
 

throAU

Aspiring Daemon

Reaction score: 147
Messages: 910

Agreed, you can't always throw technical solutions at the problem.

However, "inbound" QoS will help anyway, as there's every possibility (for example) that a legitimate file transfer (e.g., WSUS server, freebsd-update, etc.) will interfere with VoIP.
 
Top