Bufferbloat issue when using ipv4 and ipv6
-
@AlexanderK said in Bufferbloat issue when using ipv4 and ipv6:
Bufferbloat is really bad (B or C) while enabling both ipv4 and ipv6.
Doesn't make much sense.
What is your IPv6 rule looking like. -
here are both
-
@AlexanderK Make the source * for the IPv6 rule.
-
@Bob-Dig Their example specifically says WAN address, though:
https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html#create-floating-ruleHaving written that, though, I've not had to use that method...we just use PRIQ shaping for voice.
-
@Bob-Dig still happening the same.
-
@SteveITS said in Bufferbloat issue when using ipv4 and ipv6:
@Bob-Dig Their example specifically says WAN address, though
True. But with IPv6 we don't NAT anymore so having only the WAN-address in that rule wouldn't do anything. If you have a static prefix then use that.
@AlexanderK Try a different test-site.
-
I went through the guide when I first moved to pfSense and set-up FQ_Codel in the firewall as below:
Did I also make an error?
๏ธ
-
@RobbieTT said in Bufferbloat issue when using ipv4 and ipv6:
๏ธ
In their write-up they say you should add the WAN-address, so I would do it.
Only with IPv6 you shouldn't.
That is how it is looking here.But I disabled them because in my first router (Fritzbox) I can click one button to do it automacically for me and it is even better, less latency and more bandwidth.
-
My first thought was that WAN, as a source, would exclude FQ_Codel from LAN to WAN - ie upload. Presumably this is not the case?
๏ธ
-
@RobbieTT said in Bufferbloat issue when using ipv4 and ipv6:
Presumably this is not the case?
No, it will do both. But it is happening after Outbound NAT so the source address will be the WAN-Address for outgoing. Or to be more precise, I don't know how this actually works, I only know it will not work for IPv6 if the WAN-address is specified.
-
The guide is written around IPv4 with NAT.
For IPv4, if you are using NAT the source address of the packets will be the address of the WAN interface, which is why using a source of "WAN address" works. To my knowledge however, the only reason that it would be important to specify "WAN address" as the source instead of "any" is if you have multiple WAN interfaces. If you have a single WAN interface, a source address of "any" works fine.
For IPv6, there is no NAT, which means that the source address of the packets will be the address of the originating host. So if you use a source of "WAN address", then you would end up only shaping the packets that originate from the firewall itself which is not very useful. Assuming that you have a single WAN interface, you want to use a source address of "any".
FWIW, public IPv4 without NAT would need to be handled the same way as IPv6.
-
my thoughts...
My connection is 1gbit/100mbit
When i am using ipv4 and one gateway everything is perfect.
When i am using both ipv4 and ipv6 - two different gateways i have issues.
Is it possible to use the rule per interface? -
-
@AlexanderK said in Bufferbloat issue when using ipv4 and ipv6:
When i am using both ipv4 and ipv6 - two different gateways i have issues.
Is it possible to use the rule per interface?You have two rules because IPv4 and IPv6 use different gateways. But you use the same limiter queue for both IPv4 and IPv6
My floating rules look like this:
Both the IPv4 and IPv6 rules have the same queue assignments like this:
-
@AlexanderK said in Bufferbloat issue when using ipv4 and ipv6:
My connection is 1gbit/100mbit
I have a similar bandwidth, using both IPv4 and IPv6, also via PPPoE:
๏ธ
-
Assuming that the hosts in your LAN are at the same speed as your WAN connection (all 1Gb), I have an experiment to suggest...
Change your floating rule such that you are only assigning a limiter to the upload side, like so:
and then re-test. Does your grade change or remain the same?
-
I have the same issue. The problem is you can't select IPv4+IPv6 because it doesn't let you save the rule without choosing a gateway, but the gateways are separate for IPv4/6. Thus creating the issue where each gateway receives a limit of X+X, instead of just X. In other words, the limiter is applied separately for IPv4/6 instead of in combination.
-
@dennypage said in Bufferbloat issue when using ipv4 and ipv6:
Assuming that the hosts in your LAN are at the same speed as your WAN connection (all 1Gb), I have an experiment to suggest...
Change your floating rule such that you are only assigning a limiter to the upload side, like so:
and then re-test. Does your grade change or remain the same?
Sorry Denny, I thought I had replied to your suggestion at the time. I set FQ_CoDel on download through experimentation but mindful that setting it on upload only is common. It did improve my latency / buffurbloat under load and with tuning I found a good balance between latency and the small decrease in bandwidth. I experienced the same on 2 different routers previously but both of them did not have the CPU power to run download FQ-CoDel at high bandwidths - this is one of the reasons I moved to pfSense.
The downlink from pfSense to my production LAN & VLAN runs at 10 GbE, as do my switches and a number of servers and hosts, so typically at greater bandwidths than my nominal 1 GbE WAN connection. I am not sure my config is what you seek for your experiment but still happy to tweak & test it for you, if you would still like some data?
๏ธ
-
@RobbieTT I had suggested the experiment because on reading the description of your config at the time it seemed that you might not have a choke (buffer) point in your download path. And if there is no choke point, shaping such as CoDel is a hinderance rather than a benefit. Sounds like you were already aware of this however.
-
@dennypage - Thanks Denny