- frog - lists.frrouting.org

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

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 09 Aug '23

09 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 24 Jul '23

24 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 12 Jul '23

12 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 05 Jul '23

05 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

ibgp regression on 8.5.2 ?
by mike tancsa 30 Jun '23

30 Jun '23

I was updating an internal distribution router that got wedged in vtysh from 8.5 to 8.5.2 and found all my ibgp peers would not come up. Same error on the half dozen peers Jun 29 14:00:55 ibgp-4 bgpd[38150]: [HZN6M-XRM1G] %NOTIFICATION: received from neighbor xx.yy.zz.251 3/4 (UPDATE Message Error/Attribute Flags Error) 14 bytes 80 1a 0b 01 00 0b 00 00 00 00 00 00 00 01 Jun 29 14:01:00 ibgp-4 bgpd[38150]: [HZN6M-XRM1G] %NOTIFICATION: received from neighbor xx.yy.zz.251 3/4 (UPDATE Message Error/Attribute Flags Error) 14 bytes 80 1a 0b 01 00 0b 00 00 00 00 00 00 00 01 Jun 29 14:01:05 ibgp-4 bgpd[38150]: [HZN6M-XRM1G] %NOTIFICATION: sent to neighbor xx.yy.zz.251 3/4 (UPDATE Message Error/Attribute Flags Error) 14 bytes c0 1a 0b 01 0 On the older versions of frr, [NYD0B-A3BTB][EC 33554433] AIGP attribute must be flagged as "Transitive" [HZN6M-XRM1G] %NOTIFICATION: sent to neighbor xx.yy.zz.241 3/4 (UPDATE Message Error/Attribute Flags Error) 14 bytes 80 1a 0b 01 0 [GW152-RVASS][EC 33554455] bgp_process_packet: BGP UPDATE receipt failed for peer: xx.yy.zz.241 I downgraded from 8.5.2 to 8.5.1 and all was good. Also, another peer thats still running 7.x was fine with it all. Nothing special about the config. One of the untouched boxes running 8.5 neighbor THOTLAN peer-group neighbor THOTLAN remote-as 11647 neighbor THOTLAN description Core1LanEx neighbor THOTLAN update-source [dot.251] neighbor .241 peer-group HOTLAN neighbor .241 description The box the flipped out neighbor .241 bfd neighbor THOTLAN activate neighbor THOTLAN next-hop-self neighbor THOTLAN weight 111 The box I tried to upgrade from 8.5 to 8.5.2 that then went back to 8.5.1 neighbor THOTLAN peer-group neighbor THOTLAN remote-as 11647 neighbor THOTLAN update-source [dot.241] neighbor THOTLAN timers 16 50 neighbor .251 description One of the many other peers that didnt like me neighbor .251 bfd neighbor THOTLAN activate neighbor THOTLAN next-hop-self neighbor THOTLAN soft-reconfiguration inbound neighbor THOTLAN weight 109 ---Mike

2 7

FRR 8.5.2 Release
by Jafar Al-Gharaibeh 26 Jun '23

26 Jun '23

Dear FRR Community, We are pleased to announce FRR 8.5.2 bug fix release. For release notes please visit: https://frrouting.org/release/8.5.2/ https://github.com/FRRouting/frr/releases/tag/frr-8.5.2 Cheers, The FRR Development Team!

1 0