On 8/31/23, 4:28 AM, "juniper-nsp on behalf of Tobias Heister via juniper-nsp" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: > Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp: > > Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp: > >> A network I operate is going with: > >> > >> bgp-error-tolerance { > >> malformed-route-limit 0; > >> } > >> > >> The thoughts being that there is no real reason to retain the malformed > >> route and the default of 1000 is arbitrary. We haven't really seen a rash > >> of them, so adjusting the logging hasn't proven needed yet. > > > > It does seem arbitrary. retaining all seems like a better choice, > > operationally. allowing the operator diagnose why a route is missing; > > show route .... hidden.
That's the exact use case. Otherwise it's yet another completely arbitrary case of, "where did this route go and do we have zombies to worry about?" > Which in theory opens a new attack vector for the future. > > As the update is malformed it could do $something to the handling in > e.g. RPD or other daemons by processing them somehow wrong. By not > holding or further process any of them that could (maybe, hopefully?) be > minimized. You're encouraged to engage in whatever level of paranoia here that makes you happy operationally. The internal behavior is we throw out the portion of the path attribute that was decided to be bad. We spent a fair amount of time doing audit over various bits of code that interact with such stripped path attribute sets, like logging and tracing. That said, we've had bugs over the years in logging, trace, etc. that may be fixed in current versions but perhaps not past ones. I can't identify any bug of concern in running releases from memory. Thus, if you're more comfortable with just throwing the things out and not worrying about tracking down routes that are bad, go for it. It's a supported scenario. > Of course proper code and handling of malformed things would be even > better, but you know ... For the moment, this depends on configuration of the error-tolerance "feature". Making the behavior default is working its way through management for a targeted release. -- Jeff Juniper Business Use Only _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
