...
Unicycle masters and workers (all Unicycle nodes other than Genesis) , are configured by the Redfish API calls issued by the RC to make DHCP Requests on the edge site's local 'pxe' network's L2 broadcast domain. The Genesis node's MaaS acts as the DHCP server.
Unicycle masters and workers (all Unicycle nodes other than Genesis) are configured then provisioned by the MaaS server running on the Genesis node to PXE boot over the remote site's 'pxe' network.
The Unicycle DHCP/HTTP PXE/PXE process flow is summarized below .(omitting the Redfish API calls):
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Network name | Subnet size | Needs to be externally routable**? | Function |
|---|---|---|---|
| 'oob' | Any* | No | Provides the connectivity between the Build server and RC and then RC and Rover/Unicycle nodes for Redfish API calls to configure/interogate the servers' BIOS. |
| 'host' | Any* | Yes | Provides the edge site's isolated network for MaaS provisioning (MaaS runs on the genesis node once provisioned). It does not need to be routable to any other network. |
| 'pxe' | /24 fixed in R1 | No | Provides a remote site's L2 local network for MaaS provisioning. |
| 'ksn' | /24 fixed in R1 | No | Provides the connectivity and BGP route exchange for the calico network. |
| 'storage' | /24 fixed in R1 | No | Provides the openstack storage network |
| 'neutron' | /24 fixed in R1 | No | Provides the openstack neutron network |
| 'datapath' | Defined in openstack | No *** | Provides the openstack datapath network for the SR-IOV variant VMs |
| 'vxlan' | /24 fixed in R1 | No**** | Provides the openstack storage network for the OVS-DPDK variant VMs |
Notes:
* The 'oob' network may be split in to multiple subnets if required. Each server except the Build Server (and the RC if built on a VM) requires an iDRAC/iLO address which must be manually pre-provisioned into the server.
...
In case of Unicycle calico is used as the kubernetes CNI thus pods routing information is exchanged via BGP between all controller and worker nodes.
Two architectural options exist to implement the route exchange for calico pods
...
(2) Using the more traditional full iBGP mesh between all calico pods
Validation has been primarily performed using the external fabric router approach. However limited validation has also been performed using the internal iBGP calico mesh.
In this the first case the external fabric router need needs to eBGP peer with all calico pods. To do this dynamic BGP peering is defined in the fabric router to accept BGP connection requests from any BGP speaker with an IP address from the calico 'ksn' network.
The site specific input yaml files documented in the Unicycle Deployment section of the release 1 documentation contain examples from the validations lab deployments of the the BGP related information required to force the calico pods to peer using eBGP such as own ASN and the external ASN of the fabric BGP router.
The Akraino/Airship deployment process configures the Unicycle pod's BGP configuration of the calico nodes. Modification of the Unicycle site specific input file fields allows the user to implement either the first or second BGP architectural option and in case of the first option the values of the external eBGP peer and its ASN.