I don't know if the default value of 1 is a good idea, but per feature, it could be.
For example, we use it in the OpenVPN https://github.com/vyos/vyos-1x/blob/3edf114bed538733388252da0d23b49002273558/src/conf_mode/interfaces_openvpn.py#L844

@ssasso, I would be grateful if you provide the output of the following command:

• sudo /usr/lib/frr/frr-reload.py --reload --debug --stdout /run/frr/config/vyos.frr.conf

Ran into this on a rolling build (FRR 10.5.2). Without any source binding, the session stays stuck in Connecting with (unspec) as local address:

https://github.com/vyos/vyos-1x/pull/5289

PR https://github.com/vyos/vyos-1x/pull/5280

https://github.com/vyos/vyos-1x/pull/5288

In T8990#269967, @a.kudientsov wrote:

https://github.com/vyos/vyos-1x/pull/5287

https://github.com/vyos/vyos-1x/pull/5287

https://github.com/vyos/vyos-1x/pull/5286

https://github.com/vyos/vyos-1x/pull/5285

PR: https://github.com/vyos/vyos-1x/pull/5284
Suggested CLI and details in PR.

Phase 1 + Phase 2 (evaluate) progress — 2026-06-19:

A workaround to using a custom private registry is to manually preload the images.

https://github.com/vyos/vyos-1x/pull/5283

'Resolved for the rolling

Cannot reproduce on version 2026.06.16-1247-rolling

Jun 19 10:10:41 vyos dhclient[1840]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 12
Jun 19 10:10:50 vyos vyos-configd[738]: Received message: {"type": "init"}
Jun 19 10:10:50 vyos vyos-configd[738]: config session pid is 2765
Jun 19 10:10:50 vyos vyos-configd[738]: config session sudo_user is vyos
Jun 19 10:10:50 vyos vyos-configd[738]: commit_scripts: ['vpn_ipsec']
Jun 19 10:10:50 vyos vyos-configd[738]: Received message: {"type": "node", "last": true, "data": "/usr/libexec/vyos/conf_mode/vpn_ipsec.py"}
Jun 19 10:10:50 vyos systemd[1]: Reloading strongSwan IPsec IKEv1/IKEv2 daemon using swanctl...
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded 0 entries for attr plugin configuration
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded 0 RADIUS server configurations
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded IKE shared key with id 'ike-VPP' for: '192.0.2.1', '192.0.2.2'
Jun 19 10:10:50 vyos charon-systemd[3326]: updated vici connection: VPP
Jun 19 10:10:50 vyos swanctl[3857]: loaded ike secret 'ike-VPP'
Jun 19 10:10:50 vyos swanctl[3857]: no authorities found, 0 unloaded
Jun 19 10:10:50 vyos swanctl[3857]: no pools found, 0 unloaded
Jun 19 10:10:50 vyos swanctl[3857]: loaded connection 'VPP'
Jun 19 10:10:50 vyos swanctl[3857]: successfully loaded 1 connections, 0 unloaded
Jun 19 10:10:50 vyos systemd[1]: Reloaded strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
Jun 19 10:10:50 vyos vyos-configd[738]: [vpn_ipsec]
Jun 19 10:10:50 vyos vyos-configd[738]: scripts_called: ['vpn_ipsec']
Jun 19 10:10:50 vyos vyos-configd[738]: Sending reply: SUCCESS with output
Jun 19 10:10:50 vyos systemd[1]: opt-vyatta-config-tmp-new_config_2765.mount: Deactivated successfully.
Jun 19 10:10:52 vyos commit[3904]: Successful change to active configuration by user vyos on /dev/ttyS0

Taking over from @Vijayakumar and re-scoping. Research outcome: Mergify cannot run content scanners (it only gates on *existing* check results), so the path forward is fleet-wide-capable enforcement via a GitHub repository ruleset ("require workflows to pass") — no per-repo caller files — piloted on vyos-1x / vyos-build / vyatta-cfg-system / vyconf (branches rolling/circinus/sagitta) in evaluate → active mode, with a rebuilt standalone typos.yml (official crate-ci/typos action, prebuilt binary, fork-safe on: pull_request, full-tree scan, central _typos.toml allowlist). The per-repo-caller rollout (stalled ~2 months at 1 repo) is superseded.

https://github.com/vyos/vyos.vyos/pull/486

I was able to achieve the PCP set with different CoS value with subsystem tc of linux. Re-using the available options of QoS, it is possible to identify CoS values (L2 traffic) for ingress and egress. Let me explain how Linux performs the PCP values.

PR: https://github.com/vyos/vyos-1x/pull/5282

https://github.com/vyos/vyos-1x/pull/5281

Status check 2026-06-18 (triage of open GitHub Infrastructure tasks). @Vijayakumar — current state of this rollout:

Resolving — superseded by T8782 (IS-432, Passed). The centralization goal (eliminate per-repo Mergify-config duplication via extends; future policy changes = 2 PRs not 30+) is delivered fleet-wide — but via dedicated vyos/mergify + VyOS-Networks/mergify repos with extends: mergify, not this task's extends: .github design (the bare mergify repo name was chosen for fleet symmetry, and .github-repo hosting was dropped). Live on ~55 product repos; fleet extends adoption tracked/closed under T8852. No per-repo config duplication remains. Closing as resolved (delivered via sibling); Jira companion IS-404 being cancelled as superseded by IS-432.

Fix merged to rolling in vyos-documentation#2108 (Phase 0 CodeRabbit clean on the diff; root cause + fix verified in-browser).

PR: https://github.com/vyos/vyos-1x/pull/5279

PR: https://github.com/vyos/vyos-1x/pull/5278

https://github.com/vyos/vyos-1x/pull/5276

https://github.com/vyos/vyos-1x/pull/5277