I got 6 nodes where we mistyped the peer ASN in FRRConfiguration. When I attempted to update the ASN, the webhook validation kicked in and didnt allow me to do this update. Its seemed like it was trying to generate new configuration and add the remote-as to the already defined peers. Deleting the FRRConfiguration and re-creating it from scratch of course did the trick.

For reference this is the FRRConfiguration was used:
{{---
apiVersion: frrk8s.metallb.io/v1beta1
kind: FRRConfiguration
metadata:
labels:
use-for-advertisements: 'true'
name: bgp-peers-dmz-cudn-fabric-1
namespace: openshift-frr-k8s
spec:
bgp:
bfdProfiles:

• detectMultiplier: 4
  name: bfd-default
  receiveInterval: 200
  transmitInterval: 200
  routers:
• asn: 65422
  neighbors:
• address: x.x.x.x
  asn: 65420
  bfdProfile: bfd-default
  disableMP: true
  holdTime: 9s
  keepaliveTime: 3s
  ebgpMultiHop: true
  toReceive:
  allowed:
  mode: all
• address: y.y.y.y
  asn: 65420
  bfdProfile: bfd-default
  disableMP: true
  holdTime: 9s
  keepaliveTime: 3s
  ebgpMultiHop: true
  toReceive:
  allowed:
  mode: all
  vrf: dmz
  nodeSelector:
  matchExpressions:
• key: kubernetes.io/hostname
  operator: In
  values:
• worker-1.domain.com
• worker-2.domain.com
• worker-3.domain.com
• worker-4.domain.com
• worker-5.domain.com
• worker-6.domain.com}}
  Desired behavior:

The generated config for FRR, should be able to handle this case and re-generate the updated configuration for the router using the new remote-as without requiring the user to delete and start from scratch.