vyos-1x.git/data/templates/frr, 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.

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.

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.

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.

Merge pull request #5496 from vyos/T9338-l3vpn-multi-domain-switching

2026-09-29T05:11:42+00:00

T9338: add bgp mpls l3vpn-multi-domain-switching

bgp: T9360: render "orf prefix-list both" if send and receive are set

2026-09-27T18:03:43+00:00

When both the ORF send and receive capability were enabled for a BGP neighbor address-family, the FRR template emitted two individual statements: neighbor 192.0.2.1 capability orf prefix-list send neighbor 192.0.2.1 capability orf prefix-list receive FRR stores this combination as a single "both" directive, so its running configuration never matched what VyOS generated. As a result every subsequent commit, even one entirely unrelated to BGP, removed and re-added the ORF capability. Each of those cycles resets the established BGP session for about two seconds. Cover all three combinations for both a plain neighbor and a peer-group: * send only -> neighbor capability orf prefix-list send * receive only -> neighbor capability orf prefix-list receive * send + receive -> neighbor capability orf prefix-list both The "both" case additionally verifies that the individual send and receive statements are no longer rendered, as those are exactly what made FRR and VyOS disagree about the running configuration. Co-authored-by: Christian Breunig

T9338: add bgp mpls l3vpn-multi-domain-switching

2026-09-24T06:40:37+00:00

Add command set protocols bgp interface mpls l3vpn-multi-domain-switching that exposes FRR's `mpls bgp l3vpn-multi-domain-switching` under interface node.

nhrp: T9128: fix duplicate nftables meter name for multiple redirect tunnels

2026-07-27T07:07:24+00:00

Committing a second NHRP tunnel with "redirect" enabled failed with "Failed to apply NHRP tunnel firewall rules". The redirect chain in nhrpd_nftables.conf.j2 is rendered in a per-tunnel loop but hardcoded the nftables meter name "loglimit-0". With two redirect-enabled tunnels the loop declared the named set "loglimit-0" twice in table vyos_nhrp_redirect, which nft rejects, aborting the atomic ruleset load so the commit failed. Derive the meter name from the loop index (loglimit-0, loglimit-1, ...) so every redirect-enabled tunnel gets a unique meter. The first tunnel keeps the name "loglimit-0", leaving single-tunnel setups unchanged. Add a smoketest that configures two tunnels with redirect + multicast and verifies the commit succeeds and both meters are present. Also clear the "vpn ipsec" tree in tearDown so the IPsec profile created by the existing test does not leak into the new one.

bgp: T6573: fix template indention for "bgp route-reflector"

2026-06-29T15:10:13+00:00

bgp: T6573: add input/output queue limit CLI commands

2026-06-29T15:10:13+00:00

Add input-queue-limit and output-queue-limit CLI nodes to expose global FRR "bgp input-queue-limit" and "bgp output-queue-limit" commands via our CLI. Parameters control the maximum number of queued messages for all BGP peers during message parsing. FRR default is 10000 which we honor. Note that this is a global option and can only be set for the global/default BGP instance.