Fibbing and SDN
Another SDN Blog by Russ White
The last post on the topic of SDNs discussed BGP as a southbound interface to control policy. This form of SDN was once common in hyperscale data centers (though not as common as it once was). In our pursuit of out of the way (and hence interestingly different) forms of SDNs (hopefully this series will help you understand the scope and meaning of the concept of SDNs by examining both common and uncommon cases), it’s time to look at another unusual form of policy injection—Fibbing. In fibbing, a centralized controller engineers traffic flow in a link state network by interacting with the control plane directly, rather than interacting with the forwarding plane or the RIB.
To return to the device model described in a previous post—
Providing labels for the various interaction points might be helpful in slicing and dicing the various SDN options out there. To wit—
- Interacting with the configuration, or management, is not really considered an “SDN” in most circles. This is primarily because “it’s always been done this way,” or perhaps simply that “screen scraping” by automating what human operators have always done to inject policy into a network doesn’t “feel like” SDN.
- Interacting with routing processes that build the forwarding information used by network devices can be called an augmented model. The BGP as an SDN solution discussed in the last post would fall into this category, as will fibbing, considered here.
- SDN solutions that interact with the RIB can be considered a hybrid model, as they allow the distributed control plane to operate normally, while also allowing a controller to directly control the routing information on which forwarding information is built.
- SDN solutions that interact with the FIB can be considered a replacement model, as most of these solutions replace the entire distributed control plane with a centralized one.
With these classifications in mind, what is fibbing, and how does it work? The following pair of networks will be used for illustration.
In this network, the traffic flowing from A to 2001:db8:3e8:101::/64 will pass through A->C, bypassing B (using link costs as marked in the illustration). The A->B link, however, is overwhelmed, so the network administrator would like to load balance the traffic destined to 2001:db8:3e8:101::/64 between the path A->B->C and A->C without changing the link metrics in the network.
Fibbing proposes a different solution. A controller that is able to “speak” OSPF (assuming OSPF for the moment), and hence is able to inject new OSPF LSA into the network, is connected to the network. This controller creates a “fake” node in the network by injecting a new LSA, shown in the lower network as G. The two links G->D and G->E can be set to a metric that draws traffic across the apparent fake link. In this case, the two fake links are set to a cost of 25, which means D now has two equal cost links through both D->E and E->E->F, and hence will load share the traffic over the two paths.
With some clever manipulation, fibbing can actually adjust the path to one destination without impacting other destinations, making it possible to fine-tune traffic through the network without using tunneling or other traffic engineering techniques. Fibbing, like using BGP as an SDN, is an example of an augmentation form of SDN; a controller interacts directly with the distributed control plane to modify traffic flows through the network. For more information on fibbing, see http://fibbing.net.
In the next post, we’ll look at an SDN interface that is more familiar: OpenFlow