quagga: Unable to get BGP listen-range peer group active in config

[arichtman]

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [x] The title contains the plugin to which this issue belongs

Describe the bug

Quagga/BGP configuration with a single peer group set to listen on a range does not activate the peer group in the config file. This means dynamic BGP peering does not work.

This is not a regression as the front-end to listen ranges FRR feature is new ( #4722 )

To Reproduce

1. Routing > BGP
2. Set a BGP AS number and network
3. Create a peer group with remote AS mode "internal", remote AS == main AS, and listen ranges set
4. Apply changes
5. Inspect frr.conf file, see no activation of peer group

Expected behavior

frr.conf contains peer group activation configuration line. FRR BGP now listens on that range and peers with the other nodes running BGP daemon on the nominated interface/subnet/AS number.

Screenshots

Not working:

Manually edit frr.conf to add neighbor LAN activate:

Working:

Relevant log files

N/A

Additional context

I'm able to get FRR to work on OPNsense by overwriting the file with a functional config. I think the important change is neighbor LAN activate. Here's the config

Environment

# uname -a
FreeBSD opnsense.internal 14.2-RELEASE-p3 FreeBSD 14.2-RELEASE-p3 stable/25.1-n269825-cbaf3aa6b26b SMP amd64

<bgp version="1.1.0">
  <enabled>1</enabled>
  <asnumber>65551</asnumber>
  <distance/>
  <routerid/>
  <graceful>1</graceful>
  <networkimportcheck>1</networkimportcheck>
  <logneighborchanges>1</logneighborchanges>
  <networks>2403:580a:e4b1::/64</networks>
  <neighbors/>
  <aspaths/>
  <prefixlists/>
  <communitylists/>
  <routemaps/>
  <peergroups>
    <peergroup uuid="932c3b12-fb7a-4bb6-8119-2d48a9098cf2">
      <enabled>1</enabled>
      <name>LAN</name>
      <remote_as_mode>internal</remote_as_mode>
      <remoteas>65551</remoteas>
      <listenranges>2403:580a:e4b1::/64</listenranges>
      <updatesource>lan</updatesource>
      <nexthopself>0</nexthopself>
      <defaultoriginate>1</defaultoriginate>
      <linkedPrefixlistIn/>
      <linkedPrefixlistOut/>
      <linkedRoutemapIn/>
      <linkedRoutemapOut/>
    </peergroup>
  </peergroups>
  <redistributions>
    <redistribution uuid="e47af1b6-7131-48c9-b2cd-56f5920b726b">
      <enabled>1</enabled>
      <description/>
      <redistribute>connected</redistribute>
      <linkedRoutemap/>
    </redistribution>
  </redistributions>
</bgp>

frr defaults traditional
log syslog warnings
ip forwarding
ipv6 forwarding


router bgp 65551
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 no bgp ebgp-requires-policy
 bgp network import-check
 bgp graceful-restart
 neighbor LAN peer-group
 neighbor LAN remote-as internal
 neighbor LAN update-source igc1
 neighbor LAN activate
 neighbor LAN default-originate
 bgp listen range 2403:580a:e4b1::/64 peer-group LAN

 address-family ipv4 unicast
 redistribute connected
 exit-address-family
 address-family ipv6 unicast
 redistribute connected
  network 2403:580a:e4b1::/64
 exit-address-family

ipv6 route fe80::aab8:e0ff:fe00:91ed/128  igc1

Related

#4713 #4015

[Monviech]

I think the issue is illustrated here:

https://docs.frrouting.org/en/stable-10.3/bgp.html#clicmd-neighbor-A.B.C.D-activate

It says:

By default, only the IPv4 unicast address family is announced to all neighbors

Which means, the current neighbor LAN activate inside the general bgp properties should not do anything, it's already activated implicitely per default.

Though becauseno bgp default ipv4-unicast is set, each neighbor LAN activate must happen in their respective:

address-family ipv4 unicast address-family ipv6 unicast

And in the current generated example, it seems to be indeed in the wrong spot (global bgp settings), and missing in the IPv6 address family.

[Monviech]

Can you test this patch

opnsense-patch -c plugins 29970ccc7adcee6ccff8220310aeaf8d11fb7613

Afterwards press "Apply", and do a full service restart with the stop/start buttons to flush the config from vtysh with a complete new one.

[arichtman]

Confirmed it applies successfully and FRR configuration works after BGP service stop and start via Web GUI.

Fantastic - thank you!!

# cat frr.conf
frr defaults traditional
log syslog warnings
ip forwarding
ipv6 forwarding


router bgp 65551
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 no bgp ebgp-requires-policy
 bgp network import-check
 bgp graceful-restart
 neighbor LAN peer-group
 neighbor LAN remote-as internal
 neighbor LAN update-source igc1
 neighbor LAN activate
 neighbor LAN default-originate
 bgp listen range 2403:580a:e4b1::/64 peer-group LAN

 address-family ipv4 unicast
 redistribute connected
 exit-address-family
 address-family ipv6 unicast
 redistribute connected
  network 2403:580a:e4b1::/64
  neighbor LAN activate
 exit-address-family

ipv6 route fe80::aab8:e0ff:fe00:91ed/128  igc1

Cilium BGP peers