- frog - lists.frrouting.org

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

BGP_NLRI_MISMATCH Problem
by Soeren Malchow 14 May '23

14 May '23

Dears, we are struggeling with a setup, where we have a BGP setup with our carrier and IPv4 works just fine (two endpoints on our side, two on theirs) on the same two connections we are also trying to advertise IPv6 prefixes, however, in that case the carrier router spits out this error message. The FRR is running on a pfsense on our side, however, there is no need to use the ui to do the configuration, we did that already on the CLI. BGP_NLRI_MISMATCH: bgp_process_caps: mismatch NLRI with 2001:xxxx:x:x:x:x:xx:xxxx (External AS 1xxxx): peer: <inet-unicast inet6-unicast>(17) us: <inet6-unicast>(16) (instance master) Which tells me that we are offering IPv6 and IPv4 but they only want ipv6, correct ? The configuration on our side is as follows frr version 7.5.1 frr defaults traditional hostname XXXXXX service integrated-vtysh-config ! password some_password ! ip router-id 62.xx.xx.x ! router bgp 1xxxx bgp router-id 62.xx.xx.xx bgp log-neighbor-changes no bgp network import-check neighbor 62.x.x.x remote-as 3xxx neighbor 62.x.x.x description Lumen peer neighbor 62.x.x.x bfd neighbor 62.x.x.x password PASSWORD neighbor 62.x.x.x update-source 62.xx.xx.xx neighbor 2001:xxxx:x:x:x:x:x:xxxx remote-as 3xxx neighbor 2001:xxxx:x:x:x:x:x:xxxx description Lumen Circuit 1 - IPv6 neighbor 2001:xxxx:x:x:x:x:x:xxxx bfd neighbor 2001:xxxx:x:x:x:x:x:xxxx password PASSWORD neighbor 2001:xxxx:x:x:x:x:x:xxxx update-source 2001:xxxx:x:x:x:x:xx:xxxx ! address-family ipv4 unicast network 62.x.x.xxx/25 route-map ALLOW-ALL network 212.x.x.x/29 route-map ALLOW-ALL neighbor 62.x.x.x route-map ALLOW-ALL in neighbor 62.x.x.x route-map ALLOW-ALL out exit-address-family ! address-family ipv6 unicast network 2001:XXXX:XXXX:X::/64 route-map ALLOW-ALL network 2001:XXXX:XXXX::/48 route-map ALLOW-ALL neighbor 2001:1900:x:x:x:x:x:xxxx activate no neighbor 2001:1900:x:x:x:x:x:xxxx send-community neighbor 2001:1900:x:x:x:x:x:xxxx route-map ALLOW-ALL in neighbor 2001:1900:x:x:x:x:x:xxxx route-map ALLOW-ALL out exit-address-family ! route-map ALLOW-ALL permit 100 description Match any route ! line vty ! bfd peer 62.x.x.x local-address 62.xx.xx.xx interface vtnet0 no shutdown ! ! any help on how to continue with this is very much appreciated. We have no idea what to do here Cheers Soeren

2 1

libyang2 and speeding up it's use
by Donald Sharp 10 May '23

10 May '23

I recently upgraded to libyang2.1.55, from an early version of libyang2 from a year or so ago. There was a huge improvement in startup times for configs using a decent number of route maps. I would highly recommend that you grab this latest version and upgrade to using it if you can do so. thanks! donald

1 0