Traffic shaping in multi-LAN with shared inbound quota
-
Hello,
I have been using pfsense 2 since beta4 (now running latest version) and need to configure it for Traffic shaping now.
The system I am trying to setup has a single WAN (asymmetric) and two LAN interfaces. The inbound traffic limit is shared across both of the LAN interfaces so when users from both LANs download they should be caped using the same total limit of lets say 10Mbps. I have tried using the singleWan/MultiLAN wizard but it creates same queues on both of the LAN interfaces. Which means that if the WAN download limit is set to 10Mbps than both LAN interfaces get a queue qInternet set to a total bandwidth of 10Mbps. This would work fine when only one LAN interface is used at a time. But if there are users on both LAN interfaces than effectively pfsense will allow upto 2x10Mbps to flow through it. Which is not exactly what I am trying to achieve.From what I understand reading the forums, PF uses ALTQ that is conceptually based on having an outgoing queue(s) per interface. Is it possible to create a queue hierarchy that will allow one virtual parent queue set shared across multiple LAN interfaces so that total download speeds (inbound Qos) can be maintained?
Is there any other way to achieve the same goal in pfSense: Inbound QoS with multiple LAN interfaces ?
Thanks.
-
No, I don't think this is possible, but it would be nice. You could use two firewalls inline, the first would shape and the second would provide all the normal services. The first could maybe be setup in transparent bridge mode also…. just speculating though. Or you could experiment with running all download traffic through a dummynet pipe (limiter) which would at least limit the traffic to a set amount. But I don't think the shaping would be accurate since it only kicks in when the queue is full, and if each lan interface is setup to shape based on 10Mbit, but each is only getting 5Mbit then the shaping wouldn't kick in. Although you could still set lower limits for certain traffic types that would kick it. I often limit unclassified traffic to %40 percent of a connection, so bittorrent traffic would be capped at 4mbit for each interface.
I think the new shaper was supposed to address this, but it is just a fundamental design issue that queues on different interfaces don't coordinate with each other. I wonder how pf altq would handle having the bandwidth settings changed by a monitor daemon every 10 seconds or so, something that would try and balance out the bandwidth between a set of interfaces...
There is also the common line that it isn't really possible to shape download traffic anyway, since by the time the firewall has it, it already has it. It sort of works since many protocols try to behave nicely when packet loss is detected, but if someone is DOSing you with a stream of udp packets, there isn't anything pfsense can do, since it doesn't make the decision on what packets get sent to the WAN.
You just need to convince your ISP to let you install a second firewall on their end so you can shape the traffic before it gets sent to your, or they can give you access to their core routers so you can play around with cisco QOS for the traffic sent to you. I'm sure that will fly, right.
Josh -
Hey, just came upon this thread. I've been trying to do exactly what srul wanted, and am figuring out the hard way that it doesn't work. I'm open to suggestions here. We've got a staff LAN, as well as a few "public" LANs, for students and vendors at our event center. I've got a single 20/20Mbps pipe to be divided up to each of them. The traffic all comes at different times of day and days of the week, so it's illogical to split them up evenly, or at any arbitrary delineation. I really need to be able to dynamically (like with CBQ) move and borrow traffic across the interfaces, from the single 20Mbps allowance.
I tried just forcing the traffic from one interface into the queue on another, but it doesn't get shaped. I'm trying to think how multiple pfsense boxes could help. In any case, I'd need to combine all the traffic into a single interface, cause that's the catch. What if I added another pfsense box upstream, with all the traffic from the multiple interfaces dumped into 1 interface (binding multiple virtual IPs to a single interface?) and then shaped that interface based on the subnets coming through. Could that work?
-
You might want to also check http://lists.freebsd.org/mailman/listinfo/freebsd-net
-
I'm thinking more about this…
-
1. I've got a pfsense box set up now with 1 WAN and multiple LAN connections. I need to shape (dynamically allocate bandwidth based on priority and load) the inbound bandwidth (download traffic) for the LANs.
-
2. I could set up an additional pfsense box up the chain from the current one, with a single WAN and single LAN. I can set it to transparent mode, I guess.
-
3. If I set up Advanced Outbound NAT on the multi-LAN box (to differentiate by interfaces/subnets), I should be able to use that to identify the traffic on the upstream unit and shape accordingly
Thoughts?
-
-
Any thoughts, anyone?
-
I'm not sure if it's dumb luck, a successful configuration or something else entirely, but I've been able to get the HFSC shaper to work the way I want it the two times I've used it. The second time was in an environment with three LAN interfaces, and from what I can tell, the shaper is actively prioritizing traffic among the internal interfaces in the way I anticipated. Granted neither pfSense deployment is earth-shattering (both are home environments), but from skimming the forums posts on this subject, I thought documenting success using the shaper with multiple LAN interfaces might be of interest.
The configuration consisted of a single WAN interface and three LAN interfaces: Verizon, Work & LAN. The firewall is actually a friend's & we both teamed to sort out the necessary shaper configuration. The goals were simple: Verizon traffic takes precedence (he has FiOS & on-demand videos can use a portion of his "Internet" bandwidth), Work traffic trumps LAN bandwidth but not Verizon (employer-provided VoIP phone & other equipment when he works from home is connected to the Work interface; LAN is for generic home internet), any interface should be able to utilize all available idle bandwidth (but release it for high priority traffic) and no interface should be starved of bandwidth regardless of priority (the "fair service" in HFSC takes care of this).
We first ran through the multi-LAN wizard, but didn't specify any ports or protocols to prioritize, rather used the wizard to stipulate upload & download bandwidth and build the various queues on the interfaces. Once that was completed, we built a VZWeb queue on the Verizon interface, a WRKWeb queue on the Work interface and a LANWeb queue on the LAN interface as children under the Internet queue on the each of the interfaces. These three queues were duplicated on the WAN interface and placed directly under the root queue.
Priority was described via a percentage in the m2 column of the Link Share row as I've read somewhere HFSC doesn't adhere to the numerical priority label. I believe Link Share overrides Bandwidth but the percentage was duplicated in Bandwidth field for the sake of completeness. VZWeb was given 30%, WRKWeb 15% and LANWeb 5%. The Link Share m2 metrics on the ACK queue were left unchanged, but we did plug in 5% for the Realtime m2 value as a safety net.
The rules were a little trickier, couldn't get the floating rules to properly direct traffic into the queues, but specifying queues on existing rules in the interface tabs did the trick (e.g. allow LAN to any rule where LAN net is the source). We ran multiple non-interference (start with traffic on higher priority Verizon, then Work & then LAN) and non-blocking tests (going the other way with LAN first, then Work, then Verizon) and all interfaces used the appropriate amount of traffic. LAN was the only one that dropped packets, which occurred when this interface surrendered bandwidth to the other two.