- frog - lists.frrouting.org

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

20 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 05 Nov '23

05 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

RPKI, this is getting a bit frustrating
by Chris Knipe 28 Sep '23

28 Sep '23

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.

1 0

Expired certificate
by Erwan David 13 Sep '23

13 Sep '23

Hello, Going to https://deb.frrouting.org I get an expired certificate, in detail it is deb-ch.frrouting.org, certificate serial is 03:36:38:3B:C0:B1:87:4A:9F:42:F2:DB:C3:37:CE:87:2D:CC I cannot find the actual address used, but the DNS cache in my firefox gives addresses 2a07:e480:0:1::38 2a07:e480:2::1106 194.147.136.38 194.147.139.20 Hope this message will reach the right people -- Erwan David

2 1

Best Frr Version And Linux platform For Frr 40Gbps
by Ramin Malekgahsemi 11 Sep '23

11 Sep '23

Hi Dears I want Forward 40G To up 100G bps BW On Frr Please Suggest To me stable linux version and frr Version Fo this Capacity Thanks

1 0

Re: [FROG] [dev] FRR 9.0.1 and 8.5.3 Releases
by mike tancsa 08 Sep '23

08 Sep '23

Hi, I am guessing there is still no easy way to upgrade individual instances from 8.5.1 to 8.5.3 when ibgp is involved ? ie its a "do all at once" step ? https://lists.frrouting.org/pipermail/frog/2023-June/001283.html ---Mike On 9/8/2023 11:52 AM, Jafar Al-Gharaibeh via dev wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

2 1