Documentation patches?
Hi: I'd like to submit some info for the install64.octeon documentation. I just installed 6.4 on a newer EdgeRouter than the documentation was written for. The instructions in the install document are probably not enough to get the average user booted on that particular piece of hardware. I'd like to document the install while I still remember it. Can I submit a patch somewhere? Thanks! --Chris
Re: PF altq and limiting traffic among multiple interfaces
I'm no pro (and I've never seen a connection that had a transfer cap
applied to upstream+downstream), but if I was limited to 512 kb/s up+down,
I'd want to:
1) Prioritize ACKs to limit getting hammered with retransmits
2) Throttle guests tightly but allow them to borrow from other queues; not
too much, as if we allow 256k upstream we're probably getting back a lot
more bottlenecked up on the downstream. PF can't control how much data hits
the downstream except by limiting the upstream.
3) Have an upstream router that supports ECN/RED :P
4) Use the fancy HFSC scheduler! (huzzah)
For example:
altq on $ext_if bandwidth 128Kb hfsc queue { ack, dns, hipri, def, guest1,
guest2 }
queue ack bandwidth 60% priority 6 qlimit 200 hfsc (realtime 30% ecn)
queue dns bandwidth 10% priority 5 qlimit 200 hfsc (realtime 20% ecn)
queue hipri bandwidth 10% priority 4 qlimit 150 hfsc (realtime 20% ecn)
queue def bandwidth 10% priority 2 qlimit 100 hfsc (realtime 20% ecn
default)
queue guest1 bandwidth 5% priority 0 qlimit 50 hfsc (upperlimit 15% red)
queue guest2 bandwidth 5% priority 0 qlimit 50 hfsc (upperlimit 15% red)
block in all
block out on $ext_if
block out log on $int_if
block out log on $guest1_if
block out log on $guest2_if
block out log on $dmz_if
# Now to allow some traffic. For example, let's allow DNS traffic out unto
the internets at priority 5, and its TCP ACKs at priority 6:
pass out on $ext_if proto {tcp udp} from any to any port 53 queue (dns, ack)
Haven't tried it, but I imagine that that ruleset beats the hell out of
plain old filtering from the end users' perspective. You'll obviously need
to add all the packet filtering rules for it to work, but that would be my
first shot at the queueing.
Note that all the queues except guest1 and guest2 are allowed to borrow
bandwidth up to 100% of the 256kb queue, but guest1 and guest2 are
restricted to a max of 15% of that (so the 2 guest nets can do a max of 30%
of total outbound).
Note also that we're limiting outbound traffic to 128kb because outbound +
inbound are rate limited to 512k. Might actually have to reduce that a
little to speed things up once it gets congested; play with it and see!
Also, there's a high probability that something about this is wrong/stupid,
as it's untested, but I'm sure someone will correct me. ;)
On Tue, Nov 20, 2012 at 5:45 PM, Mikolaj Kucharski
miko...@kucharski.namewrote:
Hi,
Searched for this for a while. Found below old post, without answer. Is
this actually possible to setup that way?
From http://marc.info/?l=openbsd-pfm=112015092309886w=2
List: openbsd-pf
Subject:Altq - limiting traffic among multiple interfaces
From: Jonathan Camenisch alaythia () gmail ! com
Date: 2005-06-30 14:15:55
Message-ID: fd5fdde005063007153fc4c2c2 () mail ! gmail ! com
In our organization, I'd like to use Altq to keep any one process
(download or whatever) from hogging bandwidth and degrading
performance for others. It's more complicated than I expected, though,
and I haven't been able to find an example that's much like my
environment (I'd be glad to publish mine if I could get it working
well). Here's the layout:
Office (internal) subnet DMZ
| /
[fxp0] [fxp1]
Internet ---[fxp4]OpenBSD/pf firewall
[fxp2] [fxp3]
| \
Guest class 1 subnet Guest class 2 subnet
We have sort of a conference center, so we're providing access for
guests as well as offices. Hence all the subnets. We also host some of
our own web sites on the DMZ.
Now to make it more complicated, our fractional T1 provides 512Kb of
*total* bandwidth. That is, the total of upload *and* download
bandwidth can never exceed 512Kb.
Ideally, I would like to set up a single 512k queue and divy it up
(with cbq) among all traffic that passes in or out of fxp4, regardless
of which interface it exits. (I'd really like to allow borrowing among
all directions.)
But as far as I know, there's no way to do exactly that. What I'm
hoping someone could suggest is, what's the best I can do? That is,
how can I get the best utilization out of my limited connection while
preventing anything from hogging it?
Forgive me if I'm overlooking information that's already available.
I'm afraid my brain's gotten a little scrambled trying to adapt the
altq model to this scenario. Thank you for your time!
Jonathan
--
best regards
q#
Re: Hardware hunting
Thanks for all the feedback! I really like the look of the Soekris boards. The Soekris website isn't that helpful, but I jotted down all my research in case someone else wanted to look at it: https://docs.google.com/spreadsheet/ccc?key=0AqjAAj_-IRQkdEs3TWNkZnZrUGs0S0FjYnRYQjFJZlE (That's not meant to be comprehensive; I stopped researching a model when it failed one of my requirements.) The text-only version (for those reading this in elm or pine :P) is: The Soekris Net6x series is an Intel Atom E6 with an EG20T, and 4 82574L 10/100/1000 chips, which are supported by the em driver. $299 - $456 for the board. The Soekris Net5x series is an AMD Geode LX with a CS5536, and 4 VT6105m 10/100 chips, which are supported by the vr driver. $254 - $222 for the board. The Soekris Net4x series uses an anonymous ethernet chip that you can't quite read in the photos and it's not listed in the spec sheet. I am pretty sure the Net4501-30 has a VM552RR chip, but I don't know who makes that. It does have a logo that looks a bit like an old Via logo. $135 - $178 for the board, but my current guess is that that mystery ethernet chip is not gonna have a driver. I think I will probably spring for the 6501-50 with their custom enclosure and external power. That lists at $380, plus $50 for a cheapo SSD, and I should be running at less than 30 watts for $480- which is a savings of 1,227 KWh per year (or about $283 at my local power rates), so it'll pay for itself in around 19 months. (Since I want to go to bed, I'm not going to attempt to figure in the change in heat loading's effect on heating and AC bills... they'll balance each other out, dammit. ;) ) Thanks again! On Thu, Nov 15, 2012 at 4:47 PM, Chris McGee cmcge...@gmail.com wrote: Hi guys- I am hunting for a low-power firewall for my home network. For at least 10 years, whenever my firewall hardware has started to die, I've grabbed a decommissioned game PC, added a few NIC's, and put OpenBSD on it. The firewall's current incarnation pulls about 160 watts 24/7; I'd like to lower that by a lot. Requirements are: 1) Low power (50w; I want it to pay for itself before the hardware dies) 2) 4 network interfaces (3 gigabit, one gigabit or 100mbps) 3) Cheaper is better (e.g., a $200 4-port PCIE NIC on a $75 motherboard is suboptimal) 4) Works with OpenBSD 5.2 5) Won't cause a hardware bottleneck when pushing 200mbps of multidirectional traffic through a moderately complex pf ruleset (this doesn't take a lot of CPU; a 1 GHz Athlon runs at about 2% under load, and most of that is from hardware interrupts). It looks like a lot of people use the Alix 2D13 for this, but I rejected it for poor throughput (it would be great for the internet connection, but it sounds like it might be a serious bottleneck between the internal networks). Jetway makes a number of promising-looking Atom boards, including the 4-interface NF38, but the NF38 and many other JetWays use the Realtek RTL8111EVL, which doesn't appear to be OpenBSD-friendly. You can add interfaces to Jetway boards via their daughterboards, but those are either Realtek RTL8111F or Intel 82574L; same problem. (Google turns up one report of the RTL8111 series sorta working with -current, but if you read the guy's dmesg, it doesn't look like he HAS an RTL8111 in the first place.) ...anyway, if you have a low-power OpenBSD network appliance with 3-4 interfaces that you're happy with, please give me a yell. I've been through a lot of boards without finding a winner so far!
Re: New scheduler, same problem (ALTQ questions)
Giancarlo, thank you for your ideas. 2) Regarding hfsc, what is the old bandwidth statement used for? It seems like it would be obsolete. Changing it doesn't seem to affect anything, either. The manpage doesn't say. :) What do you mean by old bandwidth? I mean that the bandwidth statement seems to be deprecated... you can set those numbers to anything you want, and the behavior of the scheduler doesn't seem to change. Also, upper limit, lower limit, priority, and linkshare are all specifically defined in other statements, so it seems like a bandwidth directive really doesn't give the scheduler any instructions that it didn't already have. What I'm asking is whether hfsc even looks at the value of the bandwidth statement. (I know that it is used in cbq and priq, and I know what it does there, but hfsc is new to me. :) ) The linkshare statement specify how much of the bandwidth of that queue will be shared with other queues when not used. Think in it like a shared pool. Ahh, it must default to 100% then, because I see full usage (up to whatever I define the bandwidth as) of the link with no linkshare statements in my config file. If you modem doesn't get to renegotiate the speed with you ISP, then you are doomed, because snmp won't work, so you variable rate won't work either. I never thought of using snmp for this. I bet it doesn't help even if it does work (I bet everyone's modem is running at 38mb/s, and the bandwidth of the segment itself limits the number of packets that pass), but if the client modems DO renegotiate individual speeds, that would be neat. I have a Motorola SB5100, which does have some SNMP functions. I'm installing scli from ports right now, and I'll play with it. That would rock. However, I bet it doesn't renegotiate; my available bandwidth just depends on how much traffic the other users on my segment are generating. You can do something. You can install syweb or any other graph tool to measure how your bandwidth vary trough, i'd say, a week. Based on that, you can have cron entries to change you hfsc rates trough the day. This could work also. That's a good idea, but that is sort of hit or miss since the congestion is obviously sort of random. Thanks again! I'll let you know how the snmp thing works out (still building dependencies) :).
New scheduler, same problem (ALTQ questions)
Hi guys-
I've been using an OpenBSD firewall on my home network for about 10
years. I recently upgraded the hardware to a retired gaming machine and
went to OpenBSD 4.3 (woo!).
I'm playing with the new scheduler in altq, and I like the way that it
works, but the documentation is iffy and it still doesn't look like it
solves one problem that priq and cbq couldn't solve... prioritizing
outbound traffic on a variable-bandwidth link. (Yes, I've got a cable
modem. =D)
Here's the problem I'm trying to solve: My cable modem allows around
750kb/s when traffic is really ugly, and about 2100kb/s in the dead of the
night. In order for the scheduler to know when to start limiting traffic,
I have to tell it how fast the link is but I don't *know* how fast the
link is, because it varies.
I've been trying the following rules:
altq on $ext_if bandwidth 2048Kb hfsc queue { ack, dns, games, def, bt }
queue ack bandwidth 80% priority 6 qlimit 500 hfsc (realtime 50%
ecn)
queue dns bandwidth 5% priority 5 qlimit 500 hfsc (realtime 5%
ecn)
queue games bandwidth 5% priority 3 qlimit 500 hfsc (realtime 5% ecn)
queue def bandwidth 5% priority 2 qlimit 500 hfsc (realtime 10%
ecn default)
queue bt bandwidth 5% priority 1 qlimit 500 hfsc (upperlimit 80%
red)
(the ack queue is TCP ack's, the dns queue is DNS requests, high priority
user traffic and VOIP goes in games, and the rest is regular and
low-priority user traffic.
When I'm usually using the internet connection, my outbound bandwidth is
probably around 1200kb. Cranking the bandwidth down to 750 or so is one
solution, but then I'm artificially limiting my own upstream to the worst
case scenario.
My questions are:
1) Is there a more effective way I could be doing the above?
2) Regarding hfsc, what is the old bandwidth statement used for? It seems
like it would be obsolete. Changing it doesn't seem to affect anything,
either. The manpage doesn't say. :)
3) Another hfsc question- exactly what does the linkshare statement do? The
manpage says : linkshare sc The bandwidth share of a backlogged
queue.).
Thanks :)
--Chris
