mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-06-04 09:53:12 +00:00
7a86aa5a0a
During initial session establishment, bgpd performs a "connection transfer" to a new peer struct if the connection was initiated passively (i.e. by the remote peer). With the addition of buffered input and a reorganized packet processor, the following race condition manifests: 1. Remote peer initiates a connection. After exchanging OPEN messages, we send them a KEEPALIVE. They send us a KEEPALIVE followed by 10,000 UPDATE messages. The I/O thread pushes these onto our local peer's input buffer and schedules a packet processing job on the main thread. 2. The packet job runs and processes the KEEPALIVE, which completes the handshake on our end. As part of transferring to ESTABLISHED we transfer all peer state to a new struct, as mentioned. Upon returning from the KEEPALIVE processing routing, the peer context we had has now been destroyed. We notice this and stop processing. Meanwhile 10k UPDATE messages are sitting on the input buffer. 3. N seconds later, the remote peer sends us a KEEPALIVE. The I/O thread schedules another process job, which finds 10k UPDATEs waiting for it. Convergence is achieved, but has been delayed by the value of the KEEPALIVE timer. The racey part is that if the remote peer takes a little bit of time to send UPDATEs after KEEPALIVEs -- somewhere on the order of a few hundred milliseconds -- we complete the transfer successfully and the packet processing job is scheduled on the new peer upon arrival of the UPDATE messages. Yuck. The solution is to schedule a packet processing job on the new peer struct after transferring state. Lengthy commit message in case someone has to debug similar problems in the future... Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> |
||
|---|---|---|
| babeld | ||
| bgpd | ||
| debianpkg | ||
| doc | ||
| eigrpd | ||
| fpm | ||
| gdb | ||
| include | ||
| init | ||
| isisd | ||
| ldpd | ||
| lib | ||
| m4 | ||
| nhrpd | ||
| ospf6d | ||
| ospfclient | ||
| ospfd | ||
| pimd | ||
| pkgsrc | ||
| ports | ||
| python | ||
| qpb | ||
| redhat | ||
| ripd | ||
| ripngd | ||
| sharpd | ||
| snapcraft | ||
| solaris | ||
| tests | ||
| tools | ||
| vtysh | ||
| watchfrr | ||
| zebra | ||
| .clang-format | ||
| .dir-locals.el | ||
| .gitignore | ||
| AUTHORS | ||
| bootstrap.sh | ||
| buildtest.sh | ||
| ChangeLog | ||
| common.am | ||
| COMMUNITY.md | ||
| configure.ac | ||
| COPYING | ||
| COPYING-LGPLv2.1 | ||
| defaults.h | ||
| git-reindent-branch.py | ||
| indent.py | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.NetBSD | ||
| render_md.py | ||
| REPORTING-BUGS | ||
| SERVICES | ||
| stamp-h.in | ||
| update-autotools | ||
FRRouting is free software that manages various IPv4 and IPv6 routing protocols. Currently FRRouting supports BGP4, BGP4+, OSPFv2, OSPFv3, RIPv1, RIPv2, RIPng, PIM-SM/MSDP and LDP as well as very early support for IS-IS, EIGRP and NHRP. See the file REPORTING-BUGS to report bugs. Free RRRouting is free software. See the file COPYING for copying conditions. Public email discussion can be found at https://lists.frrouting.org/listinfo Our public slack channel is at https://frrouting.slack.com