Simplifying transit router deployment in Open Virtual Network

Today, Open Virtual Network (OVN) provides transit routers using standard logical routers with specific configuration. However, the introduction of the transit router (TR) component to the OVN Interconnect simplifies their deployment and configuration.

Introduction

Transit routers allow users to connect and configure routing across independent OVN deployments, also known as availability zones (AZs). Currently, adding a transit router to a deployment requires users to manually manage logical router and logical router port tunnel keys across multiple AZs. This process is tedious and error-prone as the number of AZs increases. 

With the introduction of TRs to OVN Interconnect, you can configure routers and router ports on multiple AZs without manually adding network components or managing tunnel keys for each zone.

OVN interconnect integration

OVN Interconnect is an OVN feature that connects multiple OVN deployments. It uses two global databases shared across all AZs and a daemon for each zone. When an AZ enables the OVN-IC daemon and configures the IC-NB and IC-SB databases, the transit router and transit router ports entries in IC-NB serve as the source of truth for creating the corresponding logical routers and ports. Each OVN-IC daemon creates logical routers in its AZ and synchronizes its configuration (for example, tunnel keys, MAC addresses, and IP addresses). OVN Interconnect manages tunnel keys for transit devices, which it allocates from a dedicated global pool to avoid clashes with existing keys across all AZs.

The following diagram (Figure 1) illustrates the steps to add a transit router using the ovn-ic-nbctl command-line tool: 

1. First, a new transit router entry is created in the Transit router table of the IC-NB database using ovn-ic-nbctl.
2. The OVN-IC daemon in each AZ monitors IC-NB for updates.
3. When the OVN-IC daemon sees the new entry, it competes with other daemons to create a datapath entry in the IC-SB using a tunnel key from the global pool.
4. Once the IC-SB datapath entry is available, the local OVN-IC daemon creates a logical router is created per AZ and configures it to use the tunnel key provided in IC-SB.

Transit router ports are added in a similar fashion with one caveat: TR ports have an assigned chassis when created and remain local to the AZ where that chassis resides. In Figure 2, a TR port assigned to Chassis 1 in AZ 1 creates a port of type patch in AZ 1 and remote in AZ 2.

Summary

The introduction of TRs and TR ports to OVN Interconnect reduces the configuration required for each zone, which simplifies deployments and lowers the risk of errors.

Feedback welcome    

Please share your questions or suggestions for this feature on the OVS/OVN mailing list. I would love to hear your feedback.

Additional resources

• Transit router - The distributed router for OVN interconnect.
• OVN Interconnect
• Using OVN interconnect for scaling OVN kubernetes deployments