| 4 | | Open vSwitch (OVS) acts as a Layer 2 device when it's not connected to its controller (and its `fail-safe-mode` is set to standalone [default]). If we want to do Layer 3 control, we need to write the control logic in its controller. However, sometimes we want to Layer 3 control while there is other Layer 3 control. For example, we want to do firewall or NAT while there is IP routing managed by XORP or Kernel Static Routing. A straightforward solution is to write your own IP forwarding logic in your controller (Yeah, practice of writing your own XORP is fun!). This is really violating the reusability principle of software engineering. Another solution is to cross your finger and hope there is someone has written it for the controller framework you use. |
| | 4 | == What is the problem? == |
| | 5 | Sometimes it is desirable to have a box which provides a custom network function (e.g. firewall, NAT, etc) using a custom OpenFlow controller. However we want the box to also provide default routing behaviour. |
| | 6 | |
| | 7 | There are several approaches to solving this problem: |
| | 8 | * A straightforward solution is to write your own IP forwarding logic in your controller. While implementing your own IP routing would be fun, it is time consuming and violates the reusability principle of software engineering. |
| | 9 | * Another solution is to hope someone has written an OpenFlow router as part of the controller framework you use. But this limits your choices of controller frameworks. |
| | 10 | * Finally, you could combine OVS software switches with an existing routing implementation (provided by the kernel, XORP, etc) in the same box. |
| | 11 | |
| | 12 | |
| | 13 | This page explains how to do the last of these options as shown in the figure. That is, it will allow us to make a custom firewall or NAT while IP routing is managed by XORP or Kernel Static Routing. |
