- frog - lists.frrouting.org

Route Server Functionality
by Michael H Lambert 15 Sep '21

15 Sep '21

I’m trying to better understand route server functionality on FRR (7.5.1 specifically) and how it differs from quagga. I found the commit in which the legacy quagga special-case code was removed and replaced by the use of add-path. What happens if the route server and the client are unable to negotiate add-path as required? If the legacy code were still in place, I would expect a failover to it in that situation. Since the legacy code is no longer present, is the client required to have properly configured add-path in order to properly talk to the route server? Thanks, Michael

1 0

Basic BGP transit with FRR
by John Antypas 04 Sep '21

04 Sep '21

To all, I've always known what FRR is, and what it can do. I've just never had to do it myself -- I've been lucky enough to have really good WAN admins who just delivered packet to me over an Ethernet cable and I stayed in the kernel where I could only break MY machine, not everyone else's on the Internet. Some poor soul told me I should venture out and let me do this.... God protects the foolish so here I go.... What I'm trying to do: My transit provider has given me a GRE tunnel for my IP blocks and over which I am to do BGP. Specifically (made up IPs, but valid prefixes) - GRE tunnel endpoints 10.1.0.1 (their end) --- 10.1.0.2 (my end). Tunnel works and passes packets - Prefixes: 199.181.204.0/24 2602:805:A000::/44 It seems to me, I need to create an frr file like this? (daemons has bgpd on) --------------------------------------------- version 7.5 frr default traditional hostname esxi password 5System5!zebra enable password 5System5!zebra log syslog traditional ip forward ipv6 forward ip forward service integrated-vtysh-conf router bgp 398319 neighbor V4 peer-group neighbor V4 as THEIR-ASN neighbor 10.1.0.2 peer-group V4 neighbor V6 peer-group neighbor V6 remote-as THEIR-ASN neighbor THEIR-V6-IP address-family ipv4 unicast redistribute connected neighbor V4 route-map IMPORT in neighbor V4 route-map EXPORT out exit-address-family address-family ipv6 unicase redistributee connected neighbor V6 activate neighbor V6 route-map INPORT in neighbor V6 route-map EXPORT out exit-address-family route-map EXPORT deny 100 route-map EXPORT permit 1 match interface lo route-map IMPORT deny 1 line vty --------------------------------- Is this even close? I just want to announce my internal prefixes out to them. Also, I've put this in frr.conf vtysh.conf, etc. and it never seems to be part of the config. Clearing I'm quite worng. Where do I go from here?

1 0

Announcing FRR 8.0.1
by Martin Winter 30 Aug '21

30 Aug '21

We are pleased to announce release 8.0.1 of FRRouting! Github Release - https://github.com/FRRouting/frr/releases/tag/frr-8.0.1 Debian Packaging - https://deb.frrouting.org/ RPM Packaging - https://rpm.frrouting.org/ This is a bugfix release of FRR 8.0 For a detailed changelog with all the fixes over 8.0 see https://github.com/FRRouting/frr/releases/tag/frr-8.0.1 As always, thank you to all contributors! - Martin

1 0

bgp view broken in 8.0 ?
by Philip Smith 27 Aug '21

27 Aug '21

Hi everyone, Is anyone using the "bgp view" feature in FRR at all? I've been using this feature on FRR 7.5.1 on Ubuntu 20.04 for several months without issue. The upgrade to FRR 8.0 that was pushed out the four weeks back broke all the BGP feeds that I have (basically for a routing analysis looking glass activity). This is the an example of the configuration I'm using: router bgp 65534 view I2 bgp router-id 128.223.157.40 bgp log-neighbor-changes no bgp default ipv4-unicast timers bgp 15 45 neighbor 64.57.28.241 remote-as 11537 neighbor 64.57.28.241 description I2 neighbor 64.57.28.241 ebgp-multihop 255 ! address-family ipv4 unicast neighbor 64.57.28.241 activate neighbor 64.57.28.241 prefix-list DENY-ALL out neighbor 64.57.28.241 route-map IMPORT in exit-address-family ! and I have around 30 BGP feeds, all going into different views. If I use FRR 7.5.1, the BGP sessions are up and running just fine. But in 8.0, they all sit there in "Connect" (IPv4 and IPv6). It looks like this, in a testbed of mine (I can't put the production system to FRR 8.0 unfortunately). Configuration: router bgp 131076 view C1100 bgp router-id 192.168.1.230 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 192.168.1.254 remote-as 131076 neighbor 192.168.1.254 description Cisco C1100 Border ! address-family ipv4 unicast distance bgp 200 200 200 neighbor 192.168.1.254 activate exit-address-family ! frr# sh bgp view C1100 sum IPv4 Unicast Summary: BGP router identifier 192.168.1.230, local AS number 131076 vrf-id 1 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 1, using 727 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 192.168.1.254 4 131076 0 0 0 0 0 never Connect 0 Cisco Total number of neighbors 1 If I revert to FRR 7.5.1 on the testbed, the peering comes up. bgpd.log says this: 2021/08/27 14:42:12 ZEBRA: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00 2021/08/27 14:42:12 BGP: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00 2021/08/27 14:42:12 STATIC: [VTVCM-Y2NW3] Configuration Read in Took: 00:00:00 and frr.log has basically the same content. The docs for bgpd don't seem to have changed and I can't find anything via the CLI that suggests the configuration is different in 8.0. Any hints or tips or clues on how to fix this? Or is this a bug introduced in 8.0? Thanks! philip --

2 1

Bugfix release for 7.5?
by Cloud Operations 17 Aug '21

17 Aug '21

Hi, We are plagued lately with an issue where bgpd terminates quite frequently out of the blue on one of our hosts. We weren't able to find anything in logs, but eventually strace gave us some information: [pid 13589] 10:04:47.905970 write(2</dev/null<char 1:3>>, "bgpd: lib/zlog_targets.c:127: zlog_fd: Assertion `iovpos == 0' failed.\n", 71) = -1 EBADF (Bad file descriptor) Searching Google only turned up this: https://git.edevau.net/Ede_Vau/frr/commit/db2baed166581081db692fab0214752db… Looking at FRR's Github it looks like this has been fixed? If that is the case are there plans to release this fix and if so when could we expect to see a fixed version out? For now we've increased the logging level to debug and currently monitoring to see if that's a viable mitigation. Are there any known mitigations we can try (if this doesn't work out)? We are running FRR 7.5.1 on CentOS 7. Kind regards -- Natterbox Limited Registered address: No 1 Croydon, 12-16 Addiscombe Road, Croydon CR0 0XT, UK Company number: 06968249 VAT number: 293 7488 48 This email and any files transmitted with it are confidential, intended solely for the use of the addressee and are not to be used, disseminated, forwarded, printed or copied by any other person. Any views or opinions are solely those of the author and do not necessarily represent those of Natterbox Limited unless specifically stated. If you have received this communication in error, please accept our apologies and promptly inform the sender by email or by telephoning the above number. Please also immediately delete this message and any attachments from your systems. Thank you. The files attached and/or any website linked to this email may contain viruses which could damage your computer, Natterbox Limited cannot accept liability for such damage.

3 3

Doubt about FRR and Debian Bullseye
by Marcelo Gondim 17 Aug '21

17 Aug '21

Dear, As Debian Bullseye was released as a stable version, I would like to know if I can upgrade my systems to Bullseye or if I should expect to release the official FRR repository at https://deb.frrouting.org/. Is there any time estimate to release in the repository? Best regards, -- ⢀⣴⠾⠻⢶⣦⠀ Marcelo Gondim ⣾⠁⢠⠒⠀⣿⡁ Sysadmin - https://www.linuxinfo.com.br ⢿⡄⠘⠷⠚⠋ DA04 922E 78B3 44A5 3C8D 23D0 8DB5 571E E151 4E19 ⠈⠳⣄⠀⠀⠀⠀ Logic will get you from A to B. Imagination will take you everywhere. (Albert Einstein)

2 1

Action on Issue in GitHub?
by Michael H Lambert 16 Aug '21

16 Aug '21

I was just wondering if there is some special incantation needed to move issues opened on GitHub into a triage state. I submitted #9344 a week ago and it has not progressed. Thanks, Michael ----- Michael H Lambert, GigaPoP Manager Phone: +1 412 268-4960 Pittsburgh Supercomputing Center/3ROX FAX: +1 412 268-5832 300 S Craig St, Pittsburgh, PA 15213 USA lambert(a)psc.edu

2 3

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

Announcing FRR 8.0.0
by Quentin Young 29 Jul '21

29 Jul '21

Hi all, We are pleased to announce the 8.0 release of FRRouting! Github Release - https://github.com/FRRouting/frr/releases/tag/frr-8.0 Debian Packaging - https://deb.frrouting.org/ RPM Packaging - https://rpm.frrouting.org/ Some major highlights: - A new daemon, pathd, has been added. This daemon implements support for segment routing. - EVPN Multihoming is now fully supported - OSPFv3 now supports VRFs - TI-LFA has been implemented in IS-IS and OSPF - Zebra now has the ability to dump netlink messages in a human-friendly format - LDP gained SNMP support And of course, innumerable bug fixes and other improvements. Please see the release notes for the detailed changelog: https://frrouting.org/release/8.0/ We expect to have a bugfix release out in the near future to include some fixes that didn't make it into this release, so please stay tuned for that. As always, thank you to all contributors! Cheers, - Quentin

1 0

OSPF, FreeBSD and aliases
by Eugene Grosbein 20 Jul '21

20 Jul '21

Hi! I hope this is right list to ask. Please correct me if not. I'm trying to move from quagga to frr 7.5.1. I have existing working setup with OSPF and FreeBSD servers that have some aliases on its OSPF-enabled interfaces. In FreeBSD, if one needs several IP addresses in same IP subnet on one interfaces (for CARP etc.) then one assigns one of IPs with "real" subnet mask and others with /32 mask: igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 inet 192.168.49.3 netmask 0xffffff00 broadcast 192.168.49.255 inet 192.168.49.13 netmask 0xffffffff broadcast 192.168.49.13 inet 192.168.49.17 netmask 0xffffffff broadcast 192.168.49.17 And another OSPF neighbour: igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 inet 192.168.49.1 netmask 0xffffff00 broadcast 192.168.49.255 inet 192.168.49.10 netmask 0xffffffff broadcast 192.168.49.13 inet 192.168.49.11 netmask 0xffffffff broadcast 192.168.49.17 This worked for me for years with quagga but frr's ospfd does not form neighbourship with following errors: interface igb0:192.168.49.17: ospf_read network address is not same [192.168.49.1] interface igb0:192.168.49.17: ospf_read network address is not same [192.168.49.10] interface igb0:192.168.49.17: ospf_read network address is not same [192.168.49.11] It seems ospfd's checks cannot cope with FreeBSD-like IP aliases. Please help.

3 8