BGP as an SDN?
A Russ White Blog
BGP as an SDN? Clearly this must be some sort of mistake! Or maybe not. Consider, for a moment, the following network:
Assuming A and B are peered using eBGP (not in the same autonomous system), and the remaining routers are configured using iBGP, so they’re all in the same AS. An out of band route reflector, marked RR on the diagram, reflects BGP routes learned at B to the remaining iBGP speakers, so they have the correct routing information to forward traffic from A to F, and from F to A.
Just within this diagram, the similarity between a centralized SDN’ish control plane and BGP using a route reflector is fairly obvious. There is, in fact, what might be called a controller in the form of a route reflector. While the routes between the routers within the AS are learned through some other means—normally an interior gateway protocol, such as IS-IS—external reachability is learned via the RR.
Now consider the two dashed lines overlaid onto the network diagram. The default path through the network—for instance, based on the internal metrics—will pass through Router C. For some reason, the network operator would like traffic being forwarded from A, towards F, to pass through D instead. How can this be accomplished? Using the RR as a sort of controller, there are many methods available within BGP. For instance—
- The RR could send a route to B which contains a flowspec rule pushing A->F traffic into a preconfigured tunnel passing through D (such as an MPLS tunnel)
- The RR could send A only a path with a next hop of D, and not the path with a next hop of C, to B
- The RR could send a route to B which contains a segment header with a label stack or loose source route that directs the traffic through D, rather than C
There are probably a dozen other ways to influence the path in this situation using a route reflector in BGP. Each of these methods have advantages and disadvantages; for instance, flowspec and segment routing can classify traffic based on the source address, or other fields in the packet header, while modifying just the destination will modify the flow for every packet destined to F. But what’s interesting here is not the specific mechanisms used and their limitations, but rather that the RR can be treated as a controller which modifies the base BGP routing information using only mechanisms available within BGP itself.
This situation can also be played out with each of the routers in the diagram being configured into a separate AS, so all the BGP peering relationships are eBGP. In this case, the RR can still act as a controller of sorts by injecting influence iBGP routes into the local BGP processes. This does take a bit more work, as eBGP routes are normally preferred over iBGP routes, but it is possible to prefer routes learned through iBGP over routes learned through eBGP in most implementations.
How would BGP fit into the two classification mechanisms discussed so far in this series? The first of these is considering where the mechanism “touches” the device, or perhaps where the Application Programming Interface (API) lives on the device, as shown in the illustration below.
In this model, BGP as an SDN “touches” the network device at the “processes,” just above the RIB, and just below the configuration management. This has some advantages, most notably—
- Most networks already deploy and (at least to some degree) understand BGP; overlaying BGP as an SDN into an existing network is, then, generally not all that difficult
- BGP has a ton of ways to influence traffic; after all, its primary function is to act as a policy distribution system, rather “just” distributing reachability information
Along with these advantages, however, there is at least one disadvantage—BGP has no knowledge of what is going on in the RIB or FIB. Routes installed by the BGP process can be overridden by other processes, including other routing protocols and/or manually configured (static) routes. There is no way for BGP to know what is actually installed or not. This could lead to routing loops, policy that’s not applied the way the operator thinks it is being applied, etc. The only way t resolve this is to have some sort of “back channel” between the RIB and the controller (or rather the route reflector acting as a controller) to see track what is actually installed in the RIB.
There is another dimension to classifying SDN solutions, as well—the split between policy and reachability. BGP as an SDN can actually fit into this classification in one of three ways—
- Without the “controller,” or if the “controller” is just sending reachability information, then BGP would be combining policy and reachability in the control plane
- If there is a “controller” that is overriding some best path calculations for policy reasons, but leaving other policies carried within BGP in place, this could be considered a sort of hybrid mode (or more generally a disaster going someplace to happen)
- If there is a “controller” that is injecting all policy, such that communities, etc., are simply not being carried in the underlying BGP, this could be considered another form of hybrid mode
BGP is an interesting test case of the classification systems discussed in the prior posts in this series; the classifications do seem to allow us to more fully understand how and where BGP might be configured, and what some of the advantages and limitations of using BGP as an SDN solution might be.
Next time, we’ll consider a “real” SDN solution.