1.4 to 1.5 upgrade problem - Multi-protocol IPv4 BGP sets weird IPv6 nexthop

bbs2web · March 13, 2024, 10:10am

Hi,

Upgraded a route reflector from 1.4 (202305300317), which used FRR 8.5.1, to 1.5 (202403020021), which uses FRR 9.1.0. The configuration was converted perfectly and things simply just worked, expect that IPv6 nexthops are altered when imported and subsequently reflected to route reflector clients.

Sessions are all iBGP, so I wouldn’t have expected the next hop to have been altered. Each participating router simply has an IPv6 address in a subnet common to the participating routers. I hope the following explains our setup:

A ----- RR ----- B

A and B are route reflector clients, with multiprotocol prefixes being exchanged over an IPv4 BGP session. RR is VyOS, where it has an IPv4 loopback IP assigned to ‘lo’ and it has it’s IPv6 IP in a bridge interface. This bridge is connected to other routers that also have their IPs in the same /64 subnet. A and B set the nexthop of IPv6 prefixes as their IPv6 address when sending these to RR.

This worked perfectly in VyOS 1.4 from May last year but VyOS 1.5 is changing the next hop address when reflecting these prefixes to other members.

Herewith an example of an IPv6 default gateway having been accepted by RR:

3710, (Received from a RR-client)
  2c0f:dead:beef:0:51:49:31:48 from 51.49.31.48 (51.49.31.48)
    Origin IGP, metric 0, localpref 140, valid, internal, best (Local Pref), rpki validation-state: not found
    Community: 55514:1013
    AddPath ID: RX 0, TX-All 38 TX-Best-Per-AS 0 TX-Best-Selected 0
    Advertised to: 51.49.31.48 51.49.31.49 51.49.31.52 51.49.31.50 51.49.31.51 51.49.31.55 51.49.32.45 51.49.32.46
    Last update: Tue Mar 12 11:09:25 2024

This however becomes a different next hop on other route reflector clients:

> /ipv6 route print detail where dst-address=::/0
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 0  Db  dst-address=::/0 gateway=::ffff:51.49.31.54 gateway-status=::ffff:51.49.31.54 unreachable distance=200 scope=40 target-scope=30 bgp-as-path="3710"
        bgp-local-pref=140 bgp-med=0 bgp-origin=igp bgp-communities=55514:1013 received-from=bwdur01-rr03

So VyOS installs the right IPv6 route and sets the correct next hop, as received from a route reflector client, but then changes the next hop to ::ffff:51.49.31.54. This is essentially ::ffff:< IPv4 address of peer that introduced prefix to RR >

Herewith redacted configs from the RR VyOS device:

set policy route-map rr_client-in rule 10 action 'permit'
set policy route-map rr_client-out rule 10 action 'permit'
set protocols bgp parameters cluster-id '51.49.31.50'
set protocols bgp parameters log-neighbor-changes
set protocols bgp parameters router-id '51.49.31.54'
set protocols bgp peer-group rr_client address-family ipv4-unicast route-map export 'rr_client-out'
set protocols bgp peer-group rr_client address-family ipv4-unicast route-map import 'rr_client-in'
set protocols bgp peer-group rr_client address-family ipv4-unicast route-reflector-client
set protocols bgp peer-group rr_client address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp peer-group rr_client address-family ipv6-unicast route-map export 'rr_client-out'
set protocols bgp peer-group rr_client address-family ipv6-unicast route-map import 'rr_client-in'
set protocols bgp peer-group rr_client address-family ipv6-unicast route-reflector-client
set protocols bgp peer-group rr_client address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp peer-group rr_client remote-as '55514'
set protocols bgp peer-group rr_client update-source 'lo'
set protocols bgp system-as '55514'

c-po · March 13, 2024, 5:34pm

So you transport IPv4 and IPv6 over the same session?

bbs2web · March 13, 2024, 7:21pm

Exactly, worked in VyOS 1.3 and 1.4 but the nexthop appears to get changed to an IPv4 address encoded as an IPv6 when sent to router regenerator clients, although VyOS installs the correct next hop for prefixes itself.

PS: We’re not wanting to do 6PE.

bbs2web · March 14, 2024, 9:18pm

I presume this to be a bug, in that VyOS 1.5 rolling installs the correct gateway for IPv6 prefixes installed via an IPv4 BGP session (multi-protocol BGP) but then sets the gateway as an IPv4 address encoded as IPv6 when reflecting the prefix to other route reflect clients.

Any suggestions or should I open a Phabricator bug?

c-po · March 21, 2024, 7:13am

Can you try using extended nexthop statement?

bbs2web · March 24, 2024, 10:19am

Unfortunately doesn’t help. I believe this to possibly relate to PE6 (MPLS labelled paths for IPv6 by encoding IPv4 gateways as IPv6) having been forced on, breaking simple yet effective multi-protocol BGP:

github.com/FRRouting/frr

bgpd: fix 6vpe nexthop (backport #15368)

FRRouting:stable/9.1 ← FRRouting:mergify/bp/stable/9.1/pr-15368

opened 09:35AM - 28 Feb 24 UTC

mergify[bot]

+735 -5

This is an automatic backport of pull request #15368 done by [Mergify](https://m…ergify.com). --- <details> <summary>Mergify commands and options</summary> <br /> More conditions and actions can be found in the [documentation](https://docs.mergify.com/). You can also trigger Mergify actions by commenting on this pull request: - `@Mergifyio refresh` will re-evaluate the rules - `@Mergifyio rebase` will rebase this PR on its base branch - `@Mergifyio update` will merge the base branch into this PR - `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch Additionally, on Mergify [dashboard](https://dashboard.mergify.com) you can: - look at your merge queues - generate the Mergify configuration with the config editor. Finally, you can contact us on https://mergify.com </details>

I’ll try log a bug report in the upstream FRR project, thank you for your time and suggestions!

bbs2web · March 24, 2024, 3:36pm

I logged the change in behaviour:

github.com/FRRouting/frr

Multi-protocol IPv4 BGP overrides IPv6 nexthop on reflection

opened 12:17PM - 24 Mar 24 UTC

bbs2web

triage

### Description We believe that the below patch, to force 6vPE prefixes to us…e an IPv4 gateway encoded as IPv6 (eg ::ffff:51.49.31.54), to break multi-protocol BGP sessions where there is no MPLS forwarding path, but instead another type of layer 2 tunnelling fabric. Merged last month: https://github.com/FRRouting/frr/pull/15453 We're kindly asking that a work around or option exist to disable this behaviour. FRR acting as a route reflector correctly learns the route, sets appropriate next-hop gateways for exchanged prefixes and can route packets towards the destination. Route reflector clients however receive prefixes where the next hop has been set as the route reflector's router ID, encoded as IPv6. Route reflector clients have access to the provider edge gateways and should, as the route reflector itself does, recursively resolve the prefix. Changing an attribute of a reflected prefix whilst processing as wanted locally is IMHO unexpected. ### Version ```text FRRouting 9.1 (uklon01-rr04) on Linux(6.6.19-amd64-vyos). Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--enable-scripting' '--enable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3' ``` ### How to reproduce FRR configuration file for RR1, which learns route for Google (in the example provided): Setting either `set ipv6 next-hop prefer-global` and/or `attribute-unchanged next-hop` in the import/export route maps and router settings makes zero difference: ``` route-map rr_client-in permit 10 match ipv6 address prefix-list all on-match goto 20 set ipv6 next-hop prefer-global route-map rr_client-in permit 20 route-map rr_client-out permit 10 match ipv6 address prefix-list all on-match goto 20 set ipv6 next-hop prefer-global route-map rr_client-out permit 20 router bgp 55514 bgp router-id 51.49.22.46 bgp log-neighbor-changes no bgp ebgp-requires-policy no bgp default ipv4-unicast bgp cluster-id 51.49.22.6 bgp bestpath as-path multipath-relax no bgp network import-check neighbor rr_client peer-group neighbor rr_client remote-as 55514 neighbor rr_client update-source lo neighbor 51.49.22.32 peer-group rr_client neighbor 51.49.22.33 peer-group rr_client ! address-family ipv4 unicast redistribute connected route-map connected-out redistribute static route-map static-out neighbor rr_client activate neighbor rr_client addpath-tx-all-paths neighbor rr_client route-reflector-client neighbor rr_client soft-reconfiguration inbound neighbor rr_client route-map rr_client-in in neighbor rr_client route-map rr_client-out out neighbor rr_client attribute-unchanged next-hop maximum-paths ibgp 2 exit-address-family ! address-family ipv6 unicast redistribute connected route-map connected-out redistribute static route-map static-out neighbor rr_client activate neighbor rr_client addpath-tx-all-paths neighbor rr_client route-reflector-client neighbor rr_client soft-reconfiguration inbound neighbor rr_client route-map rr_client-in in neighbor rr_client route-map rr_client-out out neighbor rr_client attribute-unchanged next-hop maximum-paths ibgp 2 exit-address-family exit ! ``` Network: ``` zanjnb01-rr04# show interface brief Interface Status VRF Addresses --------- ------ --- --------- br0 up default + 2001:db8:1:0:51:49:21:55/64 # IPv6 bridge eth0 up default eth0.11 up default 192.168.12.146/30 # Link to CR01 eth0.13 up default 192.168.12.154/30 # Link to CR02 eth0.14 up default 192.168.12.158/30 # Link to partner RR eth0.15 up default # IPv6 over MPLS for non-l2vpn capable routers, connected to br0 lo up default 51.49.21.55/32 pim6reg up default ``` ### Expected behavior Other route reflector clients should receive the iBGP route with the next-hop set as it shows on the FRR instance (the route reflector) that ingested the route. On the first route reflector, the route in ingested with the IPv6 next-hop set as it was received and everything works: ``` uklon01-rr04# show ipv6 route 2001:4860:4860::8888 Routing entry for 2001:4860::/32 Known via "bgp", distance 200, metric 0, best Last update 00:33:22 ago * 2001:db8:1:0:51:49:22:32, via br0, weight 1 * 2001:db8:1:0:51:49:22:33, via br0, weight 1 uklon01-rr04# show bgp ipv6 2001:4860:4860::8888 BGP routing table entry for 2001:4860::/32, version 7735842 Paths: (3 available, best #3, table default) 15169, (Received from a RR-client) 2001:db8:1:0:51:49:22:1 from 51.49.22.1 (51.49.22.1) Origin IGP, metric 0, localpref 130, valid, internal, rpki validation-state: valid Community: 55514:1003 AddPath ID: RX 0, TX-All 228655 TX-Best-Per-AS 0 TX-Best-Selected 0 Advertised to: 51.49.22.45 51.49.21.54 51.49.21.55 Last update: Sun Mar 24 09:57:01 2024 15169, (Received from a RR-client) 2001:db8:1:0:51:49:22:33 from 51.49.22.33 (51.49.22.33) Origin IGP, metric 0, localpref 200, valid, internal, multipath, rpki validation-state: valid Community: 55514:2000 AddPath ID: RX 0, TX-All 85810 TX-Best-Per-AS 0 TX-Best-Selected 0 Advertised to: 51.49.22.45 51.49.21.54 51.49.21.55 Last update: Sat Mar 23 19:31:34 2024 15169, (Received from a RR-client) 2001:db8:1:0:51:49:22:32 from 51.49.22.32 (51.49.22.32) Origin IGP, metric 0, localpref 200, valid, internal, multipath, best (Router ID), rpki validation-state: valid Community: 55514:2000 AddPath ID: RX 0, TX-All 298162 TX-Best-Per-AS 0 TX-Best-Selected 0 Advertised to: 51.49.31.48 51.49.31.49 51.49.31.52 51.49.31.50 51.49.31.51 51.49.31.55 51.49.32.45 51.49.32.46 Last update: Sun Mar 24 09:59:10 2024 uklon01-rr04# ping 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=120 time=1.50 ms ^C --- 2001:4860:4860::8888 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.502/1.502/1.502/0.000 ms ``` ### Actual behavior FRR is assuming that I want 6vPE and 'helpfully' advertises `::ffff:3331:162e` (IPv4 51.49.22.46 encoded as IPv6). This breaks other devices. I'm kindly asking that `attribute-unchanged next-hop` could be supported for corner cases where multi-protocol BGP is of high value but transport is not wanted via MPLS. Other router is is peering IPv4 and IPv6 over an IPv4 session still continues to receive routes with the route reflector's router ID set as the IPv6 encoded next hop: ``` [admin@uklon01-pe03] > ipv6 route print detail where dst-address=2001:4860::/32 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 0 Db dst-address=2001:4860::/32 gateway=::ffff:51.49.22.45 gateway-status=::ffff:51.49.22.45 unreachable distance=200 scope=40 target-scope=30 bgp-as-path="15169" bgp-local-pref=200 bgp-med=0 bgp-origin=igp bgp-communities=55514:2000 received-from=uklon01-rr03 1 Db dst-address=2001:4860::/32 gateway=::ffff:51.49.22.46 gateway-status=::ffff:51.49.22.46 unreachable distance=200 scope=40 target-scope=30 bgp-as-path="15169" bgp-local-pref=200 bgp-med=0 bgp-origin=igp bgp-communities=55514:2000 received-from=uklon01-rr04 ``` ie: Routes are inactive, as it can't resolve the gateways of ::ffff:51.49.22.45 or ::ffff:51.49.22.46 (the route reflector IPs. I would expect the prefix to be received and processed like it is on the route reflector itself. IPv4 routes are reflected as expected: ``` [admin@uklon01-pe03] > /ip route print detail where dst-address=8.8.8.0/24 Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 ADb dst-address=8.8.8.0/24 pref-src=51.49.22.34 gateway=51.49.22.32 gateway-status=51.49.22.32 recursive via 192.168.28.13 syrex-vlan6 distance=200 scope=40 target-scope=30 bgp-as-path="15169" bgp-local-pref=200 bgp-med=0 bgp-origin=igp bgp-communities=55514:2000 bgp-ext-communities="000x4300:0x0 0x0 0x0 0x0 0x0 0x0" received-from=uklon01-rr03 1 Db dst-address=8.8.8.0/24 pref-src=51.49.22.34 gateway=51.49.22.32 gateway-status=51.49.22.32 recursive via 192.168.28.13 syrex-vlan6 distance=200 scope=40 target-scope=30 bgp-as-path="15169" bgp-local-pref=200 bgp-med=0 bgp-origin=igp bgp-communities=55514:2000 bgp-ext-communities="000x4300:0x0 0x0 0x0 0x0 0x0 0x0" received-from=uklon01-rr04 ``` ### Additional context Has been working perfectly on FRR 8.5.1, due for an upgrade and sad to see this broken in FRR 9.1. ### Checklist - [X] I have searched the open issues for this bug. - [X] I have not included sensitive information in this report.

ton31337 has already provided a patch in response:

Is there a guide somewhere on how to rebuild VyOS incorporating an upstream (FRR) patch?

fernando · March 25, 2024, 6:37pm

I would like to suggest , create a bug report within :

https://vyos.dev/

you can add a patch , but you need re-build the version that are using , some example below :

github.com

vyos/vyos-build/blob/current/packages/frr/build-frr.sh

#!/bin/sh
CWD=$(pwd)
set -e

FRR_SRC=frr

if [ ! -d ${FRR_SRC} ]; then
    echo "FRR source directory does not exists, please 'git clone'"
    exit 1
fi

# VyOS requires some small FRR Patches - apply them here
# It's easier to habe them here and make use of the upstream
# repository instead of maintaining a full Fork.
# Saving time/resources is essential :-)
cd ${FRR_SRC}

PATCH_DIR=${CWD}/patches
if [ -d $PATCH_DIR ]; then
    echo "I: Apply FRRouting patches not in main repository:"

This file has been truncated. show original

github.com

vyos/vyos-build/blob/equuleus/packages/frr/patches/0001-frr-reload-rpki-context-exiting-uses-exit-and-not-en.patch

From 258409cfa05aaa378e4f120dc67fb226465fa829 Mon Sep 17 00:00:00 2001
From: Runar Borge <[email protected]>
Date: Sat, 23 Jan 2021 00:15:41 +0100
Subject: [PATCH] frr-reload: rpki context exiting uses exit and not end

Issue:
The rpki subcontext uses exit instead of end to exit.
This makes issues with frr-reload in the way that frr-reload never exits
rpki context until it reaches the next end statement. this also happens when
parsing the configuration from vtysh.

Signed-off-by: Runar Borge <[email protected]>
---
 tools/frr-reload.py | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/frr-reload.py b/tools/frr-reload.py
index 412cde091..33c4ef5e5 100755
--- a/tools/frr-reload.py
+++ b/tools/frr-reload.py

This file has been truncated. show original

bbs2web · April 3, 2024, 10:08pm

Many thanks for your assistance, I have been able to rebuild the 1.5 nightly ISO but not sure if the .patch file I created (vyos-build/packages/frr/patches/revert_0325116.patch) is being processed. Purposefully putting something in the file to invalidate the match unfortunately doesn’t yield and error and the build again completes without problems.

I’ve created the following Phabiractor task, for VyOS developers to please consider reverting the change in behaviour in FRR 9.1 introduced in February: ⚓ T6202 Multi-Protocol BGP is broken by 6PE patch in upstream FRR 9.1

Herewith what I did, which appears to possibly silently ignore failures:

Debian 12 (Bookworm) minimal install
Install minimum required development tools:
apt-get -y install devscripts git live-build make pbuilder python3-distutils python3-git python3-jinja2 python3-pystache python3-tomli qemu-utils sudo;
Clone VyOS 1.5:
git clone -b current --single-branch https://github.com/vyos/vyos-build;
Created patch file:

cat > /root/vyos-build/packages/frr/patches/revert_0325116.patch <<EOF
diff -uNr frr/bgpd/bgp_updgrp_packet.c frr2/bgpd/bgp_updgrp_packet.c
--- frr/bgpd/bgp_updgrp_packet.c        2024-04-04 00:18:33.346905387 +0200
+++ frr2/bgpd/bgp_updgrp_packet.c       2024-04-04 00:20:04.487461666 +0200
@@ -523,16 +523,11 @@
                        gnh_modified = 1;
                }

-               if (peer->nexthop.v4.s_addr != INADDR_ANY &&
-                   (IN6_IS_ADDR_UNSPECIFIED(mod_v6nhg) ||
-                    (peer->connection->su.sa.sa_family == AF_INET &&
-                     paf->afi == AFI_IP6))) {
-                       /* set a IPv4 mapped IPv6 address if no global IPv6
-                        * address is found or if announcing IPv6 prefix
-                        * over an IPv4 BGP session.
-                        */
-                       ipv4_to_ipv4_mapped_ipv6(mod_v6nhg, peer->nexthop.v4);
-                       gnh_modified = 1;
+               if (IN6_IS_ADDR_UNSPECIFIED(mod_v6nhg)) {
+                       if (peer->nexthop.v4.s_addr != INADDR_ANY) {
+                               ipv4_to_ipv4_mapped_ipv6(mod_v6nhg,
+                                                        peer->nexthop.v4);
+                       }
                }

                if (IS_MAPPED_IPV6(&peer->nexthop.v6_global)) {

Retrieved FRR source:

cd /root/vyos-build/packages/frr;
git clone -b current --single-branch https://github.com/FRRouting/frr;
./build-frr.sh
I: Apply FRRouting patches not in main repository:
Patch format detection failed.

Is there possibly an idiot’s guide somewhere where I can learn how to rebuild the FRR package and the VyOS ISO with a custom patch for FRR? I presume that I’m missing an option or step somewhere to actually compile FRR when assembling VyOS 1.5 using the build script.

bbs2web · April 5, 2024, 9:47pm

Did I mention that I have no development experience? Seriously though, many thanks for your assistance! I was able to recompile FRR with a custom patch but how to I get VyOS repackaged to include the custom FRR deb files?

Deployed a minimal Debian 12 host, then added minimum packages and figured out how to git clone the FRR source code. Looks like I need a newer version of libyang2-dev though.

  apt-get -y install devscripts git live-build make pbuilder python3-distutils python3-git python3-jinja2 python3-pystache python3-tomli qemu-utils sudo;
  git clone -b current --single-branch https://github.com/vyos/vyos-build;
  cd /root/vyos-build;
  make clean;
    apt-get -y install bison flex libc-ares-dev libelf-dev:native libpcre2-dev libreadline-dev libyang2-dev pkg-config python3-pytest:native python3-sphinx:native liblua5.3-dev;
    cd /root/vyos-build/packages/frr;
    git clone -b stable/9.1 --single-branch https://github.com/FRRouting/frr/;
    mkdir /root/vyos-build/packages/frr/patches;
    pico /root/vyos-build/packages/frr/patches/revert_0325116.patch;
      # See below
    export [email protected];
    ./build-frr.sh;
  cd /root/vyos-build;
  ./build-vyos-image iso --architecture amd64 --build-by "$EMAIL";

Patch file:

From 258409cfa05aaa378e4f120dc67fb226465fa829 Fri Apr 5 00:00:00 2024
From: David Herselman <[email protected]>
Date: Fri, 5 Apr 2024 22:46:41 +0200
Subject: [PATCH] revert 0325116

Issue:
Revert FRR patch 0325116

Signed-off-by: David Herselman <[email protected]>
---
 bgpd/bgp_updgrp_packet.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff -uNr a/bgpd/bgp_updgrp_packet.c b/bgpd/bgp_updgrp_packet.c
--- a/bgpd/bgp_updgrp_packet.c  2024-04-04 00:49:02.669157448 +0200
+++ b/bgpd/bgp_updgrp_packet.c  2024-04-04 00:49:44.197402749 +0200
@@ -523,16 +523,11 @@
 			gnh_modified = 1;
 		}

-		if (peer->nexthop.v4.s_addr != INADDR_ANY &&
-		    (IN6_IS_ADDR_UNSPECIFIED(mod_v6nhg) ||
-		     (peer->connection->su.sa.sa_family == AF_INET &&
-		      paf->afi == AFI_IP6))) {
-			/* set a IPv4 mapped IPv6 address if no global IPv6
-			 * address is found or if announcing IPv6 prefix
-			 * over an IPv4 BGP session.
-			 */
-			ipv4_to_ipv4_mapped_ipv6(mod_v6nhg, peer->nexthop.v4);
-			gnh_modified = 1;
+		if (IN6_IS_ADDR_UNSPECIFIED(mod_v6nhg)) {
+			if (peer->nexthop.v4.s_addr != INADDR_ANY) {
+				ipv4_to_ipv4_mapped_ipv6(mod_v6nhg,
+							peer->nexthop.v4);
+			}
 		}

 		if (IS_MAPPED_IPV6(&peer->nexthop.v6_global)) {

The patch is applied as expected, but I can’t build without libyang2-dev >= 2.1.80

[root@debian-linux frr]# ./build-frr.sh
I: Apply FRRouting patches not in main repository:
Applying: revert 0325116
I: Ensure Debian build dependencies are met
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
chrpath is already the newest version (0.16-2+b1).
gawk is already the newest version (1:5.2.1-2).
install-info is already the newest version (6.8-6+b1).
libcap-dev is already the newest version (1:2.66-4).
libjson-c-dev is already the newest version (0.16-2).
librtr-dev is already the newest version (0.8.0-1+b1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'libpam0g-dev' instead of 'libpam-dev'
libpam0g-dev is already the newest version (1.5.2-6+deb12u1).
libprotobuf-c-dev is already the newest version (1.4.1-1+b1).
libpython3-dev is already the newest version (3.11.2-1+b1).
libsnmp-dev is already the newest version (5.9.3+dfsg-2).
protobuf-c-compiler is already the newest version (1.4.1-1+b1).
python3-dev is already the newest version (3.11.2-1+b1).
texinfo is already the newest version (6.8-6+b1).
lua5.3 is already the newest version (5.3.6-2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I: Build Debian FRR Package
dch warning: Previous package version was Debian native whilst new version is not
dpkg-buildpackage: info: source package frr
dpkg-buildpackage: info: source version 9.1-117-gd292ccb5f
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by root <[email protected]>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-checkbuilddeps: error: Unmet build dependencies: libyang2-dev (>= 2.1.80)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)

Edit: Found and installed the newer libyang2 packages:

curl -O https://deb.frrouting.org/frr/pool/frr-9.1/liby/libyang2/libyang2_2.1.128-1~deb12u1_amd64.deb;
curl -O https://deb.frrouting.org/frr/pool/frr-9.1/liby/libyang2/libyang2-dev_2.1.128-1~deb12u1_amd64.deb;
dpkg -i libyang2*.deb;

bbs2web · April 7, 2024, 9:13am

Right, so I simply copy the compiled frr .deb packages to the root of the packages folder and the VyOS build script then uses those instead.

Herewith consolidated notes for anyone else needing to rebuild VyOS. The below notes apply against a newly deployed minimal Debian 12 (bookworm) instance:

apt-get -y install devscripts git live-build make pbuilder python3-distutils python3-git python3-jinja2 python3-pystache python3-tomli qemu-utils sudo;
git clone -b current --single-branch https://github.com/vyos/vyos-build;
cd /root/vyos-build;
curl -O https://deb.frrouting.org/frr/pool/frr-9.1/liby/libyang2/libyang2_2.1.128-1~deb12u1_amd64.deb;
curl -O https://deb.frrouting.org/frr/pool/frr-9.1/liby/libyang2/libyang2-dev_2.1.128-1~deb12u1_amd64.deb;
dpkg -i libyang2*.deb;
make clean;
  # Custom compiling FRR:
  apt-get -y install bison flex libc-ares-dev libelf-dev:native libpcre2-dev libreadline-dev libyang2-dev pkg-config python3-pytest:native python3-sphinx:native liblua5.3-dev;
  cd packages/frr;
  git clone -b stable/9.1 --single-branch https://github.com/FRRouting/frr/;
  mkdir patches;
  pico patches/revert_0325116.patch;
    # See above
  export [email protected];
  ./build-frr.sh;
  for f in frr_*.deb frr-pythontools_*.deb frr-rpki-rtrlib_*.deb frr-snmp_*.deb; do cp $f ..; done;
  cd ../..;
./build-vyos-image iso --architecture amd64 --build-by "$EMAIL";

fernando · April 8, 2024, 2:58pm

@bbs2web have seen that it was revert on FRR , so , next version should have this regression . generally , we use containers flavor for bluid/patch in VyOS, to avoid installing all the dependency.

system · May 8, 2024, 2:58pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.