![]() Currently bgp multipath has these properties: a) mp_info may or may not be on a single path, based upon path perturbations in the past. b) mp_info->count started counting at 0( meaning 1 ). As that the bestpath path_info was never included in the count c) The first mp_info in the list held the multipath data associated with the multipath. As such if you were at any other node that data was not filled in. d) As such the mp_info's that are not first on the list basically were just pointers to the corresponding bgp_path_info that was in the multipath. e) On bestpath calculation, a linklist(struct linklist *) of bgp_path_info's was created. f) This linklist was passed in to a comparison function that took the old mpinfo list and compared it item by item to the linklist and doing magic to figure out how to create a new mp_info list. g) the old mp_info and the link list had to be memory managed and freed up. h) BGP_PATH_MULTIPATH is only set on non bestpath nodes in the multipath. This is really complicated. Let's change the algorithm to this: a) When running bestpath, mark a bgp_path_info node that could be in the ecmp path as BGP_PATH_MULTIPATH_NEW. b) When running multipath, just walk the list of bgp_path_info's and if it has BGP_PATH_MULTIPATH_NEW on it, decide if it is in BGP_MULTIPATH. If we run out of space to put in the ecmp, clear the flag on the rest. c) Clean up the counting of sometimes adding 1 to the mpath count. d) Only allocate a mpath_info node for the bestpath. Clean it up when done with it. e) remove the unneeded list management associated with the linklist and the mp_list. This greatly simplifies multipath computation for bgp and reduces memory load for large scale deployments. 2 full feeds in work_queue_run prior: 0 56367.471 1123 50193 493695 50362 493791 0 0 0 TE work_queue_run BGP multipath info : 1941844 48 110780992 1941844 110780992 2 full feeds in work_queue_run after change: 1 52924.931 1296 40837 465968 41025 487390 0 0 1 TE work_queue_run BGP multipath info : 970860 32 38836880 970866 38837120 Aproximately 4 seconds of saved cpu time for convergence and ~75 mb smaller run time. Signed-off-by: Donald Sharp <sharpd@nvidia.com> |
||
---|---|---|
.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 | ||
.dockerignore | ||
.flake8 | ||
.git-blame-ignore-revs | ||
.gitignore | ||
.isort.cfg | ||
.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