VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling 2026-10-18T18:32:14+00:00 2026-10-18T18:32:14+00:00 Christian Breunig christian@breunig.cc 2026-10-18T18:32:14+00:00 urn:sha1:7216e748b8a37929f9d766f21cc47f099c92c27e isis: T9227: add distribute link-state command 2026-10-18T09:34:21+00:00 Alex Kudentsov 43482574+alexk37@users.noreply.github.com 2026-10-08T15:27:36+00:00 urn:sha1:60aabdc9587700a326c8e9df06f09ba0c60c5435 "protocols ospf parameters opaque-lsa" and "protocols ospf capability opaque" are two CLI nodes for one FRR setting, FRR's "capability opaque". Keep "capability opaque" only. The migration script ospf/2-to-3 sets "capability opaque" where "parameters opaque-lsa" exists in the default VRF, and deletes the old node (and the "parameters" node when it is left empty). FRR refuses opaque LSAs outside the default VRF, so in a VRF instance the option never took effect: for a VRF the migration drops both "parameters opaque-lsa" and a plain "capability opaque" instead of moving the value into a node FRR would refuse at the next commit. The template renders the line from "capability opaque" only; it rendered the alias form "ospf opaque-lsa" for the old node, which frr-reload found missing in the running config on every reload: while only the old node was set, every commit that reloads FRR reset all adjacencies of that OSPF instance. Tests: a migration unit test (global instance, VRF instance, a VRF with "capability opaque" set directly, both nodes set together in a VRF, and global+VRF independence), the vrf-ospf config test (now carries "parameters opaque-lsa" in both the default instance and a VRF instance; the VRF instance is expected to lose it with no replacement), test_ospf_02 uses the new node, and test_ospf_21 checks the generated FRR config. 2026-10-17T19:01:11+00:00 Jonathan Voss jvoss@onvox.net 2026-08-18T02:09:54+00:00 urn:sha1:0ac2bb320ffc5f703f1b9ed7b6fb6275b22427c9 2026-10-16T16:04:15+00:00 Christian Breunig christian@breunig.cc 2026-10-16T16:04:15+00:00 urn:sha1:1f482caab97b76e3acb4e675f15011649821a4c2 policy: T9346: Allow dot in `prefix-list` and `prefix-list6` names 2026-10-16T11:41:03+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2026-10-15T09:16:39+00:00 urn:sha1:6e3598a23b22462c59635cac4f367987c253277b VyOS 1.3 allowed a dot in `policy prefix-list` and `policy prefix-list6` names (pattern `^[-_a-zA-Z0-9.]+$`). The XML rewrite dropped the dot from the allowed characters, so a 1.3 configuration using such names can no longer be loaded or committed after an upgrade. FRR itself accepts the dot in prefix-list names. 2026-10-15T13:05:57+00:00 Ruben Herold ruben@puettmann.net 2026-09-04T09:17:26+00:00 urn:sha1:46e06d8fd1f1dd378c128fe87549bdba165f640a The Mikrotik configuration referenced by T9267 uses matching-type=substring, documented to match the value anywhere within the option string. This PR's "substring" match instead compared a fixed-length slice at a fixed byte offset (default 0) for exact equality - effectively an anchored prefix match, not a substring search - which does not reliably reproduce the ticket's own use case of picking a device model string (e.g. "T42S") out of a longer, variably-formatted hostname. Rebuild "hostname substring"/"vendor-class-id substring" on Kea's match()+lcase() instead of substring()==, so a configured value now matches anywhere in the option content and case-insensitively (options like vendor-class-id are not guaranteed to arrive in a fixed case). Drop the "offset" leaf together with it, since it has no remaining purpose once matching is no longer anchored to a fixed position, and there is no released behavior to preserve. Raw hex input and values containing a literal single quote are rejected for substring matching in verify(), since neither can be safely embedded into the generated Kea regular expression; exact "value" matching is unaffected and still accepts both. Reported by alexk37 in review of PR #5436. 2026-10-15T13:05:57+00:00 Ruben Herold ruben@puettmann.net 2026-09-04T09:03:16+00:00 urn:sha1:da0bea0d10020bfd76d2f763965947db905cab9b The byte length compared by a hostname/vendor-class-id "substring" match is always derived from "value" for a meaningful equality test: a shorter length never matches (comparing fewer option bytes against the full value literal), and a longer one is silently clamped by Kea to the available bytes, turning what looks like a prefix match into an exact match of the whole remainder. There is no legitimate use for setting it independently of "value", so drop the leaf rather than add another verify() constraint around it. Reported by alexk37 in review of PR #5436. 2026-10-15T13:05:57+00:00 Ruben Herold ruben@puettmann.net 2026-08-31T10:49:24+00:00 urn:sha1:2e5ea7a8304ed6ce504b3928e3b2f52574a61397 Client classes could previously only match on relay agent information (Option 82). Add matching on the client-sent hostname (Option 12) and vendor class identifier (Option 60), each with an exact-value or substring form, so clients sharing a subnet can be told apart by e.g. device model without splitting the subnet into per-model pools. Also let a client-class deliver its own options (reusing the existing subnet/range option syntax), so a match can directly hand out a model-specific value such as a provisioning URL, independent of which pool the client's lease is drawn from. 2026-10-14T17:16:45+00:00 Daniil Baturin daniil@vyos.io 2026-10-14T17:16:45+00:00 urn:sha1:e96e646f030f4ee6835b1ebbdca0640f0440f0d0 T7886: add a general method for verifying interface reverse dependencies 2026-10-09T13:02:37+00:00 John Estabrook jestabro@vyos.io 2026-10-09T13:02:37+00:00 urn:sha1:998fe8286fea7c2a0492fcf77ee87ae41597f0e8 config-management: T6304: Rewrite commit-archive location into a structured CLI