On 5, Jan2014, at 23:48 , Adam Thompson <[email protected]> wrote:
> I've steered you the wrong way altogether! No Problem > >> I have a TP-Link 8 port switch ( http://tinyurl.com/m2rbcdt ) that connects >> the 3 LANs and the 3 WANs to the pfSense Box. >> But I’m not sure anymore what help it is. >> I had the LANs coming in on their own physical NICs, but couldn’t get them >> together for QoS neither. >> I can get them all in their own queue for shaping, but that way I could only >> limit each LAN individually not taking into account what the other one needs. > > You've got everything you need. > > The only place you can usefully control QoS in your environment is on the > *UP*link to your ADSL provider. If you have NICs dedicated to each subnet, > then you're already at 1Gbps dedicated to each subnet. Not really, because > pfSense on that hardware can't do 1Gbps, but at least ethernet isn't the > bottleneck. > > By controlling upstream bandwidth, you can have *some* effect on downstream > bandwidth. By ensuring that no single upstream link is 100% congested, you > will almost certainly improve response time and latency. > I thought that is some how what the pfSense Shaper does, I imagined that by keeping responses of certain connections back, it would also somehow limit the downstream or some similar black magic ;-) > There will be absolutely no benefit to putting a traffic-shaping policy on > inbound traffic; I can explain the logic behind this statement if it's not > obvious, but in short: the data has already arrived at the DSL modem (and > thereby filled up the pipe) long before pfSense can touch it. No black magic at all so? Not even to limit p2p traffic and prefer pure http/https ? Or give one LAN more bandwidth when needed while more to the other LAN if the first one doesn’t need it? > I believe what you need is a standard multi-WAN setup. No VLANs or trunking > are needed at all in your situation. You will need to apply a traffic > shaping policy on all three WAN connections; you can apply the identical > policy on all, or different policies on each. If you're using pfSense's > multi-WAN feature with equal weights, I recommend placing the same traffic > policies on all three lines. > Up and running > However, bundling the three DSL connections together this way won't produce > the results you expect; pfSense doesn't magically bond uplinks and downlinks > together - no standard router or firewall really can do a good job of that. > pfSense does a decent job of load-balancing, but the end results are > imperfect and do not magically reflect a 3x increase in usable bandwidth. You’d be surprised how good of a Job it does. When the connections are good, less other Bolivians surfing the web, and each DSL line nearly reaches it’s (contracted) limit, the Client WiFi nearly suck`s down the sum of the 3 DSL bandwidth, that is according to pfSense’s traffic graphs :-) > > You might want to have a look at Mushroom's "Truffle" router. Yes, I'm > serious, that's the real name of the product. It might be useful to you, or > it might not. Latency from Bolivia might suck if you use their cloud service > on the far end; you might still have to find somewhere to host the server > side to get the most out of the "bonding" mode they offer. > I’ll look into this. Thanks _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
