f68ce97627
There is a bit of an impedance mismatch in the sequence of events here. Depending on the dplane behavior, the `ROUTE_ENTRY_SELECTED` bit will be inconsistent for rib_process_result(). With an asynchronous dataplane: 0. rib_process() is called 1. rib_install_kernel() is called, dplane action is queued 2. rib_install_kernel() returns 3. rib_process() sets the SELECTED bit appropriately, returns 4. dplane is done, triggers rib_process_result() 5. SELECTED bit is seen in "after" state (5a. NHT code looks at the SELECTED bit, works correctly.) With a synchronous dataplane: 0. rib_process() is called 1. rib_install_kernel() is called, dplane action is executed 2. dplane (should) trigger rib_process_result() 3. SELECTED bit is seen in "before" state (3a. NHT code looks at the SELECTED bit, fails.) 4. rib_install_kernel() returns 5. rib_process() sets the SELECTED bit appropriately, too late. Essentially, poking the dataplane is a sequencing point where control is handed over to the dplane. Control may or may not return immediately. Doing /anything/ after triggering the dataplane is a recipe for odd race conditions. (FWIW, I'm not sure rib_process_result() is called correctly in the synchronous case, but that's a separate problem.) Unfortunately, this change might have some unforeseen side effects. I haven't dug through the code to see if anything breaks. There /shouldn't/ be anything looking at the SELECTED bit here, but who knows. Signed-off-by: David Lamparter <equinox@opensourcerouting.org> |
||
|---|---|---|
| .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