<div dir="ltr">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.<div><br></div><div>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.  </div><div><br></div><div>donald</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 3, 2022 at 7:18 AM Willy Manga <<a href="mailto:mangawilly@gmail.com">mangawilly@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Can someone please tell me what "BGP type 32 length 672 is too large" <br>
stand for?<br>
<br>
I got this message from some bgp peers running ZTE ZXR10 . From my side <br>
I have FRRouting 8.2.2 on debian 11.<br>
<br>
Here is what I got in the logs<br>
<br>
<br>
Jul 03 10:51:40 bdr3 bgpd[3555975]: [HTHRX-GQYGJ][EC 33554454] <br>
bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:43fd:xx::<br>
<br>
<br>
Jul 03 10:51:44 bdr3 bgpd[3555975]: [PGS8W-47EHJ][EC 33554485] <br>
2001:43fd:xx::: BGP type 32 length 672 is too large, attribute total <br>
length is 243.  attr_endp is 0x7f746c0ee66c.  endp is 0x7f746c0ee49a<br>
<br>
Any idea on what is happening?<br>
<br>
<br>
-- <br>
Willy Manga<br>
@ongolaboy<br>
<a href="https://ongola.blogspot.com/" rel="noreferrer" target="_blank">https://ongola.blogspot.com/</a><br>
_______________________________________________<br>
frog mailing list<br>
<a href="mailto:frog@lists.frrouting.org" target="_blank">frog@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/frog" rel="noreferrer" target="_blank">https://lists.frrouting.org/listinfo/frog</a><br>
</blockquote></div>