![]() When ospf6 is started up and SPF is run depending on which route is selected as the parent route we could miss adding a NH. If one possible parent route has two equal cost paths and the second possible parent route has only one depending on which one is selected first determines if we have have one or two NHs. In the network below when creating a route 2001:db8:3:4::/64 in R2. When SPF is run there are two possible parent routes R3 and R4. 2001:db8:1:2 +-----+ 2001:db8:2:5 +--------------+ 2 +---------------+ | ::2 | | ::2 | | +-----+ | | | ::1| | +-----+ |::5 | 1 |2001:db8:1:3+-----+2001:db8:3:5+-----+2001:db8:5:6+-----+ | +------------+ 3 +------------+ 5 +------------+ 6 | +-----+ ::1 ::3 | |::3 ::5 | |::5 ::6| | ::1| +-----+ +-----+ +-----+ | |::3 | | 2001:db8:3:4 | | | |::4 | 2001:db8:1:4 +-----+ +--------------+ 4 | ::4 | | +-----+ The problem was if we first created the route to 2001:db8:3:4::/64 with R3 as the parent route all is fine. The code was merging the NH from the parent route and R3 has 2 NH, one pointing to R1 and one to R5. But if route 2001:db8:3:4::/64 was first created with parent as R4, it has only one NH pointing to R1, and then later a new vertex was created pointing to R3 the code would only copy the nhs from the vertex not from the parent route. The vertex always has just one NH. But the parent route could have more. So when we would bringup this setup one time we would see one NH for 2001:db8:3:4::/64 and the next time we would see two NHs. The code has been modified so that it behaves the same when the route is first created, or when a vertex is created, it selects the NHs from the parent route. Signed-off-by: Lynne Morrison <lynne@voltanet.io> |
||
---|---|---|
.github | ||
alpine | ||
babeld | ||
bfdd | ||
bgpd | ||
debian | ||
doc | ||
docker | ||
eigrpd | ||
fpm | ||
gdb | ||
grpc | ||
include | ||
isisd | ||
ldpd | ||
lib | ||
m4 | ||
mgmtd | ||
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 | ||
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