Bug #12167
open
BGP TCP setkey not set if neighbor is in peer group
0%
Description
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 2 years ago
Updated by Jim Pingle over 2 years ago
- Status changed from New to Pull Request Review
Updated by Renato Botelho over 2 years ago
- Status changed from Pull Request Review to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
Updated by Christian McDonald over 2 years ago
Target package version: v1.1.0_14
Updated by Chris Linstruth over 2 years 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.
Package Dependencies:
frr7-pythontools-7.5.1_1 frr7-7.5.1_1