Adding and updating aggregators

Adding an aggregator

Before installing Bonding on an aggregator, create its configuration in the web interface.

From the aggregator list click Add aggregator.

image0

Provide the following information.

Standard options

Name

A brief description of the aggregator. This must be unique in the aggregator’s space.

IP

The IPv4 address that bonders should use to contact the aggregator.

Warning

Do not also add this address as an interface address on the aggregator through the management server or it will conflict with the primary IP and gateway defined in /etc/network/interfaces and prevent the aggregator from coming back online after bonding is restarted. If it conflicts with an interface address in an aggregator’s networking configuration, that aggregator will not come back online if bonding is restarted.

See the errata section of the 6.5 release notes.

IPv6

The IPv6 address that bonders should use to contact the aggregator. An IPv4 address is required even if an IPv6 address is configured.

Warning

Changing the configured address (for either IP version) requires a matching manual configuration change on the node. Consult changing a host IP address before changing any configured IP address on an aggregator.

Routing group

The routing group to which the aggregator is assigned.

Serial number

The serial number of the aggregator hardware.

Asset tag

The asset tag given to the aggregator hardware.

Space

The space to which the aggregator is assigned.

Failover monitoring

Enable or disable monitoring for aggregator failures. If enabled, the management server will reassign the aggregator’s bonds to their secondary aggregators in the event of an aggregator failure or outage. Defaults for the related settings below are configured from the Administration page.

Failover interval

The number of seconds between each check sent from the management server to the aggregator.

Failover receive timeout

The number of seconds to wait to receive a response from the aggregator.

Failover failure threshold

How many sequential checks must fail before an aggregator is considered to have failed.

Failover recovery checks

How many sequential checks must succeed before an aggregator is considered to have recovered.

Failover max flap checks

The maximum number of checks that the flap damping technique will require the aggregator to respond to.

Username

Usually root, the user for management via SSH.

Password

The password for the user specified above.

Warning

The username and password fields are for record-keeping only. You should change them only if you manually change the management username or password on the aggregator.

Advanced options

The following fields are visible after you click “Show advanced”.

Proxy ARP

Enable this if you want the aggregator to proxy ARP requests for IP addresses assigned to bonders. This is useful in environments where standard routing using BGP or OSPF is not available.

Metric collection interval

How frequently to query performance metrics, in seconds.

Metric reporting interval

How frequently to report collected metrics to the management server, in seconds.

CPU governor

Select which algorithm to use for scaling CPU frequencies. If unset, the last used method for the CPU type will be used or the system default will be used after the system is rebooted. Selection of an alternate governor, particularly so Performance, may result in increased throughput on certain platforms. For a detailed explanation of each governor, see the documentation.

TCP congestion control algorithm

The TCP congestion control algorithm defines the behaviour of node sourced TCP connections. Currently, there are 14 different algorithms to choose from when configuring an aggregator on the management server. Prior to 6.4, CUBIC was the implicit choice. This option has no effect on traffic that is not originated on the aggregator itself.

  1. CUBIC
  2. BIC
  3. CDG
  4. Datacenter TCP
  5. Hamilton TCP
  6. Hybla
  7. Illinois
  8. Low priority
  9. Reno
  10. Scalable TCP
  11. Vegas
  12. Veno
  13. Westwood
  14. Yeah TCP
  15. BBR

For more information on this topic and the various algorithms refer to https://en.wikipedia.org/wiki/TCP_congestion_control

Depending on the type of traffic going over a bond, it’s possible that a different algorithm could decrease performance, while others might improve it. This is most noticable when running speed tests.

Conntrack table size

The maximum number of connections the host can track in its internal tables. If the number of tracked connections reaches this number, new connections will be dropped and an entry made in the system log file.

Web server

If checked, the aggregator will offer a simple web service to local networks and trusted remote networks.

Note

As of 2013.6, the web service on the aggregator doesn’t actually do anything. Its functionality may be expanded in future versions of Bonded Internet.

Debug

If checked, services running on the aggregator log events in much more detail than normal. Debug mode is not recommended except on the recommendation of a technical support agent.

TCP segmentation offloading

If checked, enables TCP segmentation offloading (TSO) for private WAN backhaul. Disabling TSO is necessary on some platforms that suffer severe performance degradation when the backhaul is encrypted.

When the form is complete, click Save.

Updating an aggregator

To update an aggregator, navigate to its details page and click Edit.

image1

Change the necessary fields, then click Save.

Removing an aggregator

To remove an aggregator, follow these steps:

  1. Assign its bonds to other aggregators.
  2. Shut down the aggregator operating system.
  3. Navigate to its details page and click delete button. image2
  4. Confirm your action on the dialog that appears.