BGP TCP setkey not set if neighbor is in peer group
When a neighbor is a member of a peer group, with FRR and setkey Bidirectional enabled with a password, the setkey is not placed in the kernel regardless of MD5 enabled on the peer group, the neighbor, or both.
Removing the neighbor from the peer group and placing the MD5 on the neighbor works around this.
Updated by Viktor Gurov over 1 year ago
Updated by Chris Linstruth over 1 year ago
Testing this I notice the following:
There is no way to inherit the MD5 settings from the peer group. It must be set in the individual neighbors themselves. If the key is set in the peer group and the neighbor is marked to none, the setkey is not set. If this is expected behavior, that is fine as the peer group can be used for other settings and the key can now be set.
It does look like the neighbor has to be individually set to setkey, but it will inherit the MD5 password from the group or it can be overridden there. That, to me, seems like the way to do it. Else there would need to be a specific "inherit" setting instead of "none".
Seems good to me.
Tested this on 2.5.2:
frr net 1.1.0_15 FRR routing daemon for BGP, OSPF, and OSPF6 Conflicts with Quagga OSPF and OpenBGPD. These packages cannot be installed at the same time.