SQM & 6rd - Do I need to change the interface?

Hi, I have SQM working, but I found myself wondering.. do I need to make changes if I also have IPv6 and 6rd active?

On the Interface Overview screen I have these interfaces: (LAN) br-lan, (WAN) eth0 and (WAN6) 6rd-wan6.

SQM is currently configured to run on eth0 which is native IPv4 only (for now).

6rd is IPv6 over IPv4.

It's not clear to me how 6rd-wan6 is being handled or if it's being touched at all by SQM.


I assume eth0 is the port of the router you have attached to a modem of sorts or even en ISP-supplied ethernet port. In that case a shaper on eth0 will affect all traffic. Now, for fq_codel al IPv6 traffic probably looks like a single flow due to fq_codel only looking at the external IPv4 header which is not quite ideal, as now IPv6 traffic will be a second class citizen and fairness inbetween IPv6 flows is not going to be great anymore. As far as I know the cake qdisc will actually try to dig into encapsulated IPv6 headers so in your case cake should give you fairness for IPv4 ad IPv6 flows. Since I am not 100% certain, I would recommend that you actually go and test this, though, instead of just believing me...

Hi, yes, eth0 is the lan cable which goes straight to the cablemodem.

I am using cake, could you please guide me or point me in the direction of how to perform a proper test to determine how the flows are treated and the expected observation of proper behaviour.


I'm attaching a screenshot as well, because I find the TX/RX numbers strange as well. Shouldn't the highest #s be on the WAN and not the LAN bridge?

I guess what you should test is whether IPv4 and IPv6 flows are treated similarly fair or not, so if you start one long term IPv4 download (that hope fully runs close to your links capacity) what happens if yu statr a dsl reports Pv6 only tests with say 16 measurement flows? Please see https://lede-project.org/docs/howto/sqm for how to configure cake to get the most out of it (sing and dance...) and https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for how to configure the dslreports speedtest for different numbers of flows, if you have not done so already...

Well the LAN bridge is what connects all your internal networks machines with the internet and with each other (especially wifi with wired LAN) so I am not really surprised by LAN showing a higher total than WAN. I am unsure about the difference between WAN and WAN6 though, but I genuinely do not know how these are accounted (WAN might only show the IPv4 packets).

Hope that helps...

Interesting.. the IPv6 setting on the dslreports test requires the use of non-encrypted.. so I changed it away from https. Running the test I could observe that IPv4 had a lot less bufferbloat (A+) and was slightly faster than IPv6 (could be routing) which scored B. It was visible, the bufferbloat #s were spinning madly.

As an experiment, I changed the interface away from eth0. In IPv6 speedtest mode,
6rd-wan6 - disabled SQM, full speed as if script not active
sit0 - disabled SQM, full speed as if script not active
eth1 - no good, very slow
br-lan - no good, very slow

I disabled the wan6 interface without rebooting. IPv6 speedtest still ran. Rebooted and it was enabled again and I didn't want to delete my settings so I left it alone.

I believe that the speed discrepancy between IPv4 and IPv6-6rd is due to the MTU, 1480 vs 1500.

But what is certain from what I could see, bufferbloat is worse on the 6rd encapsulation. I saw the upload meter spike red 220 ms, even though the final overall score was fine or ok (A, B vs A+). With IPv4 the meter didn't bounce around, stayed relatively level.

It's possible some of this is due to the 6rd tunnel. Pity I don't have a native dual stack at the present time from the isp to compare better.

So I believe that SQM is working, but not as well as it does with IPv4 due to bufferbloat being higher.

I decided to chuck out the IPv6-6rd setup for now since I don't connect to any IPv6 only sites.

For more detailed discussion you could post links to the dslreports results pages for both your IPv4 and IPv6 tests...


Well, these are essentially the LAN ports and here ingress and egress are reversed in relation to the internet, so I assume that your egress shaper setting is much smaller than the ingress one, and on LAN interfaces the shapers egress setting controls internet downloads, so this is somewhat expected...

Not sure what speed difference you see, but between MTU 1480 and 1500 you can expect a difference of 100-100*1480/1500 = 1.33% in goodput, so nothing to write home about...

IPv4 version result: http://www.dslreports.com/speedtest/14732227
IPv6 version result: http://www.dslreports.com/speedtest/14731927

IPv4 https https://www.dslreports.com/speedtest/14732421
IPv6 regular http http://www.dslreports.com/speedtest/14732578 (this one had a full red meter on the upload the whole time)

IPv4 with NOECN on the egress http://www.dslreports.com/speedtest/14733146
IPv6 with NOECN on the egress http://www.dslreports.com/speedtest/14732978

It appears as if ECN on with egress was not working well with IPv6-6rd

Thanks, so I now see what you mean by IPv6 is worse than IPv4... What would be intersting is two run two speedtests concurrently, one IPv4 and one IPv6 (you probably need to start these from two different computers, as the dslreports speedtest seems to require the current browser to be in focus, but you could always try the command line version of the test https://www.dslreports.com/forum/r30837078-Binaries-version-23th-December-is-posted). The goal here is to see whether bandwidth is shared fairly between IPv4 and IPv6 flows (so make sure to not use the flows keyword if you use cake as qdisc instead of dual-scrhost/dual-dsthost/triple-isolate). If sqm-scripts can not peek into the 6rd tunnel to get to the inner IPv6 headers, I fear 6rd traffic will always be a second class citizen in your network.

Note: cake as qdisc will ignore the ECN settings in the GUI and will always enable ECN, but it is only going to be used if both endpoints of a flow actually negotiate to use it, so unless you enabled ECN at your test host the different ECN options in sqm-scripts should have a negligible effect on bufferbloat/performance.

Best Regards