OpenBSD Journal

Interview: Renato Westphal (renato@)

Contributed by tbert on from the endless-network-loop-in-6-hops dept.

Renato Westphal (renato@) recently agreed to answer some questions in the wake of committing eigrpd(8):

First off, thanks for agreeing to this interview. Tell us a little about yourself, your technical background, and how you came to the OpenBSD project.

My name is Renato Westphal and I was born and live in the south of Brazil. Currently I work for Taghos Tecnologia developing web cache and CDN solutions and in my previous job I worked for a small network equipment manufacturer, which is where my background in routing protocols comes from.
My history with OpenBSD started around 2011 when I was still an undergrad student working part-time on an University-Industry partnership program. In this job I was assigned the task of implementing a full (!) MPLS solution for Linux and that task encompassed having a working implementation of the LDP protocol, among several other things. I started then looking for an open source implementation of LDP and found out that OpenBSD had a daemon called ldpd(8). I decided to check it out and it was love at the first sight when I saw its code: it was beautiful! I started then porting this daemon to Linux and on top of that fixed quite a few bugs. Two years later I decided that it would be fair to contribute my fixes back to the original implementation, it was when claudio@ invited me to join the OpenBSD team. Around that time I didn't know much about OpenBSD and was surprised with the invitation. Theo de Raadt sent me a couple of emails and I had no clue about who he was. Nevertheless, I was excited with the invitation and started to follow the mailing lists and even bought a book about OpenBSD. Within a couple days I was hooked on it and OpenBSD became my OS of choice.

You've done work on MPLS and EIGRP; how much of that is related to your need or desire to run OpenBSD in place of closed vendor solutions, and has it allowed you to replace vendor hardware?

Well, I don't administer any network, I work full time as a programmer. I have some friends however that succeeded replacing closed vendor solutions with OpenBSD boxes and that for sure motivates me to keep doing what I'm doing. My biggest motivation, however, is the challenge of resolving complex problems writing trivially simple code that is both secure and efficient.

You've said previously that you think EIGRP is an interesting protocol, and that an upcoming RFC allows any interested party to develop their own implementation. For those who may not be networkers, what makes it interesting enough for you, beyond interoperating with existing cisco infrastructures, to spend the time coding and deploying and how does it compare to OSPF?

I think that, from a Computer Science perspective, EIGRP is very interesting because of the use of DUAL, the algorithm used to find the best routes in a network. It uses the concept of diffusing computation where only the routers that are affected by a topology change need to participate in the convergence process. It's very different from link state protocols like OSPF where a single topology change forces all routers in the network to rerun the SPF algorithm. Of course this is an oversimplification, in OSPF there's the concept of areas that can be used to segregate a network and reduce the number of SPF runs, but you get the idea. DUAL was developed at SRI International and the math behind it is just impressive, understanding how it works was certainly the most valuable experience I got from implementing eigrpd(8). Now, from a network engineering perspective, EIGRP is interesting because it is easy to deploy and troubleshoot, has good scaling properties and very quick convergence times. I'm not going to compare it against OSPF because I don't want to start another EIGRP vs OSPF debate. Both are great protocols and I think that people should use whatever fit their needs. If there was a single protocol that was better than the others in all aspects, the others wouldn't exist anymore. I'm happy now that OpenBSD users are in the privileged position of choosing whichever they want.

How do you test interoperability with different vendors, in general?

During development I prefer to use a virtual environment over real gear because it's much more convenient to me. Nowadays several vendors are offering virtual machines that are full blown versions of their products, like the Cisco CSR 1000V and Juniper vMX software routers. The unlicensed version of these VMs have a throughput limitation that is generally low but enough to test routing protocols and a few other things. The nice thing about using a virtual environment is that it allows for much more flexibility in your tests. For example, if you want to add a new link or router in your testbed it's just a matter of a few seconds to do it, no need to waste time plugging physical cables or buying additional expensive hardware. Besides that, it's much easier to sniff packets between any pair of routers and you can even inject delay and jitter to simulate bad links. For sure testing interoperability in real networks in important too, and fortunately I have some friends that do it for me, but most of my tests are done in a virtual environment.

You've also mentioned wanting to work on IS-IS and RSVP-TE. Have you been able to find time to start that work?

Implementing these protocols is an old wish of mine, IS-IS in particular seems to be a lot of fun. I don't want to promise anything though. These protocols are significantly more complex than EIGRP and implementing them from scratch is a very time demanding task. For now on I'll more likely focus on improving the routing daemons that we already have and start a new "big" project only when I feel like I need a new challenge.

Other than support for individual protocols, what do you think is missing from routing in OpenBSD?

I think that OpenBSD is already very well equipped in this area, and I say that because we know about tons of people using OpenBGPD and OpenOSPFD in production networks. But I'd like to see more cutting edge developments in OpenBSD. For example, implementing new features and protocols while they are in their draft stage in IETF. I'd like to see OpenBSD as the reference platform for the development of new routing and networking technologies in general. I know it sounds a little utopian but it may become a reality in the future as more and more people know the quality of the OpenBSD network daemons and the system as a whole.

Have you worked with any other open-source projects, and if so, how has the experience compared? Has it been hard to adapt or to switch between them?

Yes, I was a maintainer of the MPLS-Linux project not long ago and I also contributed to a few other open-source projects, but nothing really relevant. For me the experience of working with open source is always positive, it's always exciting to receive an email from someone who lives overseas thanking you for your work on a project. Nowadays, however, I tend to devote most of my hacking time to OpenBSD because I love its community and the philosophy behind the project.

Thanks again for taking the time to answer our questions

Thanks for the interview; it was a pleasure for me.

(Comments are closed)


Comments
  1. By Blake (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) on 2112.net

    Awesome work Renato!

    My humble feature requests are:

    Labeled ARP:
    https://tools.ietf.org/html/draft-kompella-mpls-larp-04
    https://www.glif.is/meetings/2014/tech/kompella-labelled-arp.pdf

    RFC3107 BGP labeled unicast:
    http://goo.gl/9T3okh

    Had some interesting discussions about these with Phessler at RIPE71 last week...

  2. By Anonymous Coward (2a01:e34:ec06:8f90:cabc:c8ff:fedb:4d83) on

    IS-IS is my preferred IGP; don't forget the "dash" so it's not Da'esh...

    <grin>

  3. By Anonymous (2001:470:1f07:1af:cc64:a4ea:a22d:16c0) on

    Thanks for the nice interview. What tools do you use to inject delay and jitter in your virtual environment?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]