Support OSPF

[danderson]

OSPF would be an interesting addition to the protocol collection. In theory, speaking OSPF should be pretty simple, if we don't participate in the full link-state topology (i.e. we don't install routes, we are never on the path for any traffic except LB IPs...).

Step one is to read https://tools.ietf.org/html/rfc2328 and figure out if it's actually possible, and if so, how complex it is (do we have to support areas and other weird extensions?)

We will also have to support both OSPFv2 and OSPFv3 if we do this, for IPv6 support.

[foosinn]

I would love to see OSPF support. We have hardware that requires additional licenses for BGP, while OSPF is supported out of the box.

[mleklund]

A LOT of cisco equipment can do OSPF out of the box but they want a plus license for BGP. I suspect many of us might like this feature.

[danderson]

I understand that OSPF support would be handy, but I don't have the time to implement this myself right now. The issue is open so it's in the backlog of stuff to do, but I'm a solo developer and I can't prioritize this right now.

[mleklund]

Not a complaint!! You are doing great work, just wanted to chime in on the wish list.

[aojea]

I don't think that link-state routing protocols like OSPF are suitable for these scenarios, it's better to use distance vector protocols. If the problem is about licenses, it will be better and simpler to implement RIP.
@danderson is ok to change the title to Support RIP or is it better to create a new issues

[vaizki]

The only reason I want OSPF support is because BGP does not officially (as in RFCs etc) support ECMP load-balancing where two equal cost routes can be added by BGP into the routing table. I know some (many?) vendors have proprietary ECMP modes for BGP but my network can't do it without swapping a lot of gear. So all the traffic to a certain LB IP always goes through a single k8s node right now even though there are multiple nodes announcing the IP.

RIP doesn't do ECMP either so doesn't help me at all. OSPF does ECMP very well but I understand fully that it is not a natural protocol for metallb.

[aojea]

@vaizk do you mean that if your routers receive 2 routes with the same weight using BGP or RIP, they only install one of those routes in the routing table?
But, if those routes are learned using OSPF, those 2 routes are installed in the routing table?

[vaizki]

@aojea yes, exactly like that. This is also the correct behaviour according to OSPF, BGP and RIP specifications.

• OSPF will install both routes and do equal cost multiplath (ECMP) routing over them = loadbalance
• BGP will install one of the routes and stick with it, with the final tie-breaker being the IP address of the peer router
• RIP will either stay with one route or sometimes switch, depending on the implementation and how timers happen to coincide. But it will not use both routes at the same time

[aojea]

@vaizki thanks for the clarification, sometimes one is so used to the vendor's implementations that forget these things :)

OSPF seems complex to implement ... but RIP seems simple.

What about announcing the route using both protocols so the router can learn it via RIP and BGP, I think that configuring the same weight you will have ECMP... or maybe I'm overcomplicating this.

[vaizki]

One workaround we considered (but have not tested yet) is to run a local BIRD daemon on every node so that metallb would talk BGP to the local daemon which would then redistribute BGP routes via OSPF to core. I hope to get around to testing that soon.

[mleklund]

I was wondering if running bird or quagga as part of metallb for the routing portion might be a possibility. It seems like it might make make long term maintenance easier as well, as someone else is maintaining the routing protocols.

[danderson]

Historically, depending on a third-party implementation makes both implementation and troubleshooting harder, because the daemons are not designed for programmatic interfacing, so you end up with opaque behavior combined with blind config generation. Not to mention that as soon as you add a massive routing daemon, there's a combinatorial explosion of possible configurations, and people want ~all of them. Troubleshooting is hard enough as it is with the combinatorial explosion of k8s config options, without adding in a routing daemon with arbitrary configuration as well :(

[mleklund]

fair enough

[q3k]

I would also like for metallb to be able to talk OSPF to my ToR switches (Dell PC M6220 in an M1000e enclosure), as that switch only support OSPF and RIP. [1]

I'll be willing to help prototype and/or implement this in metallb. I was thinking of using https://github.com/bio-routing/bio-rd , but OSPF is not supported there yet - so that would be the first thing to sort out (not sure if rolling OSPF from scratch in metallb is very wise).

[1] - Interestingly, looking at firmware strings shows that BGP support is there somewhere, possibly just disabled behing a service command. There's no licensing scheme for that device, so it's not about that either.

[laoshancun]

LGTM.

[blackliner]

Since metallb uses FRR, shouldn't OSPF be supported out the box?

[fedepaol]

I am going to close this. I am open to discuss a design proposal for OSPF support, but it's not something it's being requested by users. With FRR as a backend, the support could be added without having to imlpement the protocol by ourselves, but some code is still required (plus docs, api, e2e).