Closed jbemmel closed 2 weeks ago
Yet again, we're bikeshedding a nerd knob because a rarely-used platform does not correctly support a protocol that has been standardized in 2010 and prefers a protocol from 2004 that is officially obsolete (which is rare in IETF world).
It makes no sense to change anything. The OS10 challenge is documented as a caveat, and if someone wants to support an obsolete protocol on another platform, they're most welcome to use a custom config.
Personally, I would not change the OS10 default either (and solve that with a custom config), but let's just say that OS10 is not one of my priorities ;)
Yet again, we're bikeshedding a nerd knob because a rarely-used platform does not correctly support a protocol that has been standardized in 2010 and prefers a protocol from 2004 that is officially obsolete (which is rare in IETF world).
It makes no sense to change anything. The OS10 challenge is documented as a caveat, and if someone wants to support an obsolete protocol on another platform, they're most welcome to use a custom config.
Personally, I would not change the OS10 default either (and solve that with a custom config), but let's just say that OS10 is not one of my priorities ;)
Yes I'm being very meticulous, I'm using Netlab to automate a configuration update in a production network that is heavily based on OS10 nodes (for the foreseeable future). They run VRRPv2 which is the platform default, Netlab was generating VRRPv3
Can we at least make the VRRP v3 default explicit and define gateway.vrrp.version
?
Plugin proposal: https://github.com/ipspace/netlab/pull/1498
Implemented as a plugin
See https://github.com/ipspace/netlab/blob/dev/netsim/ansible/templates/gateway/frr.vrrp-config.j2
The template currently does not specify the version, so it defaults to v3 - see https://docs.frrouting.org/en/latest/vrrp.html#interface-configuration