OpenBSD Journal

c2k15: renato@ on ldpd(8), eigrpd(8) progress

Contributed by pitrh on from the multiply my tunnels dept.

Our next c2k15 report comes from Renato Westphal (renato@), who writes,

This was my first OpenBSD Hackathon and it was a very pleasant and productive experience for me. I went to Calgary with two specific goals in mind. The first was to work with rzalamena@ to finish our VPLS implementation that we started long ago.

I implemented the pseudowire signaling on ldpd(8) and Rafael implemented the mpw(4) virtual interface that encapsulates ethernet frames into MPLS tunnels. The hackathon was the perfect opportunity for us to put everything together and make it work. We spent a lot of time doing interoperability testing and fixing the bugs that cropped up in more complex usage scenarios. After several tests we realized that our implementation was complete and we had some time to look into other things.

My second goal was to make progress with my EIGRP implementation that I started a couple of months ago. EIGRP is an advanced distance-vector routing protocol designed and developed by Cisco Systems in the 90s and that it's known for it's fast convergence time and for being simple to deploy. In my opinion EIGRP is a great routing protocol but the fact that it was Cisco's proprietary made a lot of network engineers to switch to OSPF even when EIGRP would make more sense. The good news is that in 2013 Cisco submitted an IETF Internet Draft for EIGRP and a IETF RFC is about to be released in this year. EIGRP will continue to be a proprietary protocol but it's specification will be open for anyone interested in implementing it. I decided to work on this because I think that EIGRP is a very interesting routing protocol and it can also help many OpenBSD users to deploy an OpenBSD box in a predominantly Cisco network. Besides the great progress made during the hackathon, eigrpd(8) is still missing some important bits like IPv6 and route redistribution support. The basic functionalities are already in place but I decided to wait and release eigrpd only when I finish all the major features. Unfortunately eigrpd won't make it into OpenBSD 5.8 but it will certainly be available in OpenBSD 5.9.

Finally, I had a lot of fun in Calgary. It was great to meet face to face developers that I long admired for their work and that inspired me work with open source software. Thanks to Nayden, the OpenBSD Foundation and Theo for organizing this great event!

Thanks for the report and the work it describes, Renato! Here's yet another reason to look forward to future versions.

(Comments are closed)

Comments

  1. By Dan (64.191.222.109) on

    Thanks for your work on EIGRP.

    You are right about OSPF being used mostly just because EIGRP isn't/wasn't open.

    Comments

    1. By Anonymous Coward (5.148.132.132) on

      > You are right about OSPF being used mostly just because EIGRP isn't/wasn't open.

      No, OSPF is a link-state protocol that distributes a topology. EIGRP is more similar to a distance-vector protocol that gives you no indication of actual path, meaning it's less useful for things like MPLS.

      AOTBE, OSPF and IS-IS are far superior protocols that don't come with all the Cisco baggage.

      Comments

      1. By Dan (50.184.58.48) on

        There is nothing keeping you from running MPLS with EIGRP or even RIP. LDP should advertise a label for any non BGP route.

        MPLS-TE is a different story, and requires OSPF or ISIS.

        - EIGRP is less CPU intensive and so you can have more neighbours, and it doesn't really care about how many routers are in an area (as there are no areas).
        - No need to run Dijkstra (or wait for LSA pacing) on every intra area change.
        - With EIGRP you can summarize anywhere you want.
        - With EIGRP neighbour relationship are created way faster than OSPF.
        - With EIGRP you can filter routes anywhere you want. With OSPF only ABRs and ASBR can filter routes.
        - With EIGRP you are more flexible regarding your routing design, as you don't have to design areas.

        All in all, all have a place. Personally, I'll go with EIGRP for enterprise networks.

        One more small thing. OSPF RFC is 244 pages long, and EIGRP is just 63 pages long.


        Comments

        1. By Renato Westphal (177.18.147.172) renato@openbsd.org on

          Exactly, there's no one-size-fits-all solution when it comes to routing protocols. OSPF is in general more powerful than EIGRP but I wouldn't say it is "superior". In many scenarios OSPF complexity is unnecessary and EIGRP would do a better job while keeping thing simple. And simplicity is good, we all know this. One additional advantage of EIGRP is that it is the same protocol for both IPv4 and IPv6, and these days that's something to consider.

  2. By Blake (62.74.24.239) on 2112.net

    Thanks so much for introducing these new protocols. Couple of questions:

    - do you think there's potential for OpenBSD to get a BGP-signalled VPLS implementation?

    - is Crisco's EIGRP patent-encumbered?

    I'm an IS-IS proponent myself but I realize that EIGRP use is more widespread & it doesn't require supporting a new address family in order to implement. Looking forward to kicking the tires on it.

    Comments

    1. By Renato Westphal (177.18.147.172) renato@openbsd.org on

      > Thanks so much for introducing these new protocols. Couple of questions:
      >
      > - do you think there's potential for OpenBSD to get a BGP-signalled VPLS implementation?

      Hi Blake,

      Yes, but implementing VPLS signaling and autodiscovery on bgpd(8) is not at the top of my todo list. After finishing eigrpd(8) I want to implement IS-IS and RSVP-TE, not sure which one first.

      For sure it would be a great addition to OpenBSD, in my opinion the BGP approach to VPLS is far superior and in the future it should be the de-facto standard solution. But nowadays the LDP signaling is more widespread, especially in small deployments where OpenBSD use is more common.

      > - is Crisco's EIGRP patent-encumbered?
      >
      > I'm an IS-IS proponent myself but I realize that EIGRP use is more widespread & it doesn't require supporting a new address family in order to implement. Looking forward to kicking the tires on it.

      Well, the EIGRP draft is informational and Cisco stills holds complete control over the protocol. So, EIGRP is still proprietary and there are potential problems with releasing an EIGRP implementation under the BSD license. I will reach out to Donnie, author of the EIGRP draft, and ask about his opinion on this.

      If you are interested on eigrpd(8) you can take a sneak peek here before it is released: https://github.com/rwestphal/openbsd-eigrpd

      Comments

      1. By Blake (62.74.24.177) on 2112.net

        Thanks!

        While we're on the subject of BGP-based MPLS signalling, do you think OpenBSD could get a BGP labeled unicast (RFC3107) implementation? If you've already got BGP in your network it makes a basic MPLS implementation a piece of cake. It's also really nice for rolling out lots of MPLS-speaking hosts at the edge of the network as EBGP-LU doesn't require an IGP to get MPLS working.

        Best regards.

      2. By Blake (62.74.24.177) on 2112.net

        > Yes, but implementing VPLS signaling and autodiscovery on bgpd(8) is not at the top of my todo list. After finishing eigrpd(8) I want to implement IS-IS and RSVP-TE, not sure which one first.

        Can I make a crazy suggestion? (feel free to ignore it)

        I realize that interop is more limited at the moment, but in terms of the amount of work necessary to get to a working MPLS TE implementation from the current state, it may be easier for you to get a basic RFC5543 BGP TE or draft-ietf-idr-ls-distribution implementation working. Theoretically this could even use EIGRP as the IGP :-).

        Comments

        1. By Renato Westphal (177.18.42.125) renato@openbsd.org on

          Hi Blake,

          Thanks for the suggestions. I didn't know about RFC5543, but as you said it's not widely deployed now so I don't see much value in implementing it. And RSVP-TE seems to be more fun to implement :)

          As for implementing labeled unicast on bgpd(8), I believe it should be something easy to do. bgpd(8) already has multi-protocol support, including the encoding of MPLS labels in the MP_REACH_NLRI attribute, so I think it's a matter of adding a new configuration option and a few more adjustments to make labeled unicast possible. Labeled unicast would also enable the dynamic creation of IPv6 tunnels over an IPv4+MPLS core, something Cisco calls the 6PE solution. That's a very neat feature. I'll look into this in the future as time permits.

          Comments

          1. By Blake (2.87.31.52) on 2112.net

            > Hi Blake,
            >
            > Thanks for the suggestions. I didn't know about RFC5543, but as you said it's not widely deployed now so I don't see much value in implementing it. And RSVP-TE seems to be more fun to implement :)
            >
            > As for implementing labeled unicast on bgpd(8), I believe it should be something easy to do. bgpd(8) already has multi-protocol support, including the encoding of MPLS labels in the MP_REACH_NLRI attribute, so I think it's a matter of adding a new configuration option and a few more adjustments to make labeled unicast possible. Labeled unicast would also enable the dynamic creation of IPv6 tunnels over an IPv4+MPLS core, something Cisco calls the 6PE solution. That's a very neat feature. I'll look into this in the future as time permits.

            Awesome.

            I was going to mention that BGP LU enables 6PE. This is a really good example of how it works: http://forums.juniper.net/t5/TheRoutingChurn/MPLS-ipv6-tunneling-for-6PE-and-6VPE-models/ba-p/180559

Latest Articles

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.]