New phenomenon breaks inbound TCP policing

Re:New phenomenon breaks inbound TCP policing by riskable on Tuesday June 07, 2016 @10:16AM (#11854654)

I've had a problem similar to this with my 150 megabit downlink (sigh, wish I had that much upload). The thing to remember when troubleshooting these sorts of problems is this:

    Not all iptables rules are created equal.

State tracking has significantly more overhead than other types of rules/filtering/shaping (even though state tracking is required for certain types of shaping). You may or may not have already done this but if not try this:

    iptables -t raw -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j NOTRACK
    iptables -t raw -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j NOTRACK

(replace eth0 with your Internet interface)

State tracking on port 443 and 80 is mostly useless and it's where you're likely to see the majority of your (high bandwidth) traffic. Setting NOTRACK on those ports can make a HUGE difference while still enabling your squirrel-powered router (let me guess: It requires no active cooling? haha) to shape traffic like "teh big boys."

[ Parent | on HN ]

Re:New phenomenon breaks inbound TCP policing by voltagex_ on Wednesday June 08, 2016 @02:22AM (#11860372)

For years and years I was on ~8 megabit ADSL. I thought 100 megabit fibre would solve all my problems but it just moves my problems into a different class.

Thanks for that info. As soon as I can work out why the default congestion control / single connection speed on FreeBSD 10 is so bad, I'll be running that as a router.

[ Parent | on HN ]