06-04-2018, 08:52 PM
An Introduction to FRRouting
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2018/06/an-introduction-to-frrouting.jpg" width="1551" height="732" title="" alt="" /></div><div><div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2018/06/an-introduction-to-frrouting.jpg" class="ff-og-image-inserted" /></div>
<p>I recently learned about <a href="https://frrouting.org/">FRRouting</a> (FFR), an IP routing protocol suite for Linux and Unix platforms. FRR has been under rapid development since the first release in April 2017. So, they <a href="https://cumulusnetworks.com/blog/free-range-routing-anniversary/">just turned one</a>, and they recently released version 4.0 of the software. According to the website, this release brings various enhancements aimed at creating the best routing protocol stack available. </p>
<p>How did I not know about all this? Doubtless due to a personal defect. In any case, the contributors designed FRR to streamline the routing protocol stack. FRR can be used for connecting hosts, virtual machines, and containers to the network, for network switching and routing, and much more. Here’s what I learned about the excellent FRRouting project and how it came to be. </p>
<p>FRR has its roots in the Quagga project, <a href="https://www.linux.com/learn/intro-to-linux/2018/3/dynamic-linux-routing-quagga">which I covered here</a>. In fact, it started as a fork by some long-time Quagga developers who combined their efforts to improve on that project’s well-established foundation. </p>
<h3>Why Fork?</h3>
<p>Anyone can fork an open source project, which can be either an advantage or a disadvantage. A fork can double the workload, divide the contributor community, or make two “meh” projects instead of one great one. It can create hard feelings. Or, a fork can succeed, by reviving a moribund project and bringing new energy and enthusiasm. It can also rescue a code base from the clutches of a bad commercial steward. Forking a project is rarely done on a whim because it’s a such a big step.</p>
<p>Examples of successful forks include Ubuntu, forked from Debian (although arguments rage over whether it is really a fork or some other weird thing nobody can think of a word for), the LibreOffice fork of OpenOffice, and my favorite, the MariaDB fork of MySQL. </p>
<p>MariaDB is the all-time great “having your cake and eating it” story. The short version is Sun Microsystems bought MySQL for a cool billion dollars and hired the talent that built it. But the MySQL executive team, including Monty Widenius and Marten Mickos, were publicly unhappy with Sun. They left Sun, taking their billion dollars with them. Then Oracle bought Sun, which motivated Widenius to fork MySQL and found MariaDB, which has been a clear success. (A longer version is here: <a href="https://www.linux.com/news/migrating-mariadb-mysql">Migrating to MariaDB from MySQL</a>.)</p>
<h3>Why Fork Quagga?</h3>
<p>Quagga was created as a fork of the GNU Zebra project, which had died. So, FRR is a fork of a fork. I asked on the FRR developer’s mailing list about this and received a wealth of interesting answers. (You can read the whole thread on the <a href="https://lists.frrouting.org/pipermail/dev/2018-April/thread.html">dev list archive</a>.)</p>
<p>Here’s what people said:</p>
<p>“There was a desire for a project that was governed by community consensus and documented process.”</p>
<p>“I find the FRR community very welcoming, very friendly, extremely helpful and respectful. It is very rare I come across communities like this and it is a real pleasure to engage in conversation and work on issues with them. If one needs a few eyes on a bit of code all you have to do is ask and you get constructive input, almost all of the time from multiple people.”</p>
<p>“The easy and pleasant direct access to the developers is a great bonus.”</p>
<h3>Community-driven development</h3>
<p>There was a point in time where Quagga was running on a skeleton crew, and thousands of patches were backed up from a variety of contributors, sitting, aging, and going nowhere. Thus, working through the backlog and creating a fast-paced, community-oriented project governed by consensus and documented process are some of the primary FRR drivers. A lot of the work on FRR is devoted to implementing new protocols and features, including cloud networking technologies. </p>
<h3>Governance</h3>
<p>Governance is also a necessary part of any OSS project, and it can make or break a project. FRRouting managed this by joining the vendor-neutral Linux Foundation, which is home to many important projects including the Node.js Foundation, Let’s Encrypt, and of course the Linux kernel.</p>
<p>FRRouting has a six-member technical steering committee, and members are elected to one-year terms. Maintainers have regular open meetings, and there is an official charter. This governing structure helps the project handle the numerous issues that any large, complex, and essential software project has to deal with, such as development direction and priorities, differences of opinion, licensing, finances, and so on.</p>
<h3>Getting and Using FRR</h3>
<p>FRR is hosted on GitHub. You may clone the repository, download source tarballs, or download .deb and .rpm packages. The documentation is quite good, and there is detailed information on becoming a contributor. The <a href="https://frrouting.org/user-guide/overview.html#about-frr">FRR user guide</a> also provides a great overview of the architecture.<br />Visit <a href="https://frrouting.org/">FRRouting</a> to learn more about the project. Also check out <a href="https://forums.juniper.net/t5/Automation-Programmability/FRRouting-on-Juniper-s-Advanced-Forwarding-Interface/ba-p/318708">FRRouting on Juniper’s Advanced Forwarding Interface</a> for an interesting example of where FRR is already finding a home in advanced networking architectures. </p>
</div>
<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2018/06/an-introduction-to-frrouting.jpg" width="1551" height="732" title="" alt="" /></div><div><div><img src="http://www.sickgaming.net/blog/wp-content/uploads/2018/06/an-introduction-to-frrouting.jpg" class="ff-og-image-inserted" /></div>
<p>I recently learned about <a href="https://frrouting.org/">FRRouting</a> (FFR), an IP routing protocol suite for Linux and Unix platforms. FRR has been under rapid development since the first release in April 2017. So, they <a href="https://cumulusnetworks.com/blog/free-range-routing-anniversary/">just turned one</a>, and they recently released version 4.0 of the software. According to the website, this release brings various enhancements aimed at creating the best routing protocol stack available. </p>
<p>How did I not know about all this? Doubtless due to a personal defect. In any case, the contributors designed FRR to streamline the routing protocol stack. FRR can be used for connecting hosts, virtual machines, and containers to the network, for network switching and routing, and much more. Here’s what I learned about the excellent FRRouting project and how it came to be. </p>
<p>FRR has its roots in the Quagga project, <a href="https://www.linux.com/learn/intro-to-linux/2018/3/dynamic-linux-routing-quagga">which I covered here</a>. In fact, it started as a fork by some long-time Quagga developers who combined their efforts to improve on that project’s well-established foundation. </p>
<h3>Why Fork?</h3>
<p>Anyone can fork an open source project, which can be either an advantage or a disadvantage. A fork can double the workload, divide the contributor community, or make two “meh” projects instead of one great one. It can create hard feelings. Or, a fork can succeed, by reviving a moribund project and bringing new energy and enthusiasm. It can also rescue a code base from the clutches of a bad commercial steward. Forking a project is rarely done on a whim because it’s a such a big step.</p>
<p>Examples of successful forks include Ubuntu, forked from Debian (although arguments rage over whether it is really a fork or some other weird thing nobody can think of a word for), the LibreOffice fork of OpenOffice, and my favorite, the MariaDB fork of MySQL. </p>
<p>MariaDB is the all-time great “having your cake and eating it” story. The short version is Sun Microsystems bought MySQL for a cool billion dollars and hired the talent that built it. But the MySQL executive team, including Monty Widenius and Marten Mickos, were publicly unhappy with Sun. They left Sun, taking their billion dollars with them. Then Oracle bought Sun, which motivated Widenius to fork MySQL and found MariaDB, which has been a clear success. (A longer version is here: <a href="https://www.linux.com/news/migrating-mariadb-mysql">Migrating to MariaDB from MySQL</a>.)</p>
<h3>Why Fork Quagga?</h3>
<p>Quagga was created as a fork of the GNU Zebra project, which had died. So, FRR is a fork of a fork. I asked on the FRR developer’s mailing list about this and received a wealth of interesting answers. (You can read the whole thread on the <a href="https://lists.frrouting.org/pipermail/dev/2018-April/thread.html">dev list archive</a>.)</p>
<p>Here’s what people said:</p>
<p>“There was a desire for a project that was governed by community consensus and documented process.”</p>
<p>“I find the FRR community very welcoming, very friendly, extremely helpful and respectful. It is very rare I come across communities like this and it is a real pleasure to engage in conversation and work on issues with them. If one needs a few eyes on a bit of code all you have to do is ask and you get constructive input, almost all of the time from multiple people.”</p>
<p>“The easy and pleasant direct access to the developers is a great bonus.”</p>
<h3>Community-driven development</h3>
<p>There was a point in time where Quagga was running on a skeleton crew, and thousands of patches were backed up from a variety of contributors, sitting, aging, and going nowhere. Thus, working through the backlog and creating a fast-paced, community-oriented project governed by consensus and documented process are some of the primary FRR drivers. A lot of the work on FRR is devoted to implementing new protocols and features, including cloud networking technologies. </p>
<h3>Governance</h3>
<p>Governance is also a necessary part of any OSS project, and it can make or break a project. FRRouting managed this by joining the vendor-neutral Linux Foundation, which is home to many important projects including the Node.js Foundation, Let’s Encrypt, and of course the Linux kernel.</p>
<p>FRRouting has a six-member technical steering committee, and members are elected to one-year terms. Maintainers have regular open meetings, and there is an official charter. This governing structure helps the project handle the numerous issues that any large, complex, and essential software project has to deal with, such as development direction and priorities, differences of opinion, licensing, finances, and so on.</p>
<h3>Getting and Using FRR</h3>
<p>FRR is hosted on GitHub. You may clone the repository, download source tarballs, or download .deb and .rpm packages. The documentation is quite good, and there is detailed information on becoming a contributor. The <a href="https://frrouting.org/user-guide/overview.html#about-frr">FRR user guide</a> also provides a great overview of the architecture.<br />Visit <a href="https://frrouting.org/">FRRouting</a> to learn more about the project. Also check out <a href="https://forums.juniper.net/t5/Automation-Programmability/FRRouting-on-Juniper-s-Advanced-Forwarding-Interface/ba-p/318708">FRRouting on Juniper’s Advanced Forwarding Interface</a> for an interesting example of where FRR is already finding a home in advanced networking architectures. </p>
</div>