Can SDN controllers inject or delete routes in a router?

Question

I have seen that some SDN controllers implement a BGP plugin in their architecture (for instance, Opendaylight). But, since controllers do not sent or route packets, I wonder how and if they can update the routes or paths present in any router. Otherwise, what would be the purpose to have such BGP plugins?

Answer 1

SDN is anything but a standard. So it is possible that some SDN implementations allow to inject / delete routes while other don't.

BGP is one routing protocol among many. A router learn routes from directly connected networks, static routes and routing protocols.

A SDN controller should at least able to add or remove static routes.

A SDN BGP feature could be simply a BMP plugin that allow the controller to view BGP routes.

Answer 2

Having an out-of-path router inject a route into another BGP speaker is quite common - consider the way a route-reflector works - they are often BGP daemons running on servers with no transit traffic.

In fact an RR is probably a good analogy for an SDN controller - it receives all paths, computes the best from it's point of view, then advertises this to all it's clients.

Answer 3

Let's forget about SDN for the moment, and consider what happens in a traditional router. There is some software that looks at the BGP configuration and also the BGP information from peers, and reaches some conclusion about what prefixes must be forwarded to what interface. Now the same router may also have other routing protocols running simultaneously, and there may be some statically configured routes as well.

The router "distills" the information coming from these disparate sources (routing protocols, static routes and others) and comes up with a final "Forwarding Table". When a routable packet arrives on an interface, the router hardware (ASIC) or forwarding software will consult the "Forwarding Table" to see where (over what interface) that packet must be forwarded.

In other words, even in traditional routers, there is a logical separation between the software that derives the Forwarding Table, and the software (or hardware ASIC) that uses the Forwarding Table.

Coming now to controller based architectures: here the idea is that we move the derivation of the Forwarding Table to a different physical device (the controller). The actual router is now left with the task of merely using the Forwarding Table that the controller sends it.