[j-nsp] Unknown Attribute 28 in BGP

[Saku Ytti]

Either will help, configure either or both and you're good.

Actual fixed release will behave the same as if drop-path-attribute 28
had been configured. That is read T, read L, seek past V, without
parsing.

On Sun, 11 Jun 2023 at 19:36, Einar Bjarni Halldórsson <einar at isnic.is> wrote:
>
> On 6/11/23 15:24, Saku Ytti wrote:
> > set protocols bgp drop-path-attributes 28 works if your release is too
> > old for set protocols bgp bgp-error-tolerance, and is preferable in
> > some ways, as it will protect your downstream as well.
> >
>
> 18.2R3-S3.11 supports protocols bgp bgp-error-tolerance, but reading
> through the docs, I see:
>
> > The bgp-error-tolerance statement overrides this behavior so that the following BGP error handling is in effect:
> >
> >     For fatal errors, Junos OS sends a notification message titled Error Code Update Message and resets the BGP session. An error in the MP_{UN}REACH attribute is considered to be fatal. The presence of multiple MP_{UN}REACH attributes in one BGP update is also considered to be a fatal error. Junos OS resets the BGP session if it cannot parse the NLRI field or the BGP update correctly. Failure to parse the BGP update packet can happen when the attribute length does not match the length of the attribute value.
>
> I read this section so that even if I configure bgp-error-tolerance, it
> won't make a difference since junos considers this a fatal error and
> resets the BGP session.
>
> .einar



-- 
  ++ytti