44f7f1320c
Issue: For consecutive messages such as MAC1 -> VTEP1 add MAC1 -> VTEP2 add MAC1 -> VTEP1 add Final state, i.e. (MAC1 -> VTEP1 add) should be sent via FPM. But, with current code, FPM will send (MAC1 -> VTEP2 add) RCA: When FPM receives (MAC1, VTEP1), it stores it in the FPM processing queue and hash table. When FPM receives (MAC1, VTEP2), this entry is stored as another node as hash table key is (mac, vtep and vni) IF FPM again receives (MAC1, VTEP1), we fetch this node in the hash table which is already enqueued. When the FPM queue is processed, we will send FPM message for (MAC1, VTEP1) first and then for (MAC1, VTEP2) This sequencing issue happened because the key of the table is (MAC, VTEP, VNI) Fix: Change the key of the hash table to (MAC, VNI) So, every time we receive a new update for (MAC1, VNI1), we will find a node in the processing queue corresponding to MAC1 if present. We will update this same node for every operation related to (MAC1, VNI1) Thus, at the time when FPM processes this node, it will have latest MAC1 info. Signed-off-by: Ameya Dharkar <adharkar@vmware.com> |
||
|---|---|---|
| .github | ||
| alpine | ||
| babeld | ||
| bfdd | ||
| bgpd | ||
| debian | ||
| doc | ||
| docker | ||
| eigrpd | ||
| fpm | ||
| gdb | ||
| grpc | ||
| include | ||
| isisd | ||
| ldpd | ||
| lib | ||
| m4 | ||
| mlag | ||
| nhrpd | ||
| ospf6d | ||
| ospfclient | ||
| ospfd | ||
| pbrd | ||
| pimd | ||
| pkgsrc | ||
| python | ||
| qpb | ||
| redhat | ||
| ripd | ||
| ripngd | ||
| sharpd | ||
| snapcraft | ||
| solaris | ||
| staticd | ||
| tests | ||
| tools | ||
| vrrpd | ||
| vtysh | ||
| watchfrr | ||
| yang | ||
| zebra | ||
| .clang-format | ||
| .dir-locals.el | ||
| .dockerignore | ||
| .gitignore | ||
| bootstrap.sh | ||
| buildtest.sh | ||
| changelog-auto.in | ||
| config.version.in | ||
| configure.ac | ||
| COPYING | ||
| COPYING-LGPLv2.1 | ||
| Makefile.am | ||
| README.md | ||
| stamp-h.in | ||
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 as well as Solaris 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