net/frr: multiprotocol BGP sessions are not supported

[g-a-c]

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 and I'm convinced that mine is new.

[x] The title contains the plugin to which this issue belongs

Describe the bug
Web UI does not allow multiprotocol sessions to be created (for example creating an IPv6 neighbor, which sends/recieves both IPv4 and IPv6 routes). If the neighbour address is considered IPv6, then IPv4 is not activated for that neighbour

To Reproduce
Steps to reproduce the behavior:

1. Install the os-frr plugin
2. Configure an IPv6 BGP neighbour with a peer which advertises both IPv4 and IPv6 routes
3. Wait until the connection establishes
4. Use vtysh -c sh bgp sum from the console
5. Observe that PfxRcd shows a positive integer showing how many IPv6 prefixes have been received
6. Use vtysh -c sh ip bgp sum from the console
7. Observe that no IPv4 routes have been received (PfxRcd column shows Active and not a number of received prefixes)
8. Use vtysh -c sh ip bgp from the console
9. See there are no received prefixes listed

Expected behavior
Multiprotocol neighbours can exchange both IPv4 and IPv6 routes even though the BGP session is only established using one protocol or the other

Screenshots
If applicable, add screenshots to help explain your problem.

Relevant log files
If applicable, information from log files supporting your claim.

Additional context
Add any other context about the problem here.

Environment
Software version used and hardware type if relevant.
e.g.:

OPNsense 21.7_3 amd64

[mimugmail]

Please forgive me my stupid question, but it this also possible with FRR?
Most if not all setups I've seen so far had v6 for v6 peering and v4 for v4 peering.

[g-a-c]

Yes, this is possible with FRR: http://docs.frrouting.org/en/stable-7.4/bgp.html#address-families

I believe there is at least one bug in the documentation for FRR, because multiple versions of the documentation refer to a neighbor bgp version command which does not actually exist. However multiprotocol BGP works OK on my OPNsense appliance with the changes in this pull request:

opnsense# sh bgp nei
BGP neighbor is fe80::ade0, remote AS 424242xxxx, local AS 424242yyyy, external link
  BGP version 4, remote router ID 172.20.xxx.xxx, local router ID 192.168.yyy.yyy
  BGP state = Established, up for 00:00:22
  Last read 00:00:07, Last write 00:00:21
  Hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      IPv4 Unicast: RX advertised IPv4 Unicast
      IPv6 Unicast: RX advertised IPv6 Unicast
[...snip...]
 For address family: IPv4 Unicast
  Update group 1, subgroup 1
  Packet Queue length 0
  Community attribute sent to this neighbor(all)
  593 accepted prefixes

 For address family: IPv6 Unicast
  Update group 2, subgroup 2
  Packet Queue length 0
  Community attribute sent to this neighbor(all)
  Inbound path policy configured
  Outbound path policy configured
  Incoming update prefix filter list is *dn42
  Outgoing update prefix filter list is *mynets
  579 accepted prefixes

This is my OPNsense box connected to a DN42 peer via a Wireguard tunnel, with a single BGP neighbor configured using an IPv6 link-local address, receiving both IPv4 and IPv6 prefixes

[g-a-c]

Closed with #2633