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 <ei...@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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
