vyos-1x.git/data/templates/frr/zebra.vrf.route-map.frr.j2, branch feature/T9082-codeql-cpp

frr: T6747: migrate protocols to unified FRRender class

2024-12-16T21:24:36+00:00

With FRR 10.0 daemons started to be migrated to integrated FRR mgmtd and a northbound interface. This led to some drawbacks in the current state how changes to FRR are handled. The current implementation will use frr-reload.py and specifies excatly WHICH daemon needs a config update and will only replace this part inside FRR. With FRR10 and mgmtd when a partial configuration is sent to mgmtd, it will remove configuration parts from other daemons like bgpd or ospfd which have not yet been migrated to mgmtd. It's not possible to call frr-reload.py with daemon mgmtd - it will error out. This commit will also change the CLI for static routes: CLI command "set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop source 1.1.1.1" will be split into: * set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd source-address 1.1.1.1 * set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop To make the XML blocks reusable, and comply with the FRR CLI - this was actually a wrong implementation from the beginning as you can not have multiple BFD source addresses. CLI command "set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop source 1.1.1.1 profile bar" is changed to: * set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd profile bar CLI commands "set protocols static multicast interface-route" is moved to: * set protocols static multicast route interface To have an identical look and feel with regular static routes.

vrf: T6189: render FRR L3VNI configuration when creating VRF instance

2024-05-01T18:55:57+00:00

When adding and removing VRF instances on the fly it was noticed that the vni statement under the VRF instance in FRR vanishes. This was caused by a race condition which was previously designed to fix another bug. The wierd design of a Python helper below the VRF tree to only generate the VNI configuration nodes is now gone and all is rendered in the proper place.

T6001: add option to disable next-hop-tracking resolve-via-default in VRF context

2024-02-16T07:33:13+00:00

* set vrf name ip nht no-resolve-via-default * set vrf name ipv6 nht no-resolve-via-default

vrf: T5174: ensure no duplicate VNIs can be defined

2023-04-26T16:59:07+00:00

vrf: T5150: l3vni must be removed prior to removing BGP VRF process

2023-04-21T19:21:07+00:00

T5150: initial VRF support for Kernel/Zebra route-map filtering

2023-04-13T07:01:31+00:00