BGP (FRR Config)

[jonwilliams84]

Having come from a fairly feature rich Fortigate FG-201E, I was quite surprised how lacking these UDM Pro's are with more "advanced" features!

I currently run MetalLB for LoadBalancing services hosted on my Kubernetes Clusters; on my Fortigate it was relatively simple with BGP to advertise routes to the "virtual IP" of the LoadBalancer type services inside my k8s clusters.

With the UDM I have been forced to use Layer-2 method, with has some rather undesirable effects...namely slow failover and weird stats (or should I say weirder!) stats on the cluster members in the unifi console. (Due to them constantly having more than one IP on their interface)

I would like to know if it would be possible to run a https://hub.docker.com/r/frrouting/frr container to act as a BGP Peer for my clusters and advertise routes to the UDM network wide? If so, has anyone managed to already complete this and willing to help me out?

[ddominet]

Having an advanced use case like yourself I really tried like yourself to make it work. To run frr, other apps. At the end having realized that trying such a hack solutions to make anything work on UDM pro is extremely tedious and not really worth the hassle. It's extremely irritating because the main advertised advantage of this router is it's ease of use. Currently to do something advanced (but widespread) it's more difficult than on any other mainstream platform. I've changed my router to pfsense, so I can't help you directly, but i can remember that there was something wrong with running default image from the hub. You'll probably need to build your own docker image.

Good luck!

[jonwilliams84]

Having an advanced use case like yourself I really tried like yourself to make it work. To run frr, other apps. At the end having realized that trying such a hack solutions to make anything work on UDM pro is extremely tedious and not really worth the hassle. It's extremely irritating because the main advertised advantage of this router is it's ease of use. Currently to do something advanced (but widespread) it's more difficult than on any other mainstream platform. I've changed my router to pfsense, so I can't help you directly, but i can remember that there was something wrong with running default image from the hub. You'll probably need to build your own docker image.

Good luck!

Frustrating is one word for it. I think it's my own fault for being so spoiled with what is effectively a £10000 FG-201e as my router, and getting used to enterprise grade functionality. If the licence hadn't expired on the Fortigate, I would probably rip the UDM out and send it back....but the licence is £1000's per year!

As an alternative option, I was thinking of maybe using another Fortigate FG-60e that I have as the main internet gateway and still running the UDM as a SPoG for the rest of my network. I could then set this up as a BGP peer for my cluster and then just have a static route to that subnet from the UDM...But this means I have wasted a tonne on 10G cards for all my nodes and would only be able to have a 1G Uplink to FG-60e.

To get around this and to use something a little more modern than the FG, I was considering a MikroTik CRS305-1G-4S+IN as this can run SwitchOS and RouterOS, so I could have this as a simple BGP router in my network. Just not sure how powerful these are and if they can route up to 10G as well as they can switch 10G.

Something like this:

WAN (500/50) --> 1G port on MikroTik (untagged) Port 1 MikroTik (10G + Tagged X) --> 10G WAN Port on UDM Port 2 - 4 MikroTik (10G + Tagged Y) --> 3 of my cluster nodes (workers) or to 3 further CRS305 which could then provide 10G to all 6 nodes.

I could then BGP-peer MetalLB with the MikroTik(s) and have a static route to that subnet on the UDM via the MikroTiks.

At this point - I have just re-read what I have typed & I think this is getting too complicated and expensive!

[ddominet]

Having an advanced use case like yourself I really tried like yourself to make it work. To run frr, other apps. At the end having realized that trying such a hack solutions to make anything work on UDM pro is extremely tedious and not really worth the hassle. It's extremely irritating because the main advertised advantage of this router is it's ease of use. Currently to do something advanced (but widespread) it's more difficult than on any other mainstream platform. I've changed my router to pfsense, so I can't help you directly, but i can remember that there was something wrong with running default image from the hub. You'll probably need to build your own docker image.

Good luck!

Frustrating is one word for it. I think it's my own fault for being so spoiled with what is effectively a £10000 FG-201e as my router, and getting used to enterprise grade functionality. If the licence hadn't expired on the Fortigate, I would probably rip the UDM out and send it back....but the licence is £1000's per year!

As an alternative option, I was thinking of maybe using another Fortigate FG-60e that I have as the main internet gateway and still running the UDM as a SPoG for the rest of my network. I could then set this up as a BGP peer for my cluster and then just have a static route to that subnet from the UDM...But this means I have wasted a tonne on 10G cards for all my nodes and would only be able to have a 1G Uplink to FG-60e.

To get around this and to use something a little more modern than the FG, I was considering a MikroTik CRS305-1G-4S+IN as this can run SwitchOS and RouterOS, so I could have this as a simple BGP router in my network. Just not sure how powerful these are and if they can route up to 10G as well as they can switch 10G.

Something like this:

WAN (500/50) --> 1G port on MikroTik (untagged) Port 1 MikroTik (10G + Tagged X) --> 10G WAN Port on UDM Port 2 - 4 MikroTik (10G + Tagged Y) --> 3 of my cluster nodes (workers) or to 3 further CRS305 which could then provide 10G to all 6 nodes.

I could then BGP-peer MetalLB with the MikroTik(s) and have a static route to that subnet on the UDM via the MikroTiks.

At this point - I have just re-read what I have typed & I think this is getting too complicated and expensive!

Mikrotik is a great solution, especially now with ROS 7.1 reworking BGP, OSPF, adding wireguard, UDP OpenVPN and more. But when it comes to CCR switches their routing capabilities are very limited because there is only 1Gb line to the CPU. If routing is your main concern I would also advise on maybe trying VyOS and building your own 1U router, or choosing some already ready solutions. https://blog.kroy.io/2019/08/23/battle-of-the-virtual-routers/

[jonwilliams84]

This why I was thinking of trying to get an FRR container running on the UDM (or maybe on an other device (if bandwidth isn't an issue I could use a RPi 4 maybe?))...

I really only need it to provide a routing table to the UDM, for which I could create a static route for the MetalLB subnets on the UDM via the FRR box.

Reckon this would work as I think?

[mabunixda]

FRR on the UDM Pro works just fine https://github.com/mabunixda/ansible-udmp/blob/main/files/10-onboot-frr.sh I use this because I am running a nomad cluster with calico network and bgp routing into a separate network of services ( like metallb on k8s )

you need to adapt the bgpd.conf with valid settings - e.g.

! -*- bgp -*-

hostname $UDMP_HOSTNAME
password zebra

router bgp 7675
bgp router-id $IP_OF_UDMP
network $NETWORK_CIDR
neighbor $METALLB_NODE_1 remote-as 7675
neighbor $METALLB_NODE_x remote-as 7675
log file stdout

[jonwilliams84]

FRR on the UDM Pro works just fine https://github.com/mabunixda/ansible-udmp/blob/main/files/10-onboot-frr.sh I use this because I am running a nomad cluster with calico network and bgp routing into a separate network of services ( like metallb on k8s )

you need to adapt the bgpd.conf with valid settings - e.g.

! -*- bgp -*-

hostname $UDMP_HOSTNAME
password zebra

router bgp 7675
bgp router-id $IP_OF_UDMP
network $NETWORK_CIDR
neighbor $METALLB_NODE_1 remote-as 7675
neighbor $METALLB_NODE_x remote-as 7675
log file stdout

Hi, Thanks for the response...I have it partially working with this config:

! -*- bgp -*-
hostname UDM-Pro
password zebra
frr defaults traditional
log syslog informational
service integrated-vtysh-config
!
!
router bgp 64534
 bgp router-id 10.32.100.1
 network 10.0.8.0/24
 neighbor V4 peer-group
 neighbor V4 remote-as 64535
 neighbor V4 password zebra
 neighbor 10.32.100.15 peer-group V4
 neighbor 10.32.100.16 peer-group V4
 neighbor 10.32.100.17 peer-group V4
 neighbor 10.32.100.18 peer-group V4
 neighbor 10.32.100.19 peer-group V4
 neighbor 10.32.100.20 peer-group V4
 neighbor 10.32.100.21 peer-group V4
 neighbor 10.32.100.22 peer-group V4
 !
 address-family ipv4 unicast
  redistribute connected
  neighbor V4 soft-reconfiguration inbound
 exit-address-family
 !
line vty
!

Which shows the routes are being advertised by my cluster:

UDM-Pro# show ip bgp neighbor 10.32.100.22 received-routes
BGP table version is 6, local router ID is 10.32.100.1, vrf id 0
Default local pref 100, local AS 64534
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.8.1/32      10.32.100.22                           0 64535 ?
*> 10.0.8.2/32      10.32.100.22                           0 64535 ?

Total number of prefixes 2

However, the routing table on the UDM is not being updated:

UDM-Pro# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

C * 10.0.5.0/24 is directly connected, br5.mac, 00:00:51
C>* 10.0.5.0/24 is directly connected, br5, 00:00:51
K>* 10.0.5.3/32 [0/0] is directly connected, br5.mac, 00:00:51
K>* 10.8.8.0/24 [0/1] via 10.32.100.40, br0, 00:00:51
C>* 10.32.99.0/28 is directly connected, br999, 00:00:51
C>* 10.32.100.0/25 is directly connected, br0, 00:00:51
C>* 10.32.100.128/25 is directly connected, br2, 00:00:51
C>* 10.32.101.0/24 is directly connected, br107, 00:00:51
C>* 172.20.20.0/29 is directly connected, eth8, 00:00:51
K>* 192.168.1.0/24 [0/1] via 172.20.20.1, eth8, 00:00:51
K>* 192.168.10.0/24 [0/2] via 10.32.100.40, br0, 00:00:51
K>* 192.168.20.0/24 [0/2] via 172.20.20.1, eth8, 00:00:51

Any ideas what I am missing?

[jonwilliams84]

Okay...getting a bit further...added a policy:

! -*- bgp -*-
hostname UDM-Pro
password zebra
frr defaults traditional
log file stdout
service integrated-vtysh-config
!
!
router bgp 64534
 bgp router-id 10.32.100.1
 network 10.0.8.0/24
 neighbor V4 peer-group
 neighbor V4 remote-as 64535
 neighbor V4 password zebra
 neighbor 10.32.100.15 peer-group V4
 neighbor 10.32.100.16 peer-group V4
 neighbor 10.32.100.17 peer-group V4
 neighbor 10.32.100.18 peer-group V4
 neighbor 10.32.100.19 peer-group V4
 neighbor 10.32.100.20 peer-group V4
 neighbor 10.32.100.21 peer-group V4
 neighbor 10.32.100.22 peer-group V4
 !
 address-family ipv4 unicast
  redistribute connected
  neighbor V4 soft-reconfiguration inbound
  neighbor V4 route-map ALLOW-ALL in
 exit-address-family
 !
route-map ALLOW-ALL permit 100
!
line vty
!

But...now the route is showing as rejected:

UDM-Pro# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

C * 10.0.5.0/24 is directly connected, br5.mac, 00:01:06
C>* 10.0.5.0/24 is directly connected, br5, 00:01:06
K>* 10.0.5.3/32 [0/0] is directly connected, br5.mac, 00:01:06
B>r 10.0.8.1/32 [20/0] via 10.32.100.21, br0, weight 1, 00:01:01
  r                    via 10.32.100.22, br0, weight 1, 00:01:01
B>r 10.0.8.2/32 [20/0] via 10.32.100.21, br0, weight 1, 00:01:01
  r                    via 10.32.100.22, br0, weight 1, 00:01:01

I feel I am so close!

[mabunixda]

I actual had to restart some services to get all routes published ( on nomad of course )

[jonwilliams84]

I actual had to restart some services to get all routes published ( on nomad of course )

I have tried, no joy.

Would you mind posting your bgpd.conf please? I must be missing something simple.

[mabunixda]

I had a running k8s cluster with metallb when I was using a USG - this one had a possibility to enable bgp out of the box. In the meantime I switched to nomad for my local clustering setup, but so i had to setup calico with a bgp configuration.

But i ended up with this very basic bgpd.conf

! -*- bgp -*-
hostname coroscant
password zebra

router bgp 7675
bgp router-id 172.16.0.1
network 172.16.0.1/16
neighbor 172.16.0.252 remote-as 7675
neighbor 172.16.0.253 remote-as 7675

log stdout

Did you enable bgpd on frr's daemons configuration file? On default it's set to not start

$ sed -i 's/bgpd=.*/bgpd=yes/' daemons
$ grep bgp daemons 
bgpd=yes
bgpd_options="   -A 127.0.0.1"

[jonwilliams84]

Yep, enabled the daemon...

The route are being seen on the UDM, but the hosts routing table isn't updated with the advertised routes.

UDM-Pro# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

C * 10.0.5.0/24 is directly connected, br5.mac, 00:03:32
C>* 10.0.5.0/24 is directly connected, br5, 00:03:32
K>* 10.0.5.3/32 [0/0] is directly connected, br5.mac, 00:03:32
B>r 10.0.8.1/32 [200/0] via 10.32.100.21, br0, weight 1, 00:02:11
  r                     via 10.32.100.22, br0, weight 1, 00:02:11
B>r 10.0.8.2/32 [200/0] via 10.32.100.21, br0, weight 1, 00:02:11
  r                     via 10.32.100.22, br0, weight 1, 00:02:11

However on the UDM console:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.5.0        0.0.0.0         255.255.255.0   U         0 0          0 br5
10.0.5.3        0.0.0.0         255.255.255.255 UH        0 0          0 br5.mac
10.8.8.0        10.32.100.40    255.255.255.0   UG        0 0          0 br0
10.32.99.0      0.0.0.0         255.255.255.240 U         0 0          0 br999
10.32.100.0     0.0.0.0         255.255.255.128 U         0 0          0 br0
10.32.100.128   0.0.0.0         255.255.255.128 U         0 0          0 br2
10.32.101.0     0.0.0.0         255.255.255.0   U         0 0          0 br107
172.20.20.0     0.0.0.0         255.255.255.248 U         0 0          0 eth8
192.168.1.0     172.20.20.1     255.255.255.0   UG        0 0          0 eth8
192.168.10.0    10.32.100.40    255.255.255.0   UG        0 0          0 br0

Did you have to do anything else on the UDM? Don't suppose you have your Nomad/MetalLB Config to hand?

[mabunixda]

the container is running privileged? I am using the upper referenced script to run my frr instance on udmp. I also tried frr:v8.1.0 now - still working...

I also created a LAN definition on the Unifi Controller for this network with DHCP Mode none and a VLAN ID. This VLAN ID is also configured on the nodes as vlan device - but this is something, metallb is aware of and should work out of the box ( when I remember correct ).

This is the CNI Network definition for my Calico network assigned to this vlan device on the machine(s)

{
    "cniVersion": "0.3.1",
    "name": "lan",
    "plugins": [
    {
        "type": "calico",
        "master": "enp3s0.20@enp3s0",
        "log_level": "INFO",
        "log_file_path": "/var/log/calico/cni/cni.log",

        "etcd_endpoints": "http://127.0.0.1:2379",
        "datastore_type": "etcdv3",

        "ipam": {
            "type": "calico-ipam",
            "assign_ipv4": "true",
            "assign_ipv6": "false",
            "ipv4_pools": [ "default-ipv4-ippool" ]
        }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

[jonwilliams84]

It works!

For some reason I have to exec into vtysh and run: clear ip bgp x.x.x.x for each of the neighbors before the routes are passes back to the UDM!

Here is my bgpd.conf:

! -*- bgp -*-
hostname UDM-Pro
password zebra
frr defaults traditional
log file stdout
service integrated-vtysh-config
!
!
router bgp 64534
 bgp ebgp-requires-policy
 bgp router-id 10.32.100.1
 neighbor V4 peer-group
 neighbor V4 remote-as 64534
 neighbor V4 password zebra
 neighbor 10.32.100.15 peer-group V4
 neighbor 10.32.100.16 peer-group V4
 neighbor 10.32.100.17 peer-group V4
 neighbor 10.32.100.18 peer-group V4
 neighbor 10.32.100.19 peer-group V4
 neighbor 10.32.100.20 peer-group V4
 neighbor 10.32.100.21 peer-group V4
 neighbor 10.32.100.22 peer-group V4
 !
 address-family ipv4 unicast
  network 10.32.100.1/32
  redistribute connected
  redistribute kernel
  neighbor V4 soft-reconfiguration inbound
  neighbor V4 route-map ALLOW-ALL in
  neighbor V4 route-map ALLOW-ALL out
 exit-address-family
 !
route-map ALLOW-ALL permit 10
!
line vty
!

Output from cli on UDM:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.5.0        0.0.0.0         255.255.255.0   U         0 0          0 br5
10.0.5.3        0.0.0.0         255.255.255.255 UH        0 0          0 br5.mac
10.0.8.1        10.32.100.21    255.255.255.255 UGH       0 0          0 br0
10.0.8.2        10.32.100.21    255.255.255.255 UGH       0 0          0 br0

I didn't need to create a network in the UDM GUI.

Here is my MetalLB Config Map:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    peers:
  config: |
    peers:
    - peer-address: 10.32.100.1
      peer-asn: 64534
      my-asn: 64535
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.0.8.0/24
      avoid-buggy-ips: true

From the UDM to a plain nginx pod / service:

# curl 10.0.8.2
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Thanks again for all your help!

[jonwilliams84]

Hmmm....Something isn't right...I have now added the rest of my nodes and now the routes aren't being propagated again on the rest of the network.

This is somewhat of a pickle as it was all working sweet on my Fortigate with minimal config!

[mabunixda]

yeah quite annoying that the UDM and Pro are not able what a small device already is able to do - even within the same company ( e.g. USG had this feature ... )

[jonwilliams84]

Right, after multiple reconfigurations, I have worked out if I have ExternalTrafflcPolicy: Local set on the k8s service I wish to advertise the route it for, it gets distributed to the UDM / Kernel and everything works, without of cause proper eBGP LoadBalancing:

B>* 10.0.8.1/32 [20/0] via 10.32.100.22, br0, weight 1, 00:07:01
B>* 10.0.8.2/32 [20/0] via 10.32.100.20, br0, weight 1, 00:07:01
B>* 10.0.8.3/32 [20/0] via 10.32.100.22, br0, weight 1, 00:07:01
B>* 10.0.8.4/32 [20/0] via 10.32.100.22, br0, weight 1, 00:07:00

However, If I set the policy to Cluster, i.e. in order to properly LoadBalance, then I see the mult-path routes appear in the FRR show ip route table but they are marked as rejected and do not get advertised to the UDM / kernel.

B>r 10.0.8.0/24 [20/0] via 10.32.100.17, br0, weight 1, 00:00:01
  r                    via 10.32.100.20, br0, weight 1, 00:04:01
  r                    via 10.32.100.21, br0, weight 1, 00:04:01
  r                    via 10.32.100.22, br0, weight 1, 00:04:01
B>r 10.0.8.5/32 [20/0] via 10.32.100.21, br0, weight 1, 00:04:00
  r                    via 10.32.100.22, br0, weight 1, 00:03:59

This must be either bgpd.conf misconfiguration, i.e. I have missed something or there's a bug in FRR; but as I have tried multiple versions of the FRR image, then I am leaning toward the former.

Leaving this here for the evening with a hope that someone cleverer than me can show me the error of my ways.

Here's my current config:

! -*- bgp -*-
hostname UDM-Pro
password zebra
frr defaults traditional
log stdout
!
!
router bgp 64588
 bgp ebgp-requires-policy
 bgp router-id 10.32.100.1
 neighbor V4 peer-group
 neighbor V4 remote-as 64500
 neighbor V4 activate
 neighbor V4 soft-reconfiguration inbound
 neighbor V4 password zebra
 neighbor 10.32.100.15 peer-group V4
 neighbor 10.32.100.16 peer-group V4
 neighbor 10.32.100.17 peer-group V4
 neighbor 10.32.100.18 peer-group V4
 neighbor 10.32.100.19 peer-group V4
 neighbor 10.32.100.20 peer-group V4
 neighbor 10.32.100.21 peer-group V4
 neighbor 10.32.100.22 peer-group V4
 !
 address-family ipv4 unicast
  redistribute connected
  neighbor V4 activate
  neighbor V4 route-map ALLOW-ALL in
  neighbor V4 route-map ALLOW-ALL out
  neighbor V4 next-hop-self
 exit-address-family
 !
route-map ALLOW-ALL permit 10
!
line vty
!

[jonwilliams84]

Finally got to the bottom of this!

The default unifi kernel DOES NOT support multi-path routing...hence all the multi-path routes being rejected!

So, I followed this https://github.com/fabianishere/udm-kernel-tools and installed the edge-2 kernel. And bingo, multi-path routing worked immediately!

B>* 10.0.8.0/24 [20/0] via 10.32.100.15, br0, weight 1, 00:00:23
  *                    via 10.32.100.16, br0, weight 1, 00:00:23
  *                    via 10.32.100.17, br0, weight 1, 00:00:23
  *                    via 10.32.100.18, br0, weight 1, 00:00:23
  *                    via 10.32.100.19, br0, weight 1, 00:00:23
  *                    via 10.32.100.20, br0, weight 1, 00:00:23
  *                    via 10.32.100.21, br0, weight 1, 00:00:23
  *                    via 10.32.100.22, br0, weight 1, 00:00:23
B>* 10.0.8.1/32 [20/0] via 10.32.100.22, br0, weight 1, 00:14:55
B>* 10.0.8.2/32 [20/0] via 10.32.100.16, br0, weight 1, 00:14:59
B>* 10.0.8.3/32 [20/0] via 10.32.100.15, br0, weight 1, 00:14:59
B>* 10.0.8.4/32 [20/0] via 10.32.100.21, br0, weight 1, 00:14:55
  *                    via 10.32.100.22, br0, weight 1, 00:14:55
B>* 10.0.8.5/32 [20/0] via 10.32.100.15, br0, weight 1, 00:00:23
  *                    via 10.32.100.16, br0, weight 1, 00:00:23
  *                    via 10.32.100.17, br0, weight 1, 00:00:23
  *                    via 10.32.100.18, br0, weight 1, 00:00:23
  *                    via 10.32.100.19, br0, weight 1, 00:00:23
  *                    via 10.32.100.20, br0, weight 1, 00:00:23
  *                    via 10.32.100.21, br0, weight 1, 00:00:23
  *                    via 10.32.100.22, br0, weight 1, 00:00:23
B>* 10.0.8.6/32 [20/0] via 10.32.100.17, br0, weight 1, 00:14:59

Happy Days!!!

[mabunixda]

Thanks @jonwilliams84 - i added the udm kernel tools also in my ansible udmp role and now also in my setup it seems that restarts are faster and routes are available earlier than before because of using a custom kernel 🥇

[mazzy89]

being used to run bird also in other context i'm running bird w/o issues on my udmprose. i made upstream the container here https://github.com/mazzy89/bird if anyone needs it

[kashalls]

I used bird inside the unifi-os container on my Unifi Dream Machine Pro. Using the on_boot.d script, I added https://github.com/Kashalls/udmp-utils/tree/master/birdc (pardon the repo) the following config...

[avolon42x]

Hi! --One-- TWO! years later and now on Unifi OS 3.x the situation hasn't changed much.. @jonwilliams84 how did you upgrade - or have you? Would love to know how you managed to get your metallb running now. Thx!

[audiato]

Unifi OS 3.x the situation hasn't changed much..

Just ran into the multi-path issue myself. Wish I knew how to assist @fabianishere with the 3.x compatible kernels. Way over my head though. For now I suppose I'll just run basic failover instead of all-active ECMP (while maybe shopping for a new router lol)