=====================================
Bonded Internet 2016.2 release notes
=====================================

August 8, 2016

We're pleased to announce the release of Bonded Internet 2016.2. This
version adds four major features:

-  Management of DHCP services for connected IPs—bonders can now offer
   DHCP and DNS services to networks behind the bonder. This makes it
   much easier to use the bonder as the only gateway for a office and no
   longer require an additional device acting as a dedicated DHCP
   server.
-  Default bonders issue a DHCP IP address to clients connected on eth0,
   making it much easier to access the default bonder web server to
   submit a node key. The user no longer needs to configure a static IP
   address on his or her workstation in order to access the web server.
-  Private WAN (PWAN) spaces can now use a gateway at a bonded site.
   This allows Internet traffic from branch offices to be routed to a
   gateway at the head office instead of using a gateway in the
   datacentre, making it easy to deploy PWAN in an organization that
   already has a central gateway at their head office.

-  PWAN space gateways, both in a datacentre and at a bonded site, can
   be used by bonds on aggregators in different routing groups. For
   example, if a customer has bonds on aggregators in a Vancouver
   datacentre and in a Montreal datacentre, and a gateway defined only
   in the Vancouver datacentre, the bonds at the Montreal datacentre
   will use the Vancouver gateway.

The diagram below demonstrates both PWAN improvements. The dashed blue
line represents Internet traffic from branch bonders traveling to the
head office bonder. From a branch bonder assigned to an aggregator in
the same routing group as the head office bonder, traffic simply goes
between the aggregators and the PWAN router on its way to the head
office gateway. From a branch bonder assigned to an aggregator in a
different routing group from the head office, the traffic goes through
its aggregator and PWAN router, over the Internet to the routing group
where the head office bonder is located, and then to the head office
gateway.

|image0|

The head office gateway can supply Internet access from a dedicated,
non-bonded Internet connection, or it can offer access via the bonder
from a connected IP that is excluded from the PWAN.

.. note::

    Due to the significant changes in PWAN in 2016.2, this version is not
    backwards-compatible with PWAN in 2016.1. If you use PWAN, you must
    upgrade all PWAN routers, aggregators, and bonders in PWAN spaces in one
    maintenance period. You cannot mix 2016.2 hosts with 2015.4 or 2016.1
    PWAN routers, aggregators, or bonders in PWAN spaces.

    You do not need to coordinate upgrades of aggregators that do not
    participate in PWAN (ie the pwan-aggregator package is not installed),
    or of bonders that are not in PWAN spaces. These can be upgraded 2016.2
    using normal practices—a 2016.2 aggregator will support a 2016.1 or
    earlier bonder.


Now, the details on 2016.2:

Private WAN
------------

Additions
^^^^^^^^^^

-  PWAN spaces can now use a gateway at a bonded site. This allows
   Internet traffic from branch offices to be routed to a gateway at the
   head office, instead of only using a gateway in the datacentre. No
   matter what type of gateway is used, or even if no gateway is
   configured, routes between bonders, aggregators, and PWAN routers are
   managed using BGP and the BIRD routing daemon. A default route is
   published in the internal BGP network when a gateway is configured.
   Since this BGP network is internal to Bonded Internet, no integration
   with other networks is necessary.
-  Space gateways, both in a datacentre and at a bonded site, can be
   used by bonds on aggregators in different routing groups. For
   example, if a customer has bonds on aggregators in a Vancouver
   datacentre and a Montreal datacentre, and a gateway defined only in
   the Vancouver datacentre, the bonds at the Montreal datacentre will
   use the Vancouver gateway. If the Montreal routing group had its own
   gateway, then of course bonds on aggregators in that routing group
   would use the Montreal gateway. Prior to 2016.2, each routing group
   needed its own gateway. If a gateway is defined at two or more
   routing groups, but some routing group has no gateway, then traffic
   from bonds in the routing group that has no gateway will be routed to
   one of the other routing groups; the destination routing group
   depends on routing metrics defined by the internal BGP network.

Changes
^^^^^^^^

-  All hosts supporting PWAN—PWAN routers, aggregators, and bonders in
   a PWAN space—must run 2016.2. PWAN 2016.2 is not compatible with
   PWAN in 2016.1. You must upgrade all relevant hosts in a single
   maintenance period.
-  Dynamic routing configuration requirements have changed; both
   ``redistribute connected`` and ``redistribute kernel`` must be
   specified in the routing protocol configuration in Quagga. This is
   normally only necessary when using NAT via PWAN router modes, not
   when using dedicated gateway modes. For more information, see
   `Configuring private WAN dynamic routing in
   Quagga <../private-wan/private-wan-with-private-wan-routers/quagga.html>`__.
-  Debian 6 is not supported for PWAN bonders. Prior to 2016.2, bonders
   didn't have any special function related to PWAN, but in 2016.2
   bonders do apply special configurations when they are in a PWAN
   space, and these configurations require Debian 7 or 8.

Fixes
^^^^^^

-  PWAN NAT rules for an IP address other than a gateway address work
   properly.

Bonding Node
-------------

Additions
^^^^^^^^^^

-  When enabled in the management application, bonders supervise DHCP
   and DNS servers for connected IPs. DHCP can be managed locally or can
   forward requests to one or more relay servers. DHCP and DNS is served
   by dnsmasq.
-  On a default bonder, DHCP addresses are assigned to clients connected
   to the eth0 inteface, eliminating the need to configure a static IP
   address on a client in order to access the bonder, although the
   static IP address method still works. All DNS requests are directed
   to the bonder's IP address, so a request for any HTTP page will
   result in the client's browser loading the bonder web page.
-  The core node service supervises the BIRD daemon when the bond is in
   a PWAN space.

Changes
^^^^^^^^

-  Routing tables have been completely redesigned, even on bonds and
   aggregators not in PWAN spaces. If your bonders or aggregators have
   customized routes or rules, please test your configurations before
   upgrading. If you have questions, please contact technical support.
-  The bonding package conflicts with the NetworkManager package. This
   fixes a provisioning issue occurring since July 2016 related to
   unreliability with Debian's HTTP mirrors.

Fixes
^^^^^^

-  When traffic is sent to a host in the network of one of a bond's
   legs, it is routed through the tunnel. Previously it was routed
   directly through the leg, resulting in triangular routing that would
   result in connection failures. This change allows connections to
   complete successfully.
-  When provisioning or updating a bonder, configuration files, keys,
   and certificates are written to disk in a more reliable way to avoid
   writing corrupt or empty files.
-  When a bonder's automatic source IP option is disabled, certain
   iptables rules are now updated properly so that bonders can continue
   to make DNS requests.
-  TCP proxy no longer becomes unresponsive while taking 100% of a CPU
   core after the connection between the bonder and aggregator is
   interrupted in certain circumstances.

Bonding Admin
--------------

Additions
^^^^^^^^^^

-  Options for managing DHCP servers are available in an "advanced" pane
   for each connected IP on the bond page.
-  Three new charts have been added to the System Charts page in the
   Administration section—a chart recording the time taken to run a
   worker job in the Huey service, and two charts monitoring OpenVPN
   server metrics.
-  There is an internal setting for the Debian mirror referenced in ISO
   files. This defaults to Debian's `httpredir
   service <http://httpredir.debian.org/>`__. To change this, please
   contact technical support.

Changes
^^^^^^^^

-  Provisioning ISOs boot with a Linux 4.5 kernel instead of the default
   Debian 8 Linux 3.16 kernel.
-  A new service queries InfluxDB data periodically to downsample it to
   the level used in week, month, and year charts. Previously this was
   handled internally in InfluxDB but it suffered from issues on high
   and medium load servers. The dedicated service eliminates this issue
   and provides future flexibility for this capability.
-  Certain limits are applied to InfluxDB queries, such as a limit on
   execution time.
-  When a password reset is requested for an email that does not have a
   registered account, a error message is shown. Previously no notice
   was given if the email was not found.
-  Logs are persisted in the systemd journal rather than being removed
   after about one day.
-  A variety of changes have been made to the collectd service to make
   it more reliable.

Fixes
^^^^^^

-  Various exceptions in the web application and other services are now
   handled properly, especially related to managing PWAN gateway and NAT
   options and bond options.
-  HTML templates and CSS files are served in a way that prevents
   versions cached by a browser from being used improperly. It also
   speeds up rendering of web pages.
-  Metrics on the space statistics page are accurate again.
-  The user that triggers a speed test by using the "repeat" button is
   logged properly. Previously tests executed this way were recorded as
   being triggered by the system.
-  Configuration updates no longer fail to execute in a certain
   circumstance.


.. |image0| image:: /attachments/12320845/12320851.png
