mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-08-06 16:20:08 +00:00
ac2cb9bf94
Currently, it is possible to rename the default VRF either by passing `-o` option to zebra or by creating a file in `/var/run/netns` and binding it to `/proc/self/ns/net`. In both cases, only zebra knows about the rename and other daemons learn about it only after they connect to zebra. This is a problem, because daemons may read their config before they connect to zebra. To handle this rename after the config is read, we have some special code in every single daemon, which is not very bad but not desirable in my opinion. But things are getting worse when we need to handle this in northbound layer as we have to manually rewrite the config nodes. This approach is already hacky, but still works as every daemon handles its own NB structures. But it is completely incompatible with the central management daemon architecture we are aiming for, as mgmtd doesn't even have a connection with zebra to learn from it. And it shouldn't have it, because operational state changes should never affect configuration. To solve the problem and simplify the code, I propose to expand the `-o` option to all daemons. By using the startup option, we let daemons know about the rename before they read their configs so we don't need any special code to deal with it. There's an easy way to pass the option to all daemons by using `frr_global_options` variable. Unfortunately, the second way of renaming by creating a file in `/var/run/netns` is incompatible with the new mgmtd architecture. Theoretically, we could force daemons to read their configs only after they connect to zebra, but it means adding even more code to handle a very specific use-case. And anyway this won't work for mgmtd as it doesn't have a connection with zebra. So I had to remove this option. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com> |
||
|---|---|---|
| .github | ||
| alpine | ||
| babeld | ||
| bfdd | ||
| bgpd | ||
| debian | ||
| doc | ||
| docker | ||
| eigrpd | ||
| fpm | ||
| gdb | ||
| grpc | ||
| include | ||
| isisd | ||
| ldpd | ||
| lib | ||
| m4 | ||
| mlag | ||
| nhrpd | ||
| ospf6d | ||
| ospfclient | ||
| ospfd | ||
| pathd | ||
| pbrd | ||
| pceplib | ||
| pimd | ||
| pkgsrc | ||
| python | ||
| qpb | ||
| redhat | ||
| ripd | ||
| ripngd | ||
| sharpd | ||
| snapcraft | ||
| staticd | ||
| tests | ||
| tools | ||
| vrrpd | ||
| vtysh | ||
| watchfrr | ||
| yang | ||
| zebra | ||
| .clang-format | ||
| .dir-locals.el | ||
| .dockerignore | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| bootstrap.sh | ||
| buildtest.sh | ||
| config.version.in | ||
| configure.ac | ||
| COPYING | ||
| COPYING-LGPLv2.1 | ||
| Makefile.am | ||
| README.md | ||
| stamp-h.in | ||
| version.h | ||
FRRouting
FRR is free software that implements and manages various IPv4 and IPv6 routing protocols. It runs on nearly all distributions of Linux and BSD and supports all modern CPU architectures.
FRR currently supports the following protocols:
- BGP
- OSPFv2
- OSPFv3
- RIPv1
- RIPv2
- RIPng
- IS-IS
- PIM-SM/MSDP
- LDP
- BFD
- Babel
- PBR
- OpenFabric
- VRRP
- EIGRP (alpha)
- NHRP (alpha)
Installation & Use
For source tarballs, see the releases page.
For Debian and its derivatives, use the APT repository at https://deb.frrouting.org/.
Instructions on building and installing from source for supported platforms may be found in the developer docs.
Once installed, please refer to the user guide for instructions on use.
Community
The FRRouting email list server is located here and offers the following public lists:
| Topic | List |
|---|---|
| Development | dev@lists.frrouting.org |
| Users & Operators | frog@lists.frrouting.org |
| Announcements | announce@lists.frrouting.org |
For chat, we currently use Slack. You can join by clicking the "Slack" link under the Participate section of our website.
Contributing
FRR maintains developer's documentation which contains the project workflow and expectations for contributors. Some technical documentation on project internals is also available.
We welcome and appreciate all contributions, no matter how small!
Security
To report security issues, please use our security mailing list:
security [at] lists.frrouting.org