Central Control – OSPF SDN
The source for this blog post is taken from Ivan Pepelnjak’s Software Gone Wild Podcast on Fibbing and various publications from Laurent Vanbever. Laurent is an assistant professor at ETH Zürich and has some interesting publications found at this link.
The success of SDN makes it clear that operators want to manage networks in a centralised and programmable way. Operating with a central viewpoint brings many advantages to existing networks, especially enhancing the traffic engineering capabilities. However, changing the network paradigm with brand new technologies comes at a cost, both from an operational and security perspective. Fibbing is an OSPF SDN mechanism that controls the forwarding behaviour of any unmodified router speaking OSPF, without losing the benefits of distributed routing protocols. It combines the centralised approach of SDN with the advantages of traditional link state protocols. The workings originate from a combined approach between Princeton university and ETH Zurich. The controller code is available as an open-source code available on Github, found at this link.
Fibbing is a technique that offers direct control over the router’s’ forwarding by manipulating the distributed routing protocol. The solution works on the concepts of lying or fibbing to the router, in order for them to make more effective routing decisions. They make OSPF more flexible by adding central control over distributed routing. OSPF operates as normal with shortest path routing and Fibbing introduces methods to trick the router to compute any path that it wants.
OSPF is still destination based forwarding, meaning, a device will forward all packets with the same destination address to the same next hop. Paths are computed as a shortest-path over a shared weighted graph. The Fibbing mechanism does not try to change OSPF default behaviour. However, the mechanisms involved in the solution enable the forwarding of different flows destined to the same destination over different paths, increasing link utilization and the total available bandwidth. The controller introduces fake nodes and links through standard routing-protocol messages.
How can I program my network with SDN using existing protocols?
Routing protocols are an excellent API for programming router’s state. Vendors may incorporate different implementations and CLI context but they all speak the same protocol and follow RFC guidelines. Routing protocols are well known and their behaviours have been studied for years. OSPF has been enhanced and optimized differently by vendors but its framework does not change. By using OSPF in the context of SDN you are leveraging over 25 years of solid engineering.
The concept of combining SDN with existing routing protocols to enhance forwarding behaviour is not new. The first solution was the routing control platform (RCP), proposed by Princeton University and AT&T Labs-Research. The RCP solution has both an IGP viewer and a BGP function, used to provide a central function. More recently P. Lapukhov & E. Nkposong proposed a centralized routing model and introduced the concept of BGP SDN. Petre solution uses a BGP controller to manipulate BGP parameters (Local Preference) and influence forwarding. It enables networks to run only BGP routing with enhanced traffic behaviour.
How do you move traffic over a less congested link?
With OSPF-TE, you can change the cost or deploy some other 3rd party product, which is potentially expensive. If you want to change the forwarding state and don’t want to configure complex nested route maps or policy-based routing (PBR), the only remaining resource available to you is the routing protocol. Fibbing is limited to the semantics of OSPF destination based forwarding and is obviously less powerful than traffic optimizations with OpenFLow. You can change the forwarding paths for certain prefix but you don’t have the full traffic engineering flexibility of OpenFLow. But you can use the solution in combination with FlowSpec to gain extra granularity.
How does it work?
There are two ways to lie to a router; we have a Global lie and a Local lie.
Fibbing inserts extra Type-5 LSA that allows you to set a third party next hop with the Forwarding Address (FA) feature. Type-5 are external link LSAs used to advertise external routes. They are flooded through the whole OSPF domain and point packets for those external addresses. There is the concept of an FA within a Type-5 LSA, allowing the selection of third-party next hops. The solution relies on third-party next hops to influence packet forwarding.
The FA is usually set to 0.0.0.0, meaning packets should be sent directly to the ASBR. In a Fibbing configured network, Type-5 LSA is injected with an FA to direct traffic to the destination with a better cost; the forwarding address is set with a specific address combined with a preferred metric. The costs can be tweaked to attract more or less people.
There are two ways to influence forwarding with Type-5 LSA. One way is where the forwarding address is resolvable by ALL routers in the network. The FA is injected into the IGP and all nodes can reach it. This method is used to make global decisions. The other method is to have an FA that is known locally, influencing individual OSPF router decisions. For this, they create an FA for every next hop in the network, which has to be statically configured. On every router on your network, you need a static host route for each outgoing interface that you need to include for Fibbing. One fake static route per interface and this needs to be done once. If the FA is configured to be one of these then only that single router will use it.
The benefits of using a Type 5 LSA does not cause a full SPF, it’s the distance vector part of OSPF. The impact is small and linear with the number of LSA. The team at Princeton and Zurich propose the Fibbing solution can scale to 100,000’s of Type-5 LSA’s.