Unicycle OVS-DPDK Validation Servers

Verification was based on a Build Server VM and four identical Dell 740XD servers for the Regional Controller and three Unicycle nodes.

Unicycle OVS-DPDK Validation Networking

The diagram below shows an example physical and L2 connectivity, the IP subnet plan, host and iDRAC addressing scheme similar to that used in the validation.

The Unicycle deployment does not configure the networking subsystem thus the choice of switch subsystem components is not restricted to those shown and they can be replaced with devices offering equivalent functionality.

Unicycle OVS-DPDK Validation IP/VLAN Plan

Below is an example of a detailed network and IP address plan similar to that used during validation.

Unicycle OVS-DPDK BGP Plan

The three unicycle nodes automatically peer with an external fabric BGP speaker using eBGP. The calico nodes do not peer using an internal iBGP mesh. Below is and example similar to that used in the validation.

In addition to the eBGP approach, limited validation was also performed using a full iBGP mesh between calico nodes without the need for an external BGP router. To change the deployment to BGP peer in this manner follow the notes shown in the example yaml file Example Configuration Input File - Unicycle Pods with OVS-DPDK Dataplane on Dell 740XD Servers.

Unicycle OVS-DPDK LAG Details

The RC and Unicycle genesis nodes boot via VLAN tagged 'host' interface which is pre-provisioned on the QFX switches with LAG bonding. Since booting occurs before the linux kernel can bring up its LAC-P signalling the QFX switches must be configured to pass traffic on their primary (first) link before the LAG bundle is up.

Note the Unicycle [master2] and unicycle [master3] nodes do not boot over the 'host' network but rather over the edge site 'pxe' network which is a single link to each unicycle server and thus not lag bonded.