Bug #12167


BGP TCP setkey not set if neighbor is in peer group

Added by Chris Linstruth almost 3 years ago. Updated over 2 years ago.

Viktor Gurov
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:


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.

Actions #2

Updated by Jim Pingle almost 3 years ago

  • Status changed from New to Pull Request Review
Actions #3

Updated by Renato Botelho almost 3 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Viktor Gurov

PR has been merged. Thanks!

Actions #4

Updated by Christian McDonald over 2 years ago

Target package version: v1.1.0_14

Actions #5

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 


Also available in: Atom PDF