mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-08-14 04:26:12 +00:00
a7a7fa57fe
When BGP is sending updates to peers on a neighbor up event it was noticed that the bgp updates being sent were in reverse order being sent to the first peer. Imagine r1 -- r2 -- r3. r1 and r2 are ebgp peers and r2 and r3 are ebgp peers. r1's interface to r2 is currently shutdown. Prior to this fix the send order would look like this: r1 -> r2 send of routes to r2 and then they would be installed in order received: 10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 r2 would then send these routes to r3 and then they would be installed in order received: 10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 Not that big of a deal right? Well imagine a situation where r1 is originating several ten's of thousands of routes. It sends routes to r2 r2 is processing routes but in reverse order and at the same time it is sending routes to r3, in the correct order of the bgp table. r3 will have the early 10.0.0.1/32 routes installed and start forwarding while r2 will not have those routes installed yet( since they were at the end and zebra is slightly slower for processing routes than bgp is ). Ensure that the order sent is a true FIFO. What is happening is that there is an update fifo which stores all routes. And off that FIFO is a bgp advertise attribute list which stores the list of prefixes which share the same attribute that allow for more efficient packing this list was being stored in reverse order causing the problem for the initial send. When adding items to this list put them at the end so we keep the fifo order that is traversed when we walk through the bgp table. After the fix: r2 installation order: 10.0.0.0 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20 r3 installation order: 10.0.0.0 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20 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