- frog - lists.frrouting.org

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

Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software
by Turritopsis Dohrnii Teo En Ming 10 May '23

10 May '23

Subject: Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software Good day from Singapore, I have just come across this article. Thought of sharing it. Article: Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software Link: https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com GIMP also stands for Government-Induced Medical Problems.

1 0

Re: [FROG] FRR 8.5.1 Release
by Mark Tinka 01 May '23

01 May '23

I hope there would have been some fixes to the outstanding IS-IS issues I have posted about. It seems IS-IS is not going to be ready for production use anytime soon, so I'll have to go back to Quagga. Mark. On 4/30/23 12:49, Jafar Al-Gharaibeh via frog wrote: > ear FRR Community, > > We are pleased to announce FRR 8.5.1 bug fix release. > > Packages are available at: > > Debian Packages -https://deb.frrouting.org > RPM Packages -https://rpm.frrouting.org > Snaps -https://snapcraft.io/frr > Docker - quay.io/frrouting/frr:v8.5.1 > > For release notes please visit: > > https://frrouting.org/release/8.5.1/ > > https://github.com/FRRouting/frr/releases/tag/frr-8.5.1 > > > > Cheers, > > The FRR Development Team!

2 2

FRRouting to leverage AI/ML networking synergies
by David 'equinox' Lamparter 02 Apr '23

02 Apr '23

Hi all, as you are likely well aware, recent developments in Artificial Intelligence and Machine Learning have been consistently performing one quantum leap after another. To leverage the new possibilities and avenues enabled by these developments, and not get left behind, we must join up and integrate these new technologies as soon as possible. I would therefore like to present our plans for the immediate future: - all SPF calculation and BGP best-path decision logic is to be replaced by a GNN (Graph Neural Network). In preparation of this, significant effort has been made to train such a network to produce results exceeding those provided by the previous hard-coded logic. - all configuration interfacing is to be performed by Microsoft's Sydney LLM (Large Language Model) chatbot. Not only is this the obvious choice of vendor considering our SONiC integration, but we also believe Sydney to be superior in its capability to handle typical network engineers' outbursts of swearing and curses. In fact, we are confident that future networks may be configured by simply swearing at the hardware until it works. - monitoring and other OAM functions will be handled by clippy, as provided in the original version of Office 97. The rationale for this is to ease the production of the appropriate curses necessary to affect the configuration changes needed to fix the outage at hand. We understand some of you may be concerned about the reliability and availability of these new AIs. As an open source project, we will obviously not try to confine you to the use of our provided AIs. In fact, we will try our best to enable you to train up your own AI according to the needs of your particular network! (Cloud compute credits not included.) I am happy to invite you all to join our path to this bright future, -equi P.S.: Please note that, despite the obvious connection, YANG schemas and configuration data exceed the limits of swearing we were able to train Sydney for. I am unsure we will be able to achieve this particular feat, but it's not quite time to give up just yet.

3 2

IS-IS Appears More Broken Than Before
by Mark Tinka 31 Mar '23

31 Mar '23

Hi all. I posted the below in 2020 about IS-IS in FRR (7.3, at the time): https://seclists.org/nanog/2020/Apr/226 I gave up and moved back to Quagga with OSPF. I decided to try again today, with FRR 8.5, on FreeBSD-13.1-RELEASE-p6. Things seem to have taken a major step back since then. I can't even get an adjacency going with a Cisco IOS XE router: 2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister RLFA with LDP 2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister RLFA with LDP 2023/03/31 07:12:01 ISIS: [WDVAD-TY6HY] ISIS-LFA: failed to unregister RLFA with LDP 2023/03/31 07:12:01 ISIS: [YDRGH-0DJ94] Opened BPF device /dev/bpf0 2023/03/31 07:12:01 ISIS: [QJWNQ-3FFKM] BPF buffer len = 4096 2023/03/31 07:12:01 ISIS: [V3AHD-XE2Z5] failed to set BPF buffer len (4096 to 9000) 2023/03/31 07:12:01 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit packet on em0: Input/output error 2023/03/31 07:12:01 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed 2023/03/31 07:12:04 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit packet on em0: Input/output error 2023/03/31 07:12:04 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed 2023/03/31 07:12:07 ISIS: [W02G1-H56T1] IS-IS bpf: could not transmit packet on em0: Input/output error 2023/03/31 07:12:07 ISIS: [G7ZA5-AT06A][EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed Thoughts? Mark.

1 0

Re: [FROG] rpki start
by Donald Sharp 22 Mar '23

22 Mar '23

What does your config look like? Mine starts automatically, rpki is programmed to start it when you leave the rpki subnode donald On Tue, Mar 21, 2023 at 5:15 PM Chris Knipe via frog < frog(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Chris Knipe <cknipe(a)opticnetworks.net> > To: ch <ch(a)ntrv.dk>, "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Tue, 21 Mar 2023 19:00:29 +0000 > Subject: RE: [FROG] rpki start > Hi, > > > > >Or are you referring to an RPKI (caching) server FRR connects to? > > > > Correct. RPKI doesn't automatically connect to the RPKI servers unless I > issue a "rpki start" command. > > Configuration etc. is 100%, works absolutely fine. Just doesn't > automatically connect to the RPKI servers. > > -- > Chris. > > > > > ---------- Forwarded message ---------- > From: Chris Knipe via frog <frog(a)lists.frrouting.org> > To: ch <ch(a)ntrv.dk>, "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Tue, 21 Mar 2023 19:00:29 +0000 > Subject: Re: [FROG] rpki start > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog >

2 5

Re: [FROG] rpki start
by ch 22 Mar '23

22 Mar '23

On 19/03/2023 15.47, Chris Knipe via frog wrote: > Is there a way to start rpki automatically when frr starts? > > Trying to avoid having to execute "rpki start" each and every time, Having to start rpki? What is the exact scenario? A bit unclear IMO. Does RPKI not start with FRR when you specify the bgpd_option `-M rpki`? Or are you referring to an RPKI (caching) server FRR connects to?

2 1