SDN using OVN and OVS (Part 2)

In Part 2 of this series I want to briefly focus on some of the physical aspects of preparing for an OVN/OVS implementation that I feel need better discussion and background information. The aim here being to understand why decisions are being taken, not just be told that they are.

To aid some of this discussion here's a diagram of my setup so that I can walk through some of the concepts below.

To Provide, or to Manage, this is the question

Separation of your Management and Provider networks is crucial for a robust SDN implementation. Ensuring that your virtualisation hosts are part of a well-defined Management network helps maintain security and control, especially when it comes to accessing update repositories and allowing admin connections.

The distinction between the Management network and the Provider network is important because they serve different purposes. The Management network, should be tightly controlled and protected, terminating at a firewall to manage and secure traffic. This network is essential for the operational aspects of your virtualisation hosts and other critical servers.

On the other hand, the Provider network acts as the underlay for your SDN, facilitating the tunnelling of VM traffic and routing IP traffic. Keeping these networks separate helps in managing and securing each type of traffic according to its specific needs.

Separating these requirements is a solid strategy, however each engineer might need to adapt this to their own context. This kind of planning can significantly enhance the efficiency and security of your network infrastructure.

Connecting Openvswitch

Open vSwitch (OVS) should, under normal circumstances connect to physical networks, especially within OVN environments. Here are some key points to consider:

1. OVS Bridge Interfaces: These are central to connecting OVS to physical networks. Unlike traditional network configurations managed by tools like Netplan or Wicked, OVS bridges are managed using the ovs-vsctl command.
2. Configuration Options:
   • Direct Physical Port Slaving: Attach a physical port directly to the OVS bridge.
   • Bond Interfaces: Create a bond interface in your network configuration tool and assign it to the OVS bridge, or define a bond directly in OVS and add ports.
   • Multiple Ports with STP: Add multiple ports to the bridge and enable Spanning Tree Protocol (STP), though this is more experimental.
3. Management Considerations: The approach you choose depends on how you plan to manage your environment and who will be responsible for it. Most options are valid, with the exception of STP, which might be less commonly used.
4. OVN Environment:
   • br-int Bridge: This integration bridge is automatically created and managed by ovn-controller and is not directly bound to physical interfaces.
   • Uplink Bridge: To connect virtual network overlays to the physical network, you will create a second OVS bridge and attach physical interfaces to it.

Wrapping up

Hopefully, that provides a clear overview of the key physical aspects of the design you need to consider before deploying OVN/OVS. In later parts of the series, we'll delve into the details of building connectivity natively using OVN/OVS, rather than relying on wrappers like LXD and microovn.

This should help you deploy a working environment that you thoroughly understand, including the design choices involved.