#17542 introduces a regression breaking peer-group configs upon sequential config load

[ichdasich]

Description

#17542 introduced a patch to #17541, where adding a peer-group to a peer would remove the remote-as value from that peer. However, if the reverse case happens (first add a peer to the peer-group, then try to add a remote-as), #17542 prevents adding the remote-as setting.

This is likely due to the initialization of the remote-as value introduced by #17542.

The issue is that this occurs whenever the configuration is loaded sequentially with the patch applied, because the peer-group definition usually is set before the remote-as; I would guess that this includes upon daemon restart.

Version

All versions that include #17542.

How to reproduce

• configure a peer-group without setting a remote-as
• configure a new neighbor
• add the neighbor to the peer group
• try to add a remote-as to the neighbor; See: % Peer-group member cannot override remote-as of peer-group.

Expected behavior

Being able to apply a remote-as to neighbors in a peer-group where the peer-group does not set a remote-as.

Actual behavior

% Peer-group member cannot override remote-as of peer-group.

Additional context

This was encountered while debugging #17533.

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[ichdasich]

Confirmed in bgpd.c, btw:

frr/bgpd/bgpd.c

Line 2161 in a43b11f

if (peer->group->conf->as