[FROG] BGP type 32 length 672 is too large

[Donald Sharp]

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 at 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 at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20220703/ff3d750b/attachment.htm>