AN-004 Deploying aggregators on IBM Cloud¶
IBM Cloud can be used to deploy aggregators using either their “Bare Metal Server” or “Virtual Server” compute services. The managed mesh private WAN mode is ideal for facilitating transit between bonds in a space, regardless of which region their respective aggregators are in.
In addition, IBM Cloud offers two forms of secondary subnets that can be used for connected IPs, CPE NAT IPs, or routes:
Static: IP addresses are available to the resource identified as the routing endpoint.
Portable: IP addresses are available to all resources on a VLAN.
Static subnets are routed to the specified resource (i.e., an aggregator), and then will be further routed through the tunnel to the bond. However, since the routing is statically defined, aggregator failover will not be effective.
Portal subnets can be used by any resource on a VLAN which, when combined with the proxy ARP setting on an aggregator, allows failover to work within a specified IBM Cloud VLAN. For aggregator failover to be effective with proxy ARP, you must assign all primary/secondary aggregators to be in the same VLAN in IBM Cloud.
Provisioning aggregators¶
Provisioning an aggregator in IBM Cloud follows the standard deployment process for aggregators. For system requirements, see this page.
When selecting the image, use the latest supported version of Debian (see supported operating systems for nodes). Once the device is provisioned, log in via SSH and follow the guide to installing bonding on an existing Debian host.
Private WAN¶
Managed mesh¶
The Managed mesh mode is easiest to implement, since it automatically detects which aggregators have bonds in a space and sets up VXLANs between them.
To configure this, just select the Managed mesh mode on the space’s Private WAN tab. At this point, private WAN bonds should have connectivity.
Optional: Add direct VXLAN peering¶
We can provide a more direct path between the aggregators by adding custom VXLANs to the involved aggregators within the IBM Cloud VPC. This may only be necessary if you are passing large amounts of private WAN traffic between aggregators.
A unique VNI should be created for each space. Each VXLAN for the space should use that assigned VNI. Failure to do so will result in broken routing or unexpected cross routing.
Also, choose a unique subnet within the private WAN to assign to the VXLAN interfaces. Each aggregator will need a unique address in the subnet.
For the routing protocol, we will use Babel. OSPF will also work, but Babel is a more modern protocol that is better suited to this kind of application and is simpler to implement.
Warning
To enable aggregators on separate VLANs to communicate over the private network, enable ‘VLAN Spanning’ in your IBM Cloud dashboard, under the VLANs section.
On each aggregator, for each space, do the following:
Click the interfaces Add button:
Set Type to VXLAN
Set Interface name to something unique per space
Set Space to the desired space
Set the VNI to the unique VNI chosen for the space
Set the Ethernet interface to the private interface’s name, found in the Network details section of the device details in your IBM Cloud dashboard.
Click Add IP address and set a unique IP address in the subnet chosen for the space
For all other aggregators involved in the space, click Add endpoint and set the aggregator’s private IP address and the VNI chosen for the space
Click the protocols Add button:
Set the Name
Set Space to the desired space
Set Protocol to Babel
Click Add interface
Click Add interface pattern
Set Pattern 1 to the interface name chosen for the interface in the space
At this point, the VXLAN mesh will be brought up and the bonds will be able to route traffic over the mesh.