- frog - lists.frrouting.org

FRR PBR routing by DSCP
by RISTE-SMITH, Robert (External) [UKC] 06 Dec '23

06 Dec '23

I see there is a new version of FRR is just available that should provide PBR routing by matching DSCP (FRR 9.1). I use Debian version 11 at the moment and plan to upgrade from FRR 7.5 to FRR to 9.1 Will the DSCP match rule work in this platform (some mention about Linux dataplane layer in the FRR documentation)? If not (as I am guessing at the moment) is there some way to configure Debian OS to enable the feature or perhaps a different Linux OS that does support it? I am not a Linux user so would need simple instructions to get this working. Thanks. This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified. -o- Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

1 0

Adding local routes via FRR
by Scoopta 05 Dec '23

05 Dec '23

Is there a way to use FRR staticd to add local routes? Specifically I'm looking for an equivalent to the following iproute2 command: ip route add local 2001:db8::/64 dev lo FRR has ipv6 route 2001:d8b::/64 lo table 255 But that command only adds a route to the local table, it does not create a local route which can be used for whole subnet loopback. Thanks

1 0

FRR 9.0.1 and 8.5.3 Releases
by Jafar Al-Gharaibeh 28 Nov '23

28 Nov '23

Dear FRR Community, We are pleased to announce FRR 9.0.1 and FRR 8.5.3 bug fix releases. For release notes please visit: https://frrouting.org/release/ https://github.com/FRRouting/frr/releases Security updates: https://frrouting.org/security Cheers, The FRR Development Team!

1 1

Simple BGP configuration to test
by Jorge Visentini 28 Nov '23

28 Nov '23

Hi all! I configured the BGP peer to test and the sessions are UP but it does not propagate the networks. I tried all the options that I know, but it does not work yet. I don't know if the error is my installation on Rocky Linux or just my BGP syntax. *FRRouting 9.0.1Kernel 5.14.0-362.8.1.el9_3.x86_64Rocky Linux 9.3* */etc/sysctl.conf:net.ipv4.ip_forward = 1net.ipv6.conf.all.forwarding = 1* R01# show run Building configuration... Current configuration: ! frr version 9.0.1 frr defaults traditional hostname R01 log syslog informational service integrated-vtysh-config ! interface eth2 ip address 10.10.20.1/30 exit ! interface eth3 ip address 10.10.30.1/30 exit ! router bgp 65100 bgp router-id 172.10.20.1 bgp log-neighbor-changes no bgp network import-check neighbor 10.10.20.2 remote-as 65200 neighbor 10.10.20.2 description ASN65200 neighbor 10.10.30.2 remote-as 65300 neighbor 10.10.30.2 description ASN65300 ! address-family ipv4 unicast network 172.10.20.0/30 network 192.168.100.0/24 redistribute connected neighbor 10.10.20.2 soft-reconfiguration inbound neighbor 10.10.20.2 prefix-list ASN65200-IN in neighbor 10.10.20.2 prefix-list ASN65200-OUT out exit-address-family exit ! access-list ANS65200-IN seq 5 permit 0.0.0.0/0 access-list ANS65200-OUT seq 5 permit 192.168.100.0/24 ! end R01# [root@ASN65200 ~]# cat /etc/frr/frr.conf frr version 9.0.1 frr defaults traditional hostname ASN65200 log syslog informational service integrated-vtysh-config ! interface eth2 ip address 10.10.20.2/30 exit ! interface eth3 ip address 10.20.40.2/30 exit ! interface lo exit ! interface eth0 exit ! router bgp 65200 bgp router-id 2.2.2.2 bgp log-neighbor-changes no bgp network import-check neighbor 10.10.20.1 remote-as 65100 neighbor 10.20.40.1 remote-as 65400 ! address-family ipv4 unicast network 2.2.2.2/32 redistribute connected neighbor 10.10.20.1 default-originate neighbor 10.10.20.1 soft-reconfiguration inbound neighbor 10.10.20.1 prefix-list ANS65100-IN in neighbor 10.10.20.1 prefix-list ANS65100-OUT out exit-address-family exit ! access-list ASN65100-IN seq 5 permit 0.0.0.0/0 access-list ASN65100-OUT seq 5 permit 2.2.2.2/32 ! [root@ASN65200 ~]# R01# show ip bgp summary IPv4 Unicast Summary (VRF default): BGP router identifier 172.10.20.1, local AS number 65100 vrf-id 0 BGP table version 4 RIB entries 7, using 1344 bytes of memory Peers 2, using 41 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 10.10.20.2 4 65200 28 25 4 0 0 00:19:25 (Policy) (Policy) ASN65200 10.10.30.2 4 65300 0 0 0 0 0 never Active 0 ASN65300 Total number of neighbors 2 R01# do show ip bgp neighbors 10.10.20.2 received BGP table version is 4, local router ID is 172.10.20.1, vrf id 0 Default local pref 100, local AS 65100 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 RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 10.10.20.2 0 0 65200 i Total number of prefixes 1 (1 filtered) R01# Any tips? -- Att, Jorge Visentini +55 55 98432-9868

3 3

Link state in vtysh doesn't reflect carrier state
by Alasdair Muckart 21 Nov '23

21 Nov '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, I'm seeing what feels like misleading reporting of interface state in the 'brief' version of 'show int' commands and wondering if it's intentional, a bug, or if I'm missing something. Platform is Ubuntu 22.04, FRR 9.0.1 installed from the frr apt repo, kernel 5.14.0. In the output of 'sh int brief' and 'sh int desc' 'Status' is the admin status not the link status, so it shows interfaces as being 'up' when they have no carrier. This is inconsistent with how linux iproute2 tools report, and to me, it makes the brief output of 'show int' misleading. If there's only one 'status' column it should be the line protocol state not the admin state because that's the most important one for knowing if the link is actually up or not. The ideal would be to include both the way Cisco does. In this example enp4s0 and enp11s0f0 are both NO-CARRIER but 'sh int br' shows them as 'up': - --- cut --- rtr# sh int br Interface Status VRF Addresses - --------- ------ --- --------- enp2s0 up default 202.XXX.XXX.19/25 + 2404:XXX:X:XX:XXXX:XXXX:XXXX:da1b/64 enp3s0 down default enp4s0 up default enp5s0 down default enp6s0f0 down default enp6s0f1 down default enp6s0f2 down default enp6s0f3 down default enp10s0f0 down default enp10s0f1 down default enp11s0f0 up default 192.168.144.3/24 192.168.144.32/32 192.168.144.33/32 192.168.144.34/32 192.168.144.35/32 192.168.144.36/32 192.168.144.37/32 192.168.144.38/32 192.168.144.39/32 192.168.144.40/32 192.168.144.41/32 192.168.144.42/32 192.168.144.43/32 192.168.144.44/32 192.168.144.45/32 192.168.144.46/32 192.168.144.47/32 enp11s0f1 down default lo up default 192.168.157.2/32 wg1 up default 192.168.159.1/31 wg3 up default 192.168.159.10/31 wg4 up default 192.168.159.12/31 - --- cut --- A non-brief 'show interface' shows that frr knows the line protocol is down: - --- cut --- rtr# show int enp4s0 Interface enp4s0 is up, line protocol is down Link ups: 0 last: (never) Link downs: 7 last: 2023/11/21 09:27:02.34 vrf: default Description: OS Description: lldpd: was connected to index 4 metric 0 mtu 1500 speed 4294967295 flags: <UP,BROADCAST,MULTICAST> Type: Ethernet HWaddr: 90:3c:b3:3f:da:1d Interface Type Other Interface Slave Type None protodown: off - --- cut --- iproute2 and systemd-networkd tools show the interfaces as having no carrier: - --- cut --- root@rtr:~# ip -br link lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> enp2s0 UP 90:3c:b3:3f:da:1b <BROADCAST,MULTICAST,UP,LOWER_UP> enp3s0 DOWN 90:3c:b3:3f:da:1c <BROADCAST,MULTICAST> enp4s0 DOWN 90:3c:b3:3f:da:1d <NO-CARRIER,BROADCAST,MULTICAST,UP> enp5s0 DOWN 90:3c:b3:3f:da:1e <BROADCAST,MULTICAST> enp6s0f0 DOWN 90:3c:b3:3f:da:1f <BROADCAST,MULTICAST> enp6s0f1 DOWN 90:3c:b3:3f:da:20 <BROADCAST,MULTICAST> enp6s0f2 DOWN 90:3c:b3:3f:da:21 <BROADCAST,MULTICAST> enp6s0f3 DOWN 90:3c:b3:3f:da:22 <BROADCAST,MULTICAST> enp10s0f0 DOWN 90:3c:b3:3f:da:23 <BROADCAST,MULTICAST> enp10s0f1 DOWN 90:3c:b3:3f:da:24 <BROADCAST,MULTICAST> enp11s0f0 DOWN 90:3c:b3:3f:da:25 <NO-CARRIER,BROADCAST,MULTICAST,UP> enp11s0f1 DOWN 90:3c:b3:3f:da:26 <BROADCAST,MULTICAST> wg1 UNKNOWN <POINTOPOINT,NOARP,UP,LOWER_UP> wg3 UNKNOWN <POINTOPOINT,NOARP,UP,LOWER_UP> wg4 UNKNOWN <POINTOPOINT,NOARP,UP,LOWER_UP> root@rtr:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback routable unmanaged 2 enp2s0 ether routable configured 3 enp3s0 ether off unmanaged 4 enp4s0 ether no-carrier configuring 5 enp5s0 ether off unmanaged 6 enp6s0f0 ether off unmanaged 7 enp6s0f1 ether off unmanaged 8 enp6s0f2 ether off unmanaged 9 enp6s0f3 ether off unmanaged 10 enp10s0f0 ether off unmanaged 11 enp10s0f1 ether off unmanaged 12 enp11s0f0 ether no-carrier unmanaged 13 enp11s0f1 ether off unmanaged 14 wg1 wireguard routable unmanaged 15 wg3 wireguard routable unmanaged 16 wg4 wireguard routable unmanaged - --- cut --- Thanks. - -- Alasdair Muckart (he/him) Network Infrastructure Architect Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Ltd - a Catalyst IT group company DDI: +64 4 897 7794 | Mobile: +64 22 638 5141 | Tel: +64 4 499 2267 | www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. -----BEGIN PGP SIGNATURE----- iQJUBAEBCgA+FiEEu4g3jwJ68cPCdgH9iBAgH4ERwwMFAmVbxiQgHGFsYXNkYWly bXVja2FydEBjYXRhbHlzdC5uZXQubnoACgkQiBAgH4ERwwP1sQ//azguDZLHt5ur rNjZYqoovQw1aKkxhYPIWjykqX7bvVpI4CkeaYMsUQEyBktPIBUjfTAmjQ7qTCn1 HLZsizWjI1ZxEfj0uIMb582mUd0hOr5NTDromwHnM53W3R6kHwXXzB3ton76p9nx D5xBfvjFlGvk70YxwRXHz1ObA+RjXXYZ2rMrHvUq54r0vcroMO1pHPbIh/Z7ovAs h4gZ+D5kwPTYfga+47a/DRMs/vmNuqX9RB5qRGoDJ62qMnjYssB5IHj4xTxoVvZ+ 8XRNpP1KNrXRPfPzTSQizDB5thqPqHplraVCuw7izUt25ACZLxmkHX4FgJVFyVnl 0Nq4fT9M8+RAUd0AlUFDvCFKH0UFV69wmVO2oXX3DecXaLttqiw6dYrDu1zNdmkM pJtvmkoYiJMhiloAH3vuc/K2cBkSOrE7dyiV0XV9nSRlQ23vkTRe3PEMc7TIMxq5 o3M67TnWbkrzDjfZH268retgHess7xRs9yqnrGtWGJ1mq093HgmjPqRfyuU4R3EP bcdFAHDscUXw7ZiLZ9D3KZQC7bADPz2Uhxs0BXliO9O7rm5f79Z5rkbNGG3AsFgm LtvkMF2Aj9PeYiMJo4F1YlI/SaUvi574Ky19g4ktY+Ni+agZXWH/iKb0Q4Y4UwWA FDN/g2a5xafBH2PtLrENwIXh0jeYqtw= =3qCF -----END PGP SIGNATURE-----

1 0

Re: [FROG] Status of Babel Protocol Support
by Quentin Young 06 Nov '23

06 Nov '23

It gets occasional QOL patches and bug fixes when someone contributes them, but it currently has no dedicated maintainer and doesn't track any upstream implementation. You can see the sparse development history here: https://github.com/FRRouting/frr/commits/master/babeld Quentin On 11/5/2023 4:04 PM, Alasdair Muckart via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Status of Babel Protocol Support
by Alasdair Muckart 06 Nov '23

06 Nov '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Greeting FRR folk, What's the status of Babel protocol support in FRR? The Babel page[1] says: "FRR (the successor to Quagga) includes an implementation of Babel based on the babeld implementation. This version is currently obsolete, and not recommended." I'm not sure what the version of babeld included with FRR is. Is it an FRR-specific fork, or does it track upstream babeld? Thanks. [1] https://www.irif.fr/~jch/software/babel/ - -- Alasdair Muckart (he/him) Network Infrastructure Architect Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Ltd - a Catalyst IT group company DDI: +64 4 897 7794 | Mobile: +64 22 638 5141 | Tel: +64 4 499 2267 | www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267. -----BEGIN PGP SIGNATURE----- iQJUBAEBCgA+FiEEu4g3jwJ68cPCdgH9iBAgH4ERwwMFAmVIBbsgHGFsYXNkYWly bXVja2FydEBjYXRhbHlzdC5uZXQubnoACgkQiBAgH4ERwwOC7w/+LKqM7SjJezZT byVYPZ3G9cv2jbecNMZU4lc6LYzEbvLsjR52F7ajWKt6NjRUkyz0yKKqvmvkdH05 weZ+t2PUUDd9E5gMqP0m/41JczgEUvXU0KKMww2qjrNL3Gm7/XEzLymnK90B9Wtq 8FDT/ptb1d4gQfKPP0lNQ7tRW5voozNnAbNiqweQo303DbhE+vh+AEH3x/ZBGlAe RBo+Kvd970pXfdWu2bO3f/gUPZGdCEGYZZdDylkqq1G8ROvV8LvzA4omFOUalXkq GinXQ+s+qd77D63k4TDy7VrZHhzoekIAxRWQyD7gllM329Q2fUWbnlbEt7TZzQEi RUTFToY5PXCxPL4R3dvCK+FbarCz2ZoHszTGey4XyULkotZN1jZHi6HokQCqHCn+ zK2Tbam40KFIhnbPejEDzN85XHJBOgBnSqHchEWn/DKTHJw34WCMEUTblup3sw8i bOZGgKir2u4v2VJm1jWozwwEiG/UH0/SZWMEj2BIjc+xTv8ste0SUw41i4KjrhiJ nnZbYQoXmROPMQ1lhBBPXGUWtlA5hTM8Ic4U1ifnramlohml5HJMDhJ8KW5uMJDe oWBIIQ4JN3gA5elpOAxMZ1UcdPsQeqFYZWp/d43gthtQ1ezlrbfUA8+2Lma+W9wa PGUeQalLK1y/AhO1u7nz4rlAWXaXqYw= =Daws -----END PGP SIGNATURE-----

1 0

Re: [FROG] RPKI, this is getting a bit frustrating
by Donald Sharp 30 Sep '23

30 Sep '23

Can I see the output of `show memory` for bgpd? I'm not aware of any memory leaks in rpki( but that does not mean that they don't exist ). I'd also like to see the output of the rpki section of a show run. donald On Thu, Sep 28, 2023 at 12:33 PM Chris Knipe via frog < frog(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Chris Knipe <savage(a)savage.za.org> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Thu, 28 Sep 2023 15:24:21 +0000 > Subject: RPKI, this is getting a bit frustrating > > Hi All, > > > > Been battling with this one now for a while, through a few different > versions, and I am pulling my hair out here…. Is there any memory leaks in > RPKI??? > > > > My RPKI config: > > rpki > > rpki cache 172.65.0.2 8282 preference 1 > > rpki cache 172.65.0.2 8283 preference 2 > > exit > > > > Nothing more, nothing less. RPKI is (not yet) used in any route-maps, > policies, etc. > > > > RPKI works absolutely fine. However, when I start bgpd, it has a resident > memory size of ~3.6G (fine, considering it’s loading multiple full tables > for IPv4 & ipv6). When RPKI isn’t configured, the router is stable, and > memory usage is consistent and constant at ~3.6GB. > > > > However, as soon as RPKI is enabled, bgpd grows about 600MB in resident > memory per day. Eventually, the system runs out of memory and bgpd is > restarted (which, is obviously bad). > > > > root@MY-LOC-RS01A:~# ps auxxw|grep bgpd > > root 802 0.0 0.0 8784 2844 ? S<s Sep26 1:02 > /usr/lib/frr/watchfrr -d -F traditional zebra mgmtd bgpd ospfd ospf6d > staticd > > frr 850 16.8 54.7 4656684 4429752 ? S<sl Sep26 547:23 > /usr/lib/frr/bgpd -d -F traditional -A 127.0.0.1 -M rpki -e 10 > > root 12813 0.0 0.0 6608 2312 pts/2 S+ 17:21 0:00 grep > --color=auto bgpd > > > > We’re already at 4.6GB up from 3.6GB when BGP has initially started (2d > uptime for the longest BGP peer – see below). > > > > > > FRR version, and IPv4 BGP Peers (with prefixes): > > ZA-CTN-RS01A# sh ver > > FRRouting 9.0.1 (MY-LOC-RS01A) on Linux(5.15.0-84-generic). > > 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' '--disable-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' > > > > > > IPv4 Unicast Summary (VRF default): > > BGP router identifier aaa.bbb.112.164, local AS number xxxxxx vrf-id 0 > > BGP table version 8318219 > > RIB entries 1693671, using 310 MiB of memory > > Peers 12, using 245 KiB of memory > > Dampening enabled. > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ > Up/Down State/PfxRcd PfxSnt Desc > > aaa.bbb.112.165 4 xxxxxx 723094 1164605 8318219 0 0 > 2d05h58m 4 1665344 MY-LOC-RS01B > > aaa.bbb.112.240 4 xxxxxx 265406 743205 8318219 0 0 > 2d05h58m 835450 922653 MY-LOC-TR01A > > aaa.bbb.112.241 4 xxxxxx 156145 763504 8318219 0 0 > 2d05h58m 603608 922653 MY-LOC-TR01B > > aaa.bbb.112.242 4 xxxxxx 26776 761874 8318219 0 0 > 2d05h58m 113141 922653 MY-LOC-PR01A > > aaa.bbb.112.243 4 xxxxxx 37609 761874 8318219 0 0 > 2d05h58m 113141 922653 MY-LOC-PR01B > > aaa.bbb.112.244 4 xxxxxx 3241 745167 8318219 0 0 > 2d05h58m 0 922653 MY-LOC-CR01A > > aaa.bbb.112.245 4 xxxxxx 3241 743205 8318219 0 0 > 2d05h58m 0 922653 MY-LOC-CR01B > > aaa.bbb.112.248 4 xxxxxx 384 436702 8318219 0 0 > 06:16:02 0 922653 MY-LOC-IKE01A > > aaa.bbb.112.249 4 xxxxxx 381 306758 8318219 0 0 > 06:18:32 0 922653 MY-LOC-IKE01B > > aaa.bbb.113.151 4 xxxxxx 0 0 0 0 0 > never Active 0 MY-LOC-RS01A > > aaa.bbb.113.152 4 xxxxxx 0 0 0 0 0 > never Active 0 MY-LOC-RS01B > > Total number of neighbors 11 > > > > Thanks, > > Chris. > > > > > > > > > > ---------- Forwarded message ---------- > From: Chris Knipe via frog <frog(a)lists.frrouting.org> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Thu, 28 Sep 2023 15:24:21 +0000 > Subject: [FROG] RPKI, this is getting a bit frustrating > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog >

2 3

lists.frrouting.org unreachable via IPv6
by Willy Manga 30 Sep '23

30 Sep '23

Hi, I can't reach the list https://lists.frrouting.org/pipermail/frog/ over IPv6 . No issue with IPv4 though. -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 0

Re: [FROG] RPKI, this is getting a bit frustrating
by Willy Manga 29 Sep '23

29 Sep '23

Hi Chris, On 28/09/2023 20:38, frog-request(a)lists.frrouting.org wrote: > [...] > My RPKI config: > rpki > rpki cache 172.65.0.2 8282 preference 1 > rpki cache 172.65.0.2 8283 preference 2 [...] Is there a reason to use the same validator on two different ports ? Why not use another one? (by the way I was not even aware of port 8283 on that validator) In my setup running FRRouting 9.0.1 (bdr2) on Linux(6.1.0-12-amd64), debian 12. I have 3 validators - 2 from Cloudflare (IPv4 and IPv6) - another one on IPv6 We perform route origin validation without any issue. Config b# sh rpki cache-connection Connected to group 2 rpki tcp cache rp.my.domain 323 pref 5 rpki tcp cache 2606:4700:60::2 8282 pref 2 (connected) rpki tcp cache 172.65.0.2 8282 pref 3 sh memory bgpd --> http://paste.debian.net/1293467/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/

2 1