While decoding the NLRI from it's peer, FRR( well all bgp implementations should do this too ) has detected that the length reported by the packet is larger than the received packet size from the base OS. At this point in time FRR has nothing it can do other than issue a warning to the peer that something has gone wrong.

type 32 == Large community processing btw. Can you get a tcp capture of this behavior and send it to me? I'd like to ensure that FRR is not experiencing a very weird bug.

donald

On Sun, Jul 3, 2022 at 7:18 AM Willy Manga <mangawilly@gmail.com> wrote:

Hello,

Can someone please tell me what "BGP type 32 length 672 is too large"
stand for?

I got this message from some bgp peers running ZTE ZXR10 . From my side
I have FRRouting 8.2.2 on debian 11.

Here is what I got in the logs

Jul 03 10:51:40 bdr3 bgpd[3555975]: [HTHRX-GQYGJ][EC 33554454]
bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:43fd:xx::

Jul 03 10:51:44 bdr3 bgpd[3555975]: [PGS8W-47EHJ][EC 33554485]
2001:43fd:xx::: BGP type 32 length 672 is too large, attribute total
length is 243. attr_endp is 0x7f746c0ee66c. endp is 0x7f746c0ee49a

Any idea on what is happening?

--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/
_______________________________________________
frog mailing list
frog@lists.frrouting.org
https://lists.frrouting.org/listinfo/frog