vyos-1x.git/data, branch rolling

ospf: T9448: do not render metric-type when it is the default

2026-10-09T16:25:23+00:00

With metric-type 2 (the CLI default), every FRR reload deletes and re-adds "default-information originate" and every "redistribute" line under "router ospf". ospfd flushes the Type-5 LSAs on the delete and re-originates them right after, so neighbours can briefly lose the external routes on commits that do not touch OSPF. ospfd and ospf6d (for redistribute) write "metric-type 1" back to the running config and print nothing for type 2, their default. The templates render "metric-type 2", so frr-reload sees a different line on every reload. frrender now adds the XML default of metric-type to the OSPF and OSPFv3 dicts as xml_default_metric_type, for the default and every VRF instance. The templates render metric-type only when it differs from that default, so the generated config matches what FRR prints back. OSPFv3 default-information keeps rendering metric-type, as ospf6d prints it for both types. Add smoketests that read the generated config and vtysh for types 2, 1 and back to 2. Rename the "ptotocol" loop variable in test_protocols_ospf.py to "protocol", which the typos check flags on any change to this file.

Merge pull request #5366 from l0crian1/urpf-refactor

2026-10-08T20:32:45+00:00

interfaces: T9152: Refactor source-validation to use vmaps

Merge pull request #5541 from rnavarro/feat/router-advert-no-remove-on-exit

2026-10-08T05:40:43+00:00

router-advert: T9413: add no-remove-on-exit and no-flush-* options

2026-10-07T22:23:34+00:00

On shutdown radvd sends a final RA with router lifetime 0 and announces its RDNSS and DNSSL entries with lifetime 0. On a VRRP pair that sends RAs from a shared source address (source-address fe80::1), hosts read the zero router lifetime as the shared router going away and remove their default route until the backup's next RA. On my routers that was 1.6 s of IPv6 loss when the master rebooted. radvd controls this with RemoveAdvOnExit, FlushRDNSS and FlushDNSSL, all defaulting to on. Expose them per interface: set service router-advert interface no-remove-on-exit set service router-advert interface no-flush-name-server set service router-advert interface no-flush-dnssl The directives are only rendered when the options are set, so the generated radvd.conf is unchanged for existing configurations.

bgp: T9407: do not render "bgp reject-as-sets" when it is the FRR default

2026-10-07T17:50:29+00:00

Since FRR 10.5 "bgp reject-as-sets" is the default. FRR does not print the default in show running-config, so frr-reload never finds the line in the running config and sends it again on every reload. The command handler resets every BGP session of the instance (NOTIFICATION Cease, other configuration change) whether or not the value changed, so with "protocols bgp parameters reject-as-sets" set, every commit that reloads FRR reset every established session, not only commits that touch BGP. Render only the non-default form: "no bgp reject-as-sets" when the option is not set, as T7664 added it, and nothing when it is set. The option is a valueless leaf, so it has no XML default to read; the rendered "no" form already was the only place that knows what FRR's default is. Changing the option still reaches FRR: frr-reload sends "bgp reject-as-sets" when the option is set (the "no" line leaves the rendered config) and "no bgp reject-as-sets" when it is deleted, and each change resets the sessions once, as before. Add a smoketest that reads the rendered /run/frr/config/vyos.frr.conf, because FRR never prints the default form and vtysh cannot show it.

Merge pull request #5536 from alexk37/bgp-default-local-pref-100

2026-10-07T17:42:07+00:00

bgp: T9404: do not render "bgp default local-preference" when the value is 100

Merge pull request #5442 from ritika0313/T9328-v1x-blast-radius

2026-10-07T15:41:58+00:00

T9351: Accel-PPP-NG: Add CLI support for Message Authenticator attribute in Access packets (Blast-RADIUS mitigation)

bgp: T9404: do not render "bgp default local-preference" when the value is 100

2026-10-06T17:46:24+00:00

FRR does not print "bgp default local-preference 100" in show running-config because 100 is its default, so frr-reload never finds the line in the running config and sends it again on every reload. The command handler calls bgp_clear_star_soft_in() whether or not the value changed, so every reload ran "clear bgp * soft in" (once in pass 0 and twice in pass 1), a full inbound re-evaluation of every peer. Add the default (100) to the XML definition of parameters default local-pref. Templates cannot query the XML definition while rendering, so frrender takes the value from the config defaults of "parameters default" (conf.get_config_defaults) and adds it to the BGP dict as the key xml_default_local_pref, for the global instance and for every VRF instance. bgpd.frr.j2 renders the line only when the configured value differs from xml_default_local_pref, so the value 100 is not hardcoded in the template. A real value change (100 to 200, or 200 to 100) is still sent: frr-reload sees the difference between the rendered file and the running config.

Merge pull request #5532 from c-po/T9395-pppoe-frr-default-route

2026-10-05T16:26:16+00:00

pppoe: T9395: render default routes via FRR only

2026-10-04T06:44:01+00:00

Deleting a PPPoE interface shortly after its session came up could fail the commit with "% could not lock candidate DS". The default routes were installed via vtysh both from the commit and from the asynchronous ppp ip-up hook, so the two FRR sessions raced for the mgmtd lock. The IPv6 default route was also missing from the rendered FRR configuration, so an FRR reload could remove it. Both default routes are now part of the rendered FRR configuration, which vyos-configd applies at the end of every commit. PPPoE no longer calls vtysh.