1b1e934fac
Description: =========== Change is intended for fixing the NHT resolution logic. While recursively resolving nexthop, keep looking for a valid/useable route in the rib, by not stopping at the first/most-specific route in the rib. Consider the following set of events taking place on R1: R1(config)# ip route 2.2.2.0/24 ens192 R1# sharp watch nexthop 2.2.2.32 connected R1# show ip nht 2.2.2.32(Connected) resolved via static is directly connected, ens192 Client list: sharp(fd 33) -2.2.2.32 NHT is resolved over the above valid static route. R1# sharp install routes 2.2.2.32 nexthop 2.2.2.32 1 R1# 2.2.2.32(Connected) resolved via static is directly connected, ens192 Client list: sharp(fd 33) -.32/32 comes which is going to resolve through itself, but since this is an invalid route, it will be marked as inactive and will not affect the NHT. R1# sharp install routes 2.2.2.31 nexthop 2.2.2.32 1 R1# 2.2.2.32(Connected) unresolved(Connected) Client list: sharp(fd 50) -Now a .31/32 comes which will resolve over .32 route, but as per the current logic, this will trigger the NHT check, in turn making the NHT unresolved. -With fix, NHT should stay in resolved state as long as the valid static or connected route stays installed Fix: ==== -While resolving nexthops, walk up the tree from the most-specific match, walk up the tree without any ZEBRA_NHT_CONNECTED check. Co-authored-by: Vishal Dhingra <vdhingra@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.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