Created attachment 241558 [details] Put patch in files/, recompile This type of crash can happen: BGP: bgpd/bgp_lcommunity.c:236: set_lcommunity_string(): assertion ((unsigned int)len < str_buf_sz) failed The patch should fix this problem.
Hi, I seem to run into this issue as well, but the patch does not seem to fix it. Apr 20 09:42:22 cg-2023 bgpd[40721]: bgpd/bgp_lcommunity.c:239: set_lcommunity_string(): assertion ((unsigned int)len < str_buf_sz) failed I have a pcap of the session, but so far havent found the trigger.
Created attachment 241619 [details] Alternative silly patch Kurt's patch disables bypasses parsing large communities. My patch doubles the buffer size and kicks the can down the road.
(In reply to mike from comment #1) I suspect it triggers when you learn a route with more large communities that, when parsed, do not fit in a buffer of a little over 1024 bytes. Glancing at the code, it looks like BUFSIZ is a very arbitrary buffer size. I simply doubled it to make the problem go away.
(In reply to Philip Paeps from comment #3) The danger is that you need to update ALL your bgp speakers, otherwise you will propagate that internally via ibgp and.... fun times with everything crashing :( Is there a way to drop inbound communities from ebgp peers ? I dont make routing decisions so would just like to drop them at this point
No idea ... sorry. I don't have that particular problem. I only give my ibgp speakers a default route and my own routes. I don't propagate the full routing table. You should be able to use a route-map and bgp set large-community without "additive". That should drop the large communities you learned. You might want to define a large community that means "dropped all other large communities to work around an frr bug". (untested)
They have an issue and suggested fix in their repo now https://github.com/FRRouting/frr/pull/13341
A note about the bug. Unfortunately, there does not seem to be a way to defend against this bug being exploited without patching. Using a route-map to avoid the large community works after the problematic code path is hit. e.g given the peer neighbor 172.16.20.1 remote-as 65679 neighbor 172.16.20.1 description Upstream neighbor 172.16.20.1 update-source 172.16.20.2 neighbor 172.16.20.1 next-hop-self neighbor 172.16.20.1 soft-reconfiguration inbound neighbor 172.16.20.1 prefix-list UPSTREAM-IN in neighbor 172.16.20.1 prefix-list UPSTREAM-OUT out neighbor 172.16.20.1 route-map DELETE-COM-IN in route-map DELETE-COM-IN permit 10 set large-community none exit By the time the routemap is hit, the damage is done. However, if you just patch your ebgp speakers and pass along all routes to ibgp speakers, make sure you either remove the big large communities, or patch first your ibgp speakers as they too will crash from this bug.
Created attachment 241636 [details] official patch from upstream Using this now in some systems.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=dc2c49ff321068aacbb763d951f301b90094958b commit dc2c49ff321068aacbb763d951f301b90094958b Author: Olivier Cochard <olivier@FreeBSD.org> AuthorDate: 2023-04-21 21:25:25 +0000 Commit: Olivier Cochard <olivier@FreeBSD.org> CommitDate: 2023-04-21 21:34:01 +0000 net/frr8: Fix bgpd crash with large communities and enable backtrace PR: 270910 Reported by: pi net/frr8/Makefile | 14 ++++---- net/frr8/files/patch-bgpd_bgp__lcommunity.c (new) | 42 +++++++++++++++++++++++ 2 files changed, 50 insertions(+), 6 deletions(-)