October 2019 - frog - lists.frrouting.org

Yocto Recipe for FRR
by Amol Lad 10 Aug '21

10 Aug '21

Hi, Please advise if there is any Yocto recipe for FRRouting? If not, how to go about creating one for FRR? Yocto Recipe for FRR will hugely simplify integrating FRR in Yocto based embedded linux distributions. So please advise if there are any plans to develop this recipe? Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

4 10

v6 Route Replace semantics
by Donald Sharp 09 Apr '20

09 Apr '20

All - We recently introduced, into master, a new cli switch for zebra on linux `--v6-rr-semantics`. This was allow zebra to take advantage of the linux kernel getting v6 route replace semantics that is coming soon in the 4.18 linux kernel. So if you are on the bleeding edge of linux kernels and FRR you can start to take advantage of this new feature. What are Route Replace semantics you ask? Suppose we have a v6 route with 2 nexthops: S>* 4:6:7::/64 [1/0] via 1:2:3::4, enp0s3, 00:00:02 via 1:2:8::8, enp0s8, 00:00:02 Now suppose we remove a nexthop: robot# conf t robot(config)# no ipv6 route 5:7:9::/78 1:2:8::9 robot(config)# end robot# show ipv6 route [snip] S>* 5:7:9::/78 [1/0] via 1:2:3::4, enp0s3, 00:01:04 Let's look at the netlink notifications for this event: [ROUTE]5:7:9::/78 proto static metric 20 <----------- From creation of the 2x ecmp for 5:7:9::/78 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]Deleted 5:7:9::/78 proto static metric 20 <---- We delete the route nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium <----- We add it back in. In order to get the routes right in the kernel we had to delete the route first and then add it back in. Exposing a small window of packets being dropped while the route is fixed in the fib. Route Replace semantics tells the linux kernel to just replace the nexthops for the route. New packets coming in would immediately start using the new ecmp nexthop group path: [ROUTE]5:7:9::/78 proto static metric 20 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium thanks! donald

2 1

FRR on Juniper switches
by Rudy Rucker 30 Oct '19

30 Oct '19

Is anyone running FRR on Juniper switches? I read this article, but it looks more like an R&D setup. https://forums.juniper.net/t5/Industry-Solutions-and-Trends/FRRouting-on-Ju… Rudy

1 0

Routes learned from iBGP are not maintaining Metrics when advertised to eBGP peers
by Lee Clements 23 Oct '19

23 Oct '19

Doing some testing on FRR here, and hoping for some assistance. Hopefully this is the right place to go. If not, please let me know! I've got 3 remote iBGP peers that are configured as standard iBGP peers. These two iBGP peers learn some routes locally and then re-advertise these prefixes over a full-mesh iBGP network to each other, with FRR being one of the four routers in the mesh. The other three iBGP peers are Cisco. FRR has one eBGP peer, to replicate re-advertising these routes out to iBGP. In our other three iBGP peers, we leverage route-maps to increment the received MED value of the route, so that we can prefer locally received eBGP routes - all else being equal - as opposed to those learned from our iBGP speakers in other locations. We also do this so locally originated prefixes from our AS have a higher metric when going out to eBGP speakers so they don't inadvertently get preferenced when there's a better path for the route to take. I am receiving the routes from our iBGP speakers fine, and see the incremented MED on receipt of the routes from the aforementioned speaker. When I configure a local (to FRR) iBGP speaker as a route-reflector-client within the same AS, these pre-incremented MED's are correctly advertised to the local iBGP speaker and work just fine. When advertising these same prefixes to an eBGP speaker with a different AS, the metric's are not readvertised, and only a locally originated prefix maintains any sort of metric at all. Route's received from one of our remote iBGP speakers: routert# sh bgp ipv4 unicast neighbors 1.1.1.1 received-routes BGP table version is 0, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 1.1.1.1 100 100 0 i *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678 i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's being correctly re-advertised and maintaining metric on re-advertisement to our local iBGP speaker (route-reflector-client): router# sh bgp ipv4 unicast neighbors 3.3.3.3 advertised-routes BGP table version is 4560509, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 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 Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 1.2.7.0/23 2.2.2.2 0 100 32768 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's not maintaining their metric on re-advertisement to our local (to FRR) eBGP speaker: router# sh bgp ipv4 unicast neighbors 8.8.8.8 advertised-routes BGP table version is 4562244, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 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 Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 0.0.0.0 100 0 i *> 1.2.7.0/23 0.0.0.0 0 32768 i *> 2.3.4.0/21 0.0.0.0 100 0 5678i *> 3.4.5.0/24 0.0.0.0 100 0 5678 i *> 5.6.7.0/22 0.0.0.0 100 0 5678 i *> 7.8.9.0/24 0.0.0.0 100 0 5678 i Total number of prefixes 6 Am I doing something wrong here? Otherwise a pretty straight forward BGP setup with some basic route-maps in and out, nothing too crazy. Is this expected behavior in FRR? Running latest available stable release, FRRouting 7.1RPKI. Thanks for any help.

2 1

BGP on FreeBSD: Feature Parity with Linux?
by Christoph 18 Oct '19

18 Oct '19

Hello, recently we started using BIRD as BGP daemon, but since we realized that BIRD has some (security) limitations on FreeBSD 12 [1] (when compared to Linux) we are looking for an alternative and consider switching to FRR 7.2 Therefore we wanted to verify that FRR does not have similar limitations. We found some platform specific information in the documentation here: http://docs.frrouting.org/en/latest/overview.html#supported-protocols-vs-pl… (vrrp has not been added yet) but would have some additional questions: - Should we expect any (notable) differences of FRR on FreeBSD when compared to Linux that go beyond what is documented on the page mentioned above? Is FRR on BSD a second class citizen? - Does FRR (BGP) support ECMP on FreeBSD? http://docs.frrouting.org/en/latest/installation.html#cmdoption-configure-e… - What memory footprint should we expect on an FRR BGP router with two neighbors with a bgp fulltable each? - Does FRR support privilege dropping (on FreeBSD) or does it run as root entirely? I see zebra and bgpd runs as user 'frr' by default on FreeBSD, so I can answer this one myself (yes it drops privileges to a non-root user). answered via the documentation: - Does FRR's RPKI support include support for re-validation of affected routes after an RPKI ROA update or has it the same limitation as BIRD that requires re-validating all routes? [2] According to http://docs.frrouting.org/en/latest/bgp.html#prefix-origin-validation-using… this appears to be supported: > Updates from the RPKI cache servers are directly applied and path > selection is updated accordingly. (Soft reconfiguration must be > enabled for this to work). thanks, Christoph [1] https://bird.network.cz/pipermail/bird-users/2019-October/013845.html [2] https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.13 > BIRD should re-validate all of affected routes after RPKI update by > RFC 6811, but we don't support it yet! You can use a BIRD's client > command reload in bgp_protocol_name for manual call of revalidation > of all routes.

2 1

Should I remove LL IPv6 addresses from BGP peering?
by Rudy Rucker 16 Oct '19

16 Oct '19

When I do 'show bgp', I see multipath on all my routes... should I try to trim down table and only have non-LinkLocal addresses? Is this configurable in bgpd.conf, or should I remove the linkLocal from the interaface? Example: *= 2001::/32 2001:504:30::ba00:6939:1 0 108 0 6939 i * fe80::ce4e:24ff:fe1f:28d3 0 108 0 6939 i *> fe80::ce4e:24ff:fe1f:28d3 0 108 0 6939 i (IX has localpref of 108) Thanks for pointers on best practices with IPv6 and BGP, Rudy

2 1

7.2 Release
by Donald Sharp 16 Oct '19

16 Oct '19

I'd like to thank everyone who's helped with the 7.2 release. This is one of our largest releases yet! We are in the process of building release images. ------- 1016 commits, with 50 individual authors. ALL Daemons -N <namespace> to allow for config file locating when running FRR inside of a namespace Impoved Testing across all daemons BFD VRF Support Conversion to Northbound interface BGP Aggregate-address add route-map support BMP Support Improved JSON output for many commands `show bgp afi safi summary failed` command `clear bop *` clears all peers Show FQDN for `show bgp ipv4 uni` commands Display BestPath selection reason as part of show commands EIGRP Infrastructure changes to allow VRF’s SIGHUP signals the config reload Conversion to Northbound interface ISIS BFD Support Support for circuits with MTU > 8192 PBRD fwmark support as part of match criteria autocompletion of PBRMAPS Improved Nexthop Support PIMD PIM-BSM receive support Improved debugging support Store ECMP paths that are not currently legal for use Disallow igmp query from a non-connected source Many new cli improvements and changes VRRPD Add Support for RFC 3768 and RFC 5798 Route-Maps Add sequence numbers to access-lists Add `match ip next-hop type blackhole` Improved ability to notice dependency changes SHARPD `sharp watch [import|nexthop]` you can now specify a prefix instead of a ssuming a /32 STATICD Significantly Improved NHT ZEBRA Many dataplane improvements for routes, neighbor table and EVPN NHT cli can now be specified per VRF and improved ability to control NHT data being shown Removed duplicate processing of routes Improved debugablility RMAC and VxLan support for the FPM LIB RCU support Nexthop Group Improvements `log-filter WORD` added Building openssl support libcap should be used as part of build or significant slowdowns will be experienced Lua builds have been fixed Improved Cross building Snapcraft Add Fabricd Add Libyang Update rtrlib and rpki Authors: Ameya Dharkar Anuradha Karuppiah Ashish Pant Chiu Bi-Ruei Binu Abraham Biswajit Sadhu btarno Chirag Shah Christian Franke David Lamparter Dinesh Dutt Don Slice Donald Sharp Donatas Abraitis Dmitrii Turlupov Emanuele Di Pascale Faicker Mo Igor Ryzhov Jafar Al-Gharaibeh Juergen Werner Kishore Aramalla Lakshman Krishnamoorthy Lou Berger Marcel Röthke Marcin Matląg Mark Stapp Martin Winter Matthew Smith Michal Ruprich Naveen Thanikachalam Nikos Triantafillis Nitin Soni Pawel Dembicki Philippe Guibert Quentin Young Quentin Young Rafael Zalamena Renato Westphal Rajesh Girada Rob Gil Saravanan K Sarita Patra Satheesh Kumar K Soman K S

1 0

ospf6d issues (crashes getting routes from my network)
by Rudy Rucker 12 Oct '19

12 Oct '19

I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at the same time. bgpd and ospfd work fine, but ospf6 doesn't work. Not sure what I'm going wrong. Here is the output from zebra and ospf6. If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. router ospf6 ospf6 router-id 172.17.18.98 redistribute connected route-map MONKEY-ospf6 redistribute static route-map MONKEY-AND-MORE-ospf6 !interface cxl1 area 0.0.0.0 !interface cxl2 area 0.0.0.0 !interface cxl3 area 0.0.0.0 interface lo0 area 0.0.0.0 As soon as I get routes from my network, ospf6d tanks. Any thoughts? *** LOGS *** 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 5 usec, Reason: L+ 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 109 usec, Reason: R+, R-, L+ 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 116 usec, Reason: R+, N+, L+ 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 99 usec, Reason: R+, R- 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Loading]->[Full] (LoadingDone) 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to announce only ospf6 routes vrf=0 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an error and is shutting down. 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table chunks 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label chunks 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes removed from the rib *** CRASH *** If I run on the command line and don't background, it bombs after 7 seconds: # ospf6d Illegal instruction Here is the end of truss: # truss ospf6d ... mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863378432 (0x81e04f000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863382528 (0x81e050000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863386624 (0x81e051000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863390720 (0x81e052000) SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdffffff8 process killed, signal = 4 I wasn't seeing any CORE files when the process dumped, so I turned this knob: sysctl kern.sugid_coredump=1 Now there is a 1 GByte core file! # /usr/obj/usr/src/amd64.amd64/gnu/usr.bin/gdb/gdb/gdb /usr/local/sbin/ospf6d ospf6d.core (gdb) bt #0 0x000000080030678c in hash_get () from /usr/local/lib/libfrr.so.0 #1 0x000000080033a9b2 in route_node_lookup () from /usr/local/lib/libfrr.so.0 #2 0x0000000000241345 in ospf6_route_lookup () #3 0x000000000022e718 in ospf6_abr_examin_summary () #4 0x000000000022f13b in ospf6_abr_examin_brouter () #5 0x00000000002473ad in ospf6_top_init () #6 0x000000000022efda in ospf6_abr_examin_summary () #7 0x000000000022f13b in ospf6_abr_examin_brouter () #8 0x00000000002473ad in ospf6_top_init () #9 0x000000000022efda in ospf6_abr_examin_summary () #10 0x000000000022f13b in ospf6_abr_examin_brouter () #11 0x00000000002473ad in ospf6_top_init () .... lines #3 - #5 repeat to over #8500 ... I stopped hitting ENTER around there and quit. Any help would be appreciated. Rudy

3 6