Issue with QOS not working on rolling release any more (dhcp fttp)

skyeci-draytek · July 5, 2026, 10:44am

Hi,

I have been a long time Rolling release user and everything has been working great until recently. I use qos for my FTTP connection and this has worked fine upon my last update which was version 2026.05.17-0044. My qos limits my 8GB connection to 7.4gb up/down. Has worked like clockwork for the past couple of years. I updated a few days ago and again to 2026.06.30-0048 - the qos limits are now being ignored - my download goes full speed at 8.1GB.

Can anyone help getting the QOS working again on RR please.

my setup is a 8gb/8gb symmetrical connection, DHCP

Sample of my code which works fine if I revert to the last working RR I used being 17.05.2026. The latest RR does not work.

Thanks very much

set qos policy shaper DOWNLOAD bandwidth ‘7800mbit’
set qos policy shaper DOWNLOAD default queue-type ‘fq-codel’
set qos policy shaper DOWNLOAD default bandwidth ‘100%’
set qos policy shaper UPLOAD bandwidth ‘7800mbit’
set qos policy shaper UPLOAD default queue-type ‘fq-codel’
set qos policy shaper UPLOAD default bandwidth ‘100%’
set qos interface eth0 egress ‘UPLOAD’
set qos interface ifb0 egress ‘DOWNLOAD’

Apachez · July 5, 2026, 11:22am

In a perfect world it should be traceable through:

However when I go back to 17 may 2026 and trace until today there are no commits mentioning QoS so perhaps one need to be specific look elsewhere for changes.

a.kudientsov · July 5, 2026, 11:39am

Looks like the issue is caused this change - qos: T7965: Fix qos fails to reapply on dynamic interfaces after reconnection by opswill · Pull Request #5220 · vyos/vyos-1x · GitHub

Apachez · July 5, 2026, 12:06pm

How come that one is nowhere to be seen on Commits · vyos/vyos-1x · GitHub ?

skyeci-draytek · July 5, 2026, 12:24pm

a couple of days ago and today was the first time I updated since the 17th of may. That was my last working qos config.

rainmakerraw · July 7, 2026, 12:53am

I have a similar issue with redirect not working on boot (but for CAKE), and I don’t know if the underlying cause is the same? I was about to post a new thread, but decided to drop it here first in case it’s related. My originally written post follows:

I have been using VyOS Stream up until 2026.02 without issues. My hardware is a Beelink EQ12 (Intel N100, 2x Intel I225-V B3 NICs, 16GB RAM). I have a symmetric 2 Gbps XGS-PON FTTP line (no PPPoE), with a static allocation of /29 routed over /31 for IPv4, and a /48 routed over /127 for IPv6. I use CAKE on both upload and download (via ifb0 redirect), shaped to 1.85 Gbps.

Since Stream 2026.03 (and on all latest Rolling), on initial boot the ifb0 interface is successfully created. However, traffic fails to redirect to the shaper, and CAKE statistics show 0 packets and bytes processing through ifb0.

Checking the ingress filters on the WAN link following a cold boot shows that the kernel redirection hook is entirely unlinked:

vyos@vyos-lab:~$ tc filter show dev eth0 parent ffff:
vyos@vyos-lab:~$

If the system is allowed to boot, dropping into configuration mode and manually toggling the redirect line immediately resolves the issue and binds the hook, allowing CAKE to shape the packets via ifb0 as usual:

configure
delete interfaces ethernet eth0 redirect 'ifb0'
commit
set interfaces ethernet eth0 redirect 'ifb0'
commit

My QOS config is:

set qos interface eth0 egress 'UPLOAD'
set qos interface ifb0 egress 'DOWNLOAD'
set qos policy cake DOWNLOAD bandwidth '1850mbit'
set qos policy cake DOWNLOAD flow-isolation 'dual-dst-host'
set qos policy cake DOWNLOAD flow-isolation-nat
set qos policy cake DOWNLOAD rtt '70'
set qos policy cake UPLOAD bandwidth '1850mbit'
set qos policy cake UPLOAD flow-isolation 'dual-src-host'
set qos policy cake UPLOAD flow-isolation-nat
set qos policy cake UPLOAD rtt '70'
set interfaces ethernet eth0 redirect 'ifb0'

I then use the boot postconfig script to modify parameters not available in VyOS syntax (overhead, mpu, memlimit, etc). Since CAKE/redirect broke, the following logic was added to /config/scripts/vyos-postconfig-bootup.sh. This successfully resolves the unlinked filter issue on every reboot:

#!/bin/sh
# This script is executed at boot time after VyOS configuration is fully applied.
# Any modifications required to work around unfixed bugs
# or use services not available through the VyOS CLI system can be placed here.

# Wait for interfaces to settle
sleep 15

# Modify the live DOWNLOAD shaper on ifb0
tc qdisc replace dev ifb0 root cake bandwidth 1850Mbit besteffort dual-dsthost nat rtt 70ms raw overhead 26 mpu 84 memlimit 32m

# Modify the live UPLOAD shaper
tc qdisc replace dev eth0 root cake bandwidth 1850Mbit besteffort dual-srchost nat rtt 70ms raw overhead 26 mpu 84 memlimit 32m

# Clear out the environment variables that can trip up the parser
unset vbash_capabilities

# Wait for the interfaces and system to settle completely
sleep 60

# Run the configuration loop directly using the native wrapper tool
/usr/bin/vbash -c '
  export HOME=/home/vyos
  source /opt/vyatta/etc/functions/script-template
  configure
  delete interfaces ethernet eth0 redirect "ifb0"
  commit
  set interfaces ethernet eth0 redirect "ifb0"
  commit
  save
  exit
'

exit 0

I saw previous mentions of bug T6638 but that’s historical and closed as resolved. Does anyone have any hints here, and is that bug worth reopening (or a new one filing)? I’m stuck on an older Stream 2026.02 image (or else stuck without CAKE) while this issue persists.

On Stream 2026.02 and earlier versions, CAKE is absolutely flawless. I get 2ms ping to my BNG/INX and to most anycast/big servers, which only raises to 3–4 ms under full load. A flent rrul test is also exceptionally good, with CAKE’s stats showing single digit us packet delays and no backlog. As soon as I try Stream 2026.03 or recent rolling images, CAKE is dead in the water. It would be nice to see this fixed if possible!

Many thanks in advance.

Edit: The vbash addition to the postconfig script was suggested to me by Gemini AI tonight, while I was labbing the issue. It does ‘fix’ the problem, but I wouldn’t use it in production without checking in here and hopefully helping resolve the actual underlying issue.

Apachez · July 7, 2026, 3:59am

You could try something like this as workaround (see Command scripting — VyOS rolling release (current) for more info):

Create /config/rainmakerraw.sh (dont forget to also put chmod +x /config/rainmakerraw.sh):

#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
delete interfaces ethernet eth0 redirect 'ifb0'
commit
set interfaces ethernet eth0 redirect 'ifb0'
commit

Edit /config/scripts/vyos-postconfig-bootup.sh and add this to the top (after initial comment):

# Wait for interfaces to settle
sleep 5

# Call workaround
/config/rainmakerraw.sh

Would also be interesting to get the output of:

sudo dmesg | grep -i eth0

vs

sudo dmesg | grep -i ifb0

Also this right after you rebooted:

tail -n 100 /var/log/messages

Out of the blue if feels like a timing error as in when vyos-configd configures eth0 and redirects to ifb0 there is nothing to redirect into (as why the same command works later on) but at the same time I think the interfaces should already been created/existing by then - also wouldnt explain why it works in stream 2026.02 and older.

rainmakerraw · July 7, 2026, 2:47pm

Following up with completely clean logs, after rebuilding my lab VM from scratch. The issue remains entirely reproducible on a naked install with the latest rolling image. On initial boot, tc filter show dev eth0 parent ffff: returns completely blank, and CAKE on ifb0 sits at 0 packets.

The logs suggest a distinct initialisation timing window between the configuration engine and the network driver link state. vyos-configd executes the QoS and interface scripts and reports final configuration success by system time 15:02:16:

Jul  7 15:02:14 vyos-lab vyos-configd[850]: scripts_called: ['system_host-name', 'system_host-name', 'system_console', 'system_timezone', 'nat', 'interfaces_loopback_lo', 'interfaces_input_ifb0', 'interfaces_ethernet_eth0', 'interfaces_ethernet_eth1', 'system_config-management', 'system_syslog', 'system_host-name', 'system_host-name', 'system_host-name', 'system_host-name', 'system_login', 'firewall', 'qos', 'service_ntp', 'service_dhcp-server', 'service_dns_forwarding', 'service_ssh', 'system_option']
...
Jul  7 15:02:16 vyos-lab vyos-config[1045]: Configuration success

However, checking dmesg shows that the physical interface carrier transition doesn’t complete until 32.16 seconds into the kernel boot sequence:

[    1.958012] e1000 0000:02:01.0 eth0: (PCI:66MHz:32-bit) 00:0c:29:3a:fd:e5
[    1.958569] e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.347954] e1000 0000:02:01.0 e2: renamed from eth0
[   19.640377] e1000 0000:02:01.0 eth0: renamed from e2
[   30.130942] 8021q: adding VLAN 0 to HW filter on device eth0
[   32.164813] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Because the configuration engine processes the qos ruleset before the dynamic network interface link layer has matured to an active link up state, the redirection hook then seemingly fails to attach to the kernel table during boot.

Here are the complete readouts from this run as requested. I hope it helps pin down the issue:

vyos@vyos-lab:~$ sudo dmesg | grep -i eth0
[    1.958012] e1000 0000:02:01.0 eth0: (PCI:66MHz:32-bit) 00:0c:29:3a:fd:e5
[    1.958569] e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.347954] e1000 0000:02:01.0 e2: renamed from eth0
[   19.640377] e1000 0000:02:01.0 eth0: renamed from e2
[   30.130942] 8021q: adding VLAN 0 to HW filter on device eth0
[   32.164813] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

vyos@vyos-lab:~$ sudo dmesg | grep -i ifb0
vyos@vyos-lab:~$

vyos@vyos-lab:~$ tc filter show dev eth0 parent ffff:
vyos@vyos-lab:~$

vyos@vyos-lab:~$ tail -n 100 /var/log/messages
Jul  7 15:02:12 vyos-lab dbus-daemon[1007]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Jul  7 15:02:12 vyos-lab systemd[1]: Started Authorization Manager.
Jul  7 15:02:12 vyos-lab polkitd[2967]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Jul  7 15:02:12 vyos-lab systemd[1]: Started Dynamic System Tuning Daemon.
Jul  7 15:02:12 vyos-lab dbus-daemon[1007]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' requested by ':1.21' (uid=0 pid=2717 comm="/usr/bin/python3 -Es /usr/sbin/tuned -l -P")
Jul  7 15:02:12 vyos-lab systemd[1]: Starting Authorization Manager...
Jul  7 15:02:12 vyos-lab polkitd[2967]: Started polkitd version 122
Jul  7 15:02:12 vyos-lab polkitd[2967]: Loading rules from directory /etc/polkit-1/rules.d
Jul  7 15:02:12 vyos-lab polkitd[2967]: Loading rules from directory /usr/share/polkit-1/rules.d
Jul  7 15:02:12 vyos-lab polkitd[2967]: Finished loading, compiling and executing 2 rules
Jul  7 15:02:12 vyos-lab dbus-daemon[1007]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Jul  7 15:02:12 vyos-lab systemd[1]: Started Authorization Manager.
Jul  7 15:02:12 vyos-lab polkitd[2967]: Acquired the name org.freedesktop.PolicyKit1 on the system bus
Jul  7 15:02:12 vyos-lab systemd[1]: Started Dynamic System Tuning Daemon.
Jul  7 15:02:13 vyos-lab systemd[1]: Reloading.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:4 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:6 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:9 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:11 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab vyos-configd[850]: [system_option]
Jul  7 15:02:14 vyos-lab vyos-configd[850]: scripts_called: ['system_host-name', 'system_host-name', 'system_console', 'system_timezone', 'nat', 'interfaces_loopback_lo', 'interfaces_input_ifb0', 'interfaces_ethernet_eth0', 'interfaces_ethernet_eth1', 'system_config-management', 'system_syslog', 'system_host-name', 'system_host-name', 'system_host-name', 'system_host-name', 'system_login', 'firewall', 'qos', 'service_ntp', 'service_dhcp-server', 'service_dns_forwarding', 'service_ssh', 'system_option']
Jul  7 15:02:13 vyos-lab systemd[1]: Reloading.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:4 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:6 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:9 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab systemd-udevd[858]: /etc/udev/rules.d/40-usb_modeswitch.rules:11 ATTR key takes '==', '!=', or '=' operator, assuming '='.
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
Jul  7 15:02:14 vyos-lab vyos-configd[850]: [system_option]
Jul  7 15:02:14 vyos-lab vyos-configd[850]: scripts_called: ['system_host-name', 'system_host-name', 'system_console', 'system_timezone', 'nat', 'interfaces_loopback_lo', 'interfaces_input_ifb0', 'interfaces_ethernet_eth0', 'interfaces_ethernet_eth1', 'system_config-management', 'system_syslog', 'system_host-name', 'system_host-name', 'system_host-name', 'system_host-name', 'system_login', 'firewall', 'qos', 'service_ntp', 'service_dhcp-server', 'service_dns_forwarding', 'service_ssh', 'system_option']
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [WFP93-1D146] configuration write completed with exit code 0
Jul  7 15:02:14 vyos-lab vyos-configd[850]: Sending reply: SUCCESS with output
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00
Jul  7 15:02:14 vyos-lab watchfrr[1430]: [WFP93-1D146] configuration write completed with exit code 0
Jul  7 15:02:14 vyos-lab vyos-configd[850]: Sending reply: SUCCESS with output
Jul  7 15:02:14 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_1575.mount: Deactivated successfully.
Jul  7 15:02:14 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_1575.mount: Deactivated successfully.
Jul  7 15:02:15 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface pim6reg has no usable IPv4 addresses configured
Jul  7 15:02:15 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ifb0 has no usable IPv4 addresses configured
Jul  7 15:02:15 vyos-lab commit: Successful change to active configuration by user root on unknown
Jul  7 15:02:15 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_1575.mount: Deactivated successfully.
Jul  7 15:02:15 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface pim6reg has no usable IPv4 addresses configured
Jul  7 15:02:15 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ifb0 has no usable IPv4 addresses configured
Jul  7 15:02:15 vyos-lab commit[3141]: Successful change to active configuration by user root on unknown
Jul  7 15:02:15 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_1575.mount: Deactivated successfully.
Jul  7 15:02:15 vyos-lab vyos-router[1041]:  migrate activate configure.
Jul  7 15:02:15 vyos-lab systemd[1]: Reloading.
Jul  7 15:02:15 vyos-lab vyos-router[1041]: migrate activate configure.
Jul  7 15:02:15 vyos-lab systemd[1]: Reloading.
Jul  7 15:02:16 vyos-lab systemd[1]: Started VyOS netlink daemon.
Jul  7 15:02:16 vyos-lab systemd[1]: Started VyOS netlink daemon.
Jul  7 15:02:16 vyos-lab vyos-netlinkd[3181]: VyOS Netlink listener daemon started.
Jul  7 15:02:16 vyos-lab vyos-netlinkd[3181]: IPRoute.bind() using link and address RTNL subscriptions
Jul  7 15:02:16 vyos-lab vyos-config[1045]: Configuration success
Jul  7 15:02:16 vyos-lab vyos-netlinkd[3181]: VyOS Netlink listener daemon started.
Jul  7 15:02:16 vyos-lab vyos-netlinkd[3181]: IPRoute.bind() using link and address RTNL subscriptions
Jul  7 15:02:16 vyos-lab vyos-config[1045]: Configuration success
Jul  7 15:02:17 vyos-lab sshd[3017]: Accepted password for vyos from 172.16.32.200 port 58098 ssh2
Jul  7 15:02:17 vyos-lab sshd[3017]: pam_unix(sshd:session): session opened for user vyos(uid=1002) by (uid=0)
Jul  7 15:02:17 vyos-lab systemd-logind[1011]: New session 1 of user vyos.
Jul  7 15:02:17 vyos-lab systemd[1]: Created slice User Slice of UID 1002.
Jul  7 15:02:17 vyos-lab systemd[1]: Starting User Runtime Directory /run/user/1002...
Jul  7 15:02:17 vyos-lab systemd[1]: Finished User Runtime Directory /run/user/1002.
Jul  7 15:02:17 vyos-lab systemd[1]: Starting User Manager for UID 1002...
Jul  7 15:02:17 vyos-lab (systemd): pam_unix(systemd-user:session): session opened for user vyos(uid=1002) by (uid=0)
Jul  7 15:02:17 vyos-lab sshd[3017]: Accepted password for vyos from 172.16.32.200 port 58098 ssh2
Jul  7 15:02:17 vyos-lab sshd[3017]: pam_unix(sshd:session): session opened for user vyos(uid=1002) by (uid=0)
Jul  7 15:02:18 vyos-lab systemd[3187]: Queued start job for default target default.target.
Jul  7 15:02:17 vyos-lab systemd-logind[1011]: New session 1 of user vyos.
Jul  7 15:02:17 vyos-lab systemd[1]: Created slice User Slice of UID 1002.
Jul  7 15:02:17 vyos-lab systemd[1]: Starting User Runtime Directory /run/user/1002...
Jul  7 15:02:17 vyos-lab systemd[1]: Finished User Runtime Directory /run/user/1002.
Jul  7 15:02:17 vyos-lab systemd[1]: Starting User Manager for UID 1002...
Jul  7 15:02:17 vyos-lab (systemd)[3187]: pam_unix(systemd-user:session): session opened for user vyos(uid=1002) by (uid=0)
Jul  7 15:02:18 vyos-lab rsyslogd: imjournal: journal files changed, reloading...  [v8.2302.0 try [https://www.rsyslog.com/e/0](https://www.rsyslog.com/e/0) ]
Jul  7 15:02:18 vyos-lab systemd[3187]: Queued start job for default target default.target.
Jul  7 15:02:18 vyos-lab rsyslogd[2037]: imjournal: journal files changed, reloading...  [v8.2302.0 try [https://www.rsyslog.com/e/0](https://www.rsyslog.com/e/0) ]
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target paths.target - Paths.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target sockets.target - Sockets.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target timers.target - Timers.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target basic.target - Basic System.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target default.target - Main User Target.
Jul  7 15:02:18 vyos-lab systemd[3187]: Startup finished in 115ms.
Jul  7 15:02:18 vyos-lab systemd[1]: Started User Manager for UID 1002.
Jul  7 15:02:18 vyos-lab systemd[1]: Started Session 1 of User vyos.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target paths.target - Paths.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target sockets.target - Sockets.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target timers.target - Timers.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target basic.target - Basic System.
Jul  7 15:02:18 vyos-lab systemd[3187]: Reached target default.target - Main User Target.
Jul  7 15:02:18 vyos-lab systemd[3187]: Startup finished in 115ms.
Jul  7 15:02:18 vyos-lab systemd[1]: Started User Manager for UID 1002.
Jul  7 15:02:18 vyos-lab systemd[1]: Started Session 1 of User vyos.
Jul  7 15:02:18 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_3209.mount: Deactivated successfully.
Jul  7 15:02:18 vyos-lab systemd[1]: opt-vyatta-config-tmp-new_config_3209.mount: Deactivated successfully.
Jul  7 15:02:20 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface pim6reg has no usable IPv4 addresses configured
Jul  7 15:02:20 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ifb0 has no usable IPv4 addresses configured
Jul  7 15:02:20 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface pim6reg has no usable IPv4 addresses configured
Jul  7 15:02:20 vyos-lab kea-dhcp4[2575]: WARN  DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface ifb0 has no usable IPv4 addresses configured

As an aside, scripting the deletion and re-adding of ifb0 does indeed bring things back into line and allow CAKE to work. It’s a viable work-around for now on Stream 2026.03 or Rolling, but there’s clearly an underlying mechanism/race condition causing the problem to begin with. If I can provide anything else please don’t hesitate to ask. Cheers.

Apachez · July 7, 2026, 2:56pm

What is this ifb0 anyway?

Does it show up when you do a “show interfaces”?

And how come you do that redirect eth0 into ifb0?

rainmakerraw · July 7, 2026, 3:11pm

To shape downstream traffic one needs an ifb0 redirect, as per the docs.

rainmakerraw · July 7, 2026, 5:36pm

@skyeci-draytek I have managed to get this working (for CAKE) on both Stream 2026.03 and the latest rolling. It seems the logic was changed so you can’t have a redirect and a direct attachment for QoS on an interface at the same time. The end result is silent failure of the QoS shaper. For example, you can no longer have ifb0 redirecting ingress/download traffic on the WAN interface, while simultaneously having egress/upload directly attached to that physical interface. It worked fine on versions prior, so I guess something was changed (or fixed!).

Testing in the lab against both Stream and Rolling, if one instead adds a second redirect (ifb1) for egress/upload, QoS starts working again properly in both directions. It’s possible to directly attach when only shaping the upload (for example) but not with both.

I will fix up a basic config script to reflect this and send it to you for testing against fq_codel, if you’d be kind enough to update on whether it works?

Edit: I tested against fq_codel on the lab machine and it works perfectly, preserving the tc qdisc and showing show qos shaper packets passing both inbound and outbound against both redirects on the WAN interface.

rainmakerraw · July 7, 2026, 7:11pm

Last update from me, OP:

I’ve confirmed the fix. Assuming eth0 is WAN and eth1 is LAN, if you delete your existing qos and redirect(s):

delete qos
delete interfaces ethernet eth0 redirect
commit

Then re-add with dual redirects (ingress/download on WAN, egress/upload on LAN):

# Create the virtual shaper redirects
set interfaces input ifb0 description 'WAN for Download Shaper'
set interfaces input ifb1 description 'LAN for Upload Shaper'

# Define the fq_codel policies
set qos policy shaper DOWNLOAD bandwidth '7800mbit'
set qos policy shaper DOWNLOAD default queue-type 'fq-codel'
set qos policy shaper DOWNLOAD default bandwidth '100%'

set qos policy shaper UPLOAD bandwidth '7800mbit'
set qos policy shaper UPLOAD default queue-type 'fq-codel'
set qos policy shaper UPLOAD default bandwidth '100%'

# Apply the traffic policies
set qos interface ifb0 egress 'DOWNLOAD'
set qos interface ifb1 egress 'UPLOAD'

# Bind interfaces
set interfaces ethernet eth0 redirect 'ifb0'
set interfaces ethernet eth1 redirect 'ifb1'

commit; save; exit

You should be good to go. It wasn’t a VyOS bug, more a behaviour change prompting the necessity to change the config structure… HTH, but let us know if it doesn’t work or you need anything else!

skyeci-draytek · July 8, 2026, 9:12pm

Thanks so much for your help. I have tested this on a couple of my spare units this evening and it works as expected.

Sterling work!

gus · July 21, 2026, 10:46am

I am on VyOS 2026.07.11-0033-rolling (on an APU4) and I am also seeing the issue of download limits in my shaper rules being ignored (download is running much faster than the specified ingress bandwidth). In my case, my LAN ports are part of a bridge br0.

How would I do this if my LAN ports are part of a bridge? If I try this:

set interfaces ethernet br0 redirect 'ifb1'

I get the following:

vyos@vyos# set interfaces ethernet br0 redirect ‘ifb1’

Invalid Ethernet interface name
Value validation failed
Set failed

[edit]
vyos@vyos#

Thanks!

gus · July 21, 2026, 10:55am

Apologies, never mind. I should have been using:

vyos@vyos# set interfaces bridge br0 redirect ‘ifb1’