frr: upgrade to 10.2 and migrate protocols to unified FRRender class #4227
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
❌ |
c-po
changed the title
c-po
force-pushed
the
T6746-frr-10
branch
4 times, most recently
from
3bdd64a to
74bc43d
Compare
11 tasks
c-po
requested review from
dmbaturin,
sarthurdev,
jestabro,
sever-sever,
fett0,
nicolas-fort and
zdc
as code owners
1 task
dmbaturin
approved these changes
Dec 16, 2024
sever-sever
approved these changes
Dec 16, 2024
Honor ospfd deferred shutdown when "max-metric router-lsa on-shutdown" is defined. FRRouting/frr#17011
Drop newlines added by macro statement and Jinja2 comments. Jinja2 comments will be removed during package build on the shipped files.
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 <x.x.x.x/x> interface To have an identical look and feel with regular static routes.
…" CLI tagNode This will save an entire level for the configuration and there is no need for a parent "multicast" node, as it will only have "route" as tagNode below. Move set protocols static multicast route <x.x.x.x/y> to: * set protocols static mroute <x.x.x.x/y>
This is pretty usefull to monitor what's going on under the hood
Dec 08 15:27:34 vyos-configd[4324]: Received message: {"type": "init"}
Dec 08 15:27:34 vyos-configd[4324]: config session pid is 4400
Dec 08 15:27:34 vyos-configd[4324]: config session sudo_user is cpo
Dec 08 15:27:34 vyos-configd[4324]: commit_scripts: ['protocols_babel', 'protocols_bfd', 'protocols_bgp']
Dec 08 15:27:34 vyos-configd[4324]: Received message: {"type": "node", "last": false, "data": "/usr/libexec/vyos/conf_mode/protocols_babel.py"}
Dec 08 15:27:34 vyos-configd[4324]: Sending reply: error_code 1 with output
Dec 08 15:27:34 vyos-configd[4324]: Received message: {"type": "node", "last": false, "data": "/usr/libexec/vyos/conf_mode/protocols_bgp.py"}
Dec 08 15:27:34 vyos-configd[4324]: Sending reply: error_code 1 with output
Dec 08 15:27:34 vyos-configd[4324]: Received message: {"type": "node", "last": true, "data": "/usr/libexec/vyos/conf_mode/protocols_bfd.py"}
Dec 08 15:27:34 vyos-configd[4324]: Sending reply: error_code 1 with output
Dec 08 15:27:34 vyos-configd[4324]: scripts_called: ['protocols_babel', 'protocols_bgp', 'protocols_bfd']
Dec 08 15:27:34 vyos-configd[4324]: FRR: Reloading configuration - tries: 1 Python class ID: 139842739583248
Debugging the new FRRender/vyos-config integration
A lot of services have dynamic debug capabilities which will be turned on by creating a file in /tmp. These scripts have the path hardcoded and sometimes accross multiple places (bad). This commit introduces vyos.defaults.frr_debug_enable to get the path for the debug file from a single location.
When running under vyos-configd only a single apply() is done as last step in the commit algorithm. FRRender class address is provided via an attribute from vyos-configd process.
FRR 10.2 will use "[no] ip forwarding" and "[no] ipv6 forwarding" to enable or disable IP(v6) forwarding. We no longer rely on sysctl as this was overridden by FRR later on. Remove code path for sysctl setting and solely rely on FRR.
Migrate "set protocols static route <x.x.x.x/x> next-hop <y.y.y.y> bfd multi-hop source <z.z.z.z> profile <NAME>" to: "set protocols static route <x.x.x.x/x> next-hop <y.y.y.y> bfd profile bar" FRR supports only one source IP address per BFD multi-hop session. VyOS had CLI cupport for multiple source addresses which made no sense.
VNI was always retrieved via effective configuration and not active configuration.
Consolidate "multicast interface-route" and "multicast route" under common "mroute <x.x.x.x/y>" CLI node.
Sometimes FRR needs some time after reloading the configuration to appear in vtysh. This is a workaround addiung a 2 second guard timer.
Do not use custom daemon definitions like bgpd - re-use them from e.g. vyos.frrender.bgp_daemon
As vyos-configd will take care about the commit via FRRender class, and FRR needs to internally process the configuration we might read it back via vtysh "to fast". Add a 5 seconds guard timer after each cli_commit() and before calling getFRRconfig(). Guard timer is reset every time, cli_commit() is called.
|
CI integration ❌ failed! Details
|
This was referenced Dec 17, 2024
This was referenced Dec 31, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change Summary
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.1will be split into:set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd source-address 1.1.1.1set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hopTo 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 baris changed to:set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd profile barCLI commands
set protocols static multicast interface-routeis moved to:set protocols static multicast route <x.x.x.x/x> interfaceto have an identical look and feel with regular static routes.TODO
Types of changes
Related Task(s)
Related PR(s)
Component(s) name
FRR and all subsequent routing protocols
Smoketest result
Checklist: