- frog - lists.frrouting.org

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 12 Sep '23

12 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

FRR 8.4 Release
by Jafar Al-Gharaibeh 10 Aug '23

10 Aug '23

Dear FRR Community, We are pleased to announce FRR 8.4 release. Big thanks to all contributors. Packages are available at: Debian Packages - https://deb.frrouting.org RPM Packages - https://rpm.frrouting.org Snaps - https://snapcraft.io/frr Docker - frrouting/frr:v8.4.0 For release notes and a list of notable bug fixes, please visit: https://frrouting.org/release/8.4/ https://github.com/FRRouting/frr/releases/tag/frr-8.4 Cheers, The FRR Development Team!

1 3

routes periodically disappear from OS RT
by Volodymyr Litovka 10 Aug '23

10 Aug '23

Hi colleagues, suggest me, pls, where to look for the solution to the issue. Ubuntu 22.04, frr 8.5.2, router configuration is below Upon start and during some time everything is ok, but for some reasons after the time the following happens (reduced output) and can be fixed with 'clear ip ospf proc' : While FRR RT is ok: > /# sh ip route > [ ... ] > O 0.0.0.0/0 [110/10] via 100.64.98.3, blue, weight 1, 01:34:12 > via 100.64.99.3, orange, weight 1, 01:34:12 > B>* 0.0.0.0/0 [20/0] via 212.113.51.33, wan, weight 1, 1d00h30m > C>* 100.64.0.0/23 is directly connected, br-int, 1d00h30m > O>* 100.64.2.0/23 [110/20] via 100.64.98.2, blue, weight 1, 01:34:13 > * via 100.64.99.2, orange, weight 1, 01:34:13 > O>* 100.64.4.0/23 [110/20] via 100.64.98.3, blue, weight 1, 01:34:13 > * via 100.64.99.3, orange, weight 1, 01:34:13 > O 100.64.97.0/24 [110/10] is directly connected, wg0, weight 1, 01:34:24 > C>* 100.64.97.0/24 is directly connected, wg0, 1d00h30m > / > Linux RT lacks 100.64.2.0/23 and 100.64.4.0/23 - > /# ip route > default nhid 229 via 212.113.51.33 dev wan proto bgp metric 20 > 100.64.0.0/23 dev br-int proto kernel scope link src 100.64.0.1 > 100.64.97.0/24 dev wg0 proto kernel scope link src 100.64.97.1 > / > Issuing if 'clear ip ospf proc' solves the issue - these routes appear in Linux RT again, until next time. It's always ok with OSPF neighborship - hello packets are reaching all destinations (tcpdump confirms this :-) ) : > /vishnu.utc.mygaru# sh ip ospf neigh > Neighbor ID Pri State Up Time Dead Time > Address Interface RXmtL RqstL DBsmL > 100.64.2.1 1 Full/Backup 17m52s 3.823s 100.64.98.2 > blue:100.64.98.1 0 0 0 > 100.64.4.1 1 Full/DR 22m59s 3.403s 100.64.98.3 > blue:100.64.98.1 0 0 0 > 100.64.2.1 1 Full/Backup 17m52s 3.823s 100.64.99.2 > orange:100.64.99.1 0 0 0 > 100.64.4.1 1 Full/DR 22m59s 3.403s 100.64.99.3 > orange:100.64.99.1 0 0 0 > / > and following daemons are running with the following arguments - > /root@vishnu:~# ps ax |grep frr// > // 816287 ? S<s 0:18 /usr/lib/frr/watchfrr -d -F traditional > zebra bgpd ospfd staticd// > // 816303 ? S<sl 0:05 /usr/lib/frr/zebra -d -F traditional -A > 127.0.0.1 -r// > // 816308 ? S<sl 0:06 /usr/lib/frr/bgpd -d -F traditional -A > 127.0.0.1// > // 816315 ? S<s 1:19 /usr/lib/frr/ospfd -d -F traditional -A > 127.0.0.1// > // 816318 ? S<s 0:03 /usr/lib/frr/staticd -d -F traditional > -A 127.0.0.1/ > The only information I see in the log is the following: This is restart of the ospf process:/ / > /Aug 9 18:45:03 vishnu ospfd[816315]: [T08NC-EWX63][EC 134217741] > Link State Acknowledgment: Unknown Neighbor 100.64.4.1// > //Aug 9 18:45:03 vishnu ospfd[816315]: [T08NC-EWX63][EC 134217741] > Link State Acknowledgment: Unknown Neighbor 100.64.2.1// > //Aug 9 18:45:03 vishnu ospfd[816315]: [X7SPE-Y4BTR][EC 134217741] > Link State Update: Unknown Neighbor 100.64.2.1 on int: > orange:100.64.99.1// > //Aug 9 18:45:03 vishnu ospfd[816315]: [X7SPE-Y4BTR][EC 134217741] > Link State Update: Unknown Neighbor 100.64.2.1 on int: blue:100.64.98.1// > //Aug 9 18:45:03 vishnu ospfd[816315]: [X7SPE-Y4BTR][EC 134217741] > Link State Update: Unknown Neighbor 100.64.2.1 on int: blue:100.64.98.1// > //Aug 9 18:45:03 vishnu ospfd[816315]: [X7SPE-Y4BTR][EC 134217741] > Link State Update: Unknown Neighbor 100.64.2.1 on int: orange:100.64.99.1/ > and a bit later, but I don't know whether this relate to the issue and whether they appear at the same time: > /Aug 9 18:57:41 vishnu zebra[816303]: [RG2NH-FTSDH][EC 4043309102] > Kernel deleted a nexthop group with ID (300[253/254]) that we are > still using for a route, sending it back down// > //Aug 9 18:57:41 vishnu zebra[816303]: [RG2NH-FTSDH][EC 4043309102] > Kernel deleted a nexthop group with ID (280[234/235]) that we are > still using for a route, sending it back down// > //Aug 9 18:57:41 vishnu zebra[816303]: [RG2NH-FTSDH][EC 4043309102] > Kernel deleted a nexthop group with ID (276[]) that we are still using > for a route, sending it back down// > / > The question - any suggestions where to look for the solution to the problem? Which additional information I need to gather which can help solve it? May be I'm missing something in OS networking/kernel configuration? (I, actually, wasn't tweaking configuration except ip.forward=1). Will appreciate any recommendations on this. Thank you. ~~~~~~~~~~~ frr version 8.5.2 frr defaults traditional hostname vishnu log syslog informational no ipv6 forwarding service integrated-vtysh-config ! interface blue description === Blue infra === ip ospf dead-interval 4 ip ospf hello-interval 1 no ip ospf passive exit ! interface orange description === Orange infra === ip ospf dead-interval 4 ip ospf hello-interval 1 no ip ospf passive exit ! this is eBGP to ISP router bgp NNNN [ ... ] exit !this is eBGP to ISP router bgp 64512 view erspan [ ... ] exit ! router ospf ospf router-id 100.64.0.1 passive-interface default network 100.64.0.0/23 area 0 network 100.64.97.0/24 area 0 network 100.64.98.0/24 area 0 network 100.64.99.0/24 area 0 network 192.x.x.x/24 area 0 default-information originate exit ! few these prefix lists used for BGP ip prefix-list [ ... ] ! end -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 0

OVS-connected networks are missing in 'sh ip ospf database'
by Volodymyr Litovka 25 Jul '23

25 Jul '23

Hi, brief: 'sh ip ospf database' do not show networks, configured on OVS bridges, while neighbors see these networks. Details: Here is 8.5.2-0~ubuntu22.04.1 from FRR repo and Openvswitch from Ubuntu repo (2.17.7-0ubuntu0.22.04.1 ). Host configured with OVS bridges (br-ex, bt-int), 802.1q subinterfaces (orange) and plain links (blue) and marked in bold below are subject of the question: 3: blue: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 inet 100.64.98.3/24 brd 100.64.98.255 scope global blue valid_lft forever preferred_lft forever 8: orange@ens2f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UP group default qlen 1000 inet 100.64.99.3/24 brd 100.64.99.255 scope global orange valid_lft forever preferred_lft forever *10: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000** ** inet 192.145.111.65/27 brd 192.145.111.95 scope global br-ex** ** valid_lft forever preferred_lft forever** ****11: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1496 qdisc noqueue state UNKNOWN group default qlen 1000** ** inet 100.64.4.1/23 brd 100.64.5.255 scope global br-int** ** valid_lft forever preferred_lft forever* OSPF configuration on FRR is the following: interface blue ip ospf dead-interval 4 ip ospf hello-interval 1 no ip ospf passive exit ! interface orange ip ospf dead-interval 4 ip ospf hello-interval 1 no ip ospf passive exit ! router ospf ospf router-id 100.64.4.1 passive-interface default network 100.64.4.0/23 area 0 network 100.64.98.0/24 area 0 network 100.64.99.0/24 area 0 network 192.145.111.0/24 area 0 default-information originate exit but while br-ex and br-int networks are missing in output of 'sh ip ospf database' # sh ip ospf database OSPF Router with ID (100.64.4.1) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 100.64.0.1 100.64.0.1 136 0x800000f8 0xfe2e 5 100.64.2.1 100.64.2.1 135 0x800000ba 0xcd74 3 100.64.4.1 100.64.4.1 96 0x80000374 0xceaf 4 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 100.64.98.2 100.64.2.1 136 0x80000006 0xf9af 100.64.99.2 100.64.2.1 136 0x80000006 0xeeb9 AS External Link States Link ID ADV Router Age Seq# CkSum Route 0.0.0.0 100.64.0.1 1183 0x800000b9 0x4624 E2 0.0.0.0/0 [0x0] 0.0.0.0 100.64.4.1 130 0x800000bd 0x2240 E2 0.0.0.0/0 [0x0] neighboring routers see them: O>* 100.64.4.0/23 [110/20] via 100.64.98.3, blue, weight 1, 00:35:57 * via 100.64.99.3, orange, weight 1, 00:35:57 O>* 192.145.111.64/27 [110/20] via 100.64.98.3, blue, weight 1, 00:16:17 * via 100.64.99.3, orange, weight 1, 00:16:17 I guess the issue can be with UNKNOWN state of the interface (though LOWER_UP says that everything is ok with underlay). So the question is - whether this can lead to any issues (I do not see them at the moment except troubleshooting in case) or it worth attention and need to be fixed in some ways? If yes - in which ways it should be fixed? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 0

EVPN with IPv6 VTEPs
by Thomas Glanzmann 25 Jul '23

25 Jul '23

Hello everyone, I was able to build a EVPN using IPv4 VTEPs. However I would like to use IPv6 VTEPs. I tried the following configuration: https://tg.st/u/45a881f580facb5b470b169b88034997548e12cc8f552078efe9ceafb0c… However, when I run 'show evpn mac vni 100' it shows the IPv4 IP of the VTEP and not the IPv6 ip: debian3# show evpn mac vni 100 Number of MACs (local and remote) known for this VNI: 2 Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy MAC Type Flags Intf/Remote ES/VTEP VLAN Seq #'s 0e:00:00:00:00:04 local br100 1 0/0 0e:00:00:00:00:02 remote 172.31.0.171 0/0 Is it possible to use frr with EVPN and IPv6 VTEPs, if so how? Or is it impossible? Cheers, Thomas

1 0

ospf stopped working on 8.5.2
by Brian J. Murrell 13 Jul '23

13 Jul '23

My distro (Fedora 38) updated frr from 8.5.1 to 8.5.2 yesterday and upon restart of frr after that update, OSFP routing stopped working. It was working find prior to that. When I use vtysh to show the ospf route database: # show ip ospf database route % OSPF is not enabled in vrf default and indeed, the running config shows no OSPF configuration: # show running-config Building configuration... Current configuration: ! frr version 8.5.2 frr defaults traditional hostname pc.example.com no ipv6 forwarding no service integrated-vtysh-config ! end But my configuration files do configure ospf: ----- /etc/frr/daemons ----- bgpd=no ospfd=yes ospf6d=no ripd=no ripngd=no isisd=no pimd=no pim6d=no nhrpd=no eigrpd=no sharpd=no pbrd=no bfdd=no fabricd=no vrrpd=no pathd=no vtysh_enable=yes zebra_options=" -A 127.0.0.1 -s 90000000" bgpd_options=" -A 127.0.0.1" ospfd_options=" -A 127.0.0.1" ospf6d_options=" -A ::1" ripd_options=" -A 127.0.0.1" ripngd_options=" -A ::1" isisd_options=" -A 127.0.0.1" pimd_options=" -A 127.0.0.1" pim6d_options=" -A ::1" nhrpd_options=" -A 127.0.0.1" eigrpd_options=" -A 127.0.0.1" sharpd_options=" -A 127.0.0.1" pbrd_options=" -A 127.0.0.1" staticd_options="-A 127.0.0.1" bfdd_options=" -A 127.0.0.1" fabricd_options="-A 127.0.0.1" vrrpd_options=" -A 127.0.0.1" pathd_options=" -A 127.0.0.1" ----- /etc/frr/frr.conf ----- hostname pc.interlinx.bc.ca ----- /etc/frr/ospfd.conf ----- hostname pc password ospf4me enable password ospf4me ! router ospf ospf router-id 10.75.22.1 network 10.75.22.0/24 area 0 ! network 192.168.122.0/24 area 1 ! network 192.168.0.0/24 area 1 ! redistribute connected ----- /etc/frr/staticd.conf ----- ----- /etc/frr/vtysh.conf ----- no service integrated-vtysh-config ----- /etc/frr/zebra.conf ----- hostname pc password zebra enable password zebra log stdout interface pc_bridge link-detect interface virbr0 no link-detect This is the very same config that worked with 8.5.1 and is working on other machines in the network (albeit with earlier versions of frr as they are "EL8" systems which don't update as quickly as Fedora). Is there something about this configuration that is not compatible with 8.5.2? Cheers, b.

4 5

turning off hostname display in show ip bgp
by mike tancsa 06 Jul '23

06 Jul '23

I noticed that going to the latest release, I am now seeing hostnames instead of IP addresses in show ip bgp and show bgp ip sum. Is there a way to turn that off and just have IP addresses displayed ? e.g. old behaviour Network Next Hop Metric LocPrf Weight Path *= 0.0.0.0/0 xx.yy.135.76 0 0 11647 i *> xx.yy.135.73 0 0 11647 i *= zz.a.128.0/19 xx.yy.135.76 0 0 11647 ? *> xx.yy.135.73 0 0 11647 ? vs Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 xx.yy.242.17(remote-core1.sentex.ca) 0 100 11647 i * 10.99.254.1 0 64519 i *> 10.1.0.1/32 xx.yy.0.0(endpointcust1234.sentex.ca) 1 32768 ? I dont want the host names in there as it is visually kinda messy. ---Mike

2 4