We run FRR for RR’s with full tables in the default vrf and a L3VPN plus multiple additional L3VPN’s. 6PE, 6VPE both work. No complaints. [cid:ignored-in-diff-30BE7347-88C8-456D-95A2-E75A56BBF1DB] Evan S. Weiner ​​​​ Managing Member , Hosted Backbone, LLC d: (804) 549-4899<tel:(804)%20549-4899> | m: (804) 677-9544<tel:(804)%20677-9544> e: eweiner@hostedbackbone.net<mailto:eweiner@hostedbackbone.net> | w: <https://www.hostedbackbone.net/> www.hostedbackbone.net<https://www.hostedbackbone.net/> ________________________________ From: Tom Samplonius via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 2, 2026 2:22:14 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Tom Samplonius <tom@samplonius.org> Subject: FRR for BGP route reflectors? Hi, Is Free Range Routing (FRR) a viable choice for a pure BGP route reflector for a regional ISP with ~ 35 routers? A mix of L3VPN-MPLS and BGP-EVPN services. Full transit, plus some peering. About 5 x L3VPN instances, and maybe 500 x EVPN-MPLS instances. I don’t see a lot of posts of people using FRR for RR. And not a lot of people reporting issues, so maybe it is just the perfect RR solution? Tom _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STLGD7H4...

I have had this question also before. Also importantly, if you would, what kind of hardware specs do your RR's have and are they physical or virtual? --- Richard Owens Network Automation and Wireless Engineer | Information Technology Services Old Dominion University 4300 Engineering and Computational Sciences Building https://www.odu.edu/its ________________________________ From: fritz--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 2, 2026 10:09 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: fritz@init7.net <fritz@init7.net> Subject: Re: FRR for BGP route reflectors? EXTERNAL to ODU: This email is not from an ODU account. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Tom! We are using FRRouting on Linux VMs as dedicated BGP route reflectors for AFs vpnv4, vpnv6 and evpn. Having around 1000 RR clients connected with a handful of L3VPN and a few dozen EVPN instances. We don't keep the full routing table on them, but that should cause no problem, just throw a bit more memory onto the VMs. BGP works like a charm on FRRouting and is also pretty good on supporting recent BGP features. We can absolutely recommend it. As a sidenote: IGPs at FRRouting seem to get a bit less love, so don't be too sophisticated there... BR, Thomas Senior Network Engineer Init7 (AS13030) _______________________________________________ NANOG mailing list https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F5YPBTLAZTZ2PLG3THWK3R4J45NLLQLER%2F&data=05%7C02%7Crowens%40odu.edu%7C760b744b40b24195c83608dec0b11127%7C48bf86e811a24b8a8cb368d8be2227f3%7C0%7C0%7C639160063895453802%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=se8967J3xTPB4T0YC76aG2J8vFWkPJdiyXudE%2FJ%2FoAI%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5YPBTLAZTZ2PLG3THWK3R4J45NLLQLER/>

Well, while I’m curious about FRR specific characteristics, I think the typical BGP CPU advice still applies: 1. Fastest possible cores. While there are techniques to process BGP in parallel (ex. sharding), BGP often tends to serialize updates. Faster cores are always better for BGP. 2. Virtualization is just a tax. Assume it takes 10% of your performance, which is probably on the high-end for a RR. RRs don’t forward packets, so XDP and DPDK and all that stuff, do not apply. Juniper says their container routing protocol daemon (cRPD): Junos cRPD is designed to maximize routing performance. For example, it is capable of reflecting 10 copies of Internet routes to 1000 BGP peers in less than 60 seconds. I’m curious if FRR can do that, and what hardware that would be. Tom

On Jun 2, 2026, at 7:30 AM, Owens, Richard A. via NANOG <nanog@lists.nanog.org> wrote:

I have had this question also before. Also importantly, if you would, what kind of hardware specs do your RR's have and are they physical or virtual?

---

Richard Owens

Network Automation and Wireless Engineer | Information Technology Services

Old Dominion University

4300 Engineering and Computational Sciences Building

https://www.odu.edu/its

________________________________ From: fritz--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 2, 2026 10:09 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: fritz@init7.net <fritz@init7.net> Subject: Re: FRR for BGP route reflectors?

EXTERNAL to ODU: This email is not from an ODU account. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Tom!

We are using FRRouting on Linux VMs as dedicated BGP route reflectors for AFs vpnv4, vpnv6 and evpn. Having around 1000 RR clients connected with a handful of L3VPN and a few dozen EVPN instances. We don't keep the full routing table on them, but that should cause no problem, just throw a bit more memory onto the VMs. BGP works like a charm on FRRouting and is also pretty good on supporting recent BGP features. We can absolutely recommend it.

As a sidenote: IGPs at FRRouting seem to get a bit less love, so don't be too sophisticated there...

BR, Thomas Senior Network Engineer Init7 (AS13030) _______________________________________________ NANOG mailing list https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2F5YPBTLAZTZ2PLG3THWK3R4J45NLLQLER%2F&data=05%7C02%7Crowens%40odu.edu%7C760b744b40b24195c83608dec0b11127%7C48bf86e811a24b8a8cb368d8be2227f3%7C0%7C0%7C639160063895453802%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=se8967J3xTPB4T0YC76aG2J8vFWkPJdiyXudE%2FJ%2FoAI%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5YPBTLAZTZ2PLG3THWK3R4J45NLLQLER/> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G3JYH7XV...

Hello, I use FRR a lot in ISPs that I work for, but in cases of RR I prefer to use GoBGP or BIRD. I prefer GoBGP or Bird instead FRR because they are easier to automate. But yes, you can use FRR to do so. [cid:88dbfea2-6417-4e39-ac74-41fdd65216d3@BRAP284.PROD.OUTLOOK.COM]

On 3 Jun 2026, at 10:02, Douglas Fischer via NANOG <nanog@lists.nanog.org> wrote:

Perhaps these excellent publications by Justin Pietsch can help you decide: https://medium.com/the-elegant-network/performance-testing-of-commercial-bgp... I suggest reading the entire set of posts.

I don't know if anyone has done analyses of this same type recently. If so, I'd like to read them.

Em ter., 2 de jun. de 2026 às 18:14, Tom Samplonius via NANOG < nanog@lists.nanog.org> escreveu:

...

Well, while I’m curious about FRR specific characteristics, I think the typical BGP CPU advice still applies:

1. Fastest possible cores. While there are techniques to process BGP in parallel (ex. sharding), BGP often tends to serialize updates. Faster cores are always better for BGP.

2. Virtualization is just a tax. Assume it takes 10% of your performance, which is probably on the high-end for a RR. RRs don’t forward packets, so XDP and DPDK and all that stuff, do not apply.

Juniper says their container routing protocol daemon (cRPD):

Junos cRPD is designed to maximize routing performance. For example, it is capable of reflecting 10 copies of Internet routes to 1000 BGP peers in less than 60 seconds.

I’m curious if FRR can do that, and what hardware that would be.

Tom

...

On Jun 2, 2026, at 7:30 AM, Owens, Richard A. via NANOG < nanog@lists.nanog.org> wrote:

I have had this question also before. Also importantly, if you would, what kind of hardware specs do your RR's have and are they physical or virtual?

---

Richard Owens

Network Automation and Wireless Engineer | Information Technology Services

Old Dominion University

4300 Engineering and Computational Sciences Building

https://www.odu.edu/its

________________________________ From: fritz--- via NANOG <nanog@lists.nanog.org> Sent: Tuesday, June 2, 2026 10:09 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: fritz@init7.net <fritz@init7.net> Subject: Re: FRR for BGP route reflectors?

EXTERNAL to ODU: This email is not from an ODU account. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Tom!

We are using FRRouting on Linux VMs as dedicated BGP route reflectors for AFs vpnv4, vpnv6 and evpn. Having around 1000 RR clients connected with a handful of L3VPN and a few dozen EVPN instances. We don't keep the full routing table on them, but that should cause no problem, just throw a bit more memory onto the VMs. BGP works like a charm on FRRouting and is also pretty good on supporting recent BGP features. We can absolutely recommend it.

As a sidenote: IGPs at FRRouting seem to get a bit less love, so don't be too sophisticated there...

BR, Thomas Senior Network Engineer Init7 (AS13030) _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5YPBTLAZ... < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5YPBTLAZ...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/G3JYH7XV...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BMWHVTDO...

-- Douglas Fernando Fischer Engº de Controle e Automação _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/6JZ6ABP2...

Saku, I don’t frequently agree with your posts, but I agree with this. FRR is embedded in a lot of systems, and sometimes is somehow buried underneath a second CLI. These layers of config files frequently cause configuration de-sync issues. So the top level configuration that I see, is different from the configuration that FRR is using. I realize it is somewhat different, but it similar to the entire issue of “commit” versus “commit full”. You can commit a configuration, which may not be fully applied to the hardware, or you can “commit full” and really commit that change. Its just because the outer most configuration layer, doesn’t know what is going on the lower layers of configuration. But as a mid-sized ISP, and with route reflectors having the ability to identify new EVPN instances, and routers having the ability to signal to the RR, which EVPN and L3VPN instances they are part of, how much programmability would I need? Other than modifying global policy, perhaps I never need to modify the RR configuration? I certainly don’t need to modify it, to add a new EVPN or new L3VPN? Tom

On Jun 4, 2026, at 12:59 AM, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

On Wed, 3 Jun 2026 at 18:05, André Dias via NANOG <nanog@lists.nanog.org> wrote:

...

I use FRR a lot in ISPs that I work for, but in cases of RR I prefer to use GoBGP or BIRD. I prefer GoBGP or Bird instead FRR because they are easier to automate.

It boggles my mind that someone goes 'I'm going to write this very complex daemon' and then they proceed to write monolithic tightly coupled CLI+daemon+logic.

So we have a huge collection of BGP implementations, as mentioned just here, frr, gobgp, bird, rustybgp, openbgp, exabgp and many many others. But we don't really have any BGP library approaching a similar maturity level. While to me it seems it should have been an obvious win for any project, to start day1 with decoupled library, cli and daemon as separate libraries, i see it reducing work day1 due to forcing more maintainability in design.

Then instead of using low performance, lacking or non-existing APIs in your automation, you could write your own BGP worker using the library to have superior flexibility and performance, and exactly the behaviour you want. Many things you cannot do at all, because you don't have a library, like fuzzing, the daemon won't allow you to do wrong/bad things.

So please, the next person planning to write BGP or whatever project they're thinking of, separate the logic and daemon. Thank you.

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OPAVVROP...

I'm not protesting the count of BGP implementations, the more the merrier. I'm protesting the lack of BGP libraries. On Fri, 5 Jun 2026 at 16:25, Douglas Fischer <fischerdouglas@gmail.com> wrote:

Regarding the multiplicity of daemons for BGP.

I believe it's only necessary to say that there are daemons with different purposes. - FRR, for instance, most of the time doesn't allow you to break what the protocol proposes. To do that, you have to go down several layers, which isn't simple. - ExaBGP, for example, is designed so that you can do "anything you want" with the routes, regardless of whether they respect basic BGP criteria.

And both are necessary.

Em qui., 4 de jun. de 2026 às 05:00, Saku Ytti via NANOG <nanog@lists.nanog.org> escreveu:

...

On Wed, 3 Jun 2026 at 18:05, André Dias via NANOG <nanog@lists.nanog.org> wrote:

...

I use FRR a lot in ISPs that I work for, but in cases of RR I prefer to use GoBGP or BIRD. I prefer GoBGP or Bird instead FRR because they are easier to automate.

It boggles my mind that someone goes 'I'm going to write this very complex daemon' and then they proceed to write monolithic tightly coupled CLI+daemon+logic.

So we have a huge collection of BGP implementations, as mentioned just here, frr, gobgp, bird, rustybgp, openbgp, exabgp and many many others. But we don't really have any BGP library approaching a similar maturity level. While to me it seems it should have been an obvious win for any project, to start day1 with decoupled library, cli and daemon as separate libraries, i see it reducing work day1 due to forcing more maintainability in design.

Then instead of using low performance, lacking or non-existing APIs in your automation, you could write your own BGP worker using the library to have superior flexibility and performance, and exactly the behaviour you want. Many things you cannot do at all, because you don't have a library, like fuzzing, the daemon won't allow you to do wrong/bad things.

So please, the next person planning to write BGP or whatever project they're thinking of, separate the logic and daemon. Thank you.

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OPAVVROP...

-- Douglas Fernando Fischer Engº de Controle e Automação

-- ++ytti

On 02/06/2026 16:09, fritz--- via NANOG wrote:

As a sidenote: IGPs at FRRouting seem to get a bit less love, so don't be too sophisticated there...

It's one of the reasons we are running OSPF on FRR in lieu of IS-IS. It's possible IS-IS has moved on since I last tried it around 2020, but an IP network is no longer our main production platform (our use-case is a DCN), so I have no incentive to tinker with the current setup. Mark.

i run frr is-is. seems to work in the siple / classic way i run it randy

Separating Address Families and the Purpose of Address Families. Every time I come to read this thread, this point I'm going to comment on comes to mind, and I end up forgetting. I went back to the initial message of the thread to mention what I believe is important, which is separating address families according to their role within the network. From my point of view, in a network that is no longer so small, with several devices, it makes sense that Route Reflector services are separated according to their functions in the network. I like the model in which the base Address Families and the end-service Address Families are separated. The example I like to give most is to leave IPv4 and IPv6 Main, RT-Filter, private L3VPN, L2VPN VPLS, BGP-LU in one set of RRs. And VPNv4+VPNv6 for DFZ/Cache/PNIs, and FlowSpec in another set of RRs. Here in Bob's fantastic world, which is my brain, the role of EVPN is changing. But so far I see it within the first group of RRs. Even if you put these two types of RRs in the same box (because it's still too small to justify separating them), if you use different loopbacks for the two types of RRs... Separating them in the future to allow scaling becomes very simple. It's worth saying that I believe it's always better to improve the RR in Off-Path. Em ter., 2 de jun. de 2026 às 03:22, Tom Samplonius via NANOG < nanog@lists.nanog.org> escreveu:

Hi,

Is Free Range Routing (FRR) a viable choice for a pure BGP route reflector for a regional ISP with ~ 35 routers? A mix of L3VPN-MPLS and BGP-EVPN services. Full transit, plus some peering. About 5 x L3VPN instances, and maybe 500 x EVPN-MPLS instances.

I don’t see a lot of posts of people using FRR for RR. And not a lot of people reporting issues, so maybe it is just the perfect RR solution?

Tom

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/STLGD7H4...

-- Douglas Fernando Fischer Engº de Controle e Automação

Thanks Raymond, cursory look makes it look quite usable. There are purpose-built BGP libraries, but they're all more or less unmaintained, as they're not part of dog-fooding by building daemon around it, which seems crucial for survival. e.g. https://github.com/Nat-Lab/libbgp https://github.com/jeanmichel-gh/bgp4r https://github.com/wladwm/zettabgp (many many other, but none, afaik, anywhere near maturity of any of the daemons we've discussed) On Tue, 9 Jun 2026 at 07:54, Raymond Burkholder via NANOG <nanog@lists.nanog.org> wrote:

On 2026-06-04 01:59, Saku Ytti via NANOG wrote:

...

It boggles my mind that someone goes 'I'm going to write this very complex daemon' and then they proceed to write monolithic tightly coupled CLI+daemon+logic.

You may not think of them like Internet APIs, but there is a kind of tightly bound library access to FRR: https://docs.frrouting.org/projects/dev-guide/en/latest/library.html

FRR does have some hooks for customization. It also has a Lua scripting interface: https://docs.frrouting.org/projects/dev-guide/en/latest/scripting.html

There is an ability to add your own callback hooks, command line additions, ... and other stuff.

Link State API https://docs.frrouting.org/projects/dev-guide/en/latest/link-state.html

Northbound API https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northboun...

Zebra Neighbor API https://docs.frrouting.org/projects/dev-guide/en/latest/zebra-neigh-api.html

Mind you, all this access probably requires you have the FRR source code open, but given the complexity of the daemons and networking in general, this access is probably as close to API as possible.

...

So we have a huge collection of BGP implementations, as mentioned just here, frr, gobgp, bird, rustybgp, openbgp, exabgp and many many others. But we don't really have any BGP library approaching a similar maturity level. While to me it seems it should have been an obvious win for any project, to start day1 with decoupled library, cli and daemon as separate libraries, i see it reducing work day1 due to forcing more maintainability in design.

Then instead of using low performance, lacking or non-existing APIs in your automation, you could write your own BGP worker using the library to have superior flexibility and performance, and exactly the behaviour you want. Many things you cannot do at all, because you don't have a library, like fuzzing, the daemon won't allow you to do wrong/bad things.

https://docs.frrouting.org/projects/dev-guide/en/latest/fuzzing.html

...

So please, the next person planning to write BGP or whatever project they're thinking of, separate the logic and daemon. Thank you.

I'm not an FRR developer, just a satisfied user with a programming bent.

Raymond Burkholder https://blog.raymond.burkholder.net/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FHTU5M5O...

-- ++ytti