Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: dave seddon <dave.seddon.ca@gmail.com>
Cc: m@jaap.pro,
	"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>,
	Frantisek Borsik <frantisek.borsik@gmail.com>
Subject: [Cake] Re: help request for cake on a large network
Date: Sun, 28 Sep 2025 10:26:45 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.2509281021590.14886@nftneq.ynat.uz> (raw)
In-Reply-To: <CANypexTvXAdY577pxorqCKL45av3gw+fdupO6xr+gN5p=Wxq=Q@mail.gmail.com>

dave seddon wrote:

> G'day David,
>
> This sounds great and I'd be very happy to discuss this in real time
> to give you a hand.  The SCALE team does a lot of Nix, right?

Yes

> I think all the OpenWrt One routers were configured with nix, and so I assume 
> you're going to go with Nix for this?

they openwrt one routers were configured with a custom build of openwrt (we do 
have someone working on bringing nix up on them)

these routers will probably be running nix

> I think the TLDR is that cake will mostly do what you want.  The idea
> being that "it is a piece of cake" to use cake. ;)

that's what I expect, I just expect to need tuning of things to handle the large 
number of endpoints, what is appropriate for a dozen users will probably need 
larger tables to handle 3000 users :-)

> I was recently configuring an active/standby firewall, including
> configuring cake, with Nix, which I really need to 1) put config on
> github 2) document 3) and make a video about.

looking forward to it.

David Lang

>
> One nice thing I worked out is that the systemd networkd makes it
> super easy to apply the qdisc of choice.
>
> This isn't the whole config, but hopefully gives you the vague idea
>
>  cakeConfig = {
>    Bandwidth = "990M";  # We currently have 1Gb/s, so this is our limit
>    OverheadBytes = 38;  # Ethernet overhead (preamble + inter-frame gap + FCS)
>    MPUBytes = 84;       # Minimum packet unit for Ethernet
>    NAT = true;
>    FlowIsolationMode = "triple";
>    PriorityQueueingPreset = "besteffort";
>  };
>
> systemd.network.networks = {
>
>    # Bond interface configuration
>    "bond0" = {
>      matchConfig.Name = bondConfig.Name;
>      networkConfig = {
>        Address = [
>          (constructIP bondConfig.subnet4 (getNodeAddress bondConfig))
>          #bondConfig.vrrp_ip # secondary IP
>          #fd00::1/64" #FIXME!!
>        ];
>        LinkLocalAddressing = "no";
>        # Note: Gateway is configured in routes section with high metric
>        # to make it less preferred than DHCP route (metric 1024)
>      };
>      routes = [
>        {
>          Gateway = bondConfig.gateway_ip;
>          Destination = "0.0.0.0/0"; # Default route (all destinations)
>          Metric = 2000; # Higher than DHCP metric (1024) to make it
> less preferred
>        }
>      ];
>      # IMPORTANT: systemd-networkd Route syntax requirements:
>      # - Use "0.0.0.0/0" for IPv4 default routes (NOT "default")
>      # - Use "::/0" for IPv6 default routes (NOT "default")
>      # - "default" is NOT a valid Destination value in systemd-networkd
>      # - Reference:
> https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html
>      linkConfig = {
>        #RequiredForOnline = "carrier";
>        MTUBytes = MTUBytes;
>      };
>      vlan = vlanNames;
>      inherit cakeConfig;
> <------------------------ CAKE
>    };
>
>  # Bond device configuration
>  systemd.network.netdevs = {
>    "bond0" = {
>      netdevConfig = {
>        Name = bondConfig.Name;
>        Kind = "bond";
>        MTUBytes = MTUBytes;
>      };
>      bondConfig = {
>        Mode = "802.3ad";
>        # MIIMonitorSec = "100ms";
>        LACPTransmitRate = "fast"; # fast is only 1 second, so it's
> not really very fast :)
>        TransmitHashPolicy = "layer3+4";
>      };
>    };
>
>    # VLAN devices - generated from vlanConfigs
>  } // lib.foldl' (acc: name: acc // createVlanNetdev name
> vlanConfigs.${name}) {} (lib.attrNames vlanConfigs);
>
> }
>
> Regards,
> Dave Seddon
>
> On Sun, Sep 28, 2025 at 5:55 AM Frantisek Borsik
> <frantisek.borsik@gmail.com> wrote:
>>
>> Jaap - thank you very much for recommending LibreQoS.
>>
>> Yes, besides a typical last-mile ISP scenario, LibreQoS is being used in
>> various other setups, like to help with event Wi-Fi - here is one of the
>> deployments https://libreqos.io/2023/11/13/success-story-raceway/
>>
>> To brag a little, other deployment scenarios we see are data centers,
>> cruise ships, university campuses, even mines :)
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>> *In loving memory of Dave Täht: *1965-2025
>>
>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>>
>>
>> On Sun, Sep 28, 2025 at 2:38 PM David Lang <david@lang.hm> wrote:
>>
>>> I guess I didn't give enough info on our network architecture.
>>>
>>> The upstream ISP is between 500Mb and 1G.
>>>
>>> We disconnect the conference center firewall and connect our firewall in
>>> it's
>>> place (Linux system)
>>>
>>> This border router connect to the conference center firewall (so their
>>> offices
>>> still get connectivity), and to two routers (Linux, one per building) that
>>> are
>>> also direct connected (a triangle between the three routers. The border
>>> router
>>> is doing NAT for IPv4 and MSS squashing for IPV6 that goes out through a
>>> tunnel
>>> (google doesn't do PMTU discovery on IPv6)
>>>
>>> (we are currently debating between deploying OSPF between the three
>>> routers, or
>>> just giving them static routes, high priority direct and low priority for
>>> the
>>> indirect path)
>>>
>>> Each building router then connects to one or a few switches in different
>>> closets
>>> that then go to a switch in each room (trunked ports).
>>> We hve a handful of wired users, 120APs for the users, and AV equipment
>>> for each
>>> of the 16 tracks that are recorded and streamed.
>>>
>>> a quick look at libreqos and it's pushing for a more complex network
>>> layout that
>>> will be a hard sell at least this year (last year our juniper routers fell
>>> over
>>> under the MSS squashing load for IPv6, so we are going to Linux systems
>>> this
>>> year, getting people to consider cake is hard enough, let alone another
>>> middleware box)
>>>
>>> David Lang
>>>
>>> On Sun, 28 Sep 2025, Jaap de Vos wrote:
>>>
>>>> Date: Sun, 28 Sep 2025 14:12:24 +0200 (CEST)
>>>> From: Jaap de Vos <m@jaap.pro>
>>>> Reply-To: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
>>>> To: David Lang <david@lang.hm>, cake@lists.bufferbloat.net
>>>> Subject: Re: [Cake] help request for cake on a large network
>>>>
>>>> Hi David,
>>>>
>>>> I haven't tried it myself yet, but this sounds like a use case for which
>>> LibreQoS is suitable. However, LibreQoS would fit best if you can build
>>> something in line with the design assumptions:
>>> https://libreqos.readthedocs.io/en/latest/docs/v2.0/design.html
>>>> Specifically the part about putting it in between other routers and
>>> running a routing protocol with those.
>>>>
>>>> There are some good recommendations around suitable hardware and
>>> sizing/scaling too:
>>> https://libreqos.readthedocs.io/en/latest/docs/v2.0/requirements.html
>>>>
>>>> What kind of upstream bandwidth are you working with at the conference?
>>> I run the Mikrotik implementation of CAKE on a campsite. It really helps to
>>> get the most out of our asymmetrical gigabit coax line over there, no fiber
>>> available yet. So far, we got close to 500 devices on our outdoor Wi-Fi
>>> network with mostly good experiences, amazing. Before that, FQ_CoDel on
>>> PfSense worked well too, but the network wasn't as busy back then. I'd like
>>> to see CAKE on BSD some day.
>>>>
>>>> Kind regards,
>>>> Jaap de Vos
>>>>
>>>>
>>>>> On 09/28/2025 1:06 PM CEST David Lang <david@lang.hm> wrote:
>>>>>
>>>>>
>>>>> I'm starting to prepare for the next Scale conference and we are
>>> switching from
>>>>> Juniper routers to Linux routers. This gives me the ability to
>>> implement cake.
>>>>>
>>>>> One problem we have is classes that tell everyone 'go download this'
>>> that
>>>>> trigger hundreds of people to hammer the network at the same time (this
>>> is both
>>>>> a wifi and a network bandwidth issue, wifi is being worked on)
>>>>>
>>>>> The network is pretty flat, a couple of subnets each on ipv4 and ipv6.
>>>>>
>>>>> Any suggestions on how to configure cake for this sort of environment
>>> where
>>>>> there are so many devices?
>>>>>
>>>>> David Lang
>>>>> _______________________________________________
>>>>> Cake mailing list -- cake@lists.bufferbloat.net
>>>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>>>>
>>> _______________________________________________
>>> Cake mailing list -- cake@lists.bufferbloat.net
>>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>>>
>> _______________________________________________
>> Cake mailing list -- cake@lists.bufferbloat.net
>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>
>
>
>

      reply	other threads:[~2025-09-28 17:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-28 11:06 [Cake] " David Lang
2025-09-28 12:10 ` [Cake] " Sebastian Moeller
2025-09-28 12:17   ` David Lang
2025-09-28 12:12 ` Jaap de Vos
2025-09-28 12:38   ` David Lang
2025-09-28 12:56     ` Frantisek Borsik
2025-09-28 17:07       ` dave seddon
2025-09-28 17:26         ` David Lang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.2509281021590.14886@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.seddon.ca@gmail.com \
    --cc=frantisek.borsik@gmail.com \
    --cc=m@jaap.pro \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox